Skip to content
Beveiligingsnieuws

ClickFix attacks: macOS stealer and wallet theft

ClickFix-aanvallen macOS

ClickFix attacks macOS continue to evolve. Researchers describe an infection chain that starts with an apparently harmless prompt: “paste this ClickFix command in Terminal”. Next, a loader runs that gathers system information, fetches the right payload, and ultimately steals data—from browser passwords to iCloud Keychain, plus stolen session information that may already be present in the cache.

The most striking part is how the malware handles cryptocurrency. Instead of only stealing what’s immediately reachable, the campaign includes a routine that can slowly “drain” crypto wallets to an attacker-controlled address. That shifts the threat picture toward persistence and long-term fund extraction.

How ClickFix attacks macOS reach victims

The core technique combines social engineering with execution on macOS. The attack uses a ClickFix-style scenario where a user is tricked into pasting a command into the Terminal app. Once the command runs, a Bash profiler/loader is started.

This first step does more than simply “run a script.” The malware collects detailed information about the host and uses it to choose the next stage: downloading a macOS payload that matches the victim’s processor architecture.

The Go-based stealer: what gets stolen?

After profiling and fetching the payload, the real stealer function kicks in. The described malware is Go-based and targets multiple sources of valuable login and account data.

  • Browser passwords stored in the browser.
  • Apple iCloud Keychain data, which can impact multiple credential types.
  • Cached credentials already present on the system.
  • Exfiltration to an external server managed by the attacker.

Exfiltration goes beyond just one browser. It combines login sources from different ecosystems, so a single successful infection can lead to multiple routes to account and session theft.

Privilege escalation via a fake “system error”

As with many macOS stealers, the attempt is also made to increase privileges. According to the description, this is done by tricking the victim into logging in with system credentials via a misleading prompt. The prompt is presented as an “unexpected system error”.

After obtaining the needed information, the malware also tries to repair damaged system components or roll them back to a state that should limit further suspicion. These recovery mechanisms are meant to keep the user from raising the alarm too quickly.

Wallet “DRAIN”: stealing crypto with a gradual approach

While typical stealers often focus on immediate theft, this variant includes a routine that affects cryptocurrency wallets. The “DRAIN” functionality checks whether a wallet contains funds. If it does, part or all of the amount is rerouted to a wallet controlled by the attacker.

In addition, there are multiple versions or variants of that function depending on the target cryptocurrency. In the provided information, this includes Bitcoin, Litecoin, Dogecoin, Monero, Ethereum, and XRP. Notably, the malware doesn’t just perform a generic action—it calculates what 1% of the wallet contents is worth in the relevant currency, and then uses that share (or more) for the draining.

Huntress describes this as a relatively new observation: not necessarily a completely new concept, but the first time it’s been seen in malware that can drain a wallet in a way that also undermines values that are fully “wallet-emptying,” through staged or calculated withdrawal.

Infection chain with Mach-O payloads and architecture matching

The attack uses a chain that fetches and executes payloads based on the machine’s characteristics. The loader maps host profiles to a suitable Mach-O payload, depending on the victim’s CPU architecture.

This makes the campaign less “fragile.” While some infections only work on one type of system, architecture matching increases the likelihood that the same lure can succeed across different Mac environments.

Hosting and command-and-control: reference to Aeza Group

For server-side staging of payloads and command-and-control (C2), the analysis points to infrastructure linked to Aeza Group, a bulletproof hosting provider that, according to the report, has been sanctioned by the US, the UK, and Australia for facilitating wrongdoing.

For defenders, this is relevant: it indicates where the technique comes together behind the scenes. It’s not only the client-side lure that matters—server-side behavior determines how long the campaign can run and how quickly new variants can be rolled out.

ClickFix activity: more variants and added evasions

The release fits into a broader set of ClickFix campaigns reported in recent weeks. Several patterns are mentioned, each adding another layer of camouflage:

  • A macOS campaign that spreads MacSync and Atomic Stealer, where the attack waits between delivering the lure via look-alike domains. In addition, server-side browser fingerprinting and hardware validation are used to serve only “appropriate” environments and to block crawlers, sandboxes, and some analysis tools.
  • A ClickFix variant on Windows that abuses a legitimate component: Program Compatibility Assistant (pcalua.exe). This deploys a launcher to bypass older-process detection. Next, using PowerShell and WMI among other things, a route is started to a remote WebDAV share with tokenized URLs.
  • A campaign aiming to bypass network-level detection using on-the-fly WebAssembly instantiation and steganography via SVG. This involves using compromised legitimate websites that execute injected JavaScript, build wasm modules, and ultimately assemble the ClickFix link in steps.

These examples show that ClickFix is not one fixed “malware.” It’s more of an approach: lure users into pasting + a chain that fetches in stages, matches the environment, and then attacks the target with additional evasions.

What you can do to prevent it

Even though the technique is technical by design, prevention starts with the behavior around Terminal and similar execution contexts. Consider these practical measures.

  • Don’t “paste commands into Terminal”. If someone asks you to copy and paste something into Terminal, treat it as a red flag—especially if the explanation is vague or rushed.
  • Use security monitoring that can flag suspicious script execution and payload downloads. Pay attention to chains that first profile and then fetch a payload.
  • Limit privileges and check whether account and authentication prompts appear at unexpected times.
  • Keep macOS and browsers up to date and review password storage where needed. This won’t stop everything, but it reduces attack effectiveness.

If you want to go deeper into related phishing/lure patterns, you can also look at earlier reporting on ClickFix-like environments and supply-chain-style contexts. For example: In Other News: AI, supply chain and ports under pressure for a broader threat overview, and CI workflows hacked via GitHub issues: fix this if you want to understand how attackers misuse chains to reach code execution.

Conclusion

ClickFix attacks macOS are more than “dropping in a stealer once.” The described chain shows how attackers first recognize a host, then pull credentials and iCloud Keychain data from different sources, and—against some targets—use the DRAIN function to slowly move crypto wallets toward the attacker. That makes the threat not only technical, but also strategic: the goal is continuity in fund theft, not just quick data exfiltration.

By treating Terminal paste-actions critically, limiting privileges, and detecting suspicious execution and download patterns, you reduce the chance that a ClickFix lure ever works in your environment.

Source: https://thehackernews.com/2026/08/clickfix-attacks-deliver-macos-stealer.html