New ClickLock macOS Stealer Kills Apps Every 210ms Until Victims Type Their Password

A new macOS infostealer, ClickLock Stealer, is actively targeting users by forcing them to repeatedly enter their passwords through a loop of killing apps. The malware, a copy of GSocket, uses a deceptive Cloudflare CAPTCHA to lure victims, and then relentlessly kills Finder, Dock, and other system processes until a password is provided. 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.

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. 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.

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. 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 browser, osascriptspawning 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.

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 Hacker News has asked Group-IB for the macOS version breakdown behind those targets and will update this story with any response.