I Could've Accessed 17T Microsoft Records

How one unchecked login token put 17 trillion rows in a Microsoft internal analytics service within reach. An estimated 17.3 trillion stored rows across a wide range of Microsoft datasets were reachable through a single internal analytics service, all because it never checked the signature on a login token. That flaw let me claim an administrator’s identity and submit unauthorized SQL queries without any real credentials. I used only table descriptions, metadata, and bounded sample rows to understand the potential scope. Two quick notes first. The impact I describe is hypothetical. It’s what an attacker could have done with this access, but luckily I found the bug instead, reported it, and never touched any customer data or PII. And for transparency: Microsoft had editorial control over this post, cutting sections and figures and reshaping how the impact is described before publication. “We appreciate the opportunity to investigate the findings reported by Faav. Their submission and coordinated vulnerability disclosure helped us to better protect our customers by hardening our services. We value and appreciate safe security research under the terms of the Microsoft Bug Bounty Program and look forward to continuing to work with Faav in the future.” Hey! I’m Faav. A little over a year ago, when I was 15, I published Break into any Microsoft building: Leaking PII in Microsoft Guest Check-In , my first Microsoft write-up. I’m 16 now, and this one is a little bigger. Since then I’ve gone all-in on bug bounty. I’ve spent the year hacking Microsoft off and on around school, and finding bugs across Amazon, Google, Adobe, and a bunch of other companies.

I also started building AI into how I hunt, which led me to develop Antares, my personal AI hackbot. This one started as an automated lead that Antares couldn’t finish. Ten days later, after a Friday of schoolwork and one late-night hunch, it turned into the biggest Microsoft bug I’d ever found. On August 25, 2026, Antares identified an internal Microsoft service called Titan. Its web interface sat behind a VPN REQUIRED page for Microsoft employees, so the frontend was out of reach. But since when has a locked front door stopped anyone? The “VPN REQUIRED” page shown to a non-employee visiting Titan’s frontend. The API wasn’t linked anywhere on the frontend, so Antares searched Microsoft subdomains and found a separate endpoint that resolved to an Azure Cloud Services host. Its public Swagger file listed four routes: /Get Configuration /Get Onboarded Tables /v2/Query /v2/Insert The Swagger doc specified Azure AD bearer authentication for three of the four routes. The exception was /v2/Query , which also happened to be the one that accepted raw SQL. So naturally, that’s where I started poking. The query needed a table Name , and Swagger gave no example values. I pulled 2023 snapshots of Titan’s login and privacy pages from the Wayback Machine, and reading the archived Superset configuration recovered 56 table definitions, including a routing value called Test Data . The archived Titan interface before the current VPN restriction. POST /v2/Query HTTP / 1.1 Host : [redacted] Content-Type : application/json { "query" : "SELECT 1" , "table Name" : "Test Data" , "row Limit" : 1 } With no authorization header it returned 401 Unauthorized , so Antares started probing how it validated JWTs.

Over the next ten days, while I worked through hundreds of other leads, Antares kept coming back to Titan and chipping away at its JWT checks one error at a time. It started with a token from my external Entra test tenant, created months earlier and used regularly for testing. Titan threw back a tenant error. Changing the tenant to Microsoft’s reached an audience error. Changing the audience hit an application allowlist error. Changing the application ID finally reached a user lookup. The payload kept changing while the signature stayed exactly the same, and Titan kept accepting the new claims, like a bouncer checking the name on every ID but never looking at the photo. That was the first big clue it wasn’t verifying signatures. I’d exploited an unsigned JWT bypass by hand before I ever used AI, so I recognized the pattern immediately. Next I replaced the token entirely with a synthetic JWT using this header: { "alg" : "none" , "typ" : "JWT" } A normal signed JWT has three populated sections: header.payload.signature . Mine ended with a bare period, because the third section was empty: base64url(header).base64url(payload). Titan wasn’t validating the signature at all. The payload used the values Titan expected, but with a upn I controlled: { "aud" : "[redacted]" , "tid" : "[redacted]" , "appid" : "[redacted]" , "upn" : " [email protected] " , "oid" : "00000000-0000-0000-0000-000000000000" } That cleared the tenant, audience, and application checks, then returned: User ' [email protected] ' not found Antares was running Codex and Claude on the lead. Because a UPN is normally an email-formatted Entra identity, both models kept testing placeholders, published service aliases, and Microsoft employee-style addresses. The unsigned token was already reaching Titan’s local user lookup.

⚡ Effects Interpreter