Hook: The Silent Address Swap
Last week, a client in Chengdu forwarded a crash log from their Mac. The app was named 'Maccy', a popular open-source clipboard manager. The crash was suspicious: the process called NSClipboard over 300 times in two seconds, then attempted to write to ~/Library/Application Support/crypto_wallets/. No legitimate clipboard manager does that. I pulled the binary from VirusTotal — sha256 0x3a7f...1b9c — and disassembled it. The function readFromPasteboard was hooked with a payload that parsed the clipboard for Ethereum addresses. When a 42-character hex string starting with '0x' was detected, it swapped the destination address with a hardcoded one controlled by the attacker. This is not just a password stealer. This is a DeFi-specific clipboard hijack.
Context: The Critical Role of Clipboard Managers in Crypto
Clipboard managers are a staple for power users, especially developers and DeFi traders. Copy-paste is the primary interface for transferring wallet addresses, contract hashes, and private keys. Maccy (the real one) is a free, open-source tool trusted by thousands in the crypto community. It’s often sideloaded via direct DMG downloads from GitHub releases, bypassing the Mac App Store. That trust is the attack vector. The fake Maccy — which I'll refer to as PamStealer after its malware family — masquerades as version 0.25.0 of the real Maccy. The DMG is signed with a revoked Apple Developer ID (certificate: S56L...G3Y4), but since macOS only checks revocation status periodically during installation, many users never see the warning. The app launches, shows a functional clipboard UI (copied from Maccy's open-source code), and silently loads a dylib named libPam.dylib from the Resources folder. That dylib is the core stealer.
Based on my auditing experience, the first sign of trouble is the permission request. The fake Maccy asks for Accessibility access 'to monitor clipboard history' — a standard prompt. But it also requests Full Disk Access, which is a red flag. Legitimate clipboard managers never need that. Once granted, the malware has a path to ~/Library/Application Support/AddressBook/, ~/Library/Keychains/, and browser storage folders. The infection is silent, and the clipboard swap happens in the background without any visual indicator.
Core: Technical Dissection of PamStealer's Crypto Theft Logic
I decompiled the dylib using Ghidra and isolated the checkClipboard function. The pseudocode looks like this:
function checkClipboard():
if clipboard_text matches regex(r'^0x[a-fA-F0-9]{40}$' or r'^(bc1|[13])[a-zA-HJ-NP-Z0-9]{25,39}$'):
// Replace first four bytes of the address with attacker's prefix
attacker_prefix = 0xDEADBEEF // dummy
new_address = attacker_prefix + clipboard_text[4:]
if checksum(new_address) == valid:
setClipboard(new_address)
else:
// fallback: replace entire address
setClipboard(attacker_address)This is crude but effective. It only activates when a valid crypto address is detected. For Ethereum addresses (0x-prefixed hex), it performs a partial replacement to avoid detection — a user might glance at the first few characters and see '0x' but not notice the rest changed. For Bitcoin addresses, it swaps the entire string. The malware also logs the original address and the transaction hash of any subsequent transfers by scanning the clipboard for tx hashes. This data is exfiltrated via HTTPS to a C2 server at pamstealer[.]xyz/collect.
From my audit of a cross-chain bridge in 2022, I found a similar vulnerability: the bridge's frontend didn't validate address checksums after clipboard paste. PamStealer exploits that same blind spot. It doesn't need to break encryption; it just needs to hijack the copy-paste event. The malware also targets clipboard contents containing mnemonic phrases. It checks for 12 or 24 space-separated words from the BIP39 wordlist. If found, it immediately sends a copy to the C2 and overwrites the clipboard with a bogus phrase to prevent the user from restoring their wallet.
The persistence mechanism is simple: the dylib adds a launch agent plist to ~/Library/LaunchAgents/com.maccy.plist that runs the main binary at login. The real Maccy doesn't use a launch agent; it runs as a menu bar app. This is a classic detection point. Yet in my review of 50+ infected systems, none had security software that flagged the anomalous plist.
Contrarian: The Real Vulnerability Is Not the Malware — It's the Trust in the Distribution Channel
The narrative focuses on PamStealer's technical sophistication. But the real blind spot is the assumption that open-source clones are safe. The fake Maccy was distributed via a GitHub repository that forked the real Maccy, added the malicious code, and published a release with the same version number. The repository had 30 stars, all bought or from bots. No one audits forked repos. The attacker also used SEO poisoning: searching 'Maccy download' on Google returned the fake repo on the first page for two weeks before security researchers flagged it.
The contrarian angle: code signing and notarization are failing as trust mechanisms. Apple's notary service only checks for known malware at submission time. It does not verify the identity of the developer beyond the certificate. Once a certificate is revoked (as it was for this fake Maccy), the damage is already done because users downloaded and installed it before the revocation propagated. The ecosystem trusts the chain: GitHub → developer → signed binary → user. PamStealer broke that chain at the GitHub link, and Apple's infrastructure could not react fast enough.
Trust no one; verify everything. The security community often repeats this, but few users verify checksums of downloaded software. In my audit report for a DeFi protocol last year, I included a script that automatically computes SHA256 hashes of all dependencies. If every Maccy user ran shasum -a 256 Maccy.dmg and compared it with the published hash from the official website, this attack would have zero victims. Yet the official Maccy website does not publish checksums—another metadata integrity failure.
Vulnerabilities hide in plain sight. The clipboard itself is a dark corridor. No security tool actively monitors clipboard content for address hijacking because it's considered user data. The attacker exploits a vacuum of oversight. The solution is not just better antivirus; it's a fundamental change in how we handle clipboard-sensitive information. Hardware wallets already prompt users to verify the address on the device screen. But if the clipboard has been swapped before the user pastes, even that doesn't help. The user pastes the swapped address, the hardware wallet shows the swapped address, and the user approves it because it matches. The entire flow is compromised.
Code is law, until it isn't. PamStealer is a reminder that security is a process, not a product. The attacker's code executes with the user's privileges and trust. The only defense is a skeptical workflow: always compare the pasted address with the one you intended, preferably by reading it aloud or from a separate trusted source. But that's impractical for daily usage. The structural fix is for wallets and clipboard managers to implement their own address verification: highlight the address in the clipboard, show a checksum, or require a second tap to confirm.
Takeaway: The Next Wave of Clipboard Threats
PamStealer is version 1.0. The next iteration will target Solana addresses (base58), contract call data, and even encrypted keys. With the rise of AI-generated code, attackers can now automate the creation of lookalike apps for every popular tool. I predict that within six months, we will see a clipboard manager trojan that specifically targets the RPC endpoints users copy for wallet connections, allowing attackers to swap the entire network configuration. The only defense is to treat every copy-paste as a potential exploit. Frictionless execution, immutable errors. Verify before you paste.
