Credential-stealing malware sold as a subscription service is getting a professional makeover. Microsoft’s threat research team disclosed on July 16, 2026 that ACR Stealer, a malware-as-a-service (MaaS) infostealer tied to the rebranding of Amatera Stealer, is now running two distinct intrusion chains that combine social engineering, steganography, and blockchain-based command infrastructure to steal browser credentials and enterprise documents.
What Microsoft found
Between late April and mid-June 2026, Microsoft observed the campaigns across customer environments, according to the company’s security blog post co-authored by Microsoft Security Research and Balaji Venkatesh S. Both chains start the same way: a ClickFix-style prompt, delivered through malvertising or search-result poisoning, tells the victim to run a command to “verify” themselves or fix a supposed problem. That single click is the entire authentication bypass. There is no software vulnerability to patch here; the exploit is the user’s trust in a fake support instruction.
From that starting point, the two chains diverge in how they hide the next stage. The first uses a WebDAV share dressed up with legitimacy-mimicking file and folder names to deliver a DLL, which in turn drops a Python-based loader disguised inside a folder named to resemble legitimate software. Persistence is set through a scheduled task masquerading as a routine update check. A subset of this variant resolves its command-and-control address through blockchain RPC endpoints, a dead-drop technique that makes takedown harder because there is no single server to seize.
The second chain skips the file drop almost entirely. It fetches a JPEG from an image-hosting service and extracts a payload hidden inside the image’s pixel data, a classic steganography technique that lets the malware blend into what looks like ordinary web traffic. Everything from that point runs in memory: the payload is decrypted, decompressed, and executed without ever touching disk in a form a file-based antivirus scan would recognize.
What it means for the security leader
Both chains converge on the same objective: browser-stored passwords, session cookies, and authentication tokens, pulled via Windows’ DPAPI decryption process, plus PDFs and Microsoft 365 or OneDrive/SharePoint-synced documents sitting on the endpoint. Microsoft’s post is blunt about the consequence: “Successful compromise can expose browser credentials, session tokens, authentication artifacts, and sensitive enterprise data, potentially enabling account compromise.”
That framing matters for CISOs because it reroutes the conversation away from patch management and toward identity. A stolen session cookie can walk straight past multi-factor authentication if it is replayed before it expires, and a MaaS operation like ACR Stealer exists precisely to commoditize that theft at scale, renting the tooling to whoever can run a convincing lure. The Amatera Stealer lineage Microsoft cites suggests the underlying developer group is iterating specifically on evasion, not just distribution, which is the same trajectory security teams have watched across other infostealer families for the past two years.
The absence of victim-count or sector data in Microsoft’s disclosure is itself a signal worth noting: this is an active-monitoring advisory, not a post-mortem on a contained incident. Security teams should treat it as a live detection problem, not historical reading.
The target list is also a tell. Consumer-grade infostealers historically chased browser passwords and crypto wallets. Microsoft’s write-up lists PDFs, Microsoft 365 documents, and OneDrive- and SharePoint-synchronized files alongside browser credentials in both intrusion chains, which points to an operation calibrated for corporate endpoints rather than home users. Paired with a MaaS distribution model, that means the same tooling gets rented out to whatever buyer shows up, from commodity credential resellers to more targeted operators, with enterprise data as the deliberate objective rather than a byproduct.
It also raises the bar for what “stopping the download” actually protects. A stealer that runs its final payload entirely in memory, whether unpacked from a DLL or decoded out of a JPEG’s pixel data, never gives a file-scanning antivirus product a file to catch. That is precisely why Microsoft’s guidance leans so heavily on behavior-based detection and application control rather than signature updates: by the time there is a signature, the loader has already changed.
What to do about it
Microsoft’s recommendations center on catching the behavior rather than the file. Specific guidance from the post includes:
- Train users to recognize ClickFix-style prompts, fake verification checks, and “paste and run” instructions as malicious regardless of how official they look.
- Apply application control policies that block PowerShell, Python, mshta.exe, and rundll32.exe from executing out of user-writable directories.
- Hunt for scheduled tasks masquerading as software updates, along with timestomping and PowerShell history clearing, both of which point to an attacker covering tracks.
- Run endpoint detection and response in block mode with automated investigation enabled, and turn on cloud-delivered protection and behavior-based detections.
- Enforce PowerShell script block logging, module logging, and transcription, and enable tamper protection so malware cannot quietly weaken antivirus configuration.
None of this requires knowing which specific stealer variant hit a given machine. The chain Microsoft describes is built to look ordinary at every stage, from the “update check” scheduled task to the JPEG that is actually a payload container, which is exactly why detection has to focus on behavior patterns rather than signatures. For a deeper look at how infostealers are increasingly riding legitimate software supply chains rather than phishing alone, see CyberTech’s coverage of the jscrambler npm compromise, which used a compromised publishing credential to turn a trusted package into an infostealer delivery vector.
Source: Microsoft Security Blog
