The Decade-Long Blind Spot in Azure Directory Telemetry

For years, security operations teams monitoring Microsoft Azure environments operated under a fundamental illusion of coverage. Sign-in logs, conditional access events, role assignment changes, OAuth consent grants — all meticulously collected, parsed, and analyzed. Yet an entire attack surface remained completely invisible: the Azure Active Directory Graph API, the legacy directory service that adversary tooling has relied upon for bulk enumeration since the earliest days of cloud-focused red teaming.

Cloud Security Alert: For years, security operations teams monitoring Microsoft Azure environments operated under a fundamental illusion of coverage.

That visibility gap officially closed in early 2026 with the general availability of AzureADGraphActivityLogs. For defenders who understand what this telemetry represents, the significance cannot be overstated. Tools like ROADrecon and AADInternals have been silently querying directory objects — users, groups, authentication methods, service principals — without producing a single capturable log event. Not because the telemetry was restricted or buried in privileged tiers, but because it simply did not exist as a customer-accessible stream.

That changes now. And the detection opportunities that follow are substantial.

Why the Legacy API Remains an Active Attack Target

The Azure AD Graph API — hosted at graph.windows.net — has been officially deprecated since 2019. Microsoft has repeatedly urged migration to the modern Microsoft Graph surface at graph.microsoft.com, and retirement enforcement continues on Microsoft's timeline. Despite this, the legacy API remains queryable in a significant number of production tenants, and adversary tooling developers have had little incentive to modernize their codebases.

Several factors keep this API attractive to attackers:

Why the Legacy API Remains an Active Attack Target
Tooling inertia: Widely used offensive frameworks including ROADrecon and AADInternals continue to issue calls against graph.windows.net endpoints. These tools have not been fully ported to the modern Graph surface.
Data asymmetry: Internal API versions such as 1.61-internal return enriched user object data — including strong authentication detail — inline during a standard directory walk. Retrieving equivalent information via Microsoft Graph requires separate endpoint calls gated by elevated permission scopes. Bulk enumeration tooling exploits this difference directly.
Blocking complexity: Tenant-wide suppression of AAD Graph access requires iterating every app registration individually through the blockAzureADGraphAccess control on application authentication behaviors. Legacy automation dependencies mean most organizations have not completed this process.
Adversaries and red teamers have been hammering these API endpoints for years. The absence of logs was not a sign of inactivity — it was a sign of zero visibility.

What Normal Traffic Looks Like — and Why Anomalies Stand Out

One of the most operationally useful characteristics of this new log source is the predictability of legitimate baseline traffic. In practice, the overwhelming majority of AAD Graph API calls originate from a small set of first-party Microsoft callers: internal Microsoft OData and ADO.NET client libraries, the Azure Graph Client Library, Azure Portal sessions identifiable by standard browser user-agent strings, and a tail of first-party application IDs generating requests with empty user-agent fields.

This narrow legitimate footprint makes adversarial traffic genuinely detectable. Any user-agent string or application identity falling outside that recognizable baseline warrants immediate scrutiny. Offensive tools typically self-identify through distinctive user-agent strings, query an unusually broad range of directory endpoints within compressed timeframes, leverage *-internal API version identifiers, or generate bursts of 4xx error responses consistent with automated enumeration behavior.

Five Detection Patterns That Catch Real-World Enumeration

With AzureADGraphActivityLogs flowing into a SIEM, the following hunting approaches consistently surface enumeration activity in validated environments:

  • Tooling user-agent signatures: ROADrecon, AADInternals, and similar frameworks embed recognizable strings in request headers. Querying user_agent.original against known offensive tool identifiers is the highest-fidelity starting point.
  • Endpoint breadth per session: Legitimate callers typically access a limited set of resource types. Sessions touching users, groups, service principals, roles, and authentication policies within minutes suggest automated directory walking.
  • Internal API version usage: Legitimate production applications do not call 1.61-internal or similar undocumented internal API versions. Any appearance of *-internal version strings in request paths should be treated as a high-confidence signal.
  • FOCI client-ID anomalies: Family of Client ID token abuse produces characteristic mismatches between the calling application identity and expected token issuance patterns.
  • 4xx error rate surges: Bulk enumeration tools probing for accessible objects generate elevated rates of not-found and forbidden responses. Sudden spikes from a single source IP or user identity indicate scanning behavior.

Ingesting the Logs: What You Need to Know

For organizations already forwarding Azure diagnostic logs to an event hub, enabling AzureADGraphActivityLogs requires adding a single log category to the existing diagnostic settings configuration. Events carrying the AzureADGraphActivityLogs category are automatically routed to a dedicated index with full Elastic Common Schema extraction applied, surfacing fields including event.action, event.outcome, http.request.method, source.ip, user.id, and user_agent.original in typed, queryable form.

Extended properties specific to the Azure AD Graph log schema remain accessible under the azure.aadgraphactivitylogs.properties.* namespace, providing access to API version strings, resource paths, and other fields essential to the detection logic described above.

Organizations building from scratch can have the full pipeline operational in roughly twenty minutes using the Azure integration within Kibana, with an event hub and storage account for offset checkpointing as the only infrastructure prerequisites.

What You Should Do

  • Enable AzureADGraphActivityLogs immediately if you are running Azure diagnostic settings. The log category is available now and requires minimal configuration change.
  • Establish a baseline of legitimate callers in your tenant before building threshold-based alerts. First-party Microsoft services generate predictable traffic patterns that define your normal.
  • Build user-agent detections first. Offensive tooling signatures are the highest-fidelity, lowest-false-positive detection opportunity this data source provides.
  • Flag any use of *-internal API versions. There is no legitimate production use case for undocumented internal API version strings in this log source.
  • Prioritize the blocking of legacy API access where feasible, iterating through application registrations to set blockAzureADGraphAccess where no legitimate dependency exists.
  • Cross-correlate with sign-in and token issuance logs. AAD Graph enumeration activity frequently follows initial access events. Correlating these streams surfaces attack progression that neither source reveals independently.

The emergence of AzureADGraphActivityLogs represents a genuine shift in the defender's ability to monitor a historically opaque attack surface. The tools used to exploit it have been operational for years. The detection opportunity — finally — is here.