Microsoft Disrupts YAM Store Network Behind 1 Billion Phishing Scams and M365 Device-Code Attacks

According to reporting from BleepingComputer, SecurityWeek, and CyberScoop, that torrent of digital fraud targeted consumers and more than 75,000 organizations across 150 countries. For Windows and enterprise IT administrators, the number that matters most is even more pointed: Microsoft stated that more than 750 million of those malicious email and SMS messages were aimed directly at Microsoft customers, with a heavy emphasis on Microsoft 365 environments and device-code phishing.

Rather than chasing individual spam senders one spoofed domain at a time, Microsoft’s Digital Crimes Unit (DCU), Health-ISAC, and law enforcement went after the wholesalers: an underground cloud-account and infrastructure bazaar known as YAM Store (tracked by Microsoft as Storm-3119) and the phishing-as-a-service (PhaaS) kits it supported, namely CoGUI, Haozi, and the Iron Man System (collectively tracked as Storm-2990).

The Anatomy of a Modern Phishing Supply Chain​

Gone are the days when a phishing campaign required a lone attacker to hand-code a clumsy HTML login page and blast it out from a single compromised web server. Today’s phishing ecosystem operates like a dark-web SaaS conglomerate, complete with upstream infrastructure brokers, containerized deployment pipelines, subscription licensing, and localized template libraries.

The investigation began when Microsoft and Japan’s NPA examined a wave of fraudulent activity and traced the connective tissue back to YAM Store. According to Microsoft’s findings as reported by BleepingComputer, YAM Store operated as a foundational supplier for cybercriminals, selling compromised or fraudulently registered Microsoft and Google cloud environments, user accounts, licenses, and cloud storage.

How YAM Store Built "Legitimate" Cloud Footprints​

To acquire cloud tenants and accounts that wouldn't immediately trip automated fraud sensors, YAM Store operators relied on two distinct identity-fabrication tactics:

• Digital Grave-Robbing: Operators purchased expired domains that previously belonged to real, defunct organizations. They then rebuilt the websites to make those dead businesses appear active and legitimate, using those resurrected corporate identities to register for cloud services.
• AI-Generated Front Companies: Where expired domains weren't used, operators turned to artificial intelligence tools to fabricate entirely fictional organizations from scratch, generating convincing corporate web content and supporting business documentation to pass verification checks.

Once inside compromised or fraudulently obtained Microsoft environments, the operators didn't just send mail. According to Microsoft, they abused stolen application credentials to programmatically manage accounts and licenses, and they commandeered SharePoint and OneDrive storage to host malicious phishing material on trusted Microsoft domains.

Section Summary: YAM Store (Storm-3119) acted as the logistics backbone for Storm-2990 phishing campaigns, supplying compromised and AI-fabricated Microsoft and Google cloud tenants, managing licenses via stolen application credentials, and abusing SharePoint and OneDrive to host lures.

From CoGUI to Iron Man: Inside the Storm-2990 Phishing Kits​

With the cloud accounts and hosting infrastructure supplied by YAM Store, buyers needed the actual traps. Microsoft linked the marketplace to three major phishing kits: CoGUI, Haozi, and the Iron Man System.

While CoGUI previously focused its fire on victims in the United States and Japan, Microsoft noted that the Iron Man System largely displaced it by mid-2026. To prevent security researchers and automated sandboxes from inspecting their pages, these kits came pre-packaged with geofencing, IP filtering, and fake CAPTCHA gates designed to verify that a visitor was a real human in the intended target region before rendering the login trap.

[YAM Store / Storm-3119]
   ├── Acquires expired domains & builds AI-generated fake companies
   ├── Obtains/compromises Microsoft & Google cloud environments
   └── Abuses SharePoint, OneDrive & stolen app credentials
          │
          ▼
[Storm-2990 PhaaS Kits: Iron Man, CoGUI, Haozi]
   ├── Deploys 2,360+ localized templates (Courier, Tax, Banking, M365)
   ├── Shields lures with Geofencing, IP filtering & fake CAPTCHAs
   └── Harvests payment cards & M365 authentication tokens (Device-Code Phishing)

Resecurity’s Deep Dive into the Iron Man System​

While Microsoft’s reporting highlights the macro-level volume of the ecosystem, threat intelligence firm Resecurity—which participated in the global operation—published a detailed technical teardown on October 14, 2026, after purchasing an Iron Man license, running version 6.3.1 of the kit inside an isolated laboratory environment, and examining the group's exposed upstream build infrastructure.

Resecurity’s lab analysis and unauthenticated review of the operators' self-hosted Gitea and container registry server revealed an operation run like a commercial software house:

It is worth noting—as Resecurity explicitly caveats in its report—that those template numbers reflect how many pre-built lure packages were available in the catalog, not confirmed successful breaches against those specific brands. Catalog growth spiked sharply in May 2026 with 322 new or updated templates in a single month, matching Microsoft’s observation that Iron Man overtook CoGUI around mid-2026.

Resecurity also uncovered a unique code-level quirk inside Iron Man's compiled binary (devops-super/internal/controller/remotegoods): a dedicated goods-catalog subsystem linked directly to payment-card capture. Victims weren't just asked for credit card numbers under the guise of an unpaid road toll or redelivery fee; the kit’s database schema captured SelectGoods, goods_name, and goods_price right alongside card_number, expiry_date, and verify_code, enabling promotional prize, loyalty-reward, or cashback lures that tricked users into "selecting" an item before handing over their financial details.

Most importantly for defenders, Resecurity’s packet captures revealed an architectural Achilles' heel: every deployed Iron Man panel polled its local license status roughly every 20 seconds, which in turn reached out to a centralized, vendor-controlled authorization backend (api2[.]peaceman[.]cc). Without regular contact with the vendor's licensing server, the admin panel cannot operate—giving law enforcement and industry partners a single pressure point to cripple buyer deployments en masse.

Section Summary: Resecurity’s analysis of Iron Man v6.3.1 revealed an actively maintained Go-based container pipeline with 911 builds, 2,360 templates across 130 regions, a built-in merchandise-selection card harvester, and a 20-second licensing heartbeat that created a central point of failure for takedown teams.

The Legal Hammer: What the Takedown Actually Removed​

To disrupt this sprawling network, Microsoft and Health-ISAC obtained a court order from the U.S. District Court for the Southern District of Florida. Armed with that legal authority and technical intelligence from Japan’s NPA, the Japan Cybercrime Control Center (JC3), Resecurity, Cloudflare, Oracle, Proofpoint, and TRM Labs, the coalition executed a multi-layered strike:

• Domain Seizures and Sinkholing: Microsoft and Health-ISAC seized and redirected core domains supporting YAM Store, CoGUI, and the Iron Man System.
• Mass Account Deactivations: Microsoft deactivated more than 20,000 accounts tied to YAM Store.
• Domain Blocking: Microsoft blocked 100,000 domains used by the ecosystem’s operators and buyers for brand impersonation and fraud.

While those numbers represent a massive disruption to the operators' supply chain and licensing backends, veteran sysadmins know better than to treat a court-ordered seizure as a permanent cure. Resecurity assessed the ecosystem's resilience to a single-point takedown as medium: while cutting off the licensing server and container registry disrupts live buyer panels immediately, the core operators remain unindicted, their real-world identities are unconfirmed, and they control multiple domain families behind content delivery networks (CDNs) that can be rotated. Furthermore, Microsoft noted on October 14 that additional infrastructure removal is still ongoing.

Section Summary: Under a Southern District of Florida court order, Microsoft, Health-ISAC, and global partners seized core marketplace and PhaaS domains, deactivated over 20,000 accounts, and blocked 100,000 fraudulent domains, though administrators must remain vigilant against operator rotation.

Why Device-Code Phishing Should Keep M365 Admins Awake​

Beyond the sheer volume of consumer SMS lures about unpaid tolls and stalled DHL packages, the enterprise story here is how Storm-2990 targeted Microsoft 365 users. Microsoft reported that out of the 750 million malicious messages aimed at its customer base, many relied on device-code phishing to steal authentication tokens.

If you have ever signed into a streaming app on a smart TV or authenticated a command-line tool on a headless server, you have used the OAuth 2.0 Device Authorization Grant flow. It works by giving the user a short alphanumeric code and directing them to a legitimate authentication URL (such as microsoft.com/devicelogin) on a separate browser or phone to enter the code and approve the sign-in.

Why do phishing operators love this flow?

• The URL is 100% Real: In a device-code phishing attack, the final page where the victim enters the code and completes multi-factor authentication (MFA) can be Microsoft’s genuine authentication portal. Email link scanners and suspicious-domain filters won't flag microsoft.com as malicious.
• No Browser Cookie Theft Required: Unlike Adversary-in-the-Middle (AiTM) reverse-proxy phishing, the attacker doesn't need to intercept session cookies in transit. The attacker initiates the device-code request on their own machine, tricks the victim into entering the resulting code via an urgent phishing lure, and Microsoft’s identity platform dutifully hands the resulting access and refresh tokens straight to the attacker's client.

Once an attacker holds a valid token, they often move immediately to establish persistence. As documented in Microsoft Security Research’s September 9, 2026 threat intelligence guidance on identity and cloud compromises, attackers who gain initial token access frequently register a new MFA method under their own control—such as a rogue authenticator app, software OTP token, or phone number—within minutes, followed by automated Microsoft Graph reconnaissance and bulk file harvesting from SharePoint Online, OneDrive for Business, and Exchange Online.

Actionable Hardening Guide for Windows and Entra ID Administrators​

Because takedowns disrupt infrastructure rather than erasing the underlying techniques, Microsoft 365 and Microsoft Entra ID administrators should use this operation as a catalyst to lock down authentication flows and audit tenant telemetry. Based on Microsoft Security Research’s established defensive guidance for device-code and cloud-identity abuse, here is what your security team should review today:

1. Block the Device-Code Authentication Flow via Conditional Access​

Unless your users have a specific, documented business requirement to sign into headless devices, smart TVs, or CLI tools using device codes, shut the door entirely.

• In the Microsoft Entra admin center, navigate to Protection > Conditional Access > Policies.
• Create or update a policy targeting All users (excluding your emergency break-glass accounts) and All cloud apps.
• Under Conditions > Authentication flows, configure the policy to match Device code flow (and Authentication transfer, if unused) and set the Grant control to Block access.

2. Enforce Phishing-Resistant MFA and Strict Registration Controls​

Standard push notifications and SMS codes will not save a user who willingly approves a session or enters a token into an AiTM proxy.

• Enforce phishing-resistant MFA—such as FIDO2 security keys, passkeys, or Windows Hello for Business—via Conditional Access Authentication Strengths, especially for privileged roles and access to Exchange, SharePoint, and Graph-privileged applications.
• Harden Security Info Registration: Require a managed, compliant device and/or trusted corporate network location before a user is allowed to register a new MFA factor or passkey. Set the sign-in frequency for security registration to require a fresh interactive authentication, and block security info registration whenever sign-in risk is elevated.

3. Restrict Unmanaged Devices and Application Consent​

Because YAM Store operators routinely abused stolen application credentials and SharePoint/OneDrive storage:

• Configure Conditional Access to require managed, compliant devices for full access to SharePoint Online, OneDrive, and Exchange Online, restricting unmanaged personal devices (where SMS phishing links are most commonly clicked) to limited web-only sessions without file download or sync rights.
• Restrict user consent for OAuth applications in Entra ID, require administrator approval, and audit existing service principals holding high-privilege Microsoft Graph permissions such as Mail.Read, Files.Read.All, and Directory.Read.All.

4. Hunt for Post-Compromise Persistence and Graph Enumeration​

Do not rely solely on static IP or domain blocklists; as Resecurity noted, Iron Man’s infrastructure sits behind rotating CDN proxies (peaceman[.]cc, peaceloving[.]xyz, haoeryu[.]top, aidchildren[.]cc, and loveboy[.]xyz). Instead, hunt for behavioral chains across your logs:

• Audit New MFA Registrations: Check CloudAppEvents and Entra audit logs for users who registered a new phone number, software OTP token, or authenticator app shortly after an unusual or unmanaged-device sign-in.
• Correlate Microsoft Graph & Storage Spikes: Look for bursts of queries against /organization, /users, /groups, or /sites followed by elevated FileAccessed or FileDownloaded events in SharePoint and OneDrive, or automated REST API access in Exchange Online.
• Remediate Thoroughly: If you uncover a compromised account, resetting the password alone is not enough. You must revoke all active sessions and refresh tokens, delete any attacker-registered MFA methods and inbox forwarding rules, and force a clean, verified MFA re-enrollment.

Section Summary: Administrators can neutralize the core enterprise tactics used by Storm-2990 and Storm-3119 by blocking the device-code flow in Conditional Access, enforcing FIDO2 or Windows Hello for Business, locking down MFA registration, auditing third-party OAuth app permissions, and hunting for anomalous MFA additions paired with SharePoint/OneDrive download spikes.

The Bigger Picture​

The takedown of YAM Store, CoGUI, and the Iron Man System infrastructure is a textbook example of modern asymmetric cyber conflict. On one side, a handful of developers maintaining a single Gitea server and a marketplace of recycled domains managed to arm enough low-skill buyers to flood the planet with a billion malicious messages in less than ten months. On the other side, taking a bite out of that operation required a federal court order, a tech superpower, international police agencies, and a coalition of threat intelligence and cloud providers acting in concert.

The sinkholes in Southern Florida will certainly ruin the week for Storm-2990’s subscription buyers whose Iron Man panels just failed their 20-second license check. But for Windows and Microsoft 365 defenders, the real victory isn't waiting for the next domain seizure—it's configuring your tenant so that even when the next phishing kit spins up tomorrow morning, a stolen device code or a spoofed SharePoint link hits a brick wall.

Update: Additional details (October 14, 2026)​

Microsoft’s technical report adds a five-stage view of how YAM Store sustained access. It says Storm-3119 used Tor-routed reconnaissance to profile cloud-enabled organizations, then relied on actor-controlled PHP, Java/Spring, and Cloudflare Workers panels to reset passwords, assign education licenses, and grant privileged attributes through stolen application credentials. Microsoft also says the group provisioned the PnP Management Shell service principal inside compromised tenants, granting broad Microsoft Graph and SharePoint permissions to turn OneDrive and SharePoint storage into resale inventory.

The report identifies payment methods including Alipay, WeChat Pay, and USDT TRC20, with a sub-reseller tier and Telegram used for order notifications. Microsoft’s own Iron Man inventory counted more than 2,335 templates across 139 countries, and says the kit supported live victim monitoring via WebSockets and Telegram alerts as victims submitted credentials, card data, and verification codes.