Wie kommt man ohne gültige Zugangsdaten an 17 Billionen Microsoft-Datensätze? Die Antwort führt zu einem internen Analytics-Dienst namens Titan und zu einer einzigen Prüfung, die dort nicht stattfand. Der Sicherheitsforscher, der unter dem Namen Faav auftritt, hat den Fall im September 2026 veröffentlicht. Er beschreibt darin eine Microsoft Sicherheitslücke, die ihn rund zehn Tage beschäftigt hat. Ausgangspunkt war ein automatischer Hinweis seines selbstgebauten KI-Werkzeugs Antares, das er als persönlichen Hackbot bezeichnet.
Faav ist inzwischen 16 Jahre alt und arbeitet seit gut einem Jahr im Rahmen des Microsoft Bug Bounty Program. Microsoft habe vor der Veröffentlichung redaktionell in den Beitrag eingegriffen, Abschnitte und Abbildungen gekürzt und die Darstellung der Auswirkungen umformuliert, berichtet er. Die geschilderte Wirkung sei hypothetisch: Er habe keine Kundendaten und keine personenbezogenen Informationen ausgelesen, sondern die Schwachstelle über den offiziellen Weg gemeldet. Genau das ist der Kern einer koordinierten Offenlegung einer Microsoft Sicherheitslücke dieser Größenordnung.
Die Titan API: ein interner Dienst mit offener Flanke
Titan ist ein interner Microsoft Analytics Service. Über ihn lassen sich Datenbanken abfragen, virtuelle Datensätze definieren und Dashboards betreiben. Seine Weboberfläche liegt hinter einer Seite, die ohne Firmen-VPN keinen Zugang erlaubt, sodass der sichtbare Teil für Außenstehende verschlossen wirkt. Hier setzt eine Analogie an, die sich durch den ganzen Fall zieht: ein Hotel mit elektronischen Türschlössern, bei dem jedes Zimmer seinen eigenen Kartenleser besitzt, am Ende aber jede beliebige Karte jede Tür öffnet. Der Vordereingang war verschlossen, die Nebenpforte stand weit offen.
Antares durchsuchte Microsoft-Subdomains und stieß auf einen separaten Endpunkt, der auf einen Azure Cloud Services Host auflöste. Dessen öffentlich erreichbare Swagger-Datei listete vier Routen auf, und drei davon verlangten laut Dokumentation eine Azure AD Bearer-Authentifizierung. Die Ausnahme war die Route /v2/Query, die zugleich rohe SQL-Abfragen entgegennahm. Dort begann die weitere Untersuchung. Ein Endpunkt, der beliebige Abfragen entgegennimmt und als einziger ohne dokumentierte Absicherung auskommt, ist ein naheliegender Startpunkt.
Die Abfrage verlangte einen Wert namens tableName, doch Swagger lieferte keine Beispiele. Über archivierte Momentaufnahmen der Titan-Anmeldeseite aus dem Jahr 2023 und eine gespeicherte Superset-Konfiguration kamen 56 Tabellendefinitionen zum Vorschein, darunter ein Routing-Wert mit dem Namen TestData. Ein Test gegen die Live-API mit diesem Wert lief ohne Autorisierungsheader in ein 401 Unauthorized. Das bestätigte, dass es Zugangskontrollen gab – die Frage war nur, wie gründlich sie arbeiteten.
Warum die JWT-Authentifizierung zur offenen Tür wurde
Ein JSON Web Token besteht normalerweise aus drei durch Punkte getrennten Abschnitten: Header, Payload und Signatur. Die Signatur beweist, dass das Token tatsächlich von der erwarteten Stelle ausgestellt wurde und nicht nachträglich verändert worden ist. Wird nur der Inhalt geprüft und die Signatur ignoriert, lässt sich jedes beliebige Token selbst bauen – so wie ein Pförtner, der den Namen auf dem Ausweis liest, aber nie das Foto daneben anschaut. Die JWT-Authentifizierung wird damit zur bloßen Formalie.
Titan gab bei der Prüfung nacheinander verschiedene Fehlermeldungen zurück: erst zur Mandantenzuordnung, dann zur Zielgruppe, dann zu einer Anwendungs-Allowlist und schließlich zu einer Nutzersuche. Faav änderte jedes Mal nur den Inhalt des Tokens und ließ die Signatur unverändert. Der Dienst akzeptierte die neuen Angaben trotzdem. Das war der entscheidende Hinweis darauf, dass die Signatur überhaupt nicht überprüft wurde.
Anschließend ersetzte der Forscher das Token durch ein selbst gebautes, dessen dritter Abschnitt leer blieb. Ein normales Token endet auf drei gefüllte Segmente, das synthetische endete auf einen bloßen Punkt, weil die Signatur fehlte. Der Dienst nahm es dennoch an und führte die Abfrage aus. Damit war die interne Microsoft Analytics Service Sicherheitslücke im Kern nachgewiesen: nicht ein einzelner Fehler in einer Randfunktion, sondern die zentrale Vertrauensprüfung fehlte.
Der Zufallstreffer mit dem Nutzernamen „admin“
Der Nutzeranspruch im Token trägt üblicherweise einen Namen, der wie eine E-Mail-Adresse aussieht, weil er aus der Entra-Identität stammt. Antares testete über Tage hinweg Platzhalter, veröffentlichte Dienstaliase und Adressen im Mitarbeiterstil. Titan antwortete stets mit einer Meldung, dass kein passender Nutzer gefunden wurde. Das Token passierte also alle Authentifizierungsschichten, scheiterte aber an der lokalen Zuordnung.
Faav überlegte, was das Backend mit dem Anspruch tatsächlich anstellt, und vermutete, dass der Wert als lokaler Anwendungsbenutzername verwendet wird. Er setzte statt einer E-Mail-Adresse schlicht admin ein und erhielt als Antwort die Zahl 1. Nach zehn Tagen voller Authentifizierungsfehler war das eine aussagekräftige Zahl, denn sie markierte den lokalen Benutzer mit der Administratorrolle. An diesem Punkt liefen unautorisierte SQL-Abfragen gegen Microsofts interne Analytik, und zwar mit den Rechten des höchsten lokalen Kontos.
admin ist offensichtlich – und zugleich offensichtlich kein gültiger Wert für diesen Anspruch. Genau deshalb hatte das KI-Werkzeug ihn nie ausprobiert, weil es das Feld beim Wort nahm. Der Mensch dagegen hatte die Bedeutung des Feldnamens infrage gestellt und sich gefragt, was ein Entwickler im Backend wohl gebaut haben könnte. Manchmal ist die Antwort so einfach, wie sie aussieht.
Was hinter der Tür lag: die 17 Billionen Microsoft Datensätze
Zuerst probierte der Forscher die naheliegende Tabelle TestData und fand dort erwartungsgemäß Testfälle. Ein SHOW DATABASES zeigte jedoch die gesamte Landschaft, darunter die Plattform-Metadatenbank, aus der sich Anwendungstabellen direkt abfragen ließen. Dort fand sich eine Tabelle mit rund 25.000 aktiven Konten samt Namen, E-Mail-Adressen und Anmeldeverlauf, dazu 17.990 Mitarbeiter-E-Mail-Adressen, 15.001 Organisationsdatensätze, 355 Datenbankkonfigurationen und 20.979 virtuelle SQL-Definitionen. Hinzu kamen rund 24.600 Dashboards, über 425.000 Diagramme und knapp 27.400 Datensatzdefinitionen.
Weil mehr als ein Datensatz dieselbe Kennung für Nutzer enthielt, wäre eine Verknüpfung von Aktivitäten über Dienste hinweg denkbar gewesen. Der Autor hat das nicht versucht. Stattdessen blieb er bei zwei Ein-Zeilen-Stichproben aus einer Bing-Analytik-Partition, um die Erreichbarkeit zu belegen, ohne Inhalte auszuwerten. Die enthaltenen Ortsangaben stammten aus Reverse-IP-Zuordnungen und beschrieben Länder oder Bundesstaaten, keine präzisen Aufenthaltsorte.
Den Gesamtumfang ermittelte der Forscher zuletzt über die 56 Routing-Werte, von denen 30 noch aktiv waren. Diese 30 Werte führten über 24 Konfigurationen zu 17 verbundenen Analytik-Datenbanken mit 9.863 eindeutigen Tabellennamen. Über zwei Metadatenpfade zählte er je eine Replik pro Shard und kam auf eine Zahl, die er erst in Dreiergruppen gliedern musste, um sie lesen zu können: 17.333.335.124.315 Zeilen. Das ist eine Speicherschätzung aus Metadaten, die historische, duplizierte und abgeleitete Daten einschließen dürfte. Die Größenordnung bleibt bemerkenswert.
Wenn KI rechnet und der Mensch kombiniert
Antares hatte über zehn Tage hinweg Arbeit erledigt, die von Hand kaum zu leisten gewesen wäre: Subdomains aufzählen, die Fehlermeldungen der JWT-Prüfung Feld für Feld durchspielen, die Angriffsfläche kartieren und das unsignierte Token durch vier Prüfschichten bringen. Was das Werkzeug nicht schaffte, war der gedankliche Schritt, dass der Anspruch auf einen Nutzernamen keineswegs ein Nutzername sein musste. Der sture Optimierer blieb in seiner Annahme gefangen, weil er den Feldnamen wörtlich genommen hatte.
Faav zieht daraus eine nüchterne Lehre: Das Werkzeug habe die Ausdauer geliefert, der Mensch den entscheidenden Einfall, und keine der beiden Seiten hätte allein zum Ziel geführt. Solche Schilderungen sind für den aktuellen Stand automatisierten Hackens aufschlussreich, weil sie nicht in Hype verfallen, sondern die Grenze klar benennen. Ein Werkzeug kann Tausende Varianten prüfen, aber es kann nicht den Kontext eines fremden Backends erraten.
Bemerkenswert ist auch der Umgang mit dem Fund. Sobald die Mitarbeiterdatensätze sichtbar waren, begann der Forscher mit einem Bericht an das Microsoft Security Response Center; nach der Bing-Stichprobe meldete er sofort. Der Fall wurde unter der Nummer 144051 noch am selben Tag eröffnet, und Microsoft bat anschließend darum, weitere Tests einzustellen. Das Unternehmen lobt in seiner Antwort die koordinierte Offenlegung im Rahmen des Microsoft Bug Bounty Program und den Beitrag zum Schutz der Kunden.
Was Entwickler und Unternehmen daraus mitnehmen sollten
Die technische Lehre ist einfach und unbequem: Beim Bau von Authentifizierung ist die Signaturprüfung nicht eine Prüfung unter vielen, sondern die Grundlage, auf der alle anderen Kontrollen erst Sinn ergeben. Ein Dienst kann Mandant, Zielgruppe, Anwendungs-ID und Nutzer korrekt prüfen – doch wenn die Signatur fehlt, prüft er nur, ob jemand die richtigen Wörter kennt. Der gesamte Zugriffsschutz existierte in der Anwendung und wurde durch eine einzige unterlassene Prüfung entwertet.
Für Entwicklerteams heißt das: bei jedem JSON Web Token zuerst die Signatur verifizieren, bevor irgendein Anspruch ausgewertet wird. Zusätzlich lohnt es, interne Feldnamen nicht als selbstverständlich zu behandeln. Wenn ein Wert als Nutzername dienen soll, sollte das Backend ihn auch als solchen behandeln und nicht als Identitätsadresse interpretieren. Solche Details entscheiden über Erfolg oder Misserfolg eines Angriffs, und sie lassen sich in Code-Reviews gezielt suchen.
Viele Schwachstellen dieser Art bleiben unentdeckt, weil sich niemand die Mühe macht, einen öffentlichen Endpunkt systematisch abzuklopfen. Der Fall zeigt, wie viel ein einzelner nicht abgesicherter API-Pfad in einem ansonsten gut geschützten Umfeld freilegen kann. Wer in einem Bug-Bounty-Programm unterwegs ist, findet dort oft mehr Wirkung als im offensichtlichen Frontend. Für Microsoft ist der Vorgang eine Erinnerung, dass interne Werkzeuge mit Datenzugriff dieselbe Härte verdienen wie kundenseitige Dienste.
Eine hypothetische Reichweite von 17 Billionen Zeilen klingt spektakulär. Entscheidend ist, dass niemand diese Zugänge ausgenutzt hat und die Lücke über die koordinierte Offenlegung geschlossen wurde. Der eigentliche Wert des Berichts liegt weniger in der Zahl als in der Lücke selbst. Ein signaturloses Token ist kein exotisches Randproblem, sondern ein wiederkehrendes Muster, das sich mit wenigen Codezeilen vermeiden lässt.
Quelle: blog.faav.net
