How YAM Store turned hijacked cloud tenants into a phishing supply chain

Microsoft’s Storm‑3119 investigation describes YAM Store as an initial‑access broker for compromised or fraudulently obtained Microsoft and Google environments. Listings varied by age, subscription and organization type, including education and nonprofit identities.

That changes the defensive model. A message sent from infrastructure carrying familiar cloud and organization signals can look more credible than one from an obviously disposable host. The broker’s customers could buy an operating environment instead of building the full stack themselves.

Microsoft says the marketplace supplied accounts and infrastructure to phishing kits tracked as Storm‑2990, including CoGUI, Haozi and Iron Man.

The report says Storm‑3119 automated reconnaissance to find cloud‑enabled organizations, enrollment opportunities, licensing data and tenant information. Microsoft also observed the group using expired organization identities and creating fabricated organizations with supporting websites and documents.

The practical risk is broader than domain renewal alone. An expired domain, a stale organization record and permissive cloud enrollment can combine into a convincing identity that passes superficial checks.

Organizations should assign ownership and renewal decisions for important domains, document legitimate tenant identities and remove abandoned cloud resources. Providers still need stronger enrollment and abuse detection because a renewed domain by itself cannot prove the claimant controls a real organization.

Microsoft says the operators used application credentials and actor‑controlled administration panels to reset passwords, assign licenses and change privileged attributes. App‑only access can survive user password changes because it is attached to an application or service principal rather than one interactive session.

The reported chain then abused SharePoint and OneDrive for hosting and storage, while separate DNS tooling managed phishing domains, certificates and routing. That bundled control turned a compromised tenant into a sellable service.

Defenders should inventory privileged applications and service principals, review unexpected consent or credential additions, and investigate storage or directory changes that do not map to a known deployment owner.

Microsoft separates the roles: Storm‑3119 acquired and sold infrastructure; Storm‑2990 developers supplied phishing kits; downstream buyers selected templates and ran campaigns. The kits supported localization, geofencing, CAPTCHA gates, IP filtering and real‑time credential collection through messaging integrations.

This separation helps explain scale. Each participant can specialize, and one storefront can supply many campaigns. It also means a single phishing URL reveals only the final layer of the operation.

Incident investigations should preserve tenant, application, domain, storage and message evidence so related events can be joined. Treating every lure as an isolated mailbox problem can miss the shared supplier.

Prioritize Global Administrator assignments, app‑only credentials, service‑principal secrets, tenant‑creation anomalies and storage use that lacks a business owner. Confirm who can register applications, grant consent and create new privileged credentials.

Microsoft’s report is a vendor‑authored account of its own investigation; the exact prevalence of each technique outside the observed ecosystem is unknown. Use the disclosed patterns as hunting leads, then validate them against your environment’s evidence.

Follow the Microsoft organization page on OpenTools for material changes to the company’s identity and security products.

Image: Microsoft Threat Intelligence’s real five‑stage Storm‑3119 procurement and resale diagram, used without generative alteration or artificial upscaling.