On September 18, 2023, Wiz Research disclosed that a Microsoft AI research team had exposed 38TB of internal data — training data, employee workstation backups, and secret keys — through a single Azure Storage SAS token embedded in a public GitHub repository. The token had account-level read/write/delete permissions and no expiration date, meaning anyone who found it had standing access until Microsoft revoked it. That incident is now the reference case for a broader pattern: Azure Blob Storage is easy to provision and easy to misconfigure, and the two most common failure points — public access settings and permissive SAS tokens — keep showing up in storage account misconfiguration reports years after Microsoft tried to fix the defaults. Below is what actually drives these reports, which settings matter most, and how security teams can catch exposure before a researcher (or an attacker) does.
What is an Azure storage misconfiguration report?
An Azure storage misconfiguration report is a scored inventory of storage accounts, containers, and access controls that deviate from secure baselines like the CIS Microsoft Azure Foundations Benchmark. It typically enumerates findings against specific control IDs — for example, CIS control 3.1 ("Ensure Secure Transfer Required Is Set to Enabled"), 3.7 ("Ensure Default Network Access Rule for Storage Accounts Is Set to Deny"), and 3.15 ("Ensure Storage for Critical Data Is Encrypted with Customer-Managed Keys") — and maps each violation to the storage account, resource group, and subscription where it lives. Tools that generate these reports pull configuration state from the Azure Resource Manager API and Microsoft Defender for Cloud recommendations, then cross-reference it against exposure signals: is the container internet-reachable, does a SAS token exist without an expiry, is Shared Key authorization still enabled. The output is meant to answer one question for a security team — which storage accounts can be reached from the internet right now, and with what level of access.
What are the most common Azure Blob Storage misconfigurations?
The most common misconfigurations are public blob access left enabled, storage firewalls set to "Allow" from all networks, and SAS tokens issued without expiration dates. Microsoft changed the platform default for "Allow Blob public access" to disabled for newly created storage accounts starting in November 2021, but that change is not retroactive — accounts created before that date, or accounts where a template or Terraform module explicitly re-enables it, still default to exposed. Shared Key authorization is another recurring finding: it remains enabled by default on every storage account, and a leaked key grants full account-level access with no way to scope it down after the fact, unlike Azure AD (Microsoft Entra ID) role assignments. Missing customer-managed key encryption, disabled diagnostic logging on blob/queue/table services, and soft delete left off on accounts holding production data round out the recurring top five. Each of these maps directly to a specific, named CIS or Microsoft Defender for Cloud control, which is why they show up identically across independent audits.
How did the Microsoft Wiz-disclosed leak actually happen?
It happened because a single overly broad SAS token, generated for one internal purpose, was reused and then accidentally published inside a config file on a public GitHub repo. Wiz Research found the token while scanning public repositories for exposed secrets tied to Microsoft's AI research group; the token pointed to an Azure Storage account containing 38TB of data, including two employees' workstation backups with passwords, secret keys, and over 30,000 internal Microsoft Teams messages from 359 employees. Because the SAS token was scoped at the account level with full permissions and no expiration, GitHub's own secret-scanning did not flag it as a credential in the way an API key would be flagged — SAS tokens are URLs, not obviously "secret" strings, so they slip past casual review far more easily. Microsoft revoked the token within 24 hours of Wiz's disclosure on June 22, 2023, and made the finding public on September 18, 2023. The root cause was not a platform vulnerability; it was an access-scoping decision made once and never revisited.
Why do permissive SAS tokens remain the top storage risk in 2025?
They remain the top risk because SAS tokens are bearer credentials that grant access independent of Azure AD identity, and once issued, an account-level SAS with no expiration cannot be revoked individually — only by rotating the account key or SAS policy it was derived from. A developer who needs to hand a partner temporary read access to one container can, with a single Azure CLI command, generate a token scoped to the entire storage account with read, write, list, and delete permissions valid for a year or more, and that token then lives in scripts, CI logs, and Slack messages indefinitely. Microsoft's own guidance recommends stored access policies with expiration under 24 hours for anything user-delegated, but enforcement is left entirely to the engineering team issuing the token — there is no platform-level maximum lifetime unless an org explicitly sets one via Azure Policy. Combined with Shared Key authorization being on by default, a single leaked token or account key is still enough to reproduce a Wiz-style exposure in any subscription that hasn't explicitly hardened these two settings.
How can security teams detect Azure storage exposure before attackers do?
Security teams detect it by continuously scanning storage account configuration against CIS/Defender baselines and correlating those findings with actual internet reachability and data sensitivity — not just listing every non-compliant setting. A storage account with public blob access enabled but zero blobs in it is a low-priority finding; the same setting on an account holding customer PII backups is a page-someone-now finding. That prioritization requires knowing what's actually in the container (via classification or SBOM-style data inventory), whether the container is reachable from outside the virtual network, and whether any code path in the application actually depends on public access for legitimate functionality. Static configuration scanning alone produces the same flat list of hundreds of CIS violations every audit cycle; the teams that actually close exposure windows are the ones that can tell which five of those hundreds are exploitable today.
How Safeguard Helps
Safeguard ingests Azure storage account configuration alongside SBOM data and application dependency graphs so a public-access or permissive-SAS-token finding isn't reported in isolation — it's tied to whether any deployed service actually reads from or writes to that container, using reachability analysis to separate exploitable exposure from dormant configuration drift. Griffin AI, Safeguard's detection engine, correlates storage misconfigurations against known exposure patterns like the 2023 Wiz-disclosed SAS token leak to flag account-level tokens with no expiration before they end up in a public repository. Where a fix is unambiguous — enabling secure transfer, setting the default network rule to Deny, disabling Shared Key authorization — Safeguard opens an auto-fix pull request against the Terraform or Bicep module that provisions the resource, so the remediation ships through the same review process as any other infrastructure change. SBOM generation and ingest give teams a persistent record of what data and dependencies sit behind each storage account, which is what turns a 300-line CIS violation report into a five-item action list security teams can actually clear in a sprint.