Storm infostealer doesn't decrypt on your PC. That changes how you defend
Storm infostealer doesn't decrypt on your PC. That changes how you defend
For most of the last decade, infostealer malware has had a tell. To steal your saved passwords, it had to touch the browser's credential store on your machine — load the SQLite database, locate or unlock the encryption key, decrypt locally. Endpoint security products got very good at spotting exactly that sequence, which made local browser database access one of the most reliable malware detections in the industry.
A new infostealer called Storm, analysed by Varonis Threat Labs and reported by BleepingComputer, has abandoned that step entirely. Storm harvests encrypted browser data and ships it raw to the operator's own servers, decrypting everything there. On the victim's endpoint, the step that endpoint tools watch for simply never happens. For around US$900 a month — tiered from a US$300 seven-day demo up to a US$1,800 team licence with 100 seats — a criminal operator gets a stealer plus a panel that automates the next stage: replaying the victim's authenticated sessions.
This is a shift in the threat model that Australian organisations of every size need to understand, because the defensive assumptions most of us still hold were built for the old generation of stealers.
What Storm does
Per the Varonis analysis, Storm appeared on underground forums in early 2026 (forum account registered December 2025, current build v0.0.2.0, Windows-only, roughly 460 KB of C++). Its collection set is broad: saved passwords, session cookies, autofill data, Google account tokens, credit card data and browsing history from both Chromium and Gecko-based browsers (Firefox, Waterfox, Pale Moon), plus Telegram, Signal and Discord session data, crypto wallets via browser extensions and desktop apps, documents from user directories, system information and multi-monitor screenshots.
The architectural difference is where it decrypts. Previous stealers decrypted credentials on the victim's machine; the first wave of responses to Google's App-Bound Encryption in Chrome 127 involved injecting into Chrome or abusing its debugging protocol — techniques that still left forensic traces. Storm skips the whole problem by sending encrypted files to attacker infrastructure and decrypting server-side. The BleepingComputer write-up notes that even the cryptography work is off the victim's device, which removes the telemetry most endpoint tools depend on for detection.
Then comes the part that matters for defenders. Storm's panel automates session hijacking: feed in a stolen Google refresh token and a geographically matched SOCKS5 proxy, and the panel silently restores the victim's authenticated session — no password, no MFA prompt, no alert. Varonis's researchers observed a logs panel with 1,715 entries spanning multiple countries, with credentials tagged to Google, Facebook, Coinbase, Binance and other services, ready for filtering and prioritised exploitation.
Infrastructure-wise, operators connect their own VPS to Storm's central servers, so takedown pressure lands on the operator's node first. Domain-detection rules auto-label stolen credentials by service. Builds keep harvesting even after a subscription lapses.
Why your MFA is not the wall you think it is
Session hijacking is not new. What is new is its industrialisation. Varonis documented the underlying technique in their Cookie-Bite research, showing how stolen Microsoft Entra ID session cookies render MFA irrelevant and give attackers persistent Microsoft 365 access without ever touching a password. Their SessionShark analysis showed phishing kits intercepting session tokens in real time to defeat MFA at login. Storm's contribution is to make the same technique a checkbox in a subscription panel.
This is the uncomfortable part for defenders: the security boundary we teach users to protect — the password, hardened with MFA — is no longer what is being stolen. The session is. An authenticated cookie jar exfiltrated from a staff laptop is equivalent to a logged-in user, and it will behave like a logged-in user from the attacker's proxy until the session expires or is revoked. Australia's Have You Been Hacked and ASD guidance has long urged passphrases and MFA, and that advice remains correct — but it is now necessary, not sufficient.
What actually defends against this
No single control stops a chain like this; Varonis's own conclusion is that defence-in-depth is mandatory. Here is the realistic stack, roughly in order of leverage:
1. Phishing-resistant, tokenless authentication where it counts. If attackers cannot get a replayable bearer token for your critical systems, session theft loses most of its value. Hardware-backed FIDO2/WebAuthn credentials bind the login to the physical key and the origin, so a stolen cookie replay from a foreign proxy cannot mint new sessions the way a password-plus-OTP can. For administrators, finance staff, and anyone with access to customer data, a hardware FIDO2 security key is currently the most durable counter to exactly this class of theft — and it is one of the few controls that works even when the endpoint is already compromised.
2. Short session lifetimes and conditional access. Where you control the identity provider, cut session and refresh-token lifetimes for privileged roles, require device compliance for token issuance, and enable token binding/protection features where your platform supports them. A session that dies in hours is a much smaller asset than one that lives for weeks. Revoke sessions on suspicion; it is free.
3. Behavioural detection beats credential detection. Storm removes the endpoint telemetry that signature-based detection relied on, which moves the detection burden to what the account does: impossible-travel logins, logins from hosting providers and SOCKS5 exits, access patterns outside the user's norm, and mailbox rules nobody set up. For an Australian SMB without a SOC, even a lightweight identity-protection add-on in your M365 or Google Workspace tenant will flag geo- and ASN-anomalous logins that a purely endpoint-focused stack will miss.
4. Reduce the harvest. The value of a stolen browser profile scales with what is in it. Keep crypto wallets off general-purpose work machines — the BleepingComputer/Varonis report shows Storm targeting wallet extensions and desktop apps directly, so any seed material worth protecting deserves storage that never touches a browser, such as a steel seed-phrase backup plate kept offline. Strip browser extensions you do not actively need, because every extension is both data and attack surface.
5. Firmware-level hygiene on the endpoints themselves. Session cookies are exfiltrated by software that had to be installed — through a malicious download, a malvertising lure, or a compromised peripheral. Lock down the device layer: block unknown boot media, and on shared or high-risk machines consider hardware microphone and data-line blocking, such as a USB-C microphone and data blocker for devices used in sensitive conversations, to shrink what a compromised endpoint can offer a stealer in the first place.
6. Incident response that assumes the session was taken. If a user clicks something and the endpoint is suspect, the response is not "reset the password". It is: revoke all sessions and refresh tokens, check OAuth app grants and mailbox rules, review recent logins by ASN and location, then rotate. An SSD-sized blast radius from one stolen cookie is entirely avoidable if revocation happens first.
The bottom line
Storm is one product among several moving in the same direction — server-side decryption, session-first theft, subscription panels that automate replay. The market is telling defenders plainly what the target is: not your password, but your logged-in state. Organisations that treat authentication tokens as crown-jewel data — short-lived, hardware-bound, closely watched — will find that products like Storm have much less to sell. Everyone else is defending the last war.
(General security information for defenders; not legal advice. Report incidents to ASD via cyber.gov.au.)