Storm-3119/Storm-2990: YAM Store and CoGUI Infrastructure Behind Over One Billion Phishing Emails and SMS Messages

1. Overview

• Article Title: The hidden network: Inside the phishing infrastructure ecosystem powering global cybercrime
• Publisher: Microsoft
• Publication Date: 2026-10-14
• Source: Microsoft
• Related Sources: Proofpoint: Disruption Targets Major Chinese-Language Phishing Kits with Japanese Focus, Microsoft Learn: Compromised and malicious applications investigation, Microsoft Learn: Block authentication flows with Conditional Access, Microsoft Learn: How Conditional Access authentication strengths work
• Related Malware and Threat Groups: Storm-3119, Storm-2990, CoGUI, CoAceV, CoFish_Ws
• Related CVEs: None
• Related Products: Microsoft 365, Google Workspace, CoGUI, Haozi, Iron Man System, YAM Store
• Importance: High

2. Summary

YAM Store sold illicitly acquired Microsoft and Google environments to support phishing kits such as CoGUI, Haozi, and Iron Man. According to Microsoft, since January 2026, the related kits have supported the sending of over one billion phishing emails and SMS messages to more than 75,000 organizations. Japan and the United States were among the most heavily affected countries.

3. Attack Flow

Distinguish the compromise of infrastructure-supplier tenants from downstream phishing by customers who purchase that infrastructure. The following describes the relationship between supply and abuse, not a continuous intrusion sequence within a single victim organization.

Infrastructure Supply and Downstream Phishing: Different Actors and Environments

1. Storm-3119 uses application credentials from compromised tenants to retain administrative access and sells accounts, licenses, and storage. Separately, it also creates fraudulent organizations to obtain tenants.
2. Storm-2990 family kit operators purchase tenants, domains, storage, and licenses.
3. Affiliates send large volumes of emails and SMS messages mimicking Japanese consumer and finance brands.
4. Credential-stealing campaigns capture information entered on fake pages. In a separate path, attackers abuse device code authentication to induce users to authenticate to legitimate applications, allowing the attacker-controlled client to obtain tokens.
5. Stolen credentials are used for account takeover and fraud.

4. Attacker Position and Prerequisites

• On the supply side, Storm-3119 abuses application credentials or administrator privileges in compromised tenants. Downstream attackers purchase cloud infrastructure or phishing kits and target users.

5. Visible Indicators for Victims and Administrators

Victim Side

• Users view notifications or login pages resembling legitimate brands and enter credentials and payment data.

Administrator Side

• Manifests as new tenants, expired domains, high-volume mail traffic, suspicious redirects, and brand impersonation.

6. Success and Failure Conditions

Success Conditions

• The reputation of a spoofed tenant or domain may help evade reputation-based detection, but does not guarantee passage through delivery controls.
• Credential-stealing campaigns require users to enter information on fake pages. Device code phishing requires the flow to be allowed and the user to complete the authentication prompted by the attacker.

Failure Conditions and Defensive Limits

• Detect using a combination of domain age, tenant provenance, URL chains, and login context.
• Require phishing-resistant MFA, such as FIDO2, through Conditional Access authentication strengths, and apply session protection where supported.
• Following Microsoft's guidance, audit device code flow usage and block unnecessary use with Conditional Access. Make exceptions only for necessary business uses, assess operational impact in report-only mode, and then enable enforcement.

Inference: Deploying FIDO2 alone does not establish that the device code phishing path is blocked. Check the required authentication strength, the users and resources covered by Conditional Access, policy exclusions, and the authentication flows that remain allowed.

7. What Happens If the Attack Succeeds

• Credential and payment data theft leading to account takeover.
• Large-scale email and SMS fraud targeting Japanese organizations.
• Abuse of cloud infrastructure reputation.

8. Observable Logs

The following are investigation candidates. Availability depends on products, permissions, logging configuration, and retention. Missing records do not prove the absence of compromise.

• Email: Inference: Examine templates associated with CoGUI and related kits, sender tenants, Reply-To values, and redirect chains.
• Proxy/SWG/DNS: Inference: Examine access to domains associated with YAM Store or the kits, newly registered domains, and expired domains that have been reused.
• Endpoint/EDR: Inference: Examine browser history, downloads, and credential prompts.
• Identity/IdP: Inference: After phishing, look for new devices, impossible travel, added MFA methods, and mail rule changes. Also check device code flow usage and Conditional Access decisions.
• SaaS/Cloud: Inference: In a supplier tenant, correlate available audit logs for application registrations, credential changes, permission grants, and license or storage operations. A downstream victim organization may not have direct access to the supplier tenant's internal logs.
• Network: Inference: Examine relationships between high-volume email sources and landing-page infrastructure.

9. Scope of Verified Success

Attack Attempt Observed (Success Unconfirmed)

• Scope: Scope confirmed by public information
• Basis: Although the transmission of over one billion messages has been confirmed, this does not imply successful credential theft for all messages.

Information Theft or Session Compromise Confirmed

• Scope: Scope confirmed by public information
• Basis: The kits acquire credentials and payment data, and related account takeovers have been observed.

Determination Criteria for Your Organization

• Separate contact, execution, data access, and subsequent compromise; do not assume unconfirmed success from a single alert.

10. Investigation Playbook

• Investigation Starting Point: Start with brand impersonation, related domains, and post-phishing identity alerts.
• Initial Verification: Check message headers, URL chains, domain history, sender tenants, and user clicks.
• Endpoint and Server Investigation: Check browser artifacts, downloads, tokens, and saved credentials.
• Authentication and Cloud Investigation: Investigate logins, MFA changes, OAuth grants, mail rules, and session tokens. If compromise of a supplier tenant is suspected, also examine service principal sign-ins, credential changes, and application permissions.
• Subsequent Actions: Track payment fraud, BEC, internal phishing, and credential reuse.
• Containment: Revoke sessions, reset credentials, enforce phishing-resistant MFA, and block domains and tenants. For a compromised application, identify its owner and assess operational impact, then disable sign-in, rotate credentials and remove old ones, and correct excessive or unauthorized permissions.
• Classification Categories: Separate delivery, clicks, credential submissions, authentication, and fraud.

11. Defense and Detection Ideas

• Single Events: Detect brand login URLs originating from new or recycled domains.
• Timeline Correlation: Correlate messages, clicks, credential submissions, new logins, and mail rule modifications.
• Threat Hunting: Retroactively search for infrastructure related to CoGUI, CoAceV, CoFish_Ws, Haozi, and Iron Man.
• Log Limitations: A downstream victim organization may not have direct access to a supplier tenant's internal logs. Availability depends on permissions, configuration, and retention.
• Priority Countermeasures: Alongside email and URL defenses, verify the scope of policies requiring phishing-resistant MFA and block unnecessary device code flow usage with Conditional Access. Also establish session revocation procedures and brand monitoring. Domain seizures do not imply the shutdown of the entire affiliate infrastructure, so continue monitoring related domains and tenants.

12. Facts, Inference, and Hypothesis

Facts

• Microsoft tracks YAM Store as Storm-3119 and three major phishing kit operations as Storm-2990.
• Microsoft reports that, since January 2026, the related kits have supported the sending of over one billion emails and SMS messages to more than 75,000 organizations.
• Japan and the United States were the most heavily affected countries; targeted sectors included finance, healthcare, distribution, and IT.
• YAM Store sold compromised or fraudulent Microsoft and Google tenants, domains, credentials, storage, and licenses.
• Automated processes reused expired organization names and real customer details to fabricate educational and nonprofit appearances.
• CoGUI, Haozi, and Iron Man provided brand impersonation templates and credential capture, while Proofpoint assessed a high-confidence common root for CoGUI, CoAceV, and CoFish_Ws.
• Microsoft and Health-ISAC pursued litigation and domain seizure or redirection; Proofpoint, JC3, and other partners supported the investigation and disruption.
• Storm-3119 retained administrative access to tenants through app-only authentication using stolen application client secrets. This access does not depend on an individual user session.

Inference

• Public facts must be mapped and verified against your organization's assets and logs.
• Deploying FIDO2 alone does not establish that the device code phishing path is blocked. Check the required authentication strength, the users and resources covered by Conditional Access, policy exclusions, and the authentication flows that remain allowed.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unresolved Points and Additional Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1566.002	Phishing: Spearphishing Link	high	Maps to Microsoft's observation of phishing emails containing malicious links.
T1583.001	Acquire Infrastructure: Domains	high	Downstream attackers acquire illicitly obtained domains from YAM Store.
T1078	Valid Accounts	high	Reuses stolen credentials for subsequent access.

14. Unresolved Points and Additional Investigation

• The extent of remaining affiliate infrastructure, reconstruction speed, and total financial loss after the seizures remain undetermined.

15. Impact on SOCs and Organizations

Cloud environments reusing legitimate or expired organization data combined with high-volume transmission kits delivered large-scale credential phishing to Japanese organizations that was difficult to detect using standard tenant reputation alone. App-only access in a supplier tenant does not depend on individual user sessions. If a similar application compromise is suspected in your organization, investigate application credentials and permissions in addition to revoking sessions. Downstream victim organizations cannot rely on access to the supplier's internal logs, so use received emails, URLs, and authentication logs to determine the stage of compromise.

16. Summary by Target Audience

• For SOCs: Do not confuse delivery volume with actual compromise; verify up to post-click identity events.
• For Administrators: Require phishing-resistant MFA, such as FIDO2, through authentication strengths, and review Conditional Access coverage, exclusions, and allowed flows. Block unnecessary device code flow usage, make exceptions only for necessary business uses, and assess operational impact before enforcement. Also establish monitoring for new tenants and domains and session revocation procedures.
• For Users: Do not log in via links in emails or SMS; use official apps and bookmarks instead.