Terrance DeJesus

Microsoft Entra ID OAuth-Phishing und -Erkennungen

Ein Crashkurs über In-the-Wild (ItW) Entra ID OAuth-Phishing- und Erkennungsstrategien

40 Minuten LesezeitDetection Engineering
Microsoft Entra ID OAuth-Phishing und -Erkennungen

Präambel

Mitglieder des Threat Research and Detection Engineering (TRADE)-Teams bei Elastic haben kürzlich ihre Aufmerksamkeit auf eine neue Klasse von Bedrohungen gelenkt, die auf OAuth-Workflows in Microsoft Entra ID (ehemals Azure AD) abzielen. Diese Studie wurde von Volexitys jüngstem Blog Phishing for Codes: Russian Threat Actors Target Microsoft 365 OAuth Workflows inspiriert, in dem eine ausgeklügelte OAuth-Phishing-Kampagne gegen NGOs dem Bedrohungsakteur zugeschrieben wird, der als UTA0352 bezeichnet wird.

Die Untersuchung von Volexity liefert überzeugende forensische Beweise dafür, wie Angreifer vertrauenswürdige Microsoft-Anwendungen von Erstanbietern missbraucht haben, um traditionelle Abwehrmaßnahmen zu umgehen. Unter Verwendung legitimer OAuth-Flows und des Open-Source-Tools ROADtools erstellten die Akteure benutzerdefinierte Microsoft-Authentifizierungs-URLs, sammelten Sicherheitstoken und nutzten sie, um sich als Benutzer auszugeben, Berechtigungen zu erhöhen und Daten über Microsoft Graph zu exfiltrieren – einschließlich des Herunterladens von Outlook-E-Mails und des Zugriffs auf SharePoint-Websites.

Während der Bericht das Was des Angriffs gründlich dokumentiert, konzentrierte sich unser Team bei Elastic darauf, das Wie zu verstehen. Wir haben die Angriffskette in einer kontrollierten Umgebung emuliert, um die Mechanismen des Token-Missbrauchs, der Geräteregistrierung und der Token-Anreicherung aus erster Hand zu untersuchen. Diese praktischen Experimente lieferten tiefere Einblicke in das Innenleben der OAuth-Implementierung von Microsoft, den praktischen Einsatz von ROADtools, empfohlene Gegenmaßnahmen und vor allem effektive Erkennungsstrategien, um ähnliche Aktivitäten zu identifizieren und darauf zu reagieren.

OAuth in Microsoft Entra ID

Microsoft Entra ID implementiert OAuth 2.0, um den delegierten Zugriff auf Microsoft 365 Dienste wie Outlook, SharePoint und die Graph-API zu ermöglichen. Während die OAuth-Spezifikation standardisiert ist (RFC6749), führt Entra ID einzigartige Verhaltensweisen und Token-Typen ein, die beeinflussen, wie der delegierte Zugriff funktioniert und wie Angreifer ihn ausnutzen.

Beim delegierten Zugriff ist eine Anwendung berechtigt, im Namen eines angemeldeten Benutzers zu handeln, eingeschränkt durch Bereiche (Berechtigungen), die die App anfordert und denen der Benutzer oder Administrator zustimmt. Dieses Modell ist in Unternehmensumgebungen üblich, in denen Apps die E-Mails, Dateien oder Verzeichnisdaten eines Benutzers abrufen, ohne jedes Mal zur Eingabe von Anmeldeinformationen aufgefordert zu werden.

Ein typischer delegierter Autorisierungsablauf umfasst:

Autorisierungsanforderung (OAuth 2.0 Authorization Code Grant): Die App fordert Zugriff auf eine Ressource (z. B. Graph) mit bestimmten Bereichen (z. B. Mail.Read, offline_access) an. Diese werden dem URI als Parameter hinzugefügt.

  • client_id: Die ID der Anwendung (z. B. VSCode)
  • Response_type: Bestimmt den OAuth-Workflow des Grant-Typs (z. Gerätecode, Authentifizierungscode)
  • Geltungsbereich: Berechtigungen, die für die Zielressource angefordert werden (z. Mail.Read, offline_access)
  • Redirect_uri: Wohin soll ich unsere Autorisierungscodes senden?
  • Zustand: CSRF-Schutz
  • Login_hint: Benutzername vorab ausfüllen

Benutzerauthentifizierung (OpenID Connect): Entra ID authentifiziert den Benutzer über eine Richtlinie (Passwort, MFA, Gerätevertrauen).

  • Ein-Faktor-Authentifizierung (SFA)
  • Multi-Faktor-Authentifizierung (MFA)
  • Gerätevertrauen (Hybrid Join, Intune-Konformität)
  • Richtlinien für bedingten Zugriff (CAP)
  • Single Sign-On (SSO)

Einwilligen: Die Zustimmung steuert, ob die App einen Autorisierungscode erhalten kann und welche Bereiche zulässig sind.

  • Bereiche, in die der Benutzer einwilligt (z. Mail.Read, offline_access)
  • Für die Administratoreinwilligung erforderliche Bereiche (z. Directory.ReadWrite) erfordert eine Genehmigung mit erhöhten Rechten.

Tokenausstellung: Die App erhält einen Autorisierungscode und löst ihn dann ein für:

  • Access Token – kurzlebiges Token, das zum Aufrufen von APIs wie Graph verwendet wird.
  • Refresh Token (RT) – langlebigeres Token, um neue Zugriffstoken im Hintergrund zu erhalten.
  • Identitätstoken: Beschreibt den authentifizierten Benutzer. in OpenID-Flüssen vorhanden.
  • (Fakultativ) Primäres Aktualisierungstoken: Wenn sich der Benutzer auf einem in die Domäne eingebundenen oder registrierten Gerät befindet, kann ein primäres Aktualisierungstoken (PRT) unbeaufsichtigtes SSO und zusätzliche Tokenflüsse ohne Benutzerinteraktion ermöglichen.
  • Token-Ansprüche: Ansprüche sind Schlüssel-Wert-Paare, die in JWT-Token eingebettet sind und den Benutzer, die App, das Gerät, die Bereiche und den Kontext der Authentifizierung beschreiben.

Was definiert eine MSFT OAuth-Phishing-URL?

Bevor wir uns mit den wichtigsten Erkenntnissen aus dem Volexity-Bericht befassen, die in die Gestaltung unserer Erkennungsstrategie einfließen, ist es wichtig, aufzuschlüsseln, was genau eine Microsoft OAuth-Phishing-URL definiert.

Wie bereits beschrieben, verwendet Microsoft Entra ID diese URLs, um zu bestimmen, welche Anwendung (Client) im Namen welcher Benutzerprinzipal Zugriff auf welche Ressource und mit welchen Berechtigungen anfordert. Ein Großteil dieses Kontexts ist direkt in die Abfrageparameter der OAuth-Autorisierungsanforderung eingebettet, was sie zu einer wichtigen Metadatenquelle sowohl für Angreifer als auch für Verteidiger macht.

Hier ist ein Beispiel für eine Phishing-URL, die mit dem Genehmigungsprozess des Autorisierungscodes übereinstimmt und aus dem Blog von Volexity übernommen wurde:

https://login.microsoftonline[.]com/organizations/oauth2/v2.0/authorize?state=https://mae.gov[.]ro/[REMOVED]&client_id=aebc6443-996d-45c2-90f0-388ff96faa56&scope=https://graph.microsoft.com/.default&response_type=code&redirect_uri=https://insiders.vscode.dev/redirect&login_hint=<EMAIL HERE>

Lassen Sie uns einige der wichtigsten Komponenten aufschlüsseln:

  • login.microsoftonline.com – Der globale Microsoft Entra ID-Authentifizierungsendpunkt.
  • /oauth2/v2.0/authorize – MSFT Entra ID OAuth v2.0-Endpunkt für Autorisierungsworkflows
  • state – Optionaler Wert, der verwendet wird, um CSRF zu verhindern und den Anwendungsstatus beizubehalten. Wird manchmal missbraucht, um Phishing-Weiterleitungen zu verschleiern.
  • client_id – Die Anwendungs-ID, die die Anforderung stellt. Dies kann zu Microsoft-Erstanbieter-Apps (wie VSCode, Teams) oder bösartigen Apps von Drittanbietern gehören, die von Angreifern registriert wurden.
  • scope – Definiert die Berechtigungen, die die Anwendung anfordert (z. B. Mail.Read, offline_access). Der Standardbereich wird häufig für Clientanmeldeinformationsflüsse verwendet, um vorab genehmigte Berechtigungen zu erhalten.
  • response_type=code – Gibt an, dass der Flow einen Autorisierungscode anfordert, der später gegen ein Zugriffs- und/oder Aktualisierungstoken ausgetauscht werden kann.
  • redirect_uri – Wobei die Entra ID die Antwort sendet, nachdem sich der Benutzer authentifiziert hat. Wenn ein Angreifer diesen URI steuert, erhält er den Code, oder es handelt sich um einen gültigen MSFT-verwalteten URI.
  • login_hint – Gibt den Zielbenutzer an (z. B. alice @ tenant.onmicrosoft.com). Oft vorausgefüllt, um die Reibungsverluste beim Phishing zu verringern.

Hinweis: Dieses Beispiel veranschaulicht zwar eine gängige Microsoft Entra ID OAuth-Phishing-URL, es gibt jedoch viele Variationen. Angreifer können Parameter wie die Client-ID, Bereiche, Gewährungstypen oder Umleitungs-URIs je nach ihren spezifischen Zielen anpassen, sei es, um dauerhaften Zugriff zu erhalten, E-Mails zu exfiltrieren oder Berechtigungen durch umfassendere Einwilligungserteilungen zu erweitern.

Warum ist das wichtig?

Da diese Parameter anpassbar sind, können Angreifer die Werte leicht austauschen, um sie an ihren Betrieb anzupassen. Zum Beispiel:

  • Sie verwenden möglicherweise eine legitime Microsoft-Client-ID, um sich mit harmlosen Anwendungen zu vermischen.
  • Sie können eine .default-Datei verwenden Spielraum zur Umgehung bestimmter Einwilligungsaufforderungen.
  • Sie verweisen den redirect_uri auf eine Website unter ihrer Kontrolle, um den Autorisierungscode zu erfassen.
  • Sie können auf bestimmte Benutzerprinzipale abzielen, die sie möglicherweise während der Aufklärung identifiziert haben.
  • Sie können die Berechtigungen für Zielressourcen basierend auf ihren betrieblichen Anforderungen anpassen.

Sobald sich ein Ziel authentifiziert hat, ist das Ziel einfach: Einen Autorisierungscode zu erhalten. Dieser Code wird dann (häufig mithilfe von Tools wie ROADtools) gegen ein Aktualisierungstoken und/oder Zugriffstoken ausgetauscht, sodass der Angreifer Graph-API-Aufrufe tätigen oder in andere Microsoft 365 -Dienste wechseln kann, und das alles ohne weitere Benutzerinteraktion.

Abstraktion der wichtigsten Ergebnisse von Volexity

Für die Erkennung von Bedrohungen ist es wichtig, die Protokolle wie OAuth, die Workflow-Implementierung in Microsoft Entra ID und kontextbezogene Metadaten über das Verhalten und/oder die Schritte zu verstehen, die der Angreifer in Bezug auf diesen Vorgang unternommen hat.

Aus den Untersuchungen und Recherchen von Volexity können wir die verschiedenen Variationen von OAuth-Phishing einordnen, die gemeldet wurden. Wir haben uns entschieden, diese zum besseren Verständnis aufzuschlüsseln:

OAuth-Phishing für den Zugriff auf die Graph-API als VSCode-Client im Auftrag des Zielbenutzerprinzipals: Diese URLs ähneln unserem Beispiel "Was definiert eine MSFT-OAuth-Phishing-URL" – das Endziel ist ein Zugriffstoken auf die Graph-API mit Standardberechtigungen.

  • OAuth-Phishing-URLs waren benutzerdefiniert und zeigten auf den Endpunkt "authorize"
  • Client-IDs waren speziell VSCode ("aebc6443-996d-45c2-90f0-388ff96faa56")
  • Ressource/Geltungsbereich war MSFT-Diagramm ("https://graph.microsoft.com/.default") mit .default Erlaubnisse
  • Bei den Token-Grant-Flows handelte es sich um Authentifizierungscode (response_type=Code)
  • Die Umleitungs-URIs waren für legitime MSFT-Domains (insiders[.]vscode[.]Dev oder vscode-redirect[.]azurewebsites[.]netto)
  • Bei Anmeldehinweisen handelte es sich um den spezifischen Benutzerprinzipal, auf den zugegriffen wurde (nicht um Dienstprinzipale)
  • Der Angreifer forderte das Ziel auf, die URL zu öffnen, sich zu authentifizieren und den Autorisierungscode weiterzugeben (1.AXg....)

Von hier aus kann der Angreifer eine Anforderung an den OAuth-Tokenendpunkt von MSFT (https://login.microsoftonline.com/[tenant_id]/oauth2/v2.0/token) senden und das Aktualisierungstoken gegen ein Zugriffstoken austauschen. Dies reicht aus, um dem Angreifer den Zugriff auf die Graph-API und den Zugriff auf Ressourcen zu ermöglichen, die dem Benutzer normalerweise zur Verfügung stehen. Diese Indikatoren werden entscheidend sein, um unsere Erkennungs- und Jagdstrategien später in diesem Blog zu berücksichtigen.

OAuth-Phishing für die Geräteregistrierung als MSFT Auth Broker: Diese URLs sind eindeutig, da sie mit der Teilsequenz ROADtools-Nutzung verkettet sind, um ein virtuelles Gerät zu registrieren, ein RT gegen ein PRT auszutauschen und eine PRT-Anreicherung zu erfordern, um den E-Mail-Zugriff über die Graph-API und den Sharepoint-Zugriff zu erreichen.

  • OAuth-Phishing-URLs waren benutzerdefiniert und zeigten auf authorize (https://login.microsoftonline.com/[tenant_id]/oauth2/v2.0/authorize) Endpunkt
  • Bei den Client-IDs handelte es sich speziell um MSFT Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e")
  • Ressource/Geltungsbereich war Device Registration Service (DRS) ("01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9")
  • Bei den Token-Grant-Flows handelte es sich um Authentifizierungscode (response_type=Code)
  • Der Umleitungs-URI enthält einen cloudbasierten Endpunkt für den Domänenbeitritt (wird in der Regel während des Windows-Setups oder Autopiloten verwendet)
  • Anmeldehinweis enthält die E-Mail-Adresse des Benutzerprinzipals (Ziel)
  • Die Anfrage bezieht sich letztendlich auf einen ADRS-Token

Wenn der Benutzer einen Phishing hat und die URL öffnet, wird bei der Authentifizierung ein ADRS-Token bereitgestellt, das für den Angreifer erforderlich ist, um ein Gerät zu registrieren und anschließend ein PRT mit dem privaten Schlüssel und der PEM-Datei des Geräts zu erhalten.

Der Blog von Volexity enthält auch zusätzliche Informationen über die Verfolgung der Aktivität der Kompromittierungsidentität über die registrierte Geräte-ID sowie über die Aktivitäten nach der Kompromittierung, nachdem eine genehmigte 2FA-Anfrage identifiziert wurde, sodass der Angreifer die E-Mail des Ziels mit einer Sitzung herunterladen kann, die mit dem neu registrierten Gerät verbunden ist.

Mit diesem Verständnis jedes Phishingversuchs besteht unser nächstes Ziel darin, dies in unserem eigenen MSFT-Mandanten so genau wie möglich zu replizieren, um Daten für plausible Erkennungen zu sammeln.

Unsere Emulationsbemühungen

In Ordnung, an dieser Stelle haben wir die Grundlagen von OAuth und die Implementierung von Microsoft Entra ID behandelt. Wir haben aufgeschlüsselt, was eine Microsoft OAuth-Phishing-URL definiert, ihre kritischen Parameter entschlüsselt und wichtige Erkenntnisse aus der hervorragenden Untersuchung von Volexity gezogen, um Indikatoren zu identifizieren, die mit diesen Phishing-Workflows übereinstimmen.

Aber die Theorie und ein Blick in das Notizbuch von Volexity bringen uns nur so weit.

Um die Perspektive des Angreifers, die gesamte Ausführungskette, die Eigenheiten der Tools, subtile Fallstricke und Missbrauchsmöglichkeiten wirklich zu verstehen, haben wir uns für Whitebox-Tests entschieden. Wir haben den OAuth-Phishing-Prozess in unserem eigenen Mandanten nachgebildet und alles vom Token-Harvesting bis zum Ressourcenzugriff emuliert. Das Ziel? Gehen Sie über statische Indikatoren hinaus und zeigen Sie die Verhaltenskrumen auf, die Verteidiger zuverlässig erkennen können.

Fangen wir an.

Voraussetzungen

Für den Anfang ist es gut, einige Details über unsere Umgebung für die Bedrohungsforschung und -erkennung in Azure zu teilen.

  • Eingerichteter Azure-Mandant: TENANT.onmicrosoft.com
  • Eingerichtete Sharepoint-Domäne: DOMAIN.sharepoint.com
  • Native IdP Microsoft Entra ID – Aktivierung unseres IAM
  • Microsoft 365 -Lizenzen (P2) für alle Benutzer
  • Streaming von Azure-Aktivitätsprotokollen an EventHub
  • Microsoft Entra ID-Anmeldeprotokolle für das Streaming an EventHub
  • Microsoft Entra ID-Überwachungsprotokolle, die an EventHub gestreamt werden
  • Microsoft Graph-Überwachungsprotokolle für das Streaming an EventHub
  • Microsoft 365 Überwachungsprotokolle für das Streaming an EventHub
  • Elastic Azure- und M365-Integration für die Protokollverdauung von EventHub aktiviert
  • Einfacher Admin-Benutzer, der mit CAP aktiviert ist, der MFA erfordert
  • MSFT Authenticator App auf Mobilgeräten für 2FA-Emulation
  • Windows 10 Desktop mit NordVPN (Adversary Box)
  • macOS-Endpunkt (Opferbox)

Beachten Sie, dass wir die Workflows zwar von einem einzigen Endpunkt aus verfolgen können, aber häufig Daten benötigen, die separate Quelladressen für Entwicklererkennungsvariationen von unmöglichen Reisen widerspiegeln.

Szenario 1: OAuth-Phishing als VSCode-Client

Emulation

Um die von Volexity dokumentierte Phishing-Technik zu emulieren, haben wir ein Python-Skript erstellt, um eine OAuth 2.0-Autorisierungs-URL mit der Microsoft Entra ID zu generieren. Die URL initiiert einen Autorisierungscode-Erteilungsfluss, der die Identität der Visual Studio Code-Erstanbieter-App annimmt, um delegierten Zugriff auf die Microsoft Graph-API anzufordern.

Wir haben die URL mit den folgenden Parametern konfiguriert:

{
  "client_id": "aebc6443-996d-45c2-90f0-388ff96faa56",
  "response_type": "code",
  "redirect_uri": "insiders.vscode.dev/redirect",
  "scope": "https://graph.microsoft.com/.default",
  "login_hint": "user @ tenant.onmicrosoft.com",
  "prompt": "select_account",
  "state": "nothingtoseehere"
}

Abbildung 1: Parameter für die OAuth-Phishing-URL

Diese URL wird für das Ziel (in unserem Fall einen MacOS-Testbenutzer) freigegeben. Nach dem Öffnen authentifiziert es den Benutzer und schließt den OAuth-Workflow ab. Mit Hilfe von Browser-Entwicklertools erfassen wir den Autorisierungscode, der im Umleitungs-URI zurückgegeben wird, genau das, was die Angreifer von ihren Opfern verlangt haben.

Nachdem wir den Code erhalten haben, senden wir eine POST-Anfrage an:

{token_url: "https://login.microsoftonline.com/organizations/oauth2/v2.0/token"}

Dieser Austausch verwendet den authorization_code Grant-Typ und übergibt den Code, die Client-ID und den Umleitungs-URI. Microsoft gibt ein Zugriffstoken, aber kein Aktualisierungstoken zurück. Sie fragen sich vielleicht, warum das so ist?

Der Anwendungsbereich https://graph.microsoft.com/.default weist Microsoft an, ein Bearertoken für alle Graph-Berechtigungen auszugeben, die der VSCode-App bereits im Namen des Benutzers erteilt wurden. Hierbei handelt es sich um einen statischen Bereich, der aus der App-Registrierung abgerufen wird und keine dynamischen Bereiche wie Mail.Read oder offline_access enthält.

In der Dokumentation von Microsoft heißt es:

"Clients können die statische (.default) Einwilligung und die dynamische Einwilligung nicht in einer einzigen Anfrage kombinieren."

Versuchen Sie daher, offline_access neben .default einzuschließen führt zu einem Fehler. Wenn der Angreifer ein Aktualisierungstoken wünscht, muss er .default vermeiden und fordern Sie stattdessen explizit offline_access und die erforderlichen delegierten Bereiche (z. B. Mail.Read) an – vorausgesetzt, die App-Registrierung unterstützt diese.

Mit dem Zugriffstoken in der Hand wechselten wir zu einem zweiten Skript, um mit der Microsoft Graph-API zu interagieren. Das Ziel – E-Mail-Nachrichten aus dem Konto des Opfers zu extrahieren – genau wie es der Angreifer tun würde.

Zu diesem Zweck haben wir das Zugriffstoken als Bearer-JWT in den Autorisierungsheader aufgenommen und eine GET-Anfrage an den folgenden Endpunkt gestellt:

{graph_url: "https://graph.microsoft.com/v1.0/me/messages"}

Die Antwort gibt ein JSON-Array von E-Mail-Objekten zurück. Von hier aus iterieren wir einfach durch die Ergebnisse und analysieren nützliche Metadaten wie Absender, Betreff und Empfangszeit.

Um die umfassenderen Berechtigungen des Tokens zu testen, haben wir auch versucht, SharePoint-Websites mithilfe der folgenden Methoden aufzulisten:

{graph_search_url: "https://graph.microsoft.com/v1.0/sites?search=*"}

Die Anfrage schlug mit dem Fehler "Zugriff verweigert" fehl – was uns zu einer wichtigen Frage führt: Warum funktionierte der E-Mail-Zugriff, der SharePoint-Zugriff jedoch nicht? Der Grund dafür ist, dass der First-Party-Client (VSCode: aebc6443-996d-45c2-90f0-388ff96faa56) nicht über die standardmäßigen delegierten Berechtigungen mit Graph for Sharepoint verfügt – wie von Microsoft vordefiniert. Daher wissen wir, dass der Angreifer nur begrenzt auf seine Möglichkeiten zugreifen kann.

Um sicherzustellen, dass dies korrekt ist, haben wir das Zugriffstoken decodiert, um das mit VSCode verknüpfte SCP mit .default zu identifizieren Berechtigungen für Graph – Keine Sites überprüfen.* mit Genehmigung von Microsoft.

Dies ist eine der von Volexity beschriebenen Varianten, hilft uns aber, mehr über die Prozesse hinter den Kulissen für den Angreifer zu verstehen – sowie über Ressourcen, OAuth und mehr für Microsoft Entra ID.

Nachdem die Emulation abgeschlossen ist, wenden wir uns nun der Identifizierung von High-Fidelity-Signalen zu, die für die SIEM-Erkennung und Bedrohungssuche geeignet sind. Unser Fokus liegt auf Verhaltensobservablen in Microsoft Entra ID- und Microsoft Graph-Protokollen.

Erkennung

Signal 1 - Microsoft Entra ID OAuth-Phishing als Visual Studio Code-Client

Ein erfolgreicher Ablauf von OAuth 2.0 (Autorisierung) und OpenID Connect (Authentifizierung) wurde mit der Microsoft-Erstanbieteranwendung Visual Studio Code (VSCode) abgeschlossen. Die Anmeldung erfolgte im Namen des Phishing-Benutzerprinzipals, was zu einem delegierten Zugriff auf Microsoft Graph mit DEFAULT führte Erlaubnisse.

event.dataset: "azure.signinlogs" and
event.action: "Sign-in activity" and
event.outcome: "success" and
azure.signinlogs.properties.user_type: "Member" and
azure.signinlogs.properties.authentication_processing_details: *Oauth* and
azure.signinlogs.category: "NonInteractiveUserSignInLogs" and
(
  azure.signinlogs.properties.resource_display_name: "Microsoft Graph" or
  azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000"
) and (
  azure.signinlogs.properties.app_id: "aebc6443-996d-45c2-90f0-388ff96faa56" or
  azure.signinlogs.properties.app_display_name: "Visual Studio Code"
)

Signal 2 - Wiederverwendung von Microsoft Entra Session-Sitzungen mit verdächtigem Graphenzugriff

Während herkömmliche Abfragesprachen wie KQL hervorragend zum Filtern und Visualisieren einzelner Protokollereignisse geeignet sind, haben sie Schwierigkeiten, wenn eine Erkennung auf der Korrelation mehrerer Datensätze über Datensätze, Zeit und Identifikatoren beruht. Hier kommt ES|QL (Elasticsearch Query Language) wird unverzichtbar. Diese Arten von Multi-Event-Korrelationen, temporaler Logik und Feldnormalisierung sind in statischen, filterbasierten Abfragesprachen wie KQL schwierig oder völlig unmöglich, ohne mehrere unzusammenhängende Abfragen zu schreiben und sie im Nachhinein manuell zu korrelieren.

Diese Erkennung beruht auf der Korrelation mehrerer Ereignisse, die nahe beieinander, aber aus unterschiedlichen Datenquellen stammen, nämlich Anmeldeprotokollen und Microsoft Graph-Aktivitäten. Ziel ist es, verdächtige Wiederverwendungen derselben Sitzungs-ID über mehrere IPs hinweg zu finden, was möglicherweise auf Sitzungs-Hijacking oder Token-Missbrauch hindeutet. Aus Platzgründen in Bezug auf diese Veröffentlichung können Sie die tatsächliche Erkennungsregel im Abschnitt "Erkennungsregeln" anzeigen. Um den Ablauf der Abfrage und die Bedeutung besser zu veranschaulichen, finden Sie im Folgenden ein Diagramm zur Veranschaulichung auf einer höheren Ebene.

[ FROM logs-azure.* ]
        |
        |  ← Pulls events from all relevant Microsoft Cloud datasets:
        |     - azure.signinlogs (authentication)
        |     - azure.graphactivitylogs (resource access)
        ↓
[ WHERE session_id IS NOT NULL AND IP NOT MICROSOFT ASN ]
        |
        |  ← Filters out Microsoft-owned infrastructure (e.g., internal proxy,
        |     Graph API relays) using ASN checks.
        |  ← Ensures session ID exists so events can be correlated together.
        ↓
[ EVAL session_id, event_type, time_window, etc. ]
        |
        |  ← Normalizes key fields across datasets:
        |     - session_id (from signin or Graph)
        |     - user ID, app ID, event type ("signin" or "graph")
        |  ← Buckets events into 5-minute windows using DATE_TRUNC()
        ↓
[ KEEP selected fields ]
        |
        |  ← Retains only what's needed:
        |     session_id, timestamp, IP, user, client ID, etc.
        ↓
[ STATS BY session_id + time_window ]
        |
        |  ← Groups by session and time window to compute:
        |     - unique IPs used
        |     - apps involved
        |     - first and last timestamps
        |     - whether both signin and graph occurred
        ↓
[ EVAL time_diff + signin_to_graph_delay ]
        |
        |  ← Calculates:
        |     - time_diff: full session duration
        |     - delay: gap between signin and Graph access
        ↓
[ WHERE types_count > 1 AND unique_ips > 1 AND delay <= 5 ]
        |
        |  ← Flags sessions where:
        |     - multiple event types (signin + graph)
        |     - multiple IPs used
        |     - all occurred within 5 minutes
        ↓
[ Output = Suspicious Session Reuse Detected ]

Signal 3 – Microsoft Entra ID Gleichzeitige Anmeldungen mit verdächtigen Eigenschaften

Diese Erkennung identifiziert verdächtige Anmeldungen in Microsoft Entra ID, bei denen sich ein Benutzer mithilfe des Gerätecodeflusses ohne MFA oder Anmeldungen mit dem VSCode-Client authentifiziert. Wenn sich dieselbe Identität innerhalb eines kurzen Zeitfensters mit einer der beiden Methoden von zwei oder mehr unterschiedlichen IPs aus anmeldet, kann dies auf eine Tokenwiedergabe, OAuth-Phishing oder Adversary-in-the-Middle-Aktivitäten (AitM) hinweisen.

[ FROM logs-azure.signinlogs* ]
        |
        |  ← Pulls only Microsoft Entra ID sign-in logs
        ↓
[ WHERE @timestamp > NOW() - 1h AND event.outcome == "success" ]
        |
        |  ← Filters to the last hour and keeps only successful sign-ins
        ↓
[ WHERE source.ip IS NOT NULL AND identity IS NOT NULL ]
        |
        |  ← Ensures the sign-in is tied to a user and IP for correlation
        ↓
[ KEEP fields: identity, app_id, auth_protocol, IP, etc. ]
        |
        |  ← Retains app/client, IP, auth method, and resource info
        ↓
[ EVAL detection flags ]
        |
        |  ← Labels events as:
        |     - device_code: if MFA not required
        |     - visual_studio: if VS Code client used
        |     - other: everything else
        ↓
[ STATS BY identity ]
        |
        |  ← Aggregates all sign-ins per user, calculates:
        |     - IP count
        |     - Device Code or VSCode usage
        |     - App/client/resource details
        ↓
[ WHERE src_ip >= 2 AND (device_code_count > 0 OR vsc > 0) ]
        |
        |  ← Flags users with:
        |     - Sign-ins from multiple IPs
        |     - And either:
        |         - Device Code w/o MFA
        |         - Visual Studio Code app
        ↓
[ Output = Potential OAuth Phishing or Token Misuse ]

Diese Variante des OAuth-Phishings verfügt zwar nicht über die volle Persistenz von Refresh-Token oder PRTs, bietet Angreifern jedoch einen wertvollen einmaligen Zugriff auf sensible Benutzerdaten – wie z. B. E-Mails – über legitime Kanäle. Diese Übung hilft uns, die Einschränkungen und Funktionen der statischen .default-Datei zu verstehen den Einfluss von App-Registrierungen und die Frage, wie Microsoft Graph eine zentrale Rolle bei der Nachauthentifizierung spielt. Es bekräftigt auch eine umfassendere Lektion: Nicht alle OAuth-Phishing-Angriffe sind gleich. Einige zielen auf Langlebigkeit ab (wie wir später sehen werden) durch Aktualisierungstoken oder Geräteregistrierung, während andere sich auf sofortigen Datendiebstahl über First-Party-Clients konzentrieren. Das Verständnis der Nuancen ist für eine genaue Erkennungslogik unerlässlich.

Szenario 2: OAuth-Phishing für die Geräteregistrierung

Wie wir bereits erwähnt haben, berichtete Volexity auch über ein separates Phishing-Playbook, das sich an Opfer richtete, diesmal mit dem Ziel, ein virtuelles Gerät zu registrieren und ein PRT zu erhalten. Während dieser Ansatz mehr Schritte vom Angreifer erfordert, ist die Auszahlung ein Token-Granting-Token, der einen weitaus größeren Nutzen für die Durchführung seiner Operationen bietet. Für unsere Emulationsbemühungen mussten wir unser Toolset erweitern und uns auf ROADtools verlassen, genau wie der Angreifer es tat, um genau zu bleiben, aber es wurden mehrere andere Python-Skripte für erste Phishing- und Post-Compromise-Aktionen erstellt.

Emulation

Beginnend mit dem ersten Phishing passten wir unser Python-Skript an, um eine andere OAuth-URL zu erstellen, die an unser Opfer gesendet wurde. Dieses Mal lag der Fokus darauf, dass unsere Erstanbieter-Client-ID der Microsoft Authentication Broker ist, ein Aktualisierungstoken mit offline_access anfordert und an den Endpunkt-URI der Cloud-Domain-ID umleitet, der dem Endpunkt beitritt.

{
  "client_id": "29d9ed98-a469-4536-ade2-f981bc1d605e",
  "response_type": "code",
  "response_mode": "query",
  "redirect_uri": "https://login.microsoftonline.com/WebApp/CloudDomainJoin/8",
  "resource": "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9",
  "state": "nothingtoseehere"
}

Wenn der Vorgang erfolgreich ist und sich unser Opfer authentifiziert, wird der OAuth-Workflow abgeschlossen, und der Benutzer wird an den angegebenen URI mit einem angehängten Autorisierungscode in den Abfrageparametern umgeleitet. Auch hier ist dieser Code das entscheidende Stück, er muss mit dem Angreifer geteilt werden, um ihn gegen Token einzutauschen. In unserem Fall erfassen wir, sobald die Phishing-URL geöffnet und das Ziel authentifiziert ist, den in die Umleitung eingebetteten Autorisierungscode und verwenden ihn, um Token vom Microsoft Entra ID-Tokenendpunkt anzufordern.

Nun, hier wird es interessant. Als Antwort auf die Tokenanforderung erhalten wir drei Arten von Token: ein Zugriffstoken, ein Aktualisierungstoken und ein ID-Token. Sie fragen sich vielleicht: Warum bekommen wir mehr als nur ein Zugriffstoken? Die Antwort liegt in den Bereichen, die wir ursprünglich angefordert haben: openid, offline_access und profile.

  • openid gewährt uns ein ID-Token, das Teil der OpenID Connect-Schicht ist und die Identität des Benutzers bestätigt – dies ist Ihr Authentifizierungsartefakt (authN).
  • offline_access ein Aktualisierungstoken bereitstellt, das es uns ermöglicht, eine Sitzung aufrechtzuerhalten und neue Zugriffstoken anzufordern, ohne dass eine erneute Authentifizierung erforderlich ist, unterstützt dies den persistenten Zugriff, ist aber für unsere Verwendung mit ROADtx von entscheidender Bedeutung.
  • Und das Zugriffstoken selbst wird verwendet, um Anforderungen an geschützte APIs wie Microsoft Graph zu autorisieren, dies stellt die Autorisierung (authZ) dar.

Mit diesen drei Token haben wir alles: Authentifizierung, Autorisierung und langfristige Sitzungskontinuität. Das reicht aus, um von einem einfachen OAuth-Phishing-Spiel zu einem dauerhafteren Standbein zu wechseln – wie der Registrierung eines neuen Geräts in Microsoft Entra ID.

Lassen Sie uns nun die Punkte verbinden. Ein PRT erfordert die Registrierung eines gültigen Geräts, das Entra ID über ein Gerätezertifikat und einen privaten Schlüssel erkennt. Hier kommt ROADtx ins Spiel. Da unser ursprüngliches OAuth-Phishing die Identität eines verknüpften Geräteflusses annahm und der verwendete Client der Microsoft Authentication Broker war (ein Erstanbieterclient, der mit dem Geräteregistrierungsdienst interagiert), haben wir bereits das richtige Zugriffstoken für die Interaktion mit DRS in der Hand. Beachten Sie, dass der Bereich in unserem zurückgegebenen Objekt adrs_access ist, was auf Azure DRS-Zugriff hinweist und für spätere Erkennungen wichtig ist.

Von hier aus legen wir einfach das JSON-Objekt, das wir von unserer Token-Börse erhalten haben, in den .roadtool_auth Datei. Diese Datei wird nativ von ROADtools genutzt, das die gespeicherten Token verwendet, um die Geräteregistrierung durchzuführen, den Übergang des Angreifers in die Persistenz abzuschließen und die Voraussetzungen für den Erhalt eines gültigen PRT zu schaffen.

Nachdem wir die Token erhalten haben, bereiten wir sie für ROADtx vor, indem wir den JSON-Code neu formatieren. ROADtx erwartet Schlüssel in camelCase, und wir müssen auch die Client-ID des Microsoft Authentication Brokers als _clientId einschließen. Mit diesem Setup können wir den Befehl refreshtokento ausführen, der unser Aktualisierungstoken verwendet und gegen ein neues JWT austauscht, das auf DRS beschränkt ist – insbesondere den Dienstprinzipal urn:ms-drs:enterpriseregistration.windows.net.

Sobald dies eingerichtet ist, verwenden wir den Befehl device, um eine neue Geräteregistrierung zu simulieren. Für diesen Vorgang ist keine tatsächliche virtuelle Maschine oder kein physischer Host erforderlich, da es sich um eine Backend-Registrierung handelt, die einfach einen Eintrag in Entra ID erstellt. Bei Erfolg erhalten wir eine gültige Geräte-ID, ein PEM-codiertes Zertifikat und einen privaten Schlüssel, die alle erforderlich sind, um ein gültiges, hybrid eingebundenes Gerät im Microsoft-Ökosystem zu simulieren.

Nachdem wir unsere Geräteidentität festgelegt haben, rufen wir den Befehl prt auf. Dabei werden das Aktualisierungstoken, das Gerätezertifikat und der private Schlüssel verwendet, um ein neues PRT zu prägen – eine hochprivilegierte Anmeldeinformation, die die Vertrauen von Benutzer und Gerät in Microsoft Entra ID effektiv miteinander verknüpft.

Und einfach so – whollah! — wir haben ein PRT.

Aber warum sollte man das alles durchmachen? Warum sollten wir ein Gerät registrieren, ein Zertifikat generieren und ein PRT abrufen, wenn wir bereits über ein Zugriffstoken, ein ID-Token und ein Aktualisierungstoken verfügten?

Denn das PRT ist der Schlüssel zur vollständigen Emulation von Benutzer- und Geräteidentitäten. Betrachten Sie es als ein Kerberos-ähnliches Ticket-Granting-Token in der Welt von Entra ID, aber stattdessen – ein Token-Granting-Token. Mit einem gültigen FHM:

  • Ein Angreifer kann neue Zugriffs- und ID-Token für Erstanbieter-Apps wie Outlook, SharePoint oder Teams anfordern, ohne dass eine Benutzerinteraktion erforderlich ist.
  • Das PRT ermöglicht nahtloses einmaliges Anmelden für SSO über mehrere Dienste hinweg, wobei MFA und andere Richtlinien für bedingten Zugriff (Conditional Access Policies, CAP) umgangen werden, die den Benutzer in der Regel erneut auffordern. Dies ist entscheidend für den Fortbestand, da GAP und MFA oft große Hindernisse für Gegner darstellen.
  • Es unterstützt eine langlebige Persistenz, da das PRT im Hintergrund erneuert und sitzungsübergreifend genutzt werden kann, solange die Geräteidentität vertrauenswürdig bleibt.

Und vielleicht am gefährlichsten – das PRT ermöglicht es Angreifern, sich als vollständig konforme, domänengebundene Geräte- und Benutzerkombination auszugeben und so die meisten herkömmlichen Erkennungs- und Reaktionskontrollen effektiv zu umgehen, wodurch die Grenze zwischen gutartig und verdächtig für Jäger und Analysten extrem schmal wird.

Dies macht das PRT zu einem unglaublich wertvollen Gut, das verdeckte laterale Bewegungen, die Ausweitung von Berechtigungen und einen umfassenden Zugriff auf Microsoft 365 -Dienste ermöglicht. Es geht nicht mehr nur darum, reinzukommen – es geht darum, unentdeckt zu bleiben.

Vergessen wir nicht die Aktivitäten nach der Kompromittierung...

ROADtx bietet einige leistungsstarke Befehle, die häufig von Angreifern verwendet werden – prtenrich und browserprtauth. Zum Beispiel können wir auf die meisten browserbasierten UI-Dienste in der Microsoft-Suite zugreifen, indem wir unser PRT bereitstellen, das die notwendigen Metadaten für die Authentifizierung und Autorisierung enthält – das ursprünglich unserem Phishing-Opfer (mir) gehörte, aber eigentlich der Microsoft Authentication Broker ist, der in seinem Namen handelt.

Volexity berichtete auch, dass nach der Geräteregistrierung und der PRT-Akquisition eine 2FA-Anfrage an das ursprüngliche Opfer gesendet, genehmigt und dann für den Zugriff auf E-Mails über SharePoint verwendet wurde. Obwohl sie nicht genau angeben, an wie die Anfragen gestellt wurden, ist es vernünftig anzunehmen, dass der Angreifer das PRT zur Authentifizierung über einen Microsoft-Client eines Erstanbieters verwendet hat – wobei der tatsächliche Datenzugriff über Microsoft Graph erfolgt. Graph bleibt nach der Kompromittierung ein beliebtes Ziel, da es als zentraler API-Hub für die meisten Microsoft 365 -Ressourcen dient.

Zu Beginn – lassen Sie uns ROADtx nutzen, um sich mit unserem PRT zu authentifizieren, wobei Microsoft Teams unser Client und Microsoft Graph unsere Ressource ist. Wenn wir den Befehl prtauth mit unserem PRT verwenden, sind wir in der Lage, ein neues Zugriffstoken und ein neues Refresh-Token zu erhalten – ein deutlicher Beweis für die Nützlichkeit des PRT als Token-Granting-Token innerhalb der Identity Fabric von Microsoft.

Sobald unser Zugriffstoken abgerufen wurde, stecken wir es in ein benutzerdefiniertes Python-Skript, um mit der Aufzählung unserer SharePoint-Websites, -Laufwerke und -Elemente zu beginnen, die es uns ermöglichen, interessante Dateien zu identifizieren und ihren Inhalt herunterzuladen.

Mit dieser Emulation haben wir gezeigt, wie Angreifer OAuth-Phishing mit dem Microsoft Authentication Broker verketten und das notwendige Anmeldematerial erhalten können, um ROADtx für den Erwerb eines PRT zu nutzen. Dieses PRT ist dann ein wichtiges Dienstprogramm nach der Kompromittierung, um auf vertrauliche Dateien zuzugreifen, Mandantenressourcen aufzulisten und vieles mehr.

Verschieben wir nun den Fokus: Was sind plausible und genaue Signale für die Erkennung dieser Aktivität?

Erkennung

Signal 1 - Microsoft Entra ID OAuth-Phishing als Microsoft Authentication Broker

Identifiziert Instanzen, in denen ein Benutzerprinzipal einen OAuth-Autorisierungscodefluss mit dem Microsoft Authentication Broker (MAB) als Client und dem Device Registration Service (DRS) als Zielressource initiiert. Diese Erkennung konzentriert sich auf Fälle, in denen eine einzelne Sitzungs-ID innerhalb eines kurzen Zeitfensters über zwei oder mehr unterschiedliche IP-Adressen wiederverwendet wird und mindestens eine Anfrage von einem Browser stammt – ein Verhalten, das häufig mit Phishing in Verbindung gebracht wird.

[ FROM logs-azure.signinlogs-* ]
        |
        |  ← Pulls all Microsoft Entra ID sign-in logs
        ↓
[ WHERE app_id == MAB AND resource_id == DRS ]
        |
        |  ← Filters to OAuth auth code requests targeting
        |     Microsoft Authentication Broker + Device Reg Service
        ↓
[ EVAL session_id + is_browser ]
        |
        |  ← Extracts session ID and flags browser-based activity
        ↓
[ STATS BY 30-minute window, user, session_id ]
        |
        |  ← Groups logins within same session and time window,
        |     then aggregates:
        |       - user/session/token identifiers
        |       - distinct IPs and geo info
        |       - user agent, browser presence
        |       - app/resource/client info
        ↓
[ WHERE ip_count ≥ 2 AND session_id_count == 1 ]
        |
        |  ← Identifies reuse of a single session ID
        |     across ≥ 2 different IP addresses
        ↓
[ AND has_browser ≥ 1 AND auth_count ≥ 2 ]
        |
        |  ← Requires at least one browser-based request
        |     and at least two total sign-in events
        ↓
[ Output = Suspicious OAuth Flow with Auth Broker for DRS ]

Signal 2 - Verdächtige ADRS-Token-Anfrage durch Microsoft Auth Broker

Identifiziert Microsoft Entra ID-Anmeldeereignisse, bei denen sich ein Benutzerprinzipal mit einem Aktualisierungstoken authentifiziert, das für den Microsoft Authentication Broker (MAB)-Client ausgestellt wurde und auf den Geräteregistrierungsdienst (Device Registration Service, DRS) mit dem OAuth-Bereich adrs_access abzielt. Dieses Muster kann auf einen tokenbasierten Zugriff auf DRS nach einem anfänglichen Autorisierungscode-Phishing- oder Geräteregistrierungsfluss hinweisen.

event.dataset: "azure.signinlogs" and azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and azure.signinlogs.properties.authentication_processing_details.`Oauth Scope Info`: *adrs_access* and azure.signinlogs.properties.incoming_token_type: "refreshToken" and azure.signinlogs.properties.user_type: "Member"

Signal 3 - Ungewöhnliche Geräteregistrierung in Entra ID

Erkennt eine Abfolge von Entra ID-Audit-Log-Ereignissen, die auf potenziell bösartige Geräteregistrierungsaktivitäten mithilfe eines Aktualisierungstokens hinweisen, die häufig nach OAuth-Phishing auftreten. Dieses Muster ahmt das Verhalten von Tools wie ROADtx nach, bei denen ein neu registriertes Windows-Gerät (mit einer hartcodierten Betriebssystemversion 10.0.19041.928) vom Geräteregistrierungsdienst hinzugefügt wird, gefolgt von Benutzer- und Besitzerzuweisungen. Alle Ereignisse müssen dieselbe Korrelations-ID aufweisen und innerhalb eines Zeitfensters von einer Minute auftreten, was eher auf eine Automatisierung oder skriptgesteuerte Registrierung als auf legitimes Benutzerverhalten hindeutet.

sequence by azure.correlation_id with maxspan=1m
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.identity == "Device Registration Service" and azure.auditlogs.operation_name == "Add device" and azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" and (
  azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.display_name == "CloudAccountEnabled" and 
azure.auditlogs.properties.target_resources.`0`.modified_properties.`1`.new_value: "[true]") and azure.auditlogs.properties.target_resources.`0`.modified_properties.`3`.new_value like "*10.0.19041.928*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered users to device" and azure.auditlogs.properties.target_resources.`0`.modified_properties.`2`.new_value like "*urn:ms-drs:enterpriseregistration.windows.net*"]
[any where event.dataset == "azure.auditlogs" and azure.auditlogs.operation_name == "Add registered owner to device"]

Signal 3 - Übergang von Entra ID RT zu PRT von demselben Benutzer und Gerät

Diese Erkennung erkennt, wenn sich ein Microsoft Entra ID-Benutzer zum ersten Mal mit einem Aktualisierungstoken authentifiziert, das für den Microsoft Authentication Broker (MAB) ausgestellt wurde, gefolgt von der Verwendung eines primären Aktualisierungstokens (Primary Refresh Token, PRT) von demselben Gerät. Diese Sequenz ist im normalen Benutzerverhalten selten und kann darauf hindeuten, dass ein Angreifer ein Gerät erfolgreich registriert und mit Tools wie ROADtx auf dauerhaften Zugriff eskaliert hat. Durch das Herausfiltern von Aktivitäten, die im zweiten Schritt an den Geräteregistrierungsdienst (Device Registration Service, DRS) gebunden sind, konzentriert sich die Regel auf die Nutzung des PRT nach der Registrierung, um auf andere Microsoft 365 Dienste zuzugreifen.

Dieses Verhalten deutet stark auf eine tokenbasierte Kompromittierung und eine langfristige Sitzungsemulation hin, insbesondere wenn die Gerätevertrauenswürdigkeit im Hintergrund eingerichtet wird. Das Abfangen dieses Übergangs vom Aktualisierungstoken zu PRT ist entscheidend für die Aufdeckung von High-Fidelity-Signalen für OAuth-Phishing und die Persistenz nach der Kompromittierung.

sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1d
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.category == "NonInteractiveUserSignInLogs" and
    azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and
    azure.signinlogs.properties.incoming_token_type == "refreshToken" and
    azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and
    azure.signinlogs.properties.device_detail.device_id != null and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and
    azure.signinlogs.properties.user_type == "Member" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]
  [authentication where 
    event.dataset == "azure.signinlogs" and
    azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and
    azure.signinlogs.properties.resource_display_name != "Device Registration Service" and
    azure.signinlogs.result_signature == "SUCCESS"
  ]

Signal 4 - Ungewöhnliche PRT-Nutzung und registriertes Gerät für den Benutzerprinzipal

Diese Erkennung tritt auf, wenn ein Microsoft Entra ID-Benutzer ein neues Gerät registriert, das in den letzten 7 Tagen nicht zuvor gesehen wurde – ein Verhalten, das häufig mit OAuth-Phishing-Kampagnen in Verbindung gebracht wird, die mit einer ROADtx-basierten Geräteregistrierung verbunden sind. Bei diesen Angriffen verleiten Angreifer Benutzer dazu, den Zugriff auf den Microsoft Authentication Broker (MAB) zu autorisieren, der auf das DRS abzielt, ein RT zu erhalten und dann ROADtx zu verwenden, um ein gefälschtes Windows-Gerät im Hintergrund zu registrieren und ein PRT zu prägen. Diese Regel gibt eine Warnung aus, wenn sich ein Benutzerprinzipal über eine neu beobachtete Geräte-ID authentifiziert, insbesondere wenn die Sitzung ungebunden ist, was für die Tokenwiedergabe oder Gerätespoofing charakteristisch ist. Da PRTs ein registriertes und vertrauenswürdiges Gerät erfordern, spielt dieses Signal eine entscheidende Rolle bei der Identifizierung, wenn ein Angreifer von einem einfachen Token-Missbrauch zu einem dauerhaften, heimlichen Zugriff übergegangen ist, der auf eine langfristige Kompromittierung ausgerichtet ist.

event.dataset: "azure.signinlogs" and
    event.category: "authentication" and
    azure.signinlogs.properties.user_type: "Member" and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and
    not azure.signinlogs.properties.device_detail.device_id: "" and
    azure.signinlogs.properties.user_principal_name: *

Neue Bedingungen Werte:

  • azure.signinlogs.properties.user_principal_name
  • azure.signinlogs.properties.device_detail.Geräte-ID

Diese Emulation half uns, den gesamten Angreifer-Workflow zu validieren – vom Phishing zur Einholung der Einwilligung über die Etablierung von Gerätevertrauen bis hin zur Prägung eines PRT für eine langfristige Persistenz. Durch die Verkettung von OAuth-Missbrauch mit der Geräteregistrierung können Angreifer CAPs erfüllen, sich als konforme Endpunkte ausgeben und sich lateral durch Cloud-Umgebungen bewegen – oft ohne herkömmliche Sicherheitskontrollen auszulösen.

Diese Nuancen sind wichtig. Isoliert betrachtet können einzelne Ereignisse wie die Ausgabe von Token oder die Geräteregistrierung harmlos erscheinen. Wenn sie jedoch über Anmeldeprotokolle, Überwachungsdaten und Tokenmetadaten hinweg korreliert werden, zeigen sie eine deutliche Spur von Identitätskompromittierungen auf.

Wichtige Telemetriedetails für Erkennung und Missbrauch

Während unserer Emulations- und Erkennungsbemühungen erwiesen sich spezifische Telemetrieartefakte durchweg als unerlässlich, um gutartige OAuth-Aktivitäten von böswilligem Missbrauch zu unterscheiden. Zu verstehen, wie diese Felder in Microsoft Entra ID-Protokollen angezeigt werden – und wie Angreifer sie manipulieren – ist entscheidend für eine effektive Such- und Erkennungstechnik. Von Client-IDs und Grant-Typen bis hin zu Gerätekonformität, Token-Typen und Ergebnissen des bedingten Zugriffs erzählen diese Signale die Geschichte identitätsbasierter Angriffe. Im Folgenden haben wir eine Liste der wichtigsten zusammengestellt und wie sie uns dabei helfen können.

Clientanwendungs-IDs (client_id): Identifizieren Sie die Anwendung, die die OAuth-Anforderung initiiert. First-Party-Clients (z. VSCode, Auth Broker) kann missbraucht werden, um sich einzumischen. Clients von Drittanbietern können bösartig oder unüberprüft sein und stellen häufig Angriffe auf die Einwilligungserteilung dar. Wird hauptsächlich verwendet, um riskante oder unerwartete App-Nutzung zu identifizieren.

Zielressource (resource_id / resource_display_name): Definiert, auf welchen MSFT-Dienst zugegriffen wird (z. MSFT Graph oder Teams). Zu den hochwertigen Zielen gehören Graph API, SharePoint, Outlook, Teams und Verzeichnisdienste. Die Ressourcenausrichtung wird häufig durch die Ziele des Angreifers begrenzt.

Prinzipaltyp (user_type): Gibt an, ob die Anmeldung durch ein Mitglied (Benutzer) oder einen Dienstprinzipal erfolgte. Phishing-Kampagnen zielen fast immer auf Mitgliedskonten ab. Dies ermöglicht eine einfache Filterung in der Erkennungslogik, hilft aber auch bei der Kopplung ungewöhnlicher Clientanforderungen von Erstanbietern im Auftrag von Benutzerprinzipalen.

OAuth Grant Type (authentication_processing_details): Schlüssel zum Verständnis, wie das Token abgerufen wurde – Autorisierungscodes, Aktualisierungstoken, Gerätecodes, Clientanmeldeinformationen usw. Während Aktualisierungstoken und die Wiederverwendung von Gerätecode High-Fidelity-Signale für die Zeit nach der Kompromittierung sind.

Geolokalisierung: Ermöglicht es uns, atypische Anmeldungen zu identifizieren (z. seltenes Land gesehen) oder unmögliche Reisen (derselbe Benutzer von entfernten Orten in kurzer Zeit). In Kombination mit Sitzungs-ID und Korrelations-IDs können diese Token-Hijacking, Post-Identity-Compromise oder Lateral Movement aufdecken.

Gerätemetadaten (device_detail, trust_type compliance_state): Enthält Geräte-IDs, Betriebssystem, Vertrauenstypen, Konformität, verwalteten Zustand und mehr. Die Geräteregistrierung und die PRT-Ausstellung sind an diese Metadaten gebunden. Oft ein Ziel für Angreifer, um die CAP zu erfüllen und vertrauenswürdigen Zugriff zu erhalten, der dauerhaft ist.

Authentifizierungsprotokolle und -typen (authentication_protocol / incoming_token_type): Gibt an, ob die Sitzung OAuth-basiert war oder ob MFA verwendet wurde. Eingehende Tokenquellen sind diejenigen, die für diese Anforderung verwendet werden und authN oder authZ bereitstellen. Nützlich zum Erkennen der Wiederverwendung von Token und nicht interaktiven Anmeldungen.

Authentifizierungsmaterial und Sitzungskontext: Die verwendeten Token können über den Typ des eingehenden Tokens, den Tokenschutzstatus und die Sitzungs-ID abgeleitet werden. Die Wiederverwendung von Sitzungen, die lange Sitzungsdauer oder mehrere IPs, die an eine einzige Sitzung gebunden sind, deuten oft auf Missbrauch hin.

Status der Richtlinie für bedingten Zugriff: Wird während der Tokenausstellung ausgewertet – er beeinflusst jedoch stark, ob der Zugriff gewährt wurde. Dies hilft bei der Identifizierung von GAP-Umgehung und unerwarteten politischen Ergebnissen oder kann zu Risiken beitragen.

Bereiche und Zustimmungsverhalten: Angeforderte Bereiche werden in den SCP- oder OAuth-Parametern angezeigt, die in Anmeldeprotokollen erfasst werden. Zu den Indikatoren für Missbrauch gehören offline_access, .default, oder breite Bereiche wie Mail.ReadWrite. Zustimmungstelemetrie kann helfen, zu pivotieren oder zu korrelieren, wenn der Benutzer eine verdächtige Anwendung genehmigt hat.

Fazit

Die OAuth-Implementierung von Microsoft Entra ID stellt ein zweischneidiges Schwert dar: Sie ermöglicht eine leistungsstarke, nahtlose Authentifizierung – eröffnet aber auch neue Möglichkeiten für Angreifer, Angriffspfade für Vertrauen, Sitzungspersistenz und Geräteregistrierung auszunutzen.

Durch die Replikation der von Volexity beobachteten OAuth-Phishing-Techniken konnte unser Team validieren, wie Angreifer legitime Microsoft-Anwendungen, Token-Flows und Open-Source-Tools missbrauchen, um heimlichen Zugriff auf sensible Daten zu erhalten. Wir haben diese Arbeit durch praktische Emulation erweitert, indem wir tief in die Mechanismen von OAuth-Phishing und Workflows, Sicherheitstoken-Metadaten und -Erwerb eingetaucht sind und dabei geholfen haben, Verhaltensindikatoren aufzudecken, die Verteidiger erkennen können.

Unsere Ergebnisse untermauern einen wichtigen Punkt: OAuth-Missbrauch beruht nicht auf Malware oder Codeausführung. Es nutzt Identität, Zustimmung und Wiederverwendung von Token als Waffe – was traditionelle Sicherheitskontrollen zu einer Herausforderung macht – und warum protokollbasierte Erkennung, Korrelation und Verhaltensanalyse so wichtig sind.

Wir hoffen, dass die Emulationsartefakte, Erkennungsregeln und Lektionen, die hier geteilt werden, Verteidigern in der gesamten Community helfen, diese sich entwickelnde Klasse von Cloud-basierten Identitätsbedrohungen besser zu verstehen – und zu erkennen/zu jagen.

Wenn Sie Elastic verwenden, haben wir alle in diesem Blog besprochenen Erkennungsregeln als Open Source bereitgestellt, um Ihnen den Einstieg zu erleichtern. Und wenn Sie in einem anderen SIEM suchen, empfehlen wir Ihnen, die Logik anzupassen und sich entsprechend an Ihre Umgebung anzupassen.

Identität ist der neue Perimeter – und es ist an der Zeit, dass wir ihn so behandeln. Bleiben Sie gesund und viel Spaß bei der Jagd!

Regeln für die Erkennung

Referenzen:

Diesen Artikel teilen

✓FacebookLinkedInReddit (Englisch)