Paste Once, Lose Everything: What ClickLock Teaches About Trusting Your Own Terminal

7/21/2026

The most dangerous sentence in computing right now is "paste this command into your Terminal to continue."

A newly-documented macOS stealer called ClickLock (analysed by Group-IB, and now rippling across the security press) is the clearest illustration yet of why. It steals crypto wallets, browser passwords, and Keychain secrets from Mac users. And it does so without a single exploit, without elevated privileges, without a zero-day. The entire attack turns on one moment of misplaced trust: the user pasting a command they didn't write into a window they were taught to fear but never really understood.

I want to walk through it, because it's a near-perfect teaching case for a thing I keep coming back to on this blog: that the frontier of attacks isn't more sophisticated code, it's more sophisticated manipulation of the human in the loop.

The anatomy

It starts with a ClickFix page: one of those fake "verify you're human" or "fix this error" screens that instructs you to copy a command and run it in Terminal. This social-engineering pattern has exploded over the last year precisely because it outsources the hard part of an attack (getting code to execute) to the victim's own hands. You paste, you press return, you've run it. Gatekeeper never fires, because you chose to run it.

From there ClickLock pulls down four components from compromised WordPress sites and gets to work. Two modules go after credentials: one raids the macOS Keychain and Chrome, another throws up a fake password dialog. A third sweeps for over thirty cryptocurrency wallet extensions. A fourth installs a disguised reverse shell for persistence.

But the part that makes ClickLock notable rather than routine is what happens if you hesitate.

Coercion as a feature

Most stealers need you to cooperate exactly once and then they're quiet. ClickLock adds a mechanism I hadn't seen productised before: if you don't hand over your password, it makes your computer unusable until you do.

A background loop kills the macOS NotificationCenter process roughly every 210 milliseconds (several times a second) for up to six hours. This does two things at once. It suppresses every security notification and Gatekeeper prompt that might warn you something is wrong. And it degrades the machine into a flickering, broken state that a normal person will do almost anything to escape, including typing their password into the "helpful" dialog that claims it'll fix everything. Reboot, and persistence just restarts the loop.

That's not an exploit. That's coercion through denied usability. The malware doesn't defeat your security controls; it makes you want to defeat them yourself, quickly, just to make the pain stop. It's the digital equivalent of someone jamming your door lock so you'll hand over the key to anyone who offers to help.

Why this should reframe how you think about "sophisticated"

We're trained to equate attacker sophistication with technical depth: chained exploits, kernel bugs, novel cryptography. ClickLock has none of that. Its sophistication is entirely in the behavioural design: the fake-fix lure that makes you the executor, the notification-kill loop that removes your warnings and your patience, the fake dialog waiting to catch the password you'll eventually surrender.

This is the same lesson the lethal trifecta taught in the AI-agent world: that the decisive move is often getting a trusted actor (there, the agent; here, you) to take the harmful action on the attacker's behalf. The trust boundary that failed wasn't in the OS. It was the assumption that a user pasting a command into their own Terminal is a safe, deliberate act. For a huge number of people, Terminal is a black box they only ever open because a tutorial, or an attacker, told them to.

macOS users are especially exposed to this framing because the platform's whole security story ("the Mac protects you, Gatekeeper has your back") quietly teaches people that they don't have to be the last line of defence. ClickLock weaponises exactly that complacency. No exploit required when the target has been trained to trust the box.

What actually defends against it

Because there's no vulnerability to patch, the defences are behavioural and architectural, not a software update:

Treat "paste this into Terminal" as a threat indicator, full stop. Legitimate software effectively never asks a normal user to do this. Teach it the way you'd teach "no bank will ask for your PIN." For teams: this belongs in security awareness training this quarter, because ClickFix is now the dominant initial-access trick, not a fringe one.
Whatever you're about to paste, read it, and be suspicious of anything piping a remote script straight into a shell (curl … | bash and friends). If you can't read it, don't run it.
A machine behaving bizarrely is a signal, not an inconvenience. The instinct ClickLock exploits is "make the weird thing stop." The correct response to a Mac that suddenly won't behave is to disconnect it from the network and get help, not to type your password into whatever's asking.
Least privilege still helps on the back end: scoped, hardware-backed secrets and separate wallets limit the blast radius when credentials do leak. Coercion gets the password; segmentation limits what that password unlocks.

The bigger pattern

ClickLock is one instance of a category that's going to keep growing: attacks that skip the exploit and go straight for the person, using the operating system's own UI as the weapon. It's cheap, it's cross-platform in spirit, and it scales: 100+ victims across 33 countries in about two months, from a technique any competent operator can copy.

That category is exactly the gap I just closed on this site's Security Feeds page, which until this week tracked CVEs and IOCs but had no home for a CVE-less malware campaign like this one. There's now a Malware & News tier for precisely these stories, because "all things security" has to include the threats that never file for a CVE number.

The question ClickLock leaves me with, and the one worth carrying into your next security-awareness session: the last time an error message told you to paste a command to fix it, would you have pasted it? The whole attack lives in that half-second of "sure, why not."