Case study: Microsoft AI researchers' over-permissive SAS token (2023)

On 18 September 2023 the Microsoft Security Response Center (MSRC) described an incident 'involving a Microsoft employee who shared a URL for a blob store in a public GitHub repository while contributing to open-source AI learning models. This URL included an overly-permissive Shared Access Signature (SAS) token for an internal storage account.' Researchers at Wiz found the URL, used the token, and reported it through coordinated disclosure on 22 June 2023. MSRC revoked the token and blocked all external access to the storage account, 'mitigating the issue on June 24th, 2023.'

According to Microsoft, the exposed data 'included backups of two former employees' workstation profiles and internal Microsoft Teams messages of these two employees with their colleagues. No customer data was exposed, and no other internal services were put at risk.' Microsoft was explicit that 'There was no security issue or vulnerability within Azure Storage or the SAS token feature.'

Wiz's own account of the same exposure is much larger, and the two are not reconciled in the public record. This page uses Microsoft's account as the primary source and labels Wiz's figures as Wiz's. Either way, the mechanism is the same and common: a signed URL is a credential, and it was published.

A shared access signature is a set of query parameters appended to a storage URL and signed with a key. Azure Storage checks the signature and grants whatever the parameters say: which resources, which operations, from which IP addresses, and until when. There are three kinds. An account SAS and a service SAS are signed with the storage account key; a user delegation SAS is signed with a key obtained through Microsoft Entra ID, and Microsoft recommends it 'when possible for superior security'.

Microsoft Learn is blunt about the properties that matter in an incident: 'The SAS token is not tracked by Azure Storage in any way', and 'It's not possible to audit the generation of SAS tokens.' A stored access policy can revoke a service SAS without touching keys, but 'Stored access policies are not supported for the user delegation SAS or the account SAS.' An account SAS that leaks can only be revoked by rotating the key that signed it, which breaks everything else that key signed. A user delegation SAS expires with its user delegation key, and can never be valid for more than seven days.

MSRC did not publish the exact scope or expiry of the leaked token beyond calling it 'overly-permissive'. Wiz, which found it, reported that the token was 'configured to share the entire storage account', with 'full control' permissions rather than read-only, and valid until 2051; Microsoft's post does not confirm those details. The cloud provider baselines guide (/domains/runtime/cloud-posture/cloud-provider-baselines/) covers turning off Shared Key, which removes account-key SAS altogether.

Microsoft already had two layers of detection. GitHub secret scanning ran a SAS detection provided by Microsoft, which at the time flagged SAS URLs 'pointing to sensitive content, such as VHDs and private cryptographic keys.' Microsoft also ran 'complete historical rescans of all public repositories in Microsoft-owned or affiliated organizations and accounts.' That second system 'detected the specific SAS URL identified by Wiz in the robust-models-transfer repo, but the finding was incorrectly marked as a false positive.'

Microsoft fixed the root cause of that misclassification and expanded the GitHub detection 'to include any SAS token that may have overly-permissive expirations or privileges.' The broader lesson applies to any scanner: detection is half the control. If the triage step cannot tell a live, powerful credential from a harmless one, the scanner's best findings get closed. Triage needs the context a scanner lacks, such as what the token can do and how long it lives, and a closed alert for a credential should record why it was judged harmless. The leaked secret guide (/domains/identity-crypto/secrets/leaked-secret-response/) covers what to do once a finding is confirmed.

The link was published to share material for open-source AI models, which is normal research practice: weights, datasets and checkpoints are large, and a storage link is the easy way to hand them out. The failure was sharing them from a storage account that also held unrelated internal data, with a token whose scope reached that data.

Publish research artifacts from a dedicated storage account, or a dedicated container with a scoped, read-only, short-lived or anonymous-read configuration made on purpose, with nothing else in it. Review what a public link can reach before it is published, the same way a public bucket would be reviewed. The model artifact guide (/domains/ai-emerging/ml-security/model-artifact-security/) covers publishing and consuming model files safely.

The scanner below finds Azure Storage SAS URLs in text, works out whether each is an account, service or user delegation SAS from its parameters (ss and srt mark an account SAS, skoid a user delegation SAS, si a stored access policy), and reports risky permissions, revocation limits and lifetimes over one hour. It prints the resource path and never the sig value. Run with Python 3.14 on a sample file with a fake long-lived account SAS and a 30-minute read-only user delegation SAS, it flagged the first on all three counts and passed the second. Use it alongside your secret scanner, on repositories, notebooks and documentation, and treat every hit as live until proven otherwise.

"""Find Azure Storage SAS URLs in text files and grade them, without printing secrets.

Account SAS (ss, srt) and service SAS are signed with the account key; a user
delegation SAS (skoid) is signed with a Microsoft Entra key. Flags write, delete
or list permissions, and lifetimes beyond a limit. Usage: find_sas.py FILE...
"""
import re
import sys
from datetime import datetime, timezone
from urllib.parse import parse_qs, urlsplit

URL = re.compile(r"https://[a-z0-9]{3,24}\.(?:blob|dfs|file|queue|table)\.core\.windows\.net/[^\s\"'<>]*\bsig=[^\s\"'<>]+")
RISKY = {"w": "write", "d": "delete", "l": "list", "a": "add", "c": "create", "x": "delete version", "y": "permanent delete"}
MAX_HOURS = 1  # MSRC: Azure Storage recommends 1 hour or less


def when(value):
    return datetime.fromisoformat(value.replace("Z", "+00:00"))


def grade(url):
    q = {k: v[0] for k, v in parse_qs(urlsplit(url).query).items()}
    kind = "user delegation SAS" if "skoid" in q else "account SAS" if "ss" in q else "service SAS"
    if "si" in q:
        kind += " (stored access policy)"
    problems = [f"can {RISKY[p]}" for p in q.get("sp", "") if p in RISKY]
    if kind == "account SAS":
        problems.append("account SAS cannot use a stored access policy: revoking means rotating the key")
    elif kind == "service SAS":
        problems.append("no stored access policy: revoking means rotating the account key")
    if "se" in q:
        start = when(q["st"]) if "st" in q else datetime.now(timezone.utc)
        hours = (when(q["se"]) - start).total_seconds() / 3600
        if hours > MAX_HOURS:
            problems.append(f"valid for {hours:,.0f} hours (until {q['se']})")
    host_path = url.split("?")[0]
    return host_path, kind, problems


if __name__ == "__main__":
    found = 0
    for path in sys.argv[1:]:
        with open(path, encoding="utf-8", errors="replace") as f:
            for number, line in enumerate(f, 1):
                for match in URL.finditer(line):
                    found += 1
                    where, kind, problems = grade(match.group(0))
                    print(f"{path}:{number}: {where} [{kind}]")  # never print the sig
                    for problem in problems:
                        print(f"    - {problem}")
    sys.exit(1 if found else 0)

Policy beats discipline. A SAS expiration policy sets an upper limit on SAS validity for every SAS type; its action is Log by default, and Block refuses out-of-policy SAS. Microsoft Learn notes that you may need to rotate both account keys once before the policy can be set, and that Azure File Sync needs at least three days. Disabling Shared Key access stops every request authorized with the account key, including service and account SAS, so only Entra ID and user delegation SAS remain. The commands below follow the current Azure CLI reference; they were checked for shell syntax but not run against an Azure subscription for this page.

# Cap SAS lifetime at 1 hour and refuse longer ones (Block); the default is Log.
az storage account update --name stexample --resource-group rg-example \
  --sas-expiration-period 0.01:00:00 --sas-expiration-action Block

# Stop account-key (Shared Key) authorization, which also stops service and
# account SAS; only Microsoft Entra ID and user delegation SAS remain.
az storage account update --name stexample --resource-group rg-example \
  --allow-shared-key-access false --allow-blob-public-access false

# Share one blob, read-only, for 30 minutes, signed with Entra ID, not the key.
end=$(date -u -d "+30 minutes" '+%Y-%m-%dT%H:%MZ')   # GNU date; macOS: date -u -v+30M ...
az storage blob generate-sas --account-name stexample --container-name models \
  --name model-v1.bin --permissions r --expiry "$end" --https-only \
  --as-user --auth-mode login --full-uri

The SSDF column names NIST SP 800-218 version 1.1 practices; the ASVS column names ASVS 5.0 requirements.

• A signed URL is a credential. Review it like one before it goes into a repository, notebook or README.
• Scope, lifetime and revocation decide the damage: one object, read-only, an hour, and a way to revoke it.
• Prefer user delegation SAS and turn off Shared Key; then no one can mint an unrevocable account-key SAS.
• A scanner that finds the secret is only as good as the triage that follows; audit closed alerts.
• Keep what you publish in a place that holds nothing else.

Microsoft's post does not state the token's permissions, scope or expiry beyond 'overly-permissive', and it does not give the volume of data in the storage account. Wiz reported that the token shared the entire storage account, including 38TB of private files, with 'full control' permissions, valid until 2051, and that the exposed data included over 30,000 internal Teams messages from 359 Microsoft employees; those figures are Wiz's and are not confirmed by Microsoft, whose account names two former employees' data. The public record does not say whether anyone other than Wiz used the token, how long the URL had been public, or exactly when the false-positive decision was made.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. MSRC: Microsoft mitigated exposure of internal information in a storage account due to overly-permissive SAS token. 18 September 2023.
2. Microsoft Learn: Grant limited access to data with shared access signatures (SAS). Updated 27 February 2026.
3. Microsoft Learn: Configure an expiration policy for shared access signatures
4. Microsoft Learn: Create a user delegation SAS (REST API)
5. Azure CLI reference: az storage account
6. Azure CLI reference: az storage blob generate-sas
7. Wiz (third-party research, discoverer): 38TB of data accidentally exposed by Microsoft AI researchers. 18 September 2023.

Reference information

Tags

Access controlSecrets managementCloud securityIncident responseModels and training data

SDLC phase

Maintenance

Role

Platform engineers and SREs

ASVS 5.0.0 requirements

v5.0.0-13.3.2 · v5.0.0-13.3.4

Download this guide as Markdown

Continue exploring