> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Yam Store: The Phishing Network Behind a Billion Messages
- URL: https://f4n6.co.uk/security-feed/yam-store-the-phishing-network-behind-a-billion-messages/
- Published: 2026-10-15T11:45:05.000Z
- Updated: 2026-10-15T11:45:05.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

Microsoft's Digital Crimes Unit, working with Resecurity and law enforcement partners, disrupted the primary developers and infrastructure of a Chinese-language phishing ecosystem tracked as Storm-2990, whose three kits (CoGUI/NX/FA, Haozi/Phoenix, and Iron Man System) were marketed through the YAM Store marketplace, tracked as Storm-3119\. Microsoft attributes more than one billion phishing emails and SMS messages sent to over 75,000 organisations since January 2026 to actors using these kits, with financial services among the targeted sectors in Japan, the United States, Australia, and India. No CVE is involved and no verified CVSS or CISA KEV entry applies; this is a criminal-infrastructure and credential-theft campaign, not a software vulnerability. The risk to EMEA financial services is indirect but material: the kits impersonate financial brands and the marketplace sells fraudulently obtained Microsoft and Google cloud tenants, so credential phishing against your staff and customers can originate from infrastructure that looks like a legitimate cloud workspace. Attribution to Chinese-speaking developers is Microsoft's assessment and is single-sourced; the disruption's durability is unconfirmed.

## 2\. Regulatory framing

| Article                                                | Trigger (the fact in this item)                                                                                                                                                                                                                   | Practical impact                                                                                                                                                                                                                                                                           |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| DORA Art. 28: ICT third-party risk, general principles | The marketplace sells compromised or fraudulently obtained Microsoft and Google cloud environments, so a phishing campaign against you may originate from a tenant that is not your provider but is indistinguishable from one at the login page. | Your third-party risk assessment must cover the risk that attackers operate inside legitimate cloud providers' namespaces, not only the risk that your contracted providers fail. Review how you verify the provenance of Microsoft and Google login prompts reaching staff and customers. |
| NIS2 Art. 21(2)(d): supply chain security measures     | Fraudulently acquired domains tied to legitimate or expired organisation numbers are used to host phishing, which means supplier and partner domain hygiene is part of your exposure.                                                             | Extend supply chain security measures to monitoring for lookalike and re-registered domains impersonating your brand and your suppliers' brands, and to verifying that partner-facing cloud tenants are genuinely controlled by the partner.                                               |
| DORA Art. 17: ICT-related incident management process  | If a phishing campaign using these kits results in credential compromise or fraud against your institution, it is an ICT-related incident that must flow through your incident management process.                                                | Confirm your incident process captures credential-phishing and business email compromise as in-scope ICT-related incidents, with a defined path from detection to classification and reporting.                                                                                            |

No DORA Art. 18, 19, 24, 29 or 30 trigger, and no NIS2 Art. 23 or UK NIS 2018 trigger, is established by the facts in this item. Whether Art. 18 and 19 are engaged depends on the classification of any incident you actually suffer, which this item does not establish.

## 3\. Technical analysis & attack chain

The ecosystem has three layers: kit developers, an infrastructure dealer, and the criminal buyers who combine both. Microsoft tracks the developers behind all three kits as Storm-2990 and the marketplace as Storm-3119\. The kits are CoGUI (also known as NX or FA), Haozi (also known as Phoenix), and Iron Man System. CoGUI and Haozi were advertised through YAM Store first, with Iron Man System added from June 2026\. Despite separate branding and separate Telegram-based sales channels, Microsoft assesses with high confidence that the kits share development origins, code reuse, or close collaboration, and that the developers are Chinese-speaking.

Confirmed steps in how the ecosystem operates:

1. YAM Store acquires cloud infrastructure. The marketplace obtains compromised or fraudulently obtained Microsoft and Google environments, and uses automation to identify expired organisation numbers so it can register domains associated with legitimate, expired, or previously used organisation numbers.
2. The marketplace sells that infrastructure to criminal buyers. Offerings are priced and categorised by age, subscription type, and environment type, including education (.edu) and non-profit (.org) tenants. Buyers obtain workspaces at relatively low cost and use seemingly legitimate infrastructure.
3. Buyers purchase phishing kits separately. The kits provide templates impersonating legitimate brands and organisations worldwide, including government, financial, and logistics entities, and enable high-volume phishing and credential stealing.
4. Campaigns are sent at scale. Since January 2026 the actors behind these kits have facilitated more than one billion phishing emails and SMS messages to over 75,000 organisations.
5. Payment for kits and marketplace services is taken in cryptocurrency, including USDT and Ethereum, to conceal the transaction trail.

The targeting Microsoft observed covers healthcare, financial services, wholesale distribution, and IT organisations in Japan, the United States, Australia, and India. Microsoft's Digital Crimes Unit facilitated disruption of the ecosystem's primary developers and infrastructure alongside law enforcement and other partners.

Two caveats. First, the technical detail here is single-sourced to Microsoft's threat intelligence blog, with Resecurity named as an industry partner; the kit internals, the automation used to find expired organisation numbers, and the disruption's scope are not independently corroborated in the material available to us. Second, the source does not describe the kits' post-compromise behaviour: there is no published detail on session-token theft, adversary-in-the-middle proxying, credential exfiltration endpoints, or follow-on access, so we cannot characterise what happens after a credential is captured. Treat any assumption about post-compromise tradecraft as unverified.

## 4\. Mitigation & containment

P1 within 24 hours

- Confirm that your email and web gateways are configured to quarantine or banner messages originating from newly registered or recently re-registered domains, and that the same treatment applies to Microsoft and Google tenant domains that do not belong to your organisation or a known partner. The marketplace's core product is a legitimate-looking cloud tenant, so domain-age and tenant-ownership signals carry more weight here than sender reputation alone.
- Check your Microsoft Entra and Google Workspace tenant logs for authentication attempts or successful sign-ins from tenants and domains you do not control, and for consent grants to unfamiliar applications. The source does not publish specific log fields or event IDs for this campaign, so scope the hunt by tenant ownership rather than by a supplied detection signature.
- Brief your fraud and contact-centre teams on the brand-impersonation pattern: kits impersonate government, financial, and logistics brands. Any customer-reported login page or payment page that resembles your brand but sits on a domain you do not own should be escalated for takedown the same day.

P2 within 72 hours

- Review your domain portfolio and that of your key suppliers for lapsed registrations. The marketplace's automation specifically targets expired organisation numbers, so an expired domain tied to your brand or a partner's brand is directly purchasable inventory.
- Verify that phishing-resistant multi-factor authentication (FIDO2 or passkeys) is enforced for privileged and finance-adjacent accounts. Credential theft is the kits' stated purpose, and the source gives no evidence of MFA bypass capability, so MFA remains a meaningful control where it is phishing-resistant.
- Add the marketplace and kit names to threat-hunting queries as context, not as detection logic: searches for YAM Store, Storm-3119, Storm-2990, CoGUI, NX, FA, Haozi, Phoenix, and Iron Man System in internal reporting and vendor feeds will surface related activity, but these are reporting terms and will not appear in malicious artefacts.

P3 within 7 days

- Reassess third-party risk for cloud identity providers under DORA Art. 28\. The specific gap this item exposes is that an attacker-operated tenant inside Microsoft or Google is not a provider failure, so your existing provider-risk controls will not catch it.
- Add lookalike and re-registered domain monitoring for your brand and your top suppliers' brands under your NIS2 Art. 21(2)(d) supply chain measures.
- Confirm your incident management process under DORA Art. 17 explicitly captures credential phishing and business email compromise, since the source describes credential theft as the kits' function and does not describe any other impact.

No vendor patch, version pin, or CVE remediation applies to this item. There is no software fix for a criminal marketplace.

## 5\. Indicators of compromise

No atomic indicators of compromise (hashes, domains, IP addresses, URLs, file paths, registry keys) are present in the source material. The sources name kits, a marketplace, and tracking clusters, but publish no machine-pivotable artefacts.

Behavioural indicators:

| Behaviour                                                                                                                                                   | Where to observe                                   | Confidence                                                                                                                              |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Authentication or workspace activity originating from a Microsoft or Google tenant not owned by your organisation or a known partner                        | Entra ID sign-in logs, Google Workspace audit logs | Medium; inferred from the marketplace's stated product, not from a published detection                                                  |
| Phishing pages impersonating government, financial, or logistics brands hosted on domains tied to recently registered or re-registered organisation numbers | Web proxy logs, brand monitoring, customer reports | Medium; the impersonation categories are stated, the domain-age signal is our inference from the expired-organisation-number automation |
| High-volume email or SMS campaigns with shared template structure across multiple sending domains                                                           | Email gateway, SMS gateway, abuse mailbox          | Medium; volume and template reuse are stated, no template artefacts are published                                                       |

These behavioural indicators rest on a single source (Microsoft, with Resecurity as partner). Verify before enforcing.

## 6\. Detection

Insufficient indicators to author detection rules.

The sources name kits, a marketplace, and Microsoft tracking clusters (Storm-2990, Storm-3119), but publish no strings, command-line flags, mutex names, scheduled-task names, file paths, registry keys, or hard-coded values from the malicious artefacts themselves. A YARA or Sigma rule built on kit names or tracking clusters would detect reporting about the threat rather than the threat, so we are not emitting one.

## 7\. Sources

- Microsoft Threat Intelligence, "The hidden network: Inside the phishing infrastructure ecosystem powering global cybercrime", https://www.microsoft.com/en-us/security/blog/2026/10/14/the-hidden-network-inside-the-phishing-infrastructure-ecosystem-powering-global-cybercrime/, 2026-10-14
- Help Net Security, "Microsoft disrupts phishing network behind more than a billion scam messages", https://www.helpnetsecurity.com/2026/10/15/microsoft-disrupting-phishing-kits-marketplace-yam-store/, 2026-10-15
- Dark Reading, "Yam Store: The Phishing Network Behind a Billion Messages", https://www.darkreading.com/cyberattacks-data-breaches/yam-store-phishing-network-behind-billion-messages, 2026-10-14

## 8\. Adverse Trace position

We assess this as a medium-severity, high-volume credential-phishing campaign with no CVE, no CVSS score, and no CISA KEV entry, because the threat is criminal infrastructure and stolen credentials rather than a software flaw. The direct technical risk to an EMEA financial institution is that staff and customers are phished from Microsoft and Google tenants that look legitimate, and the source gives no detail on post-compromise behaviour, so we cannot bound the impact beyond credential theft. Attribution to Chinese-speaking developers is Microsoft's high-confidence assessment and is single-sourced; we treat it as unconfirmed. The disruption of primary developers and infrastructure is also single-sourced and its durability is unknown, so we do not assume the marketplace is permanently closed. We will monitor for follow-on reporting on the kits' post-compromise capabilities, for any published atomic indicators, and for evidence that YAM Store or the three kits resume operations under new branding, and we will issue a follow-up if any of those change the assessment. Clients who observe brand-impersonation pages or tenant-based sign-in anomalies matching the behavioural indicators in §5 should route them to us for correlation.

---

[Read the original source →](https://www.darkreading.com/cyberattacks-data-breaches/yam-store-phishing-network-behind-billion-messages?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*