Historical intelligence backfill. This assessment covers reporting originally published on 2025-10-20 and was added to the RWP archive on 2026-09-07.

Daily Top · Identity & Cloud

Azure Blob Storage is being used as phishing host, malware CDN, and quiet C2 — under a Microsoft hostname

Microsoft mapped Blob Storage across the ATT&CK chain, from public container recon and leaked SAS tokens to anonymous reads, long-lived SAS, and blob-triggered automation.

RWP Ventures · 2026-09-07 · event 2025-10-20 · 3 min read · priority 7.5

Bottom line up front

CONFIRMED On 20 October 2025 Microsoft Threat Intelligence published an attack-chain map for Azure Blob Storage. The story is not a new Azure CVE. It is that unstructured storage is now recon target, credential stash, phishing host, malware CDN, persistence via SAS and anonymous containers, trigger for Functions/Logic Apps, and even a covert channel. Because the hostname ends in blob.core.windows.net and the cert is Microsoft's, mail filters and users both under-react.

Nopal Cyber's 30 October hunting note on blob-hosted Microsoft-login clones is independent corroboration of the phishing-host piece, not a second Microsoft blog. Historical backfill of 20 October 2025 reporting; added 7 September 2026.

What happened

Microsoft walked Blob abuse stage by stage:

Recon: DNS/HTTP probing of *.blob.core.windows.net, tools such as Goblob and QuickAZ, plus name-guessing (including LLM-assisted guessing in Microsoft's telling).
Credential harvest: SAS tokens, account keys, and Entra material scraped from repos and CI logs. Account keys are full-privilege for the account.
Resource development: host spoofed sign-in pages and payloads in attacker-controlled or stolen storage accounts.
Initial access / lateral: blob events firing under-privileged Functions or Logic Apps.
Persistence: long-lived over-scoped SAS, flipping containers to public, enabling SFTP, punching firewall/VNet exceptions, killing diagnostics.
Collection/exfil: native copy tools (AzCopy and APIs) against mis-listed containers.

RST Cloud's secondary parse named Clop/FIN11-class overlap in a threat-report summary; treat that as low-confidence tagging unless you have the primary Microsoft actor table. Microsoft's post is a control map, not a single-gang dossier.

Why it mattered

Cloud IR still starts at VMs and Entra users. Blob is where the backups, data lakes, ML corpora, and "temporary" exports live. A leaked SAS with write+list is quieter than a stolen VM password and often longer-lived than a password reset.

Trusted-host phishing is the user-facing half: the browser lock is real, the page is fake.

Who / what was affected

Any tenant with public containers, leftover SAS in Git, storage account keys in pipelines, or blob-triggered automation with elevated identities. Microsoft did not publish a victim count. Sector: horizontal.

OT: UNKNOWN. Storage of historian exports in Blob would be an IT data problem unless someone claims process manipulation — nobody credible did in these sources.

Technical context

Defender-relevant controls Microsoft tied to the chain (paraphrased, not copied as a product checklist):

Disable shared key auth where Entra can replace it.
Short, least-privilege SAS; prefer user-delegation SAS.
No anonymous blob access unless the data is actually public.
Private endpoints / firewall; do not "open to internet for a ticket."
Diagnostic logs on; alert on public-access flips, SAS minting, and unusual AzCopy.
Functions/Logic Apps that trigger on blob create should not run as a privileged identity.

RWP is not publishing scanning wordlists or exploit scripts.

Exploitation / threat status at the time

CONFIRMED Microsoft observed the techniques; phishing-on-Blob independently reported the same month.

ASSESSED (high): most "breaches" in this class start as misconfiguration plus leaked token, not as a novel exploit.

UNKNOWN how many storage accounts were hosting kits on 20 October 2025.

What defenders should have done

Inventory public containers and shared-key auth. Turn both off except documented exceptions.
Secret scan for SAS and account keys; rotate on hit; treat Git history as compromised.
Mail/web filtering: blob.core.windows.net is not a reputation allow-list.
Review blob-triggered workflows for standing high privilege.
Hunt: new public access, SAS with se= far in the future, SFTP enabled on storage.

What we know now

Blob-hosted phishing did not stop after the blog. The control is still SAS hygiene and "Microsoft hostname ≠ Microsoft page."

RWP assessment

Confidence: High on the attack-chain description. Moderate that most enterprises still have at least one public container or immortal SAS.

Cloud storage is identity. If you cannot list who can read a container, you cannot claim you know your crown jewels.

Defensive actions

Shared-key off, anonymous off, private endpoint on for production accounts.
Rotate keys and SAS that ever touched a repo.
User training is secondary; filter and Conditional Access first.
Include storage-account logs in the same SIEM pipeline as Entra.

Sources

Microsoft Threat Intelligence — Inside the attack chain: Threat activity targeting Azure Blob Storage
MSFT News Now — Microsoft maps Azure Blob Storage attack chain
Nopal Cyber — Phishing campaign abuses Microsoft Azure Blob Storage for credential theft