SURIQ
Most infostealers are built to be quiet. They read what they can reach, ship it out, and leave the machine looking untouched so the theft surfaces weeks later, if at all. ClickLock does the opposite. It makes a Mac unusable on purpose, killing Finder, the Dock, Spotlight, the browser, and Activity Monitor every 210 milliseconds, and it keeps going until the person sitting there types their login password into a dialog that looks like the real one. Group-IB, the threat intelligence firm that documented the campaign, counted at least 100 infections across 33 countries since May 2026.
The coercion is the story. Stealing the macOS login password would normally mean reading it out of the Keychain, which is sealed by that same password. ClickLock skips the puzzle and takes the machine hostage until the user hands the password over directly. That trade, giving up stealth to guarantee the credential, is also the reason a defender can catch it: a process that kills your entire desktop five times a second is about as loud as macOS activity gets. It is a sharp turn from the quieter macOS stealers that lean on notarization to stay invisible.
How the lock works
Delivery is a ClickFix lure, the same social-engineering pattern now common on Windows. The victim lands on a page showing a fake Cloudflare verification, is told to paste a command into Terminal, and that command quietly pulls the stealer modules in the background. Group-IB noted the script hides the cursor and disables keyboard interrupts, so the download is hard to cancel once it starts.
Then the coercion begins. One background job, installed as a LaunchAgent, fires a kill loop every 210 milliseconds, and its targets are exactly the apps a worried person would open to fight back: Finder and the Dock, Spotlight, the browsers, and the recovery tools, Activity Monitor, Console, Terminal, and System Settings. Whatever you launch dies before it finishes drawing. The one window that survives is a password prompt carrying your real username and an Apple icon the malware downloaded. BleepingComputer put the loop's lifetime at 300,000 seconds, near 83 hours, or however long it takes to get a correct password. A slower loop, every 200 milliseconds for close to 35 days, keeps demanding Keychain access to reach the key that guards Chrome's saved logins.
What sells the prompt is the check behind it. According to The Hacker News, each guess is validated against dscl /Local/Default -authonly before anything leaves the machine, so a wrong password simply keeps the desktop frozen. Dismiss the dialog and the malware plants its persistence files, com.authirity.plist and com.chromer.plist, under ~/Library/LaunchAgents/ and bides its time. When a real password finally lands, the theft runs: saved logins, cookies, and form-fill data from eight browsers, then cryptocurrency wallets, password-manager vaults, FileZilla server logins, and the key that guards Chrome's Safe Storage.
The signal you already have
ClickLock is nearly invisible to signatures. Group-IB found the orchestrator script scored zero detections on VirusTotal when it was analyzed in June. So the answer is not a new signature, it is behavior. A few things happen here that almost never happen together on a healthy Mac, and each is observable without knowing anything about ClickLock specifically.
| Behavioral signal | Where it shows up | Why it fires |
|---|---|---|
| Password dialog in a loop | Process telemetry: osascript raising an auth prompt repeatedly | The malware validates each guess before exfiltrating |
| Desktop kill loop | Process launch and exit rate far above baseline | 210ms termination of Finder, Dock, Spotlight, browsers |
| New LaunchAgent file | File-integrity monitoring on ~/Library/LaunchAgents/ | com.authirity.plist and com.chromer.plist persistence |
| Telegram egress | Outbound DNS or connections to Telegram's bot API | Exfiltration channel for the stolen archive |
The strongest single tell is the pairing: a brand-new file appearing in ~/Library/LaunchAgents/ at the same moment a process starts raising osascript password dialogs in a loop. Neither is rare enough to alert on alone, but together they are close to a certain positive. This is what file-integrity monitoring on the LaunchAgents directory is for: it flags the persistence write even when the payload behind it is unknown. A managed detection service watching process behavior and egress catches the same event from the other side, before the 35-day Keychain loop ever succeeds.
The real choke point is upstream
The kill loop is memorable, but it is not where you stop this. The delivery is. ClickLock is the macOS sibling of the Windows ClickFix wave we wrote about earlier: same lure, same "paste this to prove you are human," a different persistence primitive once it lands. On Windows the payload hides in the registry or a scheduled task; on macOS it is a LaunchAgent. The payload keeps changing, but the human step does not. A curl piped into a shell, or an osascript process, spawned as a child of Terminal that traces back to a browser action is the control point that catches the whole family regardless of which stealer rides in this week.
That makes one piece of user guidance worth stating plainly: no legitimate website verification asks you to open Terminal and paste a command. Any page that does is trying to run code on your machine. Teaching that one rule shuts down the delivery stage for ClickLock and every other ClickFix payload at once.
Reset the password, then hunt the backdoor
If a Mac ran this, changing the login password is the obvious first step, but it is not the last one. Most of ClickLock's modules delete themselves after they run. One stays. A modified build of GSocket, an open-source tunneling tool, remains as a backdoor, digging into LaunchAgents, cron jobs, and shell startup files to hold a reverse shell open. The Hacker News put roughly 80 percent of that component's code as GSocket's own, and it phones a relay instead of a classic command server, which makes its traffic harder to pick out.
So the credential reset closes one door and leaves another open. A host that showed the kill-loop behavior needs a persistence hunt: inventory every file in ~/Library/LaunchAgents/, check cron and shell startup files for anything you did not put there, and treat the box as compromised until that comes back clean. Password rotation without the persistence sweep just resets the credential the attacker already has a second way to collect.