Sicherheitsforscher von Proofpoint haben eine Technik dokumentiert, mit der Angreifer Benutzernamen und Passwörter in Microsoft Entra ID überprüfen können, ohne jemals ein protokolliertes Anmeldeereignis auszulösen — eine blinde Stelle, die inzwischen in Kampagnen mit Millionen betroffener Konten ausgenutzt wird.
Was wäre, wenn Angreifer Tausende Benutzernamen und Passwörter gegen die Cloud-Identitätsverwaltung eines Unternehmens prüfen könnten, ohne auch nur ein einziges protokolliertes Anmeldeereignis auszulösen? Laut einer neuen Untersuchung des Sicherheitsanbieters Proofpoint ist dieses Szenario längst keine Theorie mehr. Die Forscher haben eine Technik namens OAuth Client ID Spoofing dokumentiert, mit der Angreifer bei Microsoft Entra ID die Gültigkeit von Konten und Passwörtern abfragen können, ohne dabei nennenswerte Spuren in den Standard-Anmeldeprotokollen zu hinterlassen.
Wie die Technik funktioniert
Microsoft Entra ID, der cloudbasierte Identitäts- und Zugriffsverwaltungsdienst von Microsoft, liefert je nach Gültigkeit einer übermittelten OAuth Client ID und danach, ob diese zu einer registrierten Anwendung gehört, unterschiedliche Antworten. Die Proofpoint-Forscher fanden heraus, dass sich dieses Verhalten gegen die Plattform selbst wenden lässt. Übermitteln Angreifer eine syntaktisch gültige, aber nicht registrierte Client ID, können sie feststellen, ob ein bestimmtes Nutzerkonto existiert und ob ein Passwort korrekt ist — ganz ohne ein erfolgreiches Anmeldeereignis zu erzeugen.
Entscheidend dabei: Beim Einsatz einer gefälschten Client ID wird im Anmeldeprotokoll kein Anwendungsname erfasst, sondern nur eine rohe Anwendungs-ID. Dieses eine fehlende Feld genügt, um Erkennungsregeln auszuhebeln, die nach verdächtiger Aktivität rund um eine bestimmte, benannte Anwendung suchen. Gefälschte IDs umgehen zudem Conditional-Access-Richtlinien, die auf bestimmte Anwendungen beschränkt sind, und indem Angreifer ihre Anfragen auf Tausende fiktive Anwendungs-IDs verteilen, unterlaufen sie anwendungsbezogenes Rate-Limiting und die Korrelation von Ereignissen. Proofpoint hebt dabei einen Fehlercode besonders hervor: AADSTS700016. Er erscheint, wenn Benutzername und Passwort korrekt sind, die Client ID jedoch nicht registriert ist — und wird leicht als gewöhnlicher Anmeldefehler abgetan, obwohl er tatsächlich gültige, funktionierende Zugangsdaten in den Händen eines Angreifers signalisiert.
Proofpoint erklärt, die Mechanik selbst in einer Laborumgebung simuliert zu haben, indem Anfragen an Microsofts OAuth-2.0-Token-Endpunkt über den Resource-Owner-Password-Credentials-Flow gesendet wurden, der die direkte Übermittlung von Benutzername und Passwort erlaubt. Bei der Prüfung von vier Szenarien — gültige registrierte Client IDs, gültige, aber nicht registrierte IDs, zufällige UUIDs und fehlerhafte Kennungen — bestätigten die Forscher, dass nur echte, registrierte Anwendungen ein vollständig protokolliertes Ereignis mit sowohl Anwendungs-ID als auch Anwendungsname erzeugen. In allen anderen Fällen bleibt das Feld für den Anwendungsnamen leer, unabhängig davon, ob die übermittelten Zugangsdaten korrekt waren.
UNK_PyReq2323: Enumeration im großen Stil über AWS-Infrastruktur
In der ersten von Proofpoint beobachteten Kampagne nutzte ein als UNK_PyReq2323 bezeichneter Akteur mehr als 700.000 verschiedene gefälschte Client IDs und operierte dabei aus einer AWS-Infrastruktur mit dem User Agent python-requests/2.32.3. Die Kampagne prüfte mehr als eine Million Nutzerkonten in knapp 4.000 Tenants. Das hohe Volumen fehlgeschlagener Versuche löste bei rund 28 Prozent der betroffenen Nutzer Kontosperren aus.
Die Methode zur Fälschung der Client IDs war dabei wenig ausgereift: Die Angreifer nutzten das bekannte Präfix der Anwendung „Exchange Online“ und randomisierten lediglich die letzten sechs Stellen. Da dieser Variationsspielraum begrenzt war, kam es zwangsläufig zu Mehrfachverwendungen derselben gefälschten ID — in manchen Fällen bei bis zu zwölf verschiedenen Konten, jedoch nie zweimal beim selben Konto.
UNK_OutFlareAZ: größere Reichweite, ausgereiftere Technik
Eine zweite, deutlich größer angelegte Kampagne, die Proofpoint als UNK_OutFlareAZ führt, operierte primär über Cloudflare-Infrastruktur und richtete sich gegen mehr als zwei Millionen Nutzer mit 3,7 Millionen gefälschten Anwendungs-IDs. Verwendet wurde der User-Agent-String für Microsoft Office/Outlook, den Proofpoint eigenen Angaben zufolge seit mehreren Jahren in zahlreichen Kampagnen beobachtet — ein Hinweis auf den Einsatz weit verbreiteter Angriffswerkzeuge.
Im Unterschied zu UNK_PyReq2323 generierte diese Gruppe für jeden einzelnen Authentifizierungsversuch eine vollständig zufällige UUIDv4, was die Korrelation für Verteidiger erheblich erschwert. Proofpoint stellte zudem fest, dass viele der anvisierten Nutzernamen typischen Namensmustern wie dsmith, msmith oder jbrown folgten und in mehreren Tenants wiederkehrten — ein Hinweis auf den Einsatz einer gemeinsamen, vorgefertigten Wortliste.
Zwei Akteure, eine Technik
Obwohl beide Kampagnen dieselbe zugrunde liegende Schwachstelle nutzten, unterschieden sie sich deutlich in User Agent, Infrastruktur, Methode zur ID-Generierung und Enumerationsmuster. Proofpoint wertet dies als Indiz dafür, dass unterschiedliche Bedrohungsakteure dieselbe Grundtechnik unabhängig voneinander übernommen haben — statt einer einzelnen Gruppe hinter beiden Operationen. Das deutet darauf hin, dass sich OAuth Client ID Spoofing als anerkanntes Handwerkszeug verbreitet und kein Einzelfall bleibt.
Was Verteidiger tun sollten
Proofpoint empfiehlt Sicherheitsteams, Anmeldeprotokolle gezielt auf Einträge ohne Anwendungsnamen zu überwachen, da eine solche Lücke auf den Einsatz einer gefälschten Client ID hindeuten kann. Insbesondere der Fehlercode AADSTS700016 sollte nicht als gewöhnlicher Anmeldefehler abgetan werden — er kann ein starkes Indiz für kompromittierte Zugangsdaten sein. Unternehmen sollten zudem prüfen, ob ihre bestehenden Conditional-Access-Richtlinien auch gegenüber nicht registrierten Anwendungs-IDs wirksam greifen, da eng auf benannte Anwendungen beschränkte Richtlinien diese Aktivität nicht erfassen.
Klassische Enumerationswerkzeuge zielen meist auf eine Handvoll fest codierter Erstanbieter-Anwendungen ab, die standardmäßig in jedem Tenant vorhanden sind. Werden Anfragen stattdessen auf Tausende fiktive Anwendungs-IDs verteilt, wird der Datenverkehr für Verteidiger erheblich schwerer nachzuvollziehen. Die Erkenntnisse von Proofpoint legen nahe, dass Angreifer zunehmend Lücken in der Protokollierung ausnutzen — nicht Lücken in der Authentifizierung selbst —, um unentdeckt zu bleiben.
Dr. Jakob Jung ist Chefredakteur Security Storage und Channel Germany. Er ist seit mehr als 20 Jahren im IT-Journalismus tätig. Zu seinen beruflichen Stationen gehören Computer Reseller News, Heise Resale, Informationweek, Techtarget (Storage und Datacenter) sowie ChannelBiz. Darüber hinaus ist er für zahlreiche IT-Publikationen freiberuflich tätig, darunter Computerwoche, Channelpartner, IT-Business, Storage-Insider und ZDnet. Seine Themenschwerpunkte sind Channel, Storage, Security, Datacenter, ERP und CRM.
Kontakt – Contact via Mail: jakob.jung@security-storage-und-channel-germany.de