Azure AD Graph Activity Logs: Aufnahme und Bedrohungserkennung, um die Sichtbarkeitslücke zu schließen

AAD Graph Activity Logs sind jetzt in Elastic einsetzbar und für Bedrohungserkennung innerhalb der SIEM/XDR-Lösung nutzbar. Dieser Satz sollte eigentlich nicht aufregend sein, aber er ist es. Im größten Teil des letzten Jahrzehnts existierte dieser Teil der Telemetrie einfach nicht als kundenzugänglicher Logstrom. Microsoft Graph Activity Logs (die moderne Oberfläche graph.microsoft.com ) wurde im April 2024 offiziell eingestellt. Das Vermächtnis graph.windows.net Oberfläche, das einzige Gegner-Werkzeug tatsächlich trifft, blieb bis Anfang 2026 dunkel.

Dieser Beitrag geht die Schleife von Anfang zu Ende ab. Warum Sichtbarkeit wichtig ist, wie man die Logs in Elastic einführt, wie man realistische Aufklärung manuell und mit ROADrecon generiert und wie man das Ergebnis in ES|QL sucht. Alles unten wurde gegen einen lebenden Mieter validiert.

Wichtigste Erkenntnisse

• AAD-Graph-Aktivitätsprotokolle gelangen über die Azure-Integration in Elastic und landen mit vollständiger ECS-Extraktion in logs-azure.aadgraphactivitylogs-* .

• ROADtools, AADInternals und Freunde arbeiten seit Jahren in einer Sichtbarkeitslücke. Die Verteidiger haben die Entscheidungen nicht erfasst.

• AAD Graph ist "veraltet", aber in den meisten Mietern noch abfragbar. Die interne API-Version 1.61 liefert weiterhin Daten, die Microsoft Graph nicht liefert.

• ECS-Felder landtypisiert (event.action, event.outcome, http.request.method, source.ip, user.id, user_agent.original). Datensatz-Extras bleiben unter azure.aadgraphactivitylogs.properties.*abfragbar.

• Fünf Hunts erkennen die Aktivität zuverlässig: Tooling User-Agents, Endpoint Width, *-internal API-Missbrauch, FOCI-Client-ID-Missmatches und 4xx-Surges.

Eine kurze Geschichte der Sichtbarkeit von Verteidigern

Verteidiger haben jahrelang mit Anmeldungen, bedingtem Zugang, Rollenzuweisungen und OAuth-Einwilligungserteilungen verbracht. Sehr wenig Inhalt deckt die zugrundeliegenden Verzeichnis-APIs ab, auf die das Gegner-Tooling tatsächlich trifft. Der Grund ist strukturell: Kundenzugängliche Logs für diese APIs existierten nicht. Microsoft Graph Activity Logs wurden zuerst veröffentlicht (Vorschau Oktober 2023, GA April 2024). AzureADGraphActivityLogs tauchte schließlich Anfang 2026 auf.

Während des größten Teils des letzten Jahrzehnts war die AAD-Graph-Enumeration für SOCs unsichtbar, nicht weil die Telemetrie verborgen war, sondern weil sie nicht existierte. ROADtools, AADInternals, MSOLSpray, Microburst. Keiner von ihnen erzeugte Daten, die jeder erfassen konnte, selbst mit einer perfekten Protokollkonfiguration.

Das ändert sich an dem Tag, an dem AzureADGraphActivityLogs in deinem platform-logs-Index landen.

AAD Graph ist "veraltet", aber immer noch sehr lebendig

Kurze Auffrischung. Azure AD Graph ist die legacy REST-API für Entra ID-Verzeichnisobjekte, gehostet bei https://graph.windows.net/{tenantId}/{objecttype} mit API-Versionen wie 1.5, 1.6 und 1.61-intern. Microsoft fordert seit 2019 alle auf, auf Microsoft Graph umzusteigen, und das Pensionsdatum wurde mehrfach verschoben.

Deprecation ist nicht verschwunden. Im Jahr 2026 kann AAD Graph weiterhin Anfragen in Umgebungen beantworten, in denen noch Altzugriffspfade verfügbar sind oder Anwendungen nicht ausdrücklich daran gehindert wurden, es zu nutzen. Einige Gründe, warum es als Ziel für Angreifer erhalten bleibt:

• Gegnerwerkzeuge wurden nicht portiert. ROADrecon nutzt es immer noch für gather. AADInternals hat Dutzende von CMDLETs, die es umwickeln.

• Die *-internal API-Versionen liefern mehr Daten zurück. 1.61-internal stellt strongAuthenticationDetail Inline auf dem Benutzerobjekt während eines normalen Verzeichnis-Walks frei. Das Microsoft Graph-Äquivalent befindet sich hinter einem separaten /authentication/methods-Endpunkt, der von UserAuthenticationMethod.Read.Allgesperrt wird. Diese Asymmetrie ist genau das, was Bulk-Enumeration-Tools ausnutzen.

• Der Block ist kein einzelner Schalter. Die blockAzureADGraphAccess kontrollieren Live-Daten pro App auf application.authenticationBehaviors, daher bedeutet das Blockieren von tenant-weiten jede App-Registrierung zu iterieren. Die meisten Umgebungen haben das nicht gemacht, weil einige alte Automatisierungen immer noch von der API abhängen. Microsofts phasenweise Rentendurchsetzung erledigt die Arbeit nach Microsofts Zeitplan, nicht nach dem des Verteidigers.

• Sichtbarkeit existierte nicht, sodass Red-Team-Mitarbeiter und Gegner die API-Endpunkte nach relevanten Informationen bombardieren konnten.

Der legitime AAD-Graph-Verkehr wird von einer Handvoll Microsoft-Anrufer aus der eigenen Partei dominiert. In unserem Test-Tenant war die Reihenfolge nach Volumen Microsoft.OData.Client, Microsoft Azure Graph Client Library, ein leeres UA-Tail von First-Party-AppIDs, Microsoft ADO.NET Data Services, und dem Azure-Portal (Chrome-UAs gegen die Portal-App-ID). Alles außerhalb dieses erkennbaren Sets ist entweder interne Werkzeuge oder unbefugte Aktivitäten. Das macht es zu einem soliden Datensatz zur Bedrohungsjagd und -erkennung. Wenn du es aufnimmst.

Einrichtung der Aufnahmepipeline

Wenn du bereits die Elastic Azure-Integration mit der Weiterleitung von Diagnoseeinstellungen an einen Event Hub nutzt, überfliege diesen Abschnitt. Du musst wahrscheinlich nur eine zusätzliche Log-Kategorie aktivieren. Von Grund auf ist es ein etwa 20-minütiger Weg.

Schritt 1: Ein Stack, um die Logs zu empfangen

Jede elastische Bereitstellung funktioniert. Ein Elastic Cloud-Test ist die Option mit geringsten Reibungskosten für Prototyping. Eine weitere Option ist das Elastic Container Project zum Einstieg. Die Azure-Integration verwaltet AzureADGraphActivityLogs bereits, sobald sie aktiviert ist.

Schritt 2: Fügen Sie die Azure-Integration hinzu

In Kibana > Azure Logs > Add Azure Logs. Geben Sie Ihre Event Hub-Verbindungsstring, den Event Hub-Namen und ein Storage-Konto für Offset-Checkpoints ein, alles auf einem Event Hub im selben Abonnement wie Ihr Tenant.

Aktiviere speziell den Azure Logs v2 Datenstrom. Das ist der Einstiegspunkt für AAD Graph Activity Logs. Der Event-Router gleicht category == "AzureADGraphActivityLogs" ab und leitet Dokumente nach logs-azure.aadgraphactivitylogs-*um, wo die Datensatz-Pipeline eine vollständige ECS-Extraktion anwendet.

Wir haben außerdem Azure AD Graph Activity Logs in ein eigenes Integrationselement aufgeteilt, sodass Sie nach "Azure AD Graph Activity Logs" suchen und direkt über die Richtlinienvorlage installieren können.

Schritt 3: Aktivieren Sie die Diagnoseeinstellungen bei Entra ID

Das ist der Schritt, den die meisten Verteidiger übersehen. AzureADGraphActivityLogs als Kategorie für diagnostische Einstellungen ist neuer. Selbst wenn deine Entra-ID-Diagnoseeinstellungen schon eine Weile konfiguriert sind, braucht die neue Kategorie ein frisches Häkchen. Andernfalls leben und sterben die Daten innerhalb der Mietergrenzen von Microsoft.

Im Azure-Portal:

1. Entra ID > Überwachung > Diagnoseeinstellungen > + Hinzufügen von Diagnoseeinstellungen.
2. Sag es.
3. Unter Logs siehe AzureADGraphActivityLogs. Während du dort bist, sind MicrosoftGraphActivityLogs, SignInLogs und AuditLogs sinnvoll, sie einzuschalten, falls sie es noch nicht sind. Die Integration übernimmt alle.
4. Unter Zieldetails streamen Sie zu einem Event-Hub (demselben wie in Schritt 2).
5. Speichern.

Schritt 4: Überprüfen Sie den Datenfluss

Innerhalb weniger Minuten sollten Sie anfangen, Ereignisse zu sehen. Schnellster Sanitätscheck:

FROM logs-azure.aadgraphactivitylogs-*
| LIMIT 20

Wenn Dokumente mit einem ausgefüllten event.action, http.request.methodund zure.aadgraphactivitylogs.properties.* Feldern zurückkommen, bist du auf der sicheren Seite. Wenn nichts erscheint, sind die üblichen Verdächtigen eine vergessene Ereignis-Hub-Berechtigung, ein Tippfehler in der Verbindungsfolge oder die AAD-Graph-Kategorie, die einfach nicht angekreuzt wird.

Um einige Ereignisse zu erzwingen, melden Sie sich im Azure-Portal an und klicken Sie auf Benutzer oder Anwendungen. Das Portal ruft intern weiterhin AAD Graph für einige Objektdetails auf. Wenn das nichts erzeugt, wird diese Curl-Schleife:

TOKEN=$(az account get-access-token --resource https://graph.windows.net --query accessToken -o tsv)
TID=$(az account show --query tenantId -o tsv)
for obj in users groups servicePrincipals applications tenantDetails; do
  curl -sS -o /dev/null -H "Authorization: Bearer $TOKEN" \
    "https://graph.windows.net/$TID/$obj?api-version=1.6&\$top=5"
done

Feldform

Sobald die Daten fließen, landen die Eigenschaften als typisierte, oberste Felder. Die, die für die Jagd wichtig sind:

• ECS, direkt bevolkt: event.action (ein semantisches Verb, abgeleitet von Methode + Sammlung, z. B. users-read, batch-execute), event.outcome, event.duration, http.request.method, http.response.status_code, source.ip, und source.geo.*, user.id, user_agent.original (plus geparste Teilkörper), url.path, azure.tenant_id, cloud.service.name = "Azure AD Graph".
• Datensatzspezifisch unter zure.aadgraphactivitylogs.properties.*: app_id,, app_id, api_version, actor_type, roles, scopes, wids, identity_provider, client_auth_method, sign_in_activity_id, token_issued_at.
• related.user bekommt sowohl user.id als auch properties.app_id, sodass Pivots auf der OAuth-Client-Dimension parallel zum Benutzer-Pivot arbeiten.

Raw JSON bleibt im Event.original für forensische Wiederholung. Für normale Jagd solltest du nicht hineingreifen müssen. Wenn ja, ES|QLs JSON_EXTRACT() ist der Hebel.

AAD-Graphenaufzählung mit ROADrecon

Um zu wissen, was man jagen sollte, muss man wissen, wie die Aktivität aussieht. Die beiden folgenden Toolkits sind die häufigsten Quellen für AAD-Graphen-Verkehr in Red-Team- und Sicherheitsforschungsworkflows. Ich habe beide gegen unseren Test-Tenant getestet.

Hinweis: Ich übernehme keine Verantwortung für den Missbrauch dieses Codes. Führe diese Tools nur gegen Mieter aus, die du besitzt oder eine ausdrückliche schriftliche Genehmigung zum Testen hast.

ROADrecon: Massen-Zählungstest

ROADrecon ist das Datenerfassungsmodul von ROADtools, Dirk-jan Mollemas Entra ID-Forschungsrahmenwerk. Sehr zu empfehlen, falls du es noch nicht benutzt hast. gather durchläuft jeden interessanten Objekttyp im Verzeichnis (Benutzer, Gruppen, Dienstprinzipalen, Anwendungen, Geräte, Verzeichnisrollen, Rollenzuweisungen, berechtigte Rollenzuweisungen, OAuth2-Berechtigungen, Verwaltungseinheiten) und schreibt das Ergebnis in SQLite.

Die Einrichtung ist der Standard-Workflow:

pip install roadrecon
roadrecon auth --device-code -c 04b07795-8ddb-461a-bbee-02f9e1bf7b46 -r https://graph.windows.net

Der Gerätecode-Fluss liefert dir eine URL und einen Code. Wir verwenden die Microsoft Azure CLI als Standard (1b730954-1685-4b74-9bfd-dac224a7b894 – AAD PowerShell), die 403s in unserem Tenant zurückgab. Nach der Anmeldung:

roadrecon gather

Laufende Roadrecon sammelt sich, wobei das resultierende Token sauber abgeschlossen ist. Aus Sicht des Mieters führte der Durchlauf in etwa 1 Minuten etwas mehr als ~2.000 AAD Graph Calls und Logs. Massenaufzählung über jeden Objekttyp, den ROADrecon kennt.

Daraus können wir erste Erkennungen erstellen, um diese Anomalien zu markieren.

Schlüsselfelder für die Bedrohungserkennung von AAD-Graphen

Vor den Jagden hier einige solide Startfelder zur Erkennung von Anomalien.

Erkennung und Prävention

Erkennung

Die Voraussetzung für jede AAD-Graphenerkennung ist, dass die Logs überhaupt vorhanden sind. Die AzureADGraphActivityLogs-Diagnosekategorie muss in Entra-ID aktiviert und an ein Ziel weitergeleitet werden, das Sie abfragen können (mindestens einen Log Analytics Workspace, idealerweise auch an einen Event Hub für Elastic-Ingestion weitergeleitet, wie im obigen Setup-Abschnitt beschrieben). Bis das erledigt ist, erfolgen die in diesem Beitrag beschriebenen Rufe vollständig außerhalb der Kamera, und keine der unten genannten Jagden feuert.

Wenn du gerade nicht in Elastic einlesen kannst, aktiviere trotzdem die Diagnoseeinstellung und sende sie an Log Analytics. Die unten stehenden KQL-Äquivalente der Hunts sind unkompliziert, und die Daten sammeln sich auch ohne weitere Verarbeitung mit Aufbewahrung.

Verhütung

Es gibt keinen einzelnen tenantweiten AAD Graph Kill-Switch im Portal. Die eigentliche Steuerung auf der Anwendungsebene ist:

• application.authenticationBehaviors.blockAzureADGraphAccess

Ein pro-App-Boolean auf der Anwendungsressource (Microsoft Graph Beta, Dokumentation). Blockieren im großen Maßstab bedeutet, jede App-Registrierung manuell oder programmatisch zu öffnen. Microsofts eigene schrittweise Pensionierung macht dies unabhängig davon auf ihrem Zeitplan. Je weiter das kommt, desto weniger Fläche gibt es zu verteidigen.

Verteidiger können sich in der Zwischenzeit auf denselben Achsen bewegen:

• Überprüfe Anwendungen in deinem Mieter, die noch Token für graph.windows.net enthalten. Setze blockAzureADGraphAccess = true auf die, die es nicht brauchen. Alles, was immer noch auf AAD Graph angewiesen ist, bricht lautstark ab, was eine alte Automatisierung aufdeckt, von der du nicht wusstest, dass du sie hast.

• Wenden Sie Conditional Access mit Azure AD Graph als Zielressource an. Der Azure AD Graph Service Principal (00000002-0000-0000-c000-000000000000) wird im Standard-CA-App-Picker nicht angezeigt, aber er wird von allen Ressourcenrichtlinien abgedeckt und kann einzeln über den benutzerdefinierten Sicherheitsattributfilteransatz gezielt werden. Microsofts Änderung der Durchsetzung im März 2026 macht dies praktischer: Low-Privilege-Scopes (User.Read, People.Read usw.), die früher automatisch von der CA-Durchsetzung ausgeschlossen waren, werden jetzt als AAD-Graph-Zugriff behandelt, sodass alle Ressourcenrichtlinien sie tatsächlich sperren. CA bewertet bei der Tokenausgabe, sodass bereits gültige Token bis zum Ablauf weiterfunktionieren.

• Wenden Sie CA auf die FOCI-Clients an, auf denen Adversary Tooling Riding (Microsoft Teams, Microsoft Office, OneDrive, Azure PowerShell usw.). Benötigt verwaltete und konforme Geräte. Der Swap-Pfad kollabiert, wenn der zugrundeliegende Client sich nicht anmelden kann.

• Für Service-Principal-Anrufer fügt Workload Identities Premium CA-Scoped zu Service Principals hinzu. Die Bedingungen sind auf Standort, Identitätsschutzrisiko und Authentifizierungskontext beschränkt; die einzige Grant-Kontrolle ist Block. Nützlich, um externe und riskante Kontextpfade einzustürzen, nicht um einen SP auf bestimmte Cloud-Apps abzugrenzen, wie es die User-CA tut.

• Deaktiviere den Gerätecode-Fluss für Nutzer, die ihn nicht benötigen. roadrecon auth --device-code ist der Weg des geringsten Widerstands in die gesamte oben genannte Pipeline und ist bei OAuth-Phishing äußerst verbreitet.

Erkennung von Verhalten

Wir haben Erkennungsregeln für die oben dokumentierten AAD Graph-Recon-Formen ausgeliefert. Jede davon befindet sich im Elastic-Detection-Rules-Repository und läuft nativ gegen den geparsten logs-azure.aadgraphactivitylogs-* Datenstrom.

Azure AD Graph Access mit Suspicious User-Agent – KQL-Match-Regel. Triggert, wenn AAD Graph Verkehr von User-Agent-Strings empfängt, die zu offensiven Tooling-Familien (Python, aiohttp, curl, Go-http-client, axios, AzureHound, BloodHound, AADIntenals usw.) passen. Ein solides Basissignal, weil keine Microsoft-Komponente von Microsoft als eine dieser Komponenten identifiziert wird, während Standard-Tools dies tun. 

Azure AD Graph High 4xx Error Ratio from User - ES|QL-Aggregation. Triggert, wenn ein einzelner Anrufer in einem kurzen Zeitraum ein ungewöhnlich hohes Verhältnis von 4xx-Antworten gegenüber AAD Graph erzeugt. Aufklärung und Brute-Force-Token-Nutzung hinterlassen eine Menge von 403ern und 404en, da Tools Endpunkte durchlaufen, für die sie keine Berechtigung haben, nach Objekt-IDs fragen, die sie nicht haben, oder eine unautorisierte Client-ID für AAD Graph verwenden. 

Azure AD Graph Access mit ungewöhnlichem Client und Benutzer – KQL new_terms Regel, mittlerer Schweregrad. Es wird ausgelöst, wenn ein (aufrufendes OAuth-Client, angemeldeter Benutzer) Paar zum ersten Mal in den vorangegangenen 14 Tagen auf AAD Graph erscheint. Entdeckt FOCI-Swaps, phished Refresh-Token, die für Clients eingelöst werden, die der Nutzer normalerweise nicht nutzt, und gestohlene Token, die unter unbekannten Clients verwendet werden. Ignoriert bekannte First-Party-Anwendungen, die häufig bei der Interaktion mit Azure AD beobachtet wurden und im Backend von Microsoft sind.

Azure AD Graph Access mit ungewöhnlichem Benutzer und ASN – KQL-Match-Regel. Schließt die üblichen Microsoft / AWS / GCP / Akamai / Cloudflare ASN-Organisationen aus und markiert AAD-Graph-Verkehr, der außerhalb dieses Sets stammt. Adversary Tooling basiert typischerweise auf privaten ISPs, VPS-Anbietern oder anonymisierenden Netzwerken, die eine andere ASN-Verteilung erzeugen als legitime First-Party-Anrufer. Anpassung pro Mieter durch Anpassung der ausgeschlossenen ASN-Liste.

Azure AD Graph Potential Enumeration (ROADrecon) - ES|QL-Aggregation, hohe Schwere. Erfordert sowohl einen aiohttp-User-Agent als auch einen Burst von 500+ AAD-Graph-Anfragen von einer einzigen Identität. Der Befehl 'Gatge ' von ROADrecon verwendet standardmäßig aiohttp und durchläuft jeden Verzeichnisobjekttyp, sodass die Kombination im Grunde ein Werkzeugfingerabdruck ist. Höher als die generische Nicht-Microsoft-UA-Regel, weil die zusätzliche Burst-Anforderung die Entwickler-Prototyp-False-Positive-Klasse entfernt.

Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration - EQL sequence, high seveity. Verbindet sich innerhalb von fünf Minuten mit einer erfolgreichen Gerätecode-Anmeldung mit der alten AAD Graph-Zielgruppe (00000002-0000-0000-c000-000000000000) auf einem nicht verwalteten Gerät mit Verzeichnis-Enumeration gegen graph.windows.net desselben Benutzers. Gerätecode-Phishing landet ein OAuth-Token, ohne das Passwort oder MFA des Nutzers zu berühren, sodass sofortige Graph-Reads von Benutzern, Dienstprinzipalern, Anwendungen, Rollenzuweisungen, Richtlinien oder Mieterdetails unter diesem Token die kompromittierte Identität sind, die vom Angreifer gesteuert wird. Die Cross-Data-Stream-Sequenz entfernt die Einzelereignis-False-Positive-Klasse, die die anderen AAD-Graph-Regeln tragen.

Sichtbarkeit der AAD-Grafik: Was als Nächstes kommt

Während des größten Teils des letzten Jahrzehnts war die AAD-Graph-Aktivität das telemetrieartige Äquivalent von Dunkler Materie. Wir wussten, dass es da war, weil die Gegner-Tools immer wieder darauf zeigten, aber die Kunden hatten keinen Diagnosestream zum Abonnieren und keine Protokolle zum Abfragen. Microsoft Graph Activity Logs schloss die Hälfte der Lücke, als sie im April 2024 GA gingen. AzureADGraphActivityLogs schloss die andere Hälfte schließlich Anfang 2026.

Jetzt, wo die Daten existieren, liegt der Rest an uns. Füge die neue Diagnoseeinstellung hinzu, richte sie auf einen Ereignishub, speichere in deinen Stack, schalte Erkennungen ein (oder erstelle eigene Optionen) und übernimm die Überwachung.

Die Entdeckungen in diesem Beitrag sind ein Ausgangspunkt. Sobald AAD-Graph-Verkehr in deinem Stack landet und eine Basislinie dessen, wie normal in deinem Tenant aussieht, verallgemeinern sich die gleichen Muster. Legitime First-Party-Microsoft-Anrufer bilden ein kleines, erkennbares Set, und alles außerhalb dieses Sets verdient eine genauere Betrachtung.

Die Aktivität war immer da. Die Sicht ist es endlich auch.

Viel Erfolg bei der Suche!

Referenzen

In der obigen Studie wurde auf Folgendes Bezug genommen:

• Elastic Azure Integration
• ROADtools GitHub
• ROADtools Wiki
• BloodHound mit Azure-AD-Funktionen
• AADInternals
• AADInternals-Dokumentation
• Migrate deine Apps von Azure AD Graph zu Microsoft Graph
• Konfigurieren Sie Microsoft Entra Diagnoseeinstellungen für Aktivitätsprotokolle
• Zugriff auf Microsoft Graph Aktivitätsprotokolle
• Microsoft Graph-Aktivitätsprotokolle sind jetzt allgemein verfügbar
• Das fehlende Glied: AADGraphActivityLogs kommt endlich an
• Azure AD Privilegien-Eskalation – Übernahme der Standard-Anwendungsberechtigungen als Anwendungsadministrator
• Missbrauch von Azure AD SSO mit dem Primary Refresh Token

Über Elastic Security Labs

Elastic Security Labs ist die Bedrohungsintelligenzabteilung von Elastic Security, die sich der Förderung positiver Veränderungen in der Bedrohungslandschaft widmet. Elastic Security Labs stellt öffentlich zugängliche Forschung zu aufkommenden Bedrohungen bereit, analysiert strategische, operative und taktische Gegnerziele und integriert diese Forschung anschließend mit den integrierten Erkennungs- und Reaktionsfunktionen von Elastic Security. Folgen Sie Elastic Security Labs auf Twitter @elasticseclabs und sehen Sie sich unsere Forschung bei www.elastic.co/security-labs/ an.