Dritter und vierter Fall einer Umgehungs-Schwachstelle in Azure-Entra-ID-Anmeldeprotokollen offengelegt

 (trustedsec.com)
1 Punkte von GN⁺ 2026-03-22 | 1 Kommentare | Auf WhatsApp teilen
  • Seit 2023 wurden insgesamt vier Schwachstellen zur Umgehung von Azure-Entra-ID-Anmeldeprotokollen entdeckt; die beiden jüngsten erwiesen sich als schwerwiegende Probleme, bei denen reguläre Token ausgestellt werden konnten
  • GraphGoblin umgeht im OAuth2-ROPC-Flow die Protokollerstellung, indem der Parameter scope wiederholt eingegeben wird, und Graph**** lässt durch einen User-Agent-String mit mehr als 50.000 Zeichen Protokolle vollständig ausfallen
  • Bei beiden Schwachstellen wurde ein Logging-Fehler durch Überschreitung der SQL-Spaltenlänge als Ursache genannt; Microsoft hat die Probleme nach der Meldung behoben
  • Microsoft stufte das Problem als „Mittel (Medium)“ ein und behebte es stillschweigend ohne Prämie oder offizielle Anerkennung; nach CVSS wird es als High (7,5–8,7 Punkte) bewertet
  • Da sich Fehler durch wiederholtes Versagen bei der Eingabevalidierung fortsetzen, werden Cross-Checks von Logs und eine Verschärfung KQL-basierter Erkennungsregeln für Sicherheitsverantwortliche als zwingende Aufgabe genannt

Offenlegung von Schwachstellen zur Umgehung von Azure-Entra-ID-Anmeldeprotokollen

  • Seit 2023 wurden insgesamt vier Schwachstellen zur Umgehung von Azure-Entra-ID-Anmeldeprotokollen entdeckt
    • Bei den ersten beiden war nur eine Prüfung der Passwortgültigkeit möglich, die beiden jüngsten erreichten jedoch ein schwerwiegenderes Niveau, bei dem sogar reguläre Token ausgestellt werden konnten
    • Alle Schwachstellen wurden inzwischen von Microsoft behoben

  • Zusammenfassung von GraphNinja und GraphGhost

    • GraphNinja: Wird beim Anmeldeversuch ein Endpunkt eines anderen Tenants angegeben, lässt sich erkennen, ob ein Passwort gültig ist, ohne dass ein Log erzeugt wird
      • Angreifer können Authentifizierungsanfragen an einen externen Tenant senden und anhand der Antwort prüfen, ob das Passwort korrekt ist
      • Microsoft führte später zusätzliches Logging ein, um dieses Problem zu beheben
    • GraphGhost: Bei Verwendung einer ungültigen Client ID schlägt der Authentifizierungsfluss erst nach der Passwortprüfung fehl, im Log erscheint dies jedoch nur als Fehlschlag
      • Die Information, dass das Passwort korrekt war, bleibt in den Administrator-Logs unsichtbar
      • Microsoft behob das Problem, indem in die Anmeldeprotokolle aufgenommen wurde, ob eine Passwortprüfung stattgefunden hat

  • Schwachstelle GraphGoblin

    • GraphGoblin umgeht im OAuth2-ROPC-Flow die Protokollerstellung, indem der Parameter scope wiederholt eingegeben wird
      • Wird eine Zeichenfolge der Form "openid openid openid ..." tausendfach wiederholt eingegeben, wird ein reguläres Token ausgestellt, aber in den Entra-ID-Anmeldeprotokollen bleibt keinerlei Eintrag zurück
    • Als Ursache wird ein INSERT-Fehler durch Überschreitung der SQL-Spaltenlänge genannt
      • Vermutet wird, dass das Speichern des Logs fehlschlug, weil die wiederholte Scope-Zeichenfolge die Feldlänge der Datenbank überschritt
    • Microsoft hatte zunächst Schwierigkeiten, das Problem nachzustellen, behob es jedoch nach Vorlage eines Video-Belegs

  • Graph****** (User-Agent-basierte Umgehung)

    • Wird im Feld User-Agent eine lange Zeichenfolge mit mehr als 50.000 Zeichen eingegeben, wird kein Log erzeugt
      • Die Authentifizierungsanfrage wird regulär verarbeitet und ein Token ausgestellt, das Log fehlt jedoch vollständig
      • Vermutet wird ein Logging-Fehler durch Überschreitung der SQL-Spaltenlänge
    • Entdeckt am 28.09.2025; am 08.10. hatte Microsoft das Problem bereits vor der Meldung behoben

  • Zusammenfassung der Timeline

    • 2025-09-20: GraphGoblin erstmals entdeckt
    • 2025-09-26: GraphGoblin an Microsoft gemeldet
    • 2025-09-28: Graph****** entdeckt
    • 2025-10-08: Graph****** vollständig behoben
    • 2025-11-21: Microsoft konnte GraphGoblin reproduzieren und begann mit der Behebung

Reaktion und Bewertung von Microsoft

  • Microsoft stufte diese Schwachstellen als „Mittel (Medium)“ ein und gewährte weder eine Prämie noch eine öffentliche Anerkennung
    • Für die beiden früheren Fälle (2023–2024) gab es Prämien und Anerkennung
    • Diesmal wurde das Problem trotz der Schwere, dass reguläre Token ausgestellt werden konnten, als nicht wichtig eingestuft
  • Die Bewertung liegt bei 7,5 Punkten (High) nach CVSS v3.1 und 8,7 Punkten (High) nach v4.0
    • Die hohe Punktzahl ergibt sich durch Beeinträchtigung der Integrity (Integrität)
    • Fehlende Logs gelten als direkte Beeinträchtigung einer Sicherheitskomponente
  • Microsoft behob das Problem innerhalb von zwei Wochen nach erfolgreicher Reproduktion
    • Die frühere Behebung von GraphNinja dauerte 7 Monate, bei GraphGhost 5 Monate

Methoden zur Erkennung der Log-Umgehung

  • Über eine KQL-Abfrage lassen sich die Session ID oder der UniqueTokenIdentifier aus Graph-Activity-Logs und Sign-In-Logs vergleichen
    • Sitzungen, die in Graph Activity vorhanden sind, aber nicht in den Sign-In-Logs, können als umgangene Anmeldungen gewertet werden
    • Das Sammeln von Graph-Activity-Logs ist allerdings nur mit einer E5-Lizenz möglich
  • Beispiel für eine KQL-Abfrage: 
    MicrosoftGraphActivityLogs
| where TimeGenerated > ago(8d)
| join kind=leftanti (union isfuzzy=true
SigninLogs,
AADNonInteractiveUserSignInLogs,
AADServicePrincipalSignInLogs,
AADManagedIdentitySignInLogs,
MicrosoftServicePrincipalSignInLogs
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
)
on $left.SignInActivityId == $right.UniqueTokenIdentifier
    • Bei Bedarf ist auch ein Vergleich auf Basis von SessionId möglich
    • Auf Grundlage der Erkennungsergebnisse kann eine Azure Log Search Alert Rule eingerichtet werden

Zusammenfassung der vier Umgehungen der Anmeldeprotokolle

Zeitpunkt der Entdeckung Methode Token-Ausstellung möglich Von Microsoft anerkannt
2023-08 / 2024-05 Keine Protokollierung der Passwortprüfung durch Angabe einer externen Tenant-ID X X
2024-12 / 2025-04 Erzwingen eines Authentifizierungsfehlers mit ungültiger Client ID X X
2025-09-20 SQL-Spaltenüberlauf durch wiederholte Scope-Eingabe O X
2025-09-28 SQL-Spaltenüberlauf durch langen User-Agent-String O N/A

Kritik an Microsofts Sicherheitsprozessen

  • Schwachstellen in zahlreichen Parametern der Entra-ID-Anmeldelogging-Funktion gefunden

    • Wiederholte Schwachstellen in zentralen Feldern wie tenant ID, client ID, scope, user-agent
    • Die Ursache ist ein einfacher Fehler bei der Eingabevalidierung, kein komplexer Angriff
    • Kritisiert werden fehlende Sicherheitsprüfung und Qualitätskontrolle bei Microsoft
    • Über Jahre hinweg wiederholen sich ähnliche Fehler im selben Bereich
    • Es wird die Möglichkeit aufgeworfen, dass bei der Einführung von KI-Codegenerierung oder im Code-Management-Prozess Lücken entstanden sind

  • Mangel an Transparenz bei der Offenlegung

    • Für keinen der vier Fälle wurde eine CVE vergeben, es gab keine offizielle Mitteilung
    • Microsoft entscheidet als CNA exklusiv darüber, ob eigene Schwachstellen offengelegt werden

Fazit

  • Die Anmeldeprotokolle von Azure Entra ID sind Kerndaten für die Angriffserkennung in Organisationen weltweit
    • Fehlen Logs, kann die gesamte Angriffserkennung unwirksam werden
  • Alle vier entdeckten Schwachstellen waren auf einem Niveau, das sich durch einfaches Input-Fuzzing erkennen ließ
  • Microsoft muss für diese wiederkehrenden Mängel öffentliche Erklärungen liefern und transparente Sicherheitsprüfungen ausbauen
  • Administratoren und Sicherheitsverantwortliche sollten ihre Abwehr durch Cross-Checks von Logs und KQL-basierte Erkennungsregeln ergänzen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-22
Hacker-News-Kommentare

  • Das erinnert an den Bericht zum Microsoft-Vorfall von CISA
    Dabei drangen staatlich unterstützte Hacker bei Microsoft ein und kompromittierten mehrere Behörden, darunter das US-Außenministerium
    Bemerkenswert war, dass nicht Microsoft, sondern ein Systemadministrator im Außenministerium Unregelmäßigkeiten in den Mail-Logs entdeckte und so den Einbruch aufdeckte
    Link zum CISA-Bericht

  • In einem Artikel von ProPublica und ArsTechnica, der Azure frontal kritisierte, hieß es, föderale Cyberexperten hätten die Microsoft-Cloud als „miserabel“ bezeichnet
    Artikellink

    • Tatsächlich scheint ein Experte damit eher die Dokumentationsqualität gemeint zu haben, und ProPublica hat das wohl auf Azure insgesamt ausgeweitet
    • Ars hat das lediglich unter Lizenz erneut veröffentlicht
    • Die Azure-Security-Ingenieure, die ich kenne, sind fast alle mental am Zusammenbrechen. Von etwa 12 Leuten ist die Hälfte ausgebrannt, und der Rest ist fachlich zu schwach
    • Bloomberg oder CNBC haben den Fall nicht aufgegriffen. Ich wünschte, jemand würde das über Medienkontakte weitergeben

  • Der aktuelle Zustand der Cybersicherheit ist für ein System, von dem die gesamte Zivilisation abhängt, viel zu wacklig
    Es ist, als würde man ein leckes Boot mit Panzerband abdichten und damit auf den Ozean hinausfahren

    • Noch schlimmer ist, dass die Branche auf diese Löcher reagiert, indem sie mehr Maschinengewehrtürme aufstellen will, statt sie zu stopfen

  • In der Diskussion über SQL-Logs sieht es so aus, als habe der Angreifer eine zu lange Eingabe gesendet, sodass das INSERT wegen Überschreitung der Spaltenlänge fehlschlug
    Dadurch wurde der Anmeldeversuch offenbar nicht protokolliert

    • Die beiden Services liefen als getrennte Komponenten. Der Prüfservice erkannte den Fehler und forderte den Logging-Service zum Schreiben eines Eintrags auf, aber selbst wenn der Logging-Service scheiterte, lieferte der Prüfservice weiterhin eine Antwort zurück
      Das wirkt wie ein strukturelles Problem durch zu komplexes Design im Authentifizierungsfluss

  • Ich habe erlebt, dass die Audit-Logs von Azure etwas anderes aufzeichneten als das, was tatsächlich passiert ist
    Ich löschte ein Client Secret, und während die UI anzeigte, dass B gelöscht würde, ließ die API am Ende nur A übrig
    Im Log sah es dann so aus, als hätte ich das getan, obwohl es in Wirklichkeit ein Systemfehler war
    Seit diesem Erlebnis ist mein Vertrauen in Azure-Logs wie auch in Audit-Logs allgemein erschüttert
    Ich halte sie für riskant als Beweismittel vor Gericht

    • Deshalb bevorzuge ich UIs mit einem Bestätigungsschritt vor Änderungen. Solche „videospielartigen“ Auto-Save-Oberflächen sind zu riskant
    • Dass das Azure-Portal (neue wie alte Version) voller Bugs ist, überrascht mich nicht. Manchmal ändert ein falsch geklickter Button ein ganz anderes Objekt
    • Dieser Fall ist ein gutes Lehrbeispiel für die Risiken von Set-Operationen vs. Delete-Operationen in Umgebungen mit gleichzeitiger Bearbeitung. Das Log war korrekt, aber das UI-Design war das Problem
    • Am Ende drückt der Nutzer nur seine Absicht aus, während die tatsächliche Ausführung vom Frontend gesteuert wird — das ist ein beunruhigender Gedanke

  • Verglichen mit den jüngsten EntraID-Schwachstellen wirkt Log-Umgehung weniger wichtig

    • Wenn zentrale Authentifizierungs-Logs jedoch nur nach dem Prinzip „best effort“ funktionieren, ist das ein schwerwiegendes Problem als Grundlage für Sicherheits-Audits
    • Letztlich bestehen erfolgreiche und unauffällige Angriffe oft aus dem Zusammenspiel mehrerer Schwachstellen

  • Microsoft hat sogar schon in Notepad kritische Schwachstellen eingebaut, daher überrascht mich so etwas nicht

  • Als ich vor einiger Zeit Azure VPN evaluiert habe, wurden erfolgreiche oder fehlgeschlagene Verbindungen überhaupt nicht protokolliert
    Als ich das ansprach, sagte Microsoft, ich solle das als Feature Request einreichen
    Damals habe ich mein Vertrauen in Azure vollständig verloren. Mit der Zeit scheint es nicht besser, sondern eher schlimmer zu werden

  • Dass IT-Administratoren Microsoft weiter nutzen, liegt daran, dass es keine echten Alternativen gibt

    • In Umgebungen wie meiner, in denen ich .NET-basierte LOB-Apps und diverse SaaS-Dienste verwalten muss, sind Microsoft-Lösungen die realistischste Wahl
      Das Budget ist knapp und das Personal fehlt, also halte ich es einfach auf einem Niveau, bei dem ich mein Gehalt bekomme und abends nach Hause gehen kann
    • Jüngere Administratoren neigen stark dazu, Microsoft zu hassen. Das könnte ein Generationenunterschied sein
    • Wie man sagt: „Nobody ever got fired for buying X“ — die Wahl von Microsoft birgt wenig Karriererisiko

  • Beeindruckend war, dass Microsoft, als es die Azure-Schwachstelle nicht reproduzieren konnte und Videobeweise verlangte, sie mit einer einzigen Zeile curl-Befehl demonstriert bekamen
    Das war wirklich ein herrlich befriedigender Moment