ACR Stealer Attacks: Why ClickFix Now Targets Browser Tokens and Microsoft 365 Files

ACR Stealer attacks became a same-day security story today after BleepingComputer reported that Microsoft is seeing a surge in intrusions stealing browser-stored passwords, authentication tokens, and sensitive enterprise documents. That combination matters because it gives attackers more than a compromised endpoint. It gives them a way to turn one user mistake into cloud access, live session abuse, and quiet document theft.

The delivery method is what makes this story especially useful. According to Microsoft's July 16 security analysis, the campaigns rely on ClickFix lures that convince users to paste and run commands, then branch into WebDAV, PowerShell, MSHTA, Python loaders, and even steganography-assisted payload delivery. There is no exotic zero-day doing the heavy lifting here. The breach path starts when a person executes the wrong command in the wrong moment.

Key Takeaway: The dangerous part of ACR Stealer is not only that it steals passwords. It steals live session material and cloud-linked files, which means a single ClickFix success can outlive a simple password reset.

Why ACR Stealer attacks matter right now

This campaign lands in a part of the stack that many teams still under-protect. Security programs often emphasize phishing-resistant login, patching, and privileged access review, but they still leave too much trust in the user workstation after sign-in.

That trust is exactly what this malware exploits. If a browser already holds active sessions, saved credentials, and access to synced business files, then the endpoint becomes a shortcut to:

• cloud account takeover
• SaaS session hijacking
• document exfiltration
• follow-on phishing or business email compromise
• quiet internal reconnaissance through synced folders

That is why this story belongs beside Hexon's earlier posts on Microsoft 365 AiTM phishing, browser extension security at work, business email security for small teams, and password manager and MFA rollout. Different delivery path, same operational problem: once attackers get access to trusted browser or identity state, the real damage can continue after the initial click.

Key Stat: Microsoft says the activity it reviewed ran across customer environments from late April to mid-June 2026, with two delivery chains showing up often enough to treat them as representative of the threat.

How the ClickFix chain actually works

The useful part of this story is not the malware name. It is the intrusion logic. ACR Stealer does not need to break a software patch boundary if it can convince a user to do the execution step for it.

Chain 1: WebDAV, rundll32, and a disguised updater path

In one common delivery chain, the victim is pushed by a ClickFix lure to run a command that pulls a malicious DLL from a remote WebDAV share and launches it with rundll32.exe. Microsoft says the paths are often dressed up with GUID-like directories and filenames that resemble normal resources so the activity looks less suspicious in passing.

From there, the operator uses heavily obfuscated PowerShell, a bundled Python runtime, scheduled-task persistence, timestomping, and process injection to keep the stealer running while reducing the obvious disk artifacts defenders like to hunt for. In some cases, Microsoft also observed the operators using blockchain-backed dead-drop resolution to change follow-on infrastructure without rebuilding the malware.

Chain 2: MSHTA, steganography, and fileless execution

The second path is even more uncomfortable because it reduces visible file evidence. A ClickFix lure launches MSHTA, fetches remote content, decodes another PowerShell stage, and then pulls a JPEG that hides the next payload inside image data.

That payload is extracted, decrypted, and executed in memory. The point is not novelty for novelty's sake. The point is to make an attack that began with a copied command look less like a traditional malware install and more like a blur of built-in tools and scripted activity.

Common Mistake: Teams still teach users to fear suspicious attachments but do not teach them to distrust 'copy this fix into Run, Terminal, or PowerShell' prompts. That gap is now large enough to drive enterprise credential theft through.

Why browser tokens and Microsoft 365 files are the real prize

A lot of defenders still instinctively rank password theft above everything else. That is outdated when browsers and sync clients hold so much post-login value.

According to the reporting, ACR Stealer goes after:

• saved browser passwords
• cookies and session tokens
• authentication artifacts decrypted through DPAPI
• PDFs and business documents
• files in Desktop and Downloads
• enterprise-synced OneDrive and SharePoint folders

That last group matters more than it may seem. A synced folder can quietly expose draft contracts, finance exports, HR records, customer lists, sales playbooks, and internal planning documents without the attacker needing to log into each SaaS app one by one.

Session tokens also complicate the usual response flow. If the attacker can reuse a live authenticated session, changing a password may not fully solve the problem until related sessions, browser state, and cloud tokens are revoked. This is the same reason Hexon has stressed recovery-path discipline in topics like help desk identity checks and account recovery security. Identity is not secure if the session layer stays trusted after compromise.

Pro Tip: If your incident runbook says 'reset the password' but does not also cover session revocation, token invalidation, browser cleanup, and synced-folder review, it is incomplete for modern stealer incidents.

What most teams still get wrong about ClickFix

The first mistake is treating ClickFix as a user-awareness footnote instead of an execution method. It is not just another social engineering trick. It is a practical way to get users to run living-off-the-land tools under their own context.

The second mistake is over-trusting built-in Windows utilities. When defenders see mshta.exe, rundll32.exe, PowerShell, or pythonw.exe, the right question is not whether the binary is signed. The right question is whether that binary should be doing this from this user, this path, and this parent process.

The third mistake is assuming anti-phishing controls are enough. ClickFix often arrives through fake verification prompts, malvertising, SEO-poisoned search results, or bogus troubleshooting steps that live outside the classic email attachment model. If your controls only focus on mail, you are leaving a wide open lane for browser-led social engineering.

This is also why the campaign feels so current. It blends user deception, legitimate tooling, cloud session abuse, and document theft into one compact path that many organizations would struggle to interrupt early.

What to change this week

You do not need a new malware family name in your SIEM before you act on the lessons here. The defensive changes are practical and should start with behavior, not branding.

1. Ban copied-command 'fixes' as a workflow

Users should never paste commands from websites, pop-ups, or troubleshooting prompts into Run, PowerShell, Command Prompt, or Terminal unless the source is validated and the action is part of a managed support process. Make that policy plain and memorable.

2. Hunt for abnormal WebDAV and MSHTA activity

Look for rare or first-time use of:

• mshta.exe
• rundll32.exe launching remote content
• pushd mapping remote WebDAV paths
• PowerShell spawning from browser-related or HTA-related chains
• unexpected pythonw.exe execution from temp-like directories

For many organizations, these signals will be more durable than any specific file hash.

3. Reduce browser and sync-client blast radius

Review which teams truly need password storage in browsers, how long sessions persist, and what data is routinely mirrored into synced OneDrive or SharePoint directories on endpoints. Convenience settings that look harmless at scale can become high-value loot stores during a stealer incident.

4. Tighten application control around user-writeable paths

Microsoft explicitly recommends reducing exposure to content launched from remote resources and user-writeable locations. If endpoints can freely run HTA, PowerShell, Python, or DLL-based content fetched from dubious paths, you are making the operator's job too easy.

5. Update the response playbook for token theft

When you suspect a stealer, do more than rotate passwords. Revoke active sessions, review consented apps, inspect cloud sign-in history, check recent document access, and assume that synchronized local folders may already have been staged for exfiltration.

Key Takeaway: Modern stealer response is not endpoint cleanup plus password reset. It is endpoint cleanup plus identity containment plus document-exposure review.

Final takeaway

The operational lesson from ACR Stealer attacks is straightforward. The user's browser is now part password vault, part session broker, and part document cache for the business. When ClickFix gets a user to execute one malicious command, attackers can cash in on all three at once.

That means the real fix is not 'be more careful online' as a vague cultural message. It is building controls and habits that assume copied commands, trusted browser state, and synced cloud files are all attack surfaces worth defending directly.