How a Misconfigured Azure SAS Token Exposed 38 TB of Microsoft Data

On September 18, a Microsoft employee uploaded a bucket of open‑source AI training data to GitHub, unintentionally exposing 38 TB of private data. Wiz security researchers discovered the leak and reported it to the software giant.

Microsoft downplayed the incident, describing it as a “lesson in sharing experience” and promising to help customers avoid similar mistakes. Wiz said the bucket contained private keys, passwords, more than 30,000 internal Microsoft Teams messages, and backup data from two employees' workstations.

The Microsoft Security Response Center stated that no customer data was compromised and no other internal services were at risk, assuring customers that no action was required.

Wiz researchers Hillai Ben‑Sasson and Ronny Greenberg explained that their scan of a misconfigured storage container revealed a GitHub repository belonging to Microsoft’s AI research team, which provided open‑source code and machine‑learning models for image recognition.

The repository included a URL with an overly permissive Shared Access Signature (SAS) token granting full control over an internal Azure storage account that held private data.

A SAS token is a signed URL that grants specific access levels to Azure storage resources. In this case, the token was misconfigured to provide full control, allowing anyone with the URL to view, delete, or modify files.

Ben‑Sasson and Greenberg noted that the account contained 38 TB of data, including personal computer backups with passwords, keys, and over 30,000 Teams messages from 359 Microsoft employees.

The vulnerable URL had been exposed since 2020 and was incorrectly set to allow “full control” rather than read‑only access, meaning any party aware of the URL could delete, replace, or inject malicious content.

Microsoft clarified that the PC backups belonged to the two former employees. After being notified on June 22, the company revoked the SAS token to prevent external access and fully patched the vulnerability on June 24.

Further investigation concluded that the exposure posed no risk to customers or business continuity.

Microsoft also recommended a set of SAS best practices, such as limiting the URL’s scope to the minimum required resources, restricting permissions to only what the application needs, and setting short expiration times (e.g., one hour).

Finally, Microsoft pledged to continuously improve its detection and scanning tools to proactively identify over‑permissive SAS URLs and strengthen default security postures.