Azure AD Graph activity logs are now accessible within Elastic, enabling threat detection capabilities for security teams. Previously, this specific stream of telemetry was largely unavailable to customers for nearly a decade. Microsoft Graph Activity Logs, the newer interface, became generally available in April 2024, but the legacy graph.windows.net surface, frequently targeted by adversary tools, remained unlogged until early 2026.
This development addresses a significant visibility gap that has allowed tools like ROADrecon and AADInternals to operate undetected. These tools leverage the Azure AD Graph API, which, despite being deprecated, remains queryable in many environments. The Azure integration for Elastic now ingests these logs, providing full Elastic Common Schema (ECS) parsing. Key data points such as event action, outcome, HTTP request method, source IP, user ID, and original user agent are extracted as typed, top-level fields. Additional dataset-specific properties are available under `azure.aadgraphactivitylogs.properties.*`.
For years, security defenders have focused on logs related to sign-ins, conditional access policies, role assignments, and OAuth consent grants. However, the underlying directory APIs, which are prime targets for adversary tooling, were largely invisible because customer-accessible logs for them did not exist. Microsoft Graph Activity Logs were introduced first, followed by AzureADGraphActivityLogs in early 2026. This means that for a considerable period, enumeration activities performed using Azure AD Graph were undetectable by Security Operations Centers (SOCs), regardless of logging configurations.
Azure AD Graph is the older REST API for Entra ID directory objects, accessible via `https://graph.windows.net/{tenantId}/{objecttype}` with versions like 1.5, 1.6, and 1.61-internal. Microsoft has been encouraging migration to Microsoft Graph since 2019, with multiple postponements of the retirement date. Despite deprecation, Azure AD Graph continues to function in environments where legacy access paths are still enabled or where applications have not been explicitly blocked. This persistence makes it an attractive target for attackers, especially since adversary tooling has not always been updated to use the newer Microsoft Graph API.
Furthermore, certain internal API versions of Azure AD Graph, such as 1.61-internal, expose more detailed information, like strong authentication details directly on the user object during a directory traversal. This contrasts with Microsoft Graph, where equivalent information might require additional permissions or separate endpoint calls. The lack of a simple, tenant-wide blocking mechanism for Azure AD Graph access, which is managed per-application, means many organizations have not fully disabled it due to dependencies on legacy automation. This phased enforcement by Microsoft, rather than a defender-controlled timeline, has historically allowed for undetected exploitation.
Legitimate Azure AD Graph traffic is typically dominated by a few first-party Microsoft applications, including Microsoft.OData.Client and the Microsoft Azure Graph Client Library. Any traffic deviating from these recognized sources can indicate internal tooling or unauthorized activity, making the logs a valuable resource for threat hunting and detection, provided they are captured.
To ingest these logs into Elastic, organizations can leverage the existing Elastic Azure integration. If the integration is already set up to forward diagnostic settings to an event hub, enabling the AzureADGraphActivityLogs category is the primary additional step. For new setups, the process involves configuring the Azure integration in Kibana, providing Event Hub connection details and a storage account for checkpointing. Crucially, the AzureADGraphActivityLogs diagnostic setting must be enabled within Entra ID's diagnostic settings in the Azure portal.
Once enabled, events are routed to `logs-azure.aadgraphactivitylogs-*`, where the dataset pipeline performs ECS extraction. Verification of data flow can be done by querying for recent events and checking for populated fields like `event.action` and `http.request.method`. To generate test events, users can navigate through Entra ID sections in the Azure portal or execute a loop of `curl` commands to query common object types via the Azure AD Graph API.
The ingested data provides structured fields for hunting, including ECS fields like `event.action`, `event.outcome`, `http.request.method`, `source.ip`, `user.id`, and `user_agent.original`. Dataset-specific properties under `azure.aadgraphactivitylogs.properties.*` offer further context, such as `app_id`, `api_version`, and `actor_type`. This structured data allows for effective pivoting and analysis, enabling the detection of activities such as unusual user agent strings, broad endpoint usage, misuse of internal API versions, mismatches in client IDs, and surges in 4xx HTTP status codes.
