ClickFix and ACR Stealer: the fake CAPTCHA that steals Microsoft 365 tokens and files

For years, security awareness has leaned on a simple idea: don't open suspicious attachments and don't download files from senders you don't know. ClickFix turns that advice on its head. There is no attachment, no download and, in many cases, not even a file for antivirus to analyse. It is the user who copies a command and runs it by hand, convinced they are clearing a routine verification step.

On 16 July 2026, Microsoft's Defender Experts team published its analysis of two ACR Stealer campaigns that began exactly like this: a fake CAPTCHA asking the user to “prove you're human”. The prize was not a stolen password but something far more useful — browser passwords, session cookies, authentication tokens and Microsoft 365 files synchronised through OneDrive and SharePoint. For an organisation, that haul is the equivalent of leaving the front door open with the keys still in the lock.

ClickFix: from novelty to the second most common initial access vector

ClickFix is a social engineering technique first documented by Proofpoint in early 2024. The mechanics never change: a web page displays a fake error message or a CAPTCHA-style check and, to “fix it” or “confirm you're not a robot”, asks the user to paste and run a command. In its H1 2025 threat report, ESET recorded a rise of more than 500% in these attacks and ranked the technique as the second most common initial access vector, behind only conventional phishing.

The jump is no accident. ClickFix solves the problem that gives attackers the biggest headache: getting past email defences and isolated analysis environments. With no attachment and no automatic download, there is nothing for an email gateway to block and no sandbox to detonate. A person performs the execution, by hand, on their own machine.

Anatomy of the trick: the user as the executor

We break down the full catalogue of lures —a Cloudflare-style fake CAPTCHA, simulated Word or Chrome errors, a fake blue screen— in our complete ClickFix defence guide. Here the focus is the most recent outcome and its conceptual mechanics, without turning it into a manual: the pattern strings together four conditions:

1. A believable lure. A compromised or spoofed site shows a CAPTCHA or a verification notice that mimics Google or Cloudflare. In July 2026 Malwarebytes documented fake verification pages for both services distributing several malware families.
2. A tampered clipboard. When the user clicks the “verify” button, the page silently places a command onto their clipboard.
3. An instruction disguised as a formality. The person is asked to open the Windows Run dialog and paste what they believe is a routine part of the check.
4. A legitimate execution. The system treats that command as an action by the user themselves, with their privileges and without any download warning.

The trace it leaves is precisely what matters to the defender: there is a record of that manual execution, of the processes launched next and of the network connections that open. That is where ClickFix is caught — not in the mailbox.

ACR Stealer: what it actually takes

In the two campaigns Microsoft described, observed between late April and mid-June 2026, the payload was ACR Stealer, an information stealer built for browser credentials and corporate data. Both chains shared the same opening move — the ClickFix trick — but diverged in how they delivered the payload and evaded detection.

Once inside, the goal is not just the password. According to The Hacker News's write-up of these campaigns, ACR Stealer harvests passwords saved in Chromium-based browsers, session cookies, authentication tokens, documents, PDFs and data synchronised through OneDrive and SharePoint. With the cookies and session tokens, an attacker can replay an already authenticated session and operate as the legitimate user without ever going back through sign-in.

Why the session token matters more than the password

This is the point many organisations have yet to internalise. Multi-factor authentication protects the moment of sign-in, but not the session that follows it. When an attacker steals a valid cookie or token, they need neither the password nor the second factor: they present the session that was already issued and the service accepts it as genuine. It is the same outcome we saw with AiTM token theft campaigns and with device code phishing, reached by different entry paths.

That is why ClickFix is so profitable against Microsoft 365 estates: it doesn't attack the password, it attacks the session. And a stolen session rarely triggers the alerts that an anomalous sign-in from another country would.

Why traditional controls fail

Three common assumptions break at once. First, “the gateway filters email”: there is no malicious attachment or download link to filter, because the user reaches the site through a search, an advert or a seemingly harmless link. Second, “the sandbox would detonate it”: there is no file to detonate, since the execution is manual. Third, “MFA has us covered”: token theft sidesteps MFA entirely.

The upshot is that the first line of defence is no longer the perimeter but the endpoint and identity telemetry. The question is no longer “how do I stop it arriving”, but “how do I see the execution when it happens and invalidate the session before it is any use to anyone”.

Operational detection

Several telemetry sources, combined, give an intrusion of this kind away:

• Windows Run history. The RunMRU registry key (under HKCU) keeps what has been launched from the Run box. Microsoft notes that in these campaigns it held traces of rundll32, pushd and WebDAV connections.
• PowerShell logging. Script block logging, module logging and transcription give real visibility of what ran — provided the telemetry is retained and someone actually reviews it.
• Process behaviour in the EDR. A browser or a user process that spawns powershell.exe, mshta.exe or rundll32.exe, followed by outbound WebDAV connections, is an anomalous chain that a well-tuned EDR will flag.

A simple hunting query in Microsoft Defender starts from that parent-child relationship between the browser and the command interpreter:

DeviceProcessEvents | where InitiatingProcessFileName in~ ('chrome.exe','msedge.exe','firefox.exe') | where FileName in~ ('powershell.exe','mshta.exe','rundll32.exe') | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine

It is a starting point for threat hunting, not a production-ready rule: it must be tuned to each organisation's legitimate tooling to keep false positives down.

Practical defence

The measures that genuinely change the equation fall into three areas.

Shrink the execution surface

Restricting access to the Run dialog by group policy for profiles that don't need it, enforcing PowerShell constrained language mode and enabling the attack surface reduction (ASR) rules that block obfuscated script execution and child-process creation from Office applications close off much of the path.

Protect the session, not just the sign-in

Token theft is neutralised by binding the session to the device. In Microsoft Entra, token protection and conditional access policies that require a compliant device make a stolen cookie far harder to use on another machine. It is also worth having a fast procedure to revoke sessions and rotate credentials at the first sign of trouble.

Close the loop with people

Awareness training has to move on. The message is no longer just “don't open attachments”, but “never paste or run a command you didn't write yourself, however official the page looks”. A legitimate CAPTCHA never asks you to open a terminal or the Run box.

What this means for NIS2 and DORA

For organisations in scope of NIS2, ClickFix touches two direct obligations: managing human risk through training and awareness, and reporting incidents within the required timeframes when an intrusion of this kind compromises essential data or systems. In financial services, DORA adds the requirement for operational resilience and for control over credential theft that could lead to fraud or service disruption. In both cases, being able to show endpoint detection and a response procedure is not an extra — it is part of compliance.

The essentials

ClickFix works because it exploits something no tool fully patches: the user's willingness to follow a step that looks routine. The good news for the defender is that, by moving execution to the endpoint, the attack leaves clear traces — in Run history, in PowerShell logs and in the process chain — that a monitored EDR and well-governed identity turn into early detection. The password stopped being the target some time ago; today it is the session. Defending accordingly is what separates a failed attempt from a real breach in Microsoft 365.

Hard2bit tip: if you want to test how your organisation would respond to an intrusion that starts with ClickFix, our threat hunting, managed SOC and incident response services cover everything from proactive hunting to containment. And if Microsoft 365 is the focus, Microsoft 365 security and an identity review are the first place to start.

This article is educational and defensive in nature. The references to tools, logs and detection queries are described conceptually to help security teams detect and mitigate the threat; they are not instructions for reproducing the attack.