Microsoft SAS token exposure

A link in a public GitHub repository was meant to let readers download AI model files. Its Azure Storage shared access signature (SAS) gave much broader access. The incident is useful because the repository contained a URL, while the important question was what that URL authorized in the storage account.

What the two incident accounts establish

Wiz reported that the link allowed access to about 38 TB of additional storage data, including backups of two former employees’ workstations and more than 30,000 Teams messages. Wiz also found that the SAS allowed write and delete operations, not just reading. Those are the researchers’ observations of reachable data and permissions; they are not evidence that an unrelated attacker downloaded 38 TB or changed a model.

Microsoft confirmed that Wiz could access internal information through the overly permissive SAS URL. Microsoft said no customer data was exposed and no other internal services were at risk. Wiz notified Microsoft on June 22, 2023; Microsoft said it revoked the token and blocked external access by June 24. The public reports do not establish broader malicious use.

Microsoft also disclosed a detection failure: its historical scan had found the URL in the repository, but the finding was incorrectly marked as a false positive. Microsoft said it fixed that cause and expanded detection for SAS tokens with excessive privileges or expiry. A scan result therefore needs review of the token’s scope and a reliable path for overturning a mistaken dismissal.

If your team finds a SAS URL in source code

1. Preserve the repository location, commit and discovery time without copying the live signature into tickets or chat. Restrict access to the complete URL. It is a bearer credential: whoever has a usable copy can exercise the access it grants.

2. Review the URL and SAS parameters with the storage owner. Identify the resource path and SAS type, then check signed services, resource types or resource, permissions, expiry, protocol and any IP restriction. An account SAS and a service SAS have different scopes. The path alone does not prove the signed scope; inspect the full authorization fields and the account configuration.

3. Contain it using the method appropriate to its type and signing key. A service SAS tied to a stored access policy can be revoked by changing that policy. An ad hoc account-key-signed SAS may require rotating the signing account key, which can disrupt other clients; plan replacement first. A user delegation SAS has a separate delegation-key revocation path. Confirm the old URL no longer works without publishing it or treating a failed single request as a complete audit.

4. Review retained Azure Storage request logs, if they were enabled, for SAS-authorized access, operations, caller IPs, time windows and changes to affected objects. SAS authentication does not by itself identify a human caller. Compare logs with known clients and document gaps where logging or retention was absent. Check the same URL and any copied signatures in other repositories and documents.

What detection can and cannot decide

Cremit scans configured, supported sources for credential patterns and routes findings for review. A detected SAS-shaped URL is a lead, not a complete account permission map or proof of misuse. The Azure storage owner must inspect the signed scope, revoke the credential and review issuer-side logs. This case shows why detection, permission review and response ownership must meet at the same finding.