Azure AD Graph Activity Logs: Ingestion and threat detection to close the visibility gap

What Happened

For years, attackers have used specialized tools to secretly map out user accounts and permissions in Microsoft cloud environments using an older, hidden system called Azure AD Graph. Microsoft has finally made the logs for this older system available to defenders. This matters because security teams can now see and stop this reconnaissance activity before an attacker can use the information to move deeper into the network. Organizations should immediately turn on this new logging feature in their Microsoft settings and send the data to their security monitoring tools.

Key Takeaways

• Azure AD Graph Activity Logs are now ingestible into Elastic via the Azure integration, closing a years-long visibility gap.
• Adversary tools like ROADtools and AADInternals have historically abused the legacy AAD Graph API because it lacked customer-facing telemetry.
• The legacy AAD Graph API remains queryable in most tenants, and internal API versions (e.g., 1.61-internal) return sensitive data not available in Microsoft Graph.
• Threat hunting can effectively target tooling user-agents, endpoint enumeration breadth, internal API misuse, and 4xx error surges.
• Defenders must explicitly enable the AzureADGraphActivityLogs diagnostic setting in Entra ID to begin capturing this telemetry.

Affected Systems

• Microsoft Entra ID
• Azure AD Graph API (graph.windows.net)
• Elastic SIEM

Attack Chain

Threat actors initiate the attack chain by acquiring an OAuth token, frequently leveraging device-code phishing to bypass MFA and password requirements. Using the compromised token, they authenticate to the legacy Azure AD Graph API via tools like ROADrecon or AADInternals. The tooling performs bulk automated enumeration across directory objects, often requesting internal API versions (e.g., 1.61-internal) to extract sensitive authentication details not visible in modern Graph APIs. This reconnaissance data is then stored locally to plan subsequent lateral movement or privilege escalation.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: Yes
• Splunk SPL Queries: No
• EQL Queries: Yes
• Other Detection Logic: No
• Platforms: Elastic Security

Elastic provides KQL and ES|QL detection rules targeting suspicious user agents, high 4xx error ratios, unusual clients, and ROADrecon enumeration behavior against Azure AD Graph.

Detection Engineering Assessment

EDR Visibility: None — This activity occurs entirely within the cloud control plane (Entra ID / Azure AD Graph API) and does not interact with endpoint operating systems. Network Visibility: None — API calls are TLS-encrypted and typically originate from attacker-controlled infrastructure directly to Microsoft's cloud endpoints. Detection Difficulty: Moderate — Requires explicit configuration of new diagnostic settings in Entra ID and baseline tuning to filter out legitimate first-party Microsoft callers.

Required Log Sources

• AzureADGraphActivityLogs
• SignInLogs
• AuditLogs

Hunting Hypotheses

Control Gaps

• Lack of AzureADGraphActivityLogs ingestion in SIEM
• Legacy applications lacking blockAzureADGraphAccess enforcement
• Overly permissive device-code flow settings

Key Behavioral Indicators

• event.action (e.g., users-read, batch-execute)
• http.response.status_code (403, 404 bursts)
• user_agent.original (aiohttp, curl, python-requests)
• azure.aadgraphactivitylogs.properties.api_version (1.61-internal)

False Positive Assessment

• Low

Recommendations

Immediate Mitigation

• Verify against your organization's incident response runbook and team escalation paths before acting.
• Consider enabling the AzureADGraphActivityLogs diagnostic setting in Entra ID and routing it to your SIEM or Log Analytics workspace.

Infrastructure Hardening

• Evaluate auditing applications in your tenant that hold tokens for graph.windows.net and consider setting blockAzureADGraphAccess to true where not needed.
• If supported by your licensing, consider applying Conditional Access policies targeting the Azure AD Graph service principal.

User Protection

• Consider disabling device-code flow for users who do not require it to reduce the risk of OAuth phishing.
• Evaluate requiring managed and compliant devices for FOCI clients (e.g., Microsoft Teams, Azure PowerShell).

Security Awareness

• Consider training security analysts on the significance of legacy AAD Graph enumeration as an indicator of cloud compromise.

MITRE ATT&CK Mapping

• T1087.004 - Account Discovery: Cloud Account
• T1526 - Cloud Service Discovery
• T1119 - Automated Collection
• T1528 - Steal Application Access Token

Additional IOCs

• Command Lines:
  • Purpose: Authenticates to Azure AD Graph using device-code flow via ROADrecon | Tools: ROADrecon | Stage: Credential Access | roadrecon auth --device-code -c
  • Purpose: Initiates bulk enumeration of Entra ID directory objects via ROADrecon | Tools: ROADrecon | Stage: Discovery | roadrecon gather