Microsoft disclosed an incident where a blob storage URL containing an overly permissive Azure Shared Access Signature token was posted by an employee in a public GitHub repository, allowing Wiz to access internal data in a Microsoft storage account.
The exposed data included backups of two former employees’ workstation profiles and internal Microsoft Teams messages, while Microsoft stated no customer data or other internal services were at risk. The core lesson is not a flaw in Azure Storage itself, but a governance and control failure around token issuance, scope and monitoring. The SAS token was broad enough to permit access to sensitive internal content and the source material shows Microsoft later expanded detections for overly permissive SAS privileges and expirations after existing scanning had incorrectly treated the finding as a false positive. This incident reinforces a practical cloud security lesson: secret exposure becomes materially more dangerous when delegated credentials are over-scoped, long-lived, insufficiently constrained by network conditions and not reliably surfaced through detection and usage visibility.
| What’s happening | Cause | Action |
|---|---|---|
| A public repository exposed a live SAS token tied to internal storage | A Microsoft employee shared a blob store URL in a public GitHub repository while contributing to open-source AI learning models and the URL included a SAS token. Microsoft explicitly states SAS tokens should be handled like secrets. | Validate that SAS tokens and equivalent cloud access URLs are continuously scanned across public code, internal repositories, tickets, wikis and collaboration platforms. SkySiege would assess whether storage access is delegated through embedded secrets, whether exposed tokens can be tied to sensitive storage resources and whether secret governance covers developer workflows and public contribution paths. |
| The token granted broader access than the use case required | Microsoft describes the token as “overly-permissive” and later expanded detections to identify SAS tokens with excessive privileges or expirations. The exposed token allowed access to data that included workstation backups and Teams messages, indicating scope exceeded a minimally necessary sharing pattern. | Validate least-privilege controls for SAS issuance: resource-level scoping, operation restrictions and short expiration windows. SkySiege would assess whether SAS tokens are scoped to specific blobs or containers, whether permissions exceed business need and whether delegated access patterns create exposure to internal or regulated data if a token is leaked. |
| Token usage was not sufficiently constrained to expected source conditions | Microsoft’s own SAS best practices note tokens can restrict access by HTTPS and IP address. The incident content does not indicate the exposed token had origin restrictions in place. Based on the evidence, lack of such controls would have allowed external use once the token was discovered. | Validate whether SAS tokens are bound to known IP ranges, trusted application paths and required transport protections where operationally feasible. SkySiege would assess storage configurations and token governance for network-based restrictions that reduce abuse when a token is exposed, especially for internal-only data paths. |
| Detection existed, but triage failed | Microsoft states its historical rescan system detected the specific SAS URL in the robust-models-transfer repository, but the finding was incorrectly marked as a false positive. Microsoft then fixed the root cause and confirmed proper reporting of over-provisioned SAS tokens. |
Validate not only that detections exist, but that they are tuned, tested and operationally trusted. SkySiege would assess whether secret scanning findings are suppressed, misclassified or disconnected from remediation workflows and whether high-risk delegated credentials receive mandatory review instead of automated dismissal. |
| Monitoring and visibility were not strong enough to make token misuse obvious before external reporting | Microsoft recommends enabling Azure Monitor and Azure Storage Logs and using SAS expiration policies to detect risky usage. The incident narrative shows the issue was reported by Wiz and then mitigated, rather than being clearly identified and contained first through internal monitoring. | Validate whether storage access logs, authorization telemetry and anomaly review are enabled and retained for delegated access tokens. SkySiege would assess whether organisations can distinguish expected SAS activity from internet-origin access, identify dormant or long-lived tokens and investigate whether unauthorised third-party use would generate actionable alerts. |
| Revocation capability mattered, but response still depended on external discovery | Microsoft revoked the SAS token and blocked external access after Wiz reported the issue, showing revocation worked once the problem was known. The exposure window remained dependent on discovery and escalation. | Validate that every delegated access mechanism has a tested revocation plan through stored access policies or parent key rotation. SkySiege would assess whether revocation is granular, documented and fast enough to contain exposure without broad operational disruption, especially for shared storage services used by multiple teams. |
This incident is a clear example of why leaked cloud secrets are only part of the problem. The larger risk came from the fact that the exposed SAS token was powerful enough to access internal data and apparently lacked tighter usage constraints such as narrowed scope, shorter lifetime and potentially source-based restrictions. When delegated credentials are over-provisioned, a simple disclosure event becomes a direct data access incident.
The operational concern is equally important. Microsoft had scanning in place, but a true finding was marked as a false positive. That is a detection engineering failure, not just a developer mistake. In practice, many enterprises have secret scanning coverage on paper but still fail at triage quality, suppression controls and escalation discipline. That creates a false sense of safety while exposed credentials remain usable.
From a governance perspective, this reflects weak control over how temporary access is issued, monitored and revoked. If an organisation cannot inventory SAS-style delegation, understand what data those tokens can reach and detect when they are used outside expected patterns, then compromised tokens function as unmonitored external access paths.
Business impact extends beyond the specific data exposed. Even where customer data is unaffected, exposure of employee communications and workstation backups creates reputational risk, legal review burden and diligence concerns about internal data handling. For acquirers, investors and enterprise customers, this raises questions about cloud credential governance maturity, detection reliability and whether similar over-scoped access paths remain undiscovered elsewhere.
