Microsoft disrupts YAM Store and three phishing kits

Microsoft Threat Intelligence and the Microsoft Digital Crimes Unit have detailed, and helped disrupt, a Chinese-language phishing ecosystem: three phishing-as-a-service kits and a marketplace that resells compromised Microsoft and Google cloud tenants. Downstream activity included device code phishing to obtain tokens, which makes this an identity problem as much as an email problem.

What happened

In an October 14, 2026 post, Microsoft said the kits CoGUI (also known as NX or FA), Haozi (also known as Phoenix) and Iron Man System, which launched in June 2026, sent more than one billion phishing emails and SMS messages to over 75,000 organizations since January 2026. Microsoft tracks the developers behind the three kits as Storm-2990. The United States and Japan were most affected, followed by Australia and India. Targeted sectors included healthcare, financial services, wholesale distribution and IT. Iron Man alone has more than 2,335 templates tailored to over 139 countries, plus geofencing, fake CAPTCHA gates and Telegram alerts for captured credentials.

The marketplace, YAM Store, is tracked as Storm-3119. Microsoft describes it as an initial access broker that acquires and resells compromised or fraudulently obtained cloud environments. Its pipeline, per Microsoft:

  • Reconnaissance over Tor to identify Microsoft 365 tenants and assess their licensing.
  • Admin panels that use stolen application credentials and app-only authentication to keep persistent Global Administrator access.
  • Provisioning the PnP Management Shell service principal with broad Microsoft Graph permissions, then using SharePoint and OneDrive as bulk hosting.
  • A custom DNS platform for phishing domains and certificates, plus an automated storefront with sub-resellers.

Microsoft says the Digital Crimes Unit, working with law enforcement and partners, facilitated a disruption of the ecosystem's primary developers and infrastructure. The Hacker News reported that the operation was court-authorized and that partners included Health-ISAC, Japan's JC3, Resecurity, Cloudflare, Oracle, Proofpoint and TRM Labs.

Why it matters

Two identity angles stand out. First, device code phishing. Microsoft lists it as a technique used to obtain tokens. Because the victim signs in on a genuine Microsoft page on the attacker's behalf, OTP or push MFA does not stop it. Second, sold tenants. A tenant bought from YAM Store comes with a real Global Administrator and a service principal holding Graph permissions. Phishing sent or hosted from it arrives from a legitimate Microsoft 365 tenant and real SharePoint or OneDrive URLs, so domain reputation checks will not flag it.

Microsoft's recommendations are passkeys, organization-wide MFA, Conditional Access requiring phishing-resistant MFA for privileged accounts, least privilege for Global Administrator, and allowing MFA and passkey registration only from trusted locations and devices. Microsoft also tells users that a sign-in prompt should clearly name the application being authenticated to. The post does not give a device code control. Separately, Microsoft's Conditional Access documentation recommends getting as close as possible to a full block on device code flow.

What to check in your environment

  • Audit device code flow use in Entra sign-in logs, then follow Microsoft's guidance: create a Conditional Access policy using the authentication flows condition in report-only mode, allow only documented cases such as legacy tooling, and block the rest. Exclude break-glass accounts.
  • Require phishing-resistant authentication strengths for Global Administrator and other privileged roles. Count how many people hold Global Administrator today.
  • Restrict registration of MFA methods and passkeys to trusted locations and devices so a phished password cannot be used to enroll an attacker's authenticator.
  • Review service principals and app consents for broad Microsoft Graph permissions you did not approve, including the PnP Management Shell app. Check for app-only credentials added to existing applications.
  • Apply Microsoft's recommended Exchange Online Protection and Defender for Office 365 settings, and make sure Safe Links policies also cover internal recipients.
  • Update your account compromise playbook to revoke sessions and refresh tokens, not just reset the password.
  • Brief helpdesk and users: verify unexpected requests by calling the sender directly, and never enter a device code they did not request themselves.

References

Original source: Microsoft Security Blog