Most macOS infostealer writeups follow a predictable arc: fake CAPTCHA, paste command, credentials gone. ClickLock Stealer, first documented by Group-IB in June 2026, adds a twist that should make any DFIR analyst sit up. The malware locks the victim out of their own desktop, killing every visible application at sub-second intervals until they type their password into a fake dialog. That alone turns this from a run-of-the-mill credential thief into a genuinely interesting detection case, and it is why this piece leans harder into the forensic and detection engineering side than the “another macOS stealer” news cycle usually warrants.

cover

In brief

  • ClickLock Stealer is a modular, Telegram-controlled macOS infostealer delivered via the ClickFix social engineering technique, uploaded to VirusTotal on June 9, 2026 with zero detections.
  • It combines credential phishing, Keychain extraction, cryptocurrency wallet theft, and a persistent GSocket backdoor into four separate payloads orchestrated by a single shell script.
  • Its defining trait is a “locker” behavior that kills Finder, Dock, Terminal, and Activity Monitor in a tight loop, forcing the user to enter credentials to regain control of the machine.
  • All four modules self-delete and apply timestamp forgery after execution, leaving a narrow and perishable forensic window.
  • At least 100 victims across 33 countries have been identified since May 2026, with more than half located in Europe.
  • Detection has to happen at the behavioral layer: process-kill loops, osascript dialog spawning, and security find-generic-password calls from shell scripts are the strongest signals available.

The kill chain, briefly

The attack starts the same way most ClickFix campaigns do: a fake Cloudflare or Claude-branded verification page convinces the victim to paste a command into Terminal, disguised as a CAPTCHA or disk-cleaning step. This is consistent with the broader wave of macOS ClickFix campaigns tracked over the past year, including the Atomic Stealer variants that later moved to Script Editor once Apple started warning users about Terminal pastes, a shift I covered here.

Once executed, the orchestrator script (script.sh) disables SIGINT, hides the cursor, and renders a fake Cloudflare progress bar as cover while it silently downloads four components in the background: a credential stealer (zsh.txt), a Keychain stealer (chromer.txt), a crypto-focused stealer (finderv2.jpg), and a GSocket-based backdoor installer (goyim). The crypto stealer and backdoor are piped directly into bash without touching disk, while the credential and Keychain modules are staged in a hidden directory at $HOME/.cacheb/ for later execution via LaunchAgents. If the victim humors the fake password prompt, the attack completes quietly in seconds. If they refuse, the malware installs persistence and waits for the next login to force the issue through the kill-loop.

The locker mechanism

This is the part that separates ClickLock from the AMOS and MacSync variants that dominate current macOS ClickFix traffic. Both the credential stealer and the Keychain stealer run a foreground loop that kills Finder, Dock, SystemUIServer, Spotlight, all major browsers, Terminal, and, notably, Activity Monitor, at intervals as tight as 200 milliseconds, specifically to prevent the victim from investigating or terminating the process. The credential-stealing loop is configured to persist for roughly 83 hours; the Keychain-stealing loop for nearly 35 days, until the flag file confirming successful extraction appears. In parallel, a separate background loop kills macOS NotificationCenter for approximately six hours, suppressing any Gatekeeper or security alert that might tip off the user.

The psychological design is worth dwelling on: the malware never tries to hide that something is happening. It just makes the fake password dialog the only usable thing on screen, a form of forced compliance dressed up as a technical glitch. As Infosecurity Magazine notes, this is a genuinely novel abuse of a platform that still requires neither admin rights nor an exploit to pull off.

What each module actually takes

Once the Keychain stealer obtains the Chrome Safe Storage AES key (by triggering a real security find-generic-password prompt and locking the desktop until it is approved), the attacker can decrypt every Chromium-stored credential offline, without ever touching the live browser session again. The full harvest is broad enough to be worth laying out plainly:

Module Target Exfiltration
Credential stealer (zsh.txt) macOS login password via fake osascript dialog, validated with dscl Telegram bot
Keychain stealer (chromer.txt) Chrome Safe Storage AES key via forced Keychain prompt Telegram bot
Crypto stealer (finderv2.jpg) 31 browser wallet extensions, 8 desktop wallets, 6 blockchain address formats, password managers Telegram bot, split if over 40 MB
GSocket backdoor (goyim) Persistent reverse shell disguised as iCloud sync gs-netcat relay over gsnc[.]eu:67

All exfiltration rides on the Telegram Bot API, which gives the attacker encrypted transport with no dedicated C2 infrastructure to stand up or take down. The crypto stealer is the most technically involved piece: it uses the plyvel Python library to decompress Snappy-compressed LevelDB blocks and reconstruct MetaMask-style encrypted vault objects, falling back to proximity-based regex matching across .ldb and .log files when plyvel is not available. That is a level of reverse engineering effort into individual wallet storage formats that suggests this is not an amateur operation, even if the shell scripting itself is unremarkable.

Forensic artifacts worth chasing

For anyone doing incident response on a suspected ClickLock infection, self-deletion and timestomping mean the live system won’t tell you much after the fact, so artifact hunting has to be deliberate. The most durable indicators are:

  • LaunchAgents: com.authirity.plist and com.chromer.plist in ~/Library/LaunchAgents/, both set to RunAtLoad, created by the credential and Keychain modules for persistence across reboots.
  • Hidden staging directory: ~/.cacheb/, containing the locally renamed zoom (credential stealer) and chromer (Keychain stealer) binaries, plus per-user log files like <username>-chrome-key.txt.
  • Timestomping pattern: every module copies its modification time from ~/Movies, a directory unlikely to have been touched recently. A file with a suspiciously exact timestamp match to ~/Movies metadata is itself an indicator.
  • iCloud masquerade: the GSocket backdoor installs to ~/Library/Application Support/iCloudsync, running under a process name spoofing SystemUIServerl, one character off from the legitimate SystemUIServer.
  • TCC grants: unexpected Full Disk Access permissions granted to Terminal.app, which the orchestrator actively walks the user through granting via System Settings.
  • Shell history and Telegram traffic: outbound TLS sessions to api.telegram.org immediately following bulk reads of browser profile directories are a strong correlation signal even after the payload deletes itself.

This pattern of self-cleaning malware that still leaves a persistence trail before it tidies up is exactly the kind of case where artefact-driven investigation matters, something I have written about in more general terms when going beneath NTFS, and the same discipline of chasing what survives cleanup applies just as well on macOS.

Detection rules and IOCs

Group-IB’s own recommendation is blunt: this sample had zero VirusTotal detections at discovery, so static signatures are not the answer here. Detection has to sit at the behavioral layer. A Sigma-style rule targeting the process-kill loop, one of the most distinctive and low-false-positive behaviors in the entire kill chain, looks like this:

title: Suspicious Rapid Process Termination Loop on macOS (ClickLock-style Locker)
status: experimental
logsource:
  category: process_creation
  product: macos
detection:
  selection:
    Image|endswith: '/killall'
  target_selection:
    CommandLine|contains:
      - 'Finder'
      - 'Dock'
      - 'SystemUIServer'
      - 'NotificationCenter'
      - 'Activity Monitor'
      - 'Terminal'
  timeframe: 5s
  condition: selection and target_selection | count(CommandLine) by ParentImage > 10
falsepositives:
  - None known; sustained sub-second killall loops targeting Activity Monitor and Terminal have no legitimate use case
level: high

A second rule should cover the forced Keychain access pattern, which is arguably the single most diagnostic behavior in the whole chain:

title: Keychain Credential Query from Non-Browser Shell Process
status: experimental
logsource:
  category: process_creation
  product: macos
detection:
  selection:
    Image|endswith: '/security'
    CommandLine|contains: 'find-generic-password'
  parent_filter:
    ParentImage|endswith:
      - '/bash'
      - '/zsh'
      - '/sh'
  condition: selection and parent_filter
falsepositives:
  - Legitimate administrative scripts querying Keychain directly, rare in standard user workflows
level: high

For network-layer detection, the current IOC set is small but should be treated as compromised infrastructure rather than dedicated C2, since the attacker is riding on hacked WordPress sites:

Domain Role
panalobet[.]ph Hosts credential stealer, Keychain stealer, crypto stealer, backdoor telemetry
store.grafsynergy[.]com Hosts GSocket backdoor payload
cottonbox[.]co[.]il Additional compromised WordPress host
api.telegram.org Exfiltration channel for all four modules
gsnc[.]eu:67 GSocket relay for persistent reverse shell

File hashes for the five known components (orchestrator, Keychain stealer, credential stealer, crypto stealer, GSocket backdoor) are published in Group-IB’s original report and should be loaded directly into EDR blocklists and YARA sweeps rather than retyped here, given how quickly infrastructure and hashes rotate on active ClickFix operations. Building that kind of rule set into something maintainable, rather than a one-off IOC dump, is the whole point of treating detection as a proper engineering discipline, which is the argument I made in more depth when writing about building a CI/CD pipeline for Sigma rules.

FAQ

What is ClickLock Stealer?

ClickLock Stealer is a modular macOS infostealer discovered by Group-IB in June 2026, distributed via ClickFix phishing pages, that locks the victim’s screen with a fake password dialog until credentials are entered.

How does ClickLock Stealer get onto a Mac?

Victims are lured to a fake CAPTCHA or verification page and instructed to paste a Terminal command, which downloads and executes the orchestrator script and its four payload modules.

What forensic artifacts does ClickLock Stealer leave behind?

LaunchAgents in ~/Library/LaunchAgents/, a hidden staging directory at ~/.cacheb/, timestomped files copied from ~/Movies metadata, shell history entries, and outbound connections to api.telegram.org.