ClickLock Stealer, a new macOS infostealer, answers a victim’s refusal by killing their apps on a loop until they hand over the login password. It arrives as a command pasted into Terminal, asks for the password behind a fake system dialog, and when the victim cancels, installs two LaunchAgents and quietly exits.
At the next login, Finder, the Dock, Spotlight, Terminal, Activity Monitor, and the major browsers start dying every 210 milliseconds, for up to 83 hours, leaving one password box on a dead desktop. Type it, and the machine gives up the Keychain, the browser credentials, and the crypto wallets.
Group-IB’s telemetry counts at least 100 targets across 33 countries since May, over half of them in Europe. Its analysts assume from the code structure that the malware is still under development. Uploaded to VirusTotal on June 9, the orchestrator script had zero detections there when Group-IB analyzed it.
And the analysts never found the front door. They have the whole payload chain and not one of the lure pages. The IOC list carries three compromised payload hosts and no lure domain: the landing page design, the domains serving it, and whatever drives traffic to them are all unconfirmed.
A completed run leaves the operator holding the validated macOS login password, Chrome’s Safe Storage AES key, and a ZIP with browser credentials and cookies, crypto wallet extension storage, desktop wallet files, password manager vaults, the Keychain, shell history, and FileZilla’s saved server credentials.
The Safe Storage key is the one that lasts. It encrypts Chrome’s saved passwords and cookies on disk, so Login Data and Cookies are decrypted offline, on the attacker’s machine, whenever they get to it. Group-IB’s advice to anyone who ran this: revoke active browser sessions, treat every saved password, cookie, and wallet key as gone, and change them.
Comply now, or comply at next login
The refusing user is not an edge case. They are what the design is for. Cancel the first dialog, and the script drops com.authirity.plist and com.chromer.plist into ~/Library/LaunchAgents/, then leaves.
The first fires the 210-millisecond kill loop until a password lands. The second launches its own kill loop at 0.2-second intervals for up to 3,000,000 seconds, roughly 34.7 days, while a background process queries the Keychain for Chrome’s Safe Storage key every half second.
That query raises a real macOS prompt, and the loop holds the desktop hostage until the victim approves it. Activity Monitor and Terminal are on both kill lists. A third loop kills NotificationCenter for six hours, so no Gatekeeper warning renders. If Terminal lacks Full Disk Access, the orchestrator opens System Settings to the right pane and walks the victim through granting it.
The front end is ClickFix. Group-IB assesses that with high confidence and has never seen it. The script takes a RAY_ID as its first argument and opens with a fake Cloudflare CAPTCHA banner over a progress bar cycling twelve status lines in ten seconds. Neither does anything. They exist to reassure someone who has just pasted a command into a terminal.
Underneath, script.sh disables keyboard interrupts, hides the cursor, and pulls four payloads from two compromised sites. Two pipe straight into bash. Two land in a hidden $HOME/.cacheb/. The soft ask is an osascript dialog wearing a downloaded Apple icon and the victim’s real username, and whatever gets typed is checked against dscl /Local/Default -authonly first, so only a working password is worth sending.
Almost none of that is new. Microsoft documented the same dscl validation in SHub Stealer in May, alongside AMOS and MacSync in the same wave of macOS ClickFix campaigns. Telegram exfil and LaunchAgent persistence are boilerplate.
The backdoor, goyim, is roughly 80 percent a copy of the public deploy script for GSocket, an open-source tunneling toolkit from The Hacker’s Choice. Its authors pitch the gs-netcat component as an encrypted reverse backdoor that needs no C2 server of its own. It rides a relay instead.
Group-IB traced this copy to an operator relay at gsnc[.]eu:67, with the binary pulled from gsocket.io itself. The stealer payloads sit on three compromised domains with clean reputations, one of them a hacked WordPress site, and the haul leaves through three Telegram bots. Group-IB observed no dedicated command-and-control infrastructure.
On macOS, the binary lands as iCloud in ~/Library/Application Support/iCloudsync and the process runs as SystemUIServerl, one letter off the real one.
Apple already tried to shut this door
macOS 26.4 shipped in late March. It warns when Terminal sees suspicious paste activity and blocks outright anything it recognizes as known malware, a mitigation Microsoft points to as a direct answer to ClickFix delivery.
Apple’s own documentation shows how much room it left: the warning only fires if you do not regularly use Terminal, and it ships with a Paste Anyway button. The hard block needs macOS to already know the malware.
Two campaigns went through that room within weeks, in opposite directions. Jamf Threat Labs documented one in April that avoids the paste entirely, using an applescript:// URL to open Script Editor with the payload preloaded, so the check never fires. Jamf’s Thijs Xhaflaire wrote that “when one door closes, attackers find another.” ClickLock is the other. It kept the paste and engineered around the person instead.
The coercion loop is the one part with no cover story. Group-IB does not hedge on the sub-second pkill and killall bursts against Finder, Dock, SystemUIServer, and NotificationCenter: “this behavior is unique to forced-interaction malware and has no legitimate use case.”
The rest of the signal set:
security find-generic-passwordcalled from a shell script rather than a browserosascriptspawning password dialogs with icons pulled from/tmp/- Bulk reads of browser profile directories followed by traffic to
api.telegram.org - curl piped into bash where the URL ends in
.jpg,.txtor.css - LaunchAgent creation in
~/Library/LaunchAgents/by a shell process, paired withlaunchctl load
If a Mac starts killing its own apps and leaves a password box on screen, do not type the password. No verification page needs your Terminal. Cloudflare’s check runs in the browser, which is the entire point of it.
Group-IB says to hold the power button until the machine shuts down, then start up in Safe Mode, and its Shift-at-startup step is the Intel procedure only. On Apple silicon, hold the power button until “Loading startup options” appears, select the volume, then hold Shift and click Continue in Safe Mode.
Cleanup is uneven. The stealer modules unload their own LaunchAgents, forge their timestamps off ~/Movies to break timeline analysis, and delete themselves. goyim does not. Sit through the loop, type the password, watch the desktop come back, and what is left is a machine that looks fine with a reverse shell on it, running as SystemUIServerl out of ~/Library/Application Support/iCloudsync.
ClickLock’s operators launched in May, a month into the warning’s life, and built for the paste. Whether one of Group-IB’s targets ever saw it is the thing the report does not say.
The Hacker News has asked Group-IB for the macOS version breakdown behind those targets and will update this story with any response.
