SURIQ
Your patch program cannot see the attack Microsoft spent the spring watching. ACR Stealer, an information stealer the company says surged from late April to mid-June, does not exploit a single vulnerability. It asks the user to run it. Once a victim pastes an attacker's command into the Windows Run box, the malware inherits everything that person is already signed in to: their browser passwords, their live session tokens, their Microsoft 365 files. There is nothing to patch, which is exactly why it works.
A stealer that exploits nothing
ACR Stealer, also sold as AcridRain and rebranded as Amatera in June 2025, has been offered on Russian-language forums since 2024 for between $199 and $1,499 a year. It is malware for rent. Microsoft's Defender Experts team reported the recent surge, and the delivery is ClickFix: a fake CAPTCHA or, increasingly, a fake AI-tool page that tells the visitor to copy a line and press Enter. We argued recently that ClickFix has become shared delivery infrastructure and the lure is the wrong thing to detect. This campaign is the proof. Both The Hacker News and BleepingComputer make the same point about the two infection chains Microsoft documented: neither one touches a bug. They ride the access the signed-in user already has.
One chain is fileless, driven by mshta.exe pulling a remote script. The other fetches a DLL from a WebDAV share with rundll32.exe. Both end in the same theft. Here is the sequence, and the host behavior that gives each step away.
| Attacker step | How it runs | What to hunt for |
|---|---|---|
| The lure | Fake CAPTCHA or fake AI-tool page tells the user to paste a command | A command run straight from the Windows Run dialog |
| First execution | mshta.exe or rundll32.exe pulls a payload from a WebDAV share or image host | rundll32.exe with no command line making a network connection |
| Unpacking | PowerShell and a Python loader decode a payload hidden in a JPEG, in memory | Scripting engines launching from Temp or AppData; PowerShell history wiped |
| Theft | DPAPI decrypts the Chrome and Edge login database; session tokens copied | Non-browser process reading the browser Login Data and cookie files |
| Reach | Collects PDFs, Microsoft 365 files, and synced OneDrive and SharePoint content | A scheduled task named like a software update; outbound to image hosts |
How do you detect a stealer that patches nothing?
You detect it by behavior, not by indicator. The reliable signals sit on the host: a command launched from the Windows Run dialog, rundll32.exe running with no command line and opening a network connection, scripting engines executing from Temp or AppData, and a process that is not a browser reading Chrome's login database. None of those depend on knowing today's malicious domain.
This is the work of threat hunting against process telemetry rather than chasing indicators. Microsoft's own advice is to stop mshta.exe, rundll32.exe, PowerShell, and Python from running content pulled into user-writeable paths, and to block low-reputation domains. The Run-dialog origin is the cleanest tell, because almost nothing legitimate starts a process that way.
One variant makes the case for behavioral detection on its own. Microsoft describes a loader that reads its next payload address from a public blockchain, a technique it names EtherHiding. Nobody can seize a smart contract, so any blocklist of ACR's servers goes stale fast. Indicators expire. The Run-dialog-to-rundll32 sequence does not.
The blast radius is your Microsoft 365 tenant
The endpoint is not the prize. ACR collects PDFs and Microsoft 365 documents from the desktop and downloads, then walks into folders synced from OneDrive and SharePoint. One compromised laptop becomes a route into cloud storage that a defender watching servers never sees leave. The data that walks out and the perimeter you guard sit in different places. We watched the same logic in Microsoft 365 Copilot abuse, and in the ClickLock coercion stealer that rode the same lure family: the account, not the machine, is the target.
Revoke the sessions first, then rotate passwords
This is the part incident responders get wrong. ACR steals live session tokens and cookies, not only saved passwords. A stolen session token is an already-authenticated pass, so resetting the password behind it changes nothing until the session itself is revoked. Most runbooks still lead with "reset the password," which leaves the attacker signed in.
We made this exact point about FortiBleed, where a password reset left the intruder's session alive, and about the Stealc and Amadey takedown, where seizing the malware did nothing for the passwords already stolen. The order is what matters. Revoke active sessions and refresh tokens at the identity provider, force everyone affected to sign in again, then rotate credentials. A password reset on its own feels like remediation while the session it was meant to kill stays valid.