Storm-2561 and GlassWorm Reveal Why Credential Theft Has Replaced Network Intrusion

Enterprise attackers in early 2026 stopped trying to break through perimeters — they started walking in through stolen session tokens. Two simultaneous campaigns show exactly how that works, and why the gap between “we have MFA” and “we are actually protected” is wider than most vendor security programs acknowledge.

In mid-January 2026, Microsoft Defender Experts identified a sustained credential theft campaign tracked as Storm-2561. The group — active since May 2025 — distributed trojanized versions of enterprise VPN clients, including spoofed installers for Cisco Secure Client, Fortinet VPN, Check Point Remote Access VPN, and Ivanti Pulse Secure. The distribution mechanism was SEO poisoning: employees searching for VPN software encountered results pointing to convincing spoofed sites, which served malware-laden ZIP files containing digitally signed trojans. Once installed, the malware harvested VPN credentials and session tokens, then displayed a realistic error message and directed the user to the legitimate vendor site — leaving no visible evidence of compromise. Microsoft publicly disclosed the campaign on March 12, 2026, after tracking it for nearly ten months.

Storm-2561 was not the only campaign targeting credentials through developer tooling in the same window. Beginning in January 2026, security researchers discovered GlassWorm: at least 72 malicious extensions injected into the Open VSX Registry — the extension marketplace used by VS Code forks including Cursor, Eclipse Theia, and Gitpod. By early March, the campaign had accumulated over 9 million installs of malicious packages and infected 151 GitHub repositories between March 3 and March 9 alone. GlassWorm’s approach was technically precise: rather than embedding malware directly in extension code, the threat actor used invisible Unicode characters to encode loader payloads — content that rendered as blank space in editors and terminals but decoded to scripts that extracted tokens, credentials, and repository secrets. Neither Storm-2561 nor GlassWorm required exploiting a vulnerability in a target’s production infrastructure. Both relied on users doing something routine — downloading software they use every day.

The Cloudflare 2026 Threat Intelligence Report, published in early March and drawing on telemetry across approximately 20% of global web traffic, provided the statistical context for this pattern. Across Cloudflare’s network, 94% of all login attempts were executed by bots using credential stuffing, brute force, and stolen password lists. Among human-initiated login attempts, 46% used credentials already compromised in prior breaches. Cloudflare’s central finding: attackers have largely stopped hacking in. They log in.

“94% of all login attempts observed across Cloudflare’s network are executed by bots — and among human-initiated logins, 46% use credentials already compromised in prior breaches.”

— Cloudflare 2026 Threat Intelligence Report

Enterprise security teams have begun updating vendor risk programs to reflect this specific threat model. SOC 2 assessments increasingly scrutinize session lifecycle controls — particularly token expiry policies, detection of concurrent sessions from anomalous locations, and how developer credential stores are protected from access by third-party tooling. Vendor security questionnaires from financial services and healthcare buyers now explicitly ask whether a SaaS vendor enforces zero-exclusion MFA policies — meaning no accounts are exempt, including service accounts and shared admin accounts — and whether the vendor has controls capable of detecting session replay. The question has shifted from “do you use MFA?” to “what is your response plan if MFA is rendered irrelevant?”

For a SaaS company working toward enterprise security readiness, the specific control gap these campaigns expose is session management. Early-stage compliance programs typically deploy MFA and document it — which satisfies a surface-level check. What they rarely address is what happens after authentication: session tokens with multi-hour or multi-day expiry windows, no concurrent session limiting, no geographic anomaly detection, and no distinction in session controls between production access and developer tooling. Both Storm-2561 and GlassWorm extracted value precisely from that gap — not from failing to authenticate, but from what remained accessible after authentication succeeded.

Being prepared on session management means having documented, testable controls rather than general policy statements. A complete posture includes defined token lifetimes by account type, documented conditions for automatic session revocation, and a process for flagging anomalous concurrent sessions. For companies where engineers use third-party IDEs, extensions, or VS Code-compatible tooling, the security program should explicitly address developer credential exposure — including secrets management, repository scanning for exposed tokens, and a policy on approved extension sources. Assessors asking about this in 2026 are not looking for a specific product; they are looking for evidence that the company has thought through the full credential lifecycle, not just the login event.

Microsoft Security Blog — Storm-2561 Uses SEO Poisoning to Distribute Fake VPN Clients for Credential Theft · The Hacker News — GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers · Cloudflare — 2026 Threat Intelligence Report: Nation-State Actors and Cybercriminals Shift from ‘Breaking In’ to ‘Logging In’ · The Register — Credential-stealing crew spoofs Ivanti, Fortinet, Cisco VPNs