Now You See Me: AADGraphActivityLogs

In my series “Detect threats using *GraphActivityLogs” I covered a lot of the basics on how to use different methods to detect certain reconnaissance tooling based on fingerprinting the specific sequence of requests or the volume of requests made to the Microsoft Graph endpoints. But one of the biggest detection gaps in all this was the Azure AD Graph, the old API on a retirement path that started before some of you might work in cyber security. All this changed in early May 2026 with the introduction of the AADGraphActivityLogs as a new log source. And don’t get me wrong, this table was in the official documentation since May 2025 but no data was flowing. After a long private preview Microsoft, almost silently released the log to all their customers and gave them crucial insights in one of the most abused protocols for reconnaissance. Notably toolkits like ROADtools and AADInternals use this API to gather deep insights into the tenant and attack vectors like the Intune Company portal Conditional Access bypass rely on the default grant to this resource.

Enable logs

Like all Entra ID logs you can configure the log forwarding of the AADGraphActivityLogs in the Diagnostic Settings of Entra ID. For my purpose I forward them to a Sentinel enabled Log Analytics workspace.

Log schema

While the log schema itself is very extensive, let’s concentrate on the fields that are crucial for detection engineers and defenders.

• TimeRequested The actual time the AAD Graph API call was made
• RequestMethod The REST API method used (e.g. POST, GET, PATCH, DELETE)
• ResponseStatusCode Response from the API itself (200 - 204, 302, 303, 400, 403, 404)
• ResponseSizeBytes The total size of the Graph response
• SignInActivityId The related signin activity Id that can be used to map this to the signin logs
• TokenIssuedAt Date and time when the access token was issued by Entra ID
• ActorType Either User or Application
• ServicePrincipalId or UserId The object Id of the identity
• AppId The app id that was used to connect to Azure AD graph
• UserAgent The UserAgent the client provided
• RequestUri The actual API endpoint requested
• CallerIpAddress The IP address from where the API call was made

Detection opportunities

UserAgent

Especially the UserAgent can be used for simple detections, since attackers did not have to give too much thought about opsec for this API, they might forget to change the source code and looking for AADInternals or aiohttp might expose adversaries already.

AADGraphActivityLogs
| where UserAgent has "aiohttp"
| extend ObjectId = iff(isempty(UserId), ServicePrincipalId, UserId)
| extend ObjectType = iff(isempty(UserId), "ServicePrincipalId", "UserId")
| project-reorder TimeGenerated, TimeRequested, ObjectId, ObjectType, RequestUri, RequestMethod, ResponseStatusCode, UserAgent

RequestUri

Gathering information for a whole tenant requires a lot of requests to different endpoints, and this is your chance to find abusers. The AAD Graph API has only a few official use cases left, so the requests to this API are by far more normalised and uniform than what you see in the Microsoft Graph API. This helps immensely baselining activity. As in my last blog posts about the Graph API, I created a hunting query which you can use to find ROADtools based on the endpoints the default gather parameter requests.

let ToolGraphQueries = dynamic([
    "servicePrincipals",
    "groups",
    "roleAssignments",
    "eligibleRoleAssignments",
    "applicationRefs",
    "directoryRoles",
    "directoryObjects",
    "applications",
    "policies",
    "oauth2PermissionGrants",
    "administrativeUnits",
    "roleDefinitions",
    "authorizationPolicy",
    "devices",
    "contacts",
    "settings",
    "tenantDetails",
    "users"
    ]);
AADGraphActivityLogs
| extend ObjectId = iff(isempty(UserId), ServicePrincipalId, UserId)
| extend ObjectType = iff(isempty(UserId), "ServicePrincipalId", "UserId")
| extend Endpoint = extract(@'^/(?:v2/)?[^/]+/([A-Za-z0-9$]+)', 1, RequestUri)
| summarize
    GraphEndpointsCalled = make_set(Endpoint, 1000),
    TotalCount=count(),
    TimeGenerated=min(TimeGenerated),
    UniqueCount=dcount(Endpoint),
    CallerIpAddress=take_any(CallerIpAddress)
    by ObjectId, ObjectType
| project
    TimeGenerated,
    ObjectId,
    ObjectType,
    TotalCount,
    UniqueCount,
    CallerIpAddress,
    MatchingQueries=set_intersect(ToolGraphQueries, GraphEndpointsCalled)
| extend ConfidenceScore = round(todouble(array_length(MatchingQueries)) / todouble(array_length(ToolGraphQueries)), 1)
| where ConfidenceScore > 0.8
| where TotalCount > 1000

ResponseSizeBytes

Dumping Entra ID to disk is a resource intensive task. You need to query all the information and transfer it. And this is where the amount of bytes transferred to a user or service principal can be a big tell. In the following hunting query I use the IdentityInfo table to calculate the estimated size of your Entra ID environment. Make sure to baseline your environment, as there could be legitimate use cases for such a dump, which you might not want to alert.

let IdentitiesInEntra = toscalar(IdentityInfo
| where TimeGenerated > ago(14d)
	| summarize dcount(AccountObjectId));
AADGraphActivityLogs
| where TimeGenerated > ago(30d)
| extend ObjectId = coalesce(UserId, ServicePrincipalId)
| summarize sum(ResponseSizeBytes) by ObjectId
| extend DirectorySize = IdentitiesInEntra * 55000
| where sum_ResponseSizeBytes > DirectorySize

This will even find an attacker that takes a slow approach to data gathering. Even if they dump Entra ID within a month, the total size is larger than the directory size.

You should recalculate the directory size based on your environment, as the IdentityInfo only includes identities, but not groups and other elements. The easiest way is to use ROADtools and run it against your environment and then use the total size of this action divided by the total amount of identities in your environment.

Ping Castle

In my first blog post I also mentioned Ping Castle as one of the applications that is using the AADGraph for recon purposes. In my research with the latest version (v3.5.0.44) I discovered that Ping Castle has moved away from using the AAD Graph directly but rather is using Microsoft Graph instead. You will still find three AAD endpoints that are used as part of the recon activity, but all three, getEffectiveAccess, tenantDetails and policies are actually backend calls by Microsoft services. They use user agent kiota-dotnet/1.16.4 in Microsoft Graph.

Detour: LLM based hunting for ROADtools activity

After I wrote the detections and hunting queries above, I wanted to do something fun and test how an AI agent, without any prior knowledge of the data would handle this task.

Environment information

• Lab tenant, no real user activity
• Harness: opencode v1.14.25
• Model: GPT-5.5 on Microsoft Foundry
• Skills:
  • XDR Hunting How to query XDR advanced hunting data including information about how to request schema information about tables and a list of available tables

Hunting session

Assessment High-confidence discovery/reconnaissance activity found in AADGraphActivityLogs over the last 14 days.

Key Finding Account roadrunner@c4a8korriban.com / object ID 12e3576c-665e-4c9e-96df-a2f34ca7eaf0 performed large-scale Azure AD Graph enumeration from 95.217.58.XXX.

Evidence:

Observed Enumeration The requests covered directory-wide discovery targets:

Sample paths included:

• /servicePrincipals/{id}/appRoleAssignedTo
• /servicePrincipals/{id}/appRoleAssignments
• /groups/{id}/$links/members
• /groups/{id}/$links/owners
• /directoryRoles/{id}/$links/members
• /oauth2PermissionGrants
• /applications
• /devices
• /users
• /tenantDetails

This pattern is consistent with automated tenant mapping: service principals, group membership, role membership, application references, OAuth grants, and app role assignments.

Sign-In Context Related sign-ins were found from the same IP:

Timing Activity occurred in three short automated bursts:

Other Activity Other actors showed much lower discovery-like volume and looked closer to routine service principal access. None approached the breadth, automation indicators, or success volume of roadrunner@c4a8korriban.com.

Recommended Actions

1. Treat roadrunner@c4a8korriban.com as potentially compromised until validated.
2. Revoke sessions and refresh tokens for the account.
3. Reset credentials and verify MFA methods.
4. Review whether access from 95.217.58.XXX / Hetzner is expected.
5. Review Azure CLI and Azure AD PowerShell consent/token usage for this account.
6. Hunt downstream for use of discovered objects, especially role assignments, app credentials, service principal changes, and OAuth grant changes after 2026-05-04 21:32Z.

Which apps use AAD Graph

According to the data in my lab tenant there are 31 apps that use the Azure AD Graph API. I mapped the AppIds to the respective app names, as not all are easily resolvable.

Other notes

As Invictus IR pointed out in their own post about the logs, the SignInActivityId is different between the actual sign-in logs and the activity logs. But not only the mentioned padding (==) is different. For around 55% of my logs this GUID style if present and not available in any other log source I have connected to my Sentinel.

AADGraphActivityLogs
| where TimeGenerated > ago(90d)
| summarize by SignInActivityId
| summarize
    Padded=countif(SignInActivityId endswith "=="),
    GUID=countif(SignInActivityId matches regex @"^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$"),
    TotalUnique=dcount(SignInActivityId)

Conclusion

First of all a big thank you to the responsible people at Microsoft who made this possible, the additional insights into this crucial but deprecated API will help many companies to detect attacks early and maybe stop the attackers in their tracks. As with the other Graph Activity Logs the required information for threat hunting is available and with the link to other logs like Sign-in logs this helps to identify the initial access and allows for informed follow up hunting.

As to my AI experiment. It’s great to see how fast and good the response to this prompt was. The reasoning came to the same conclusion as I came about the attacker and enriched the hunt with additional data from whois and AADSignInEventsBeta. While it missed the volume based approach, it was enough to pinpoint all my ROADtool runs without problems. Using these capabilities as an additional tool in your tool-belt, while still using you own brain to challenge the findings will make your research faster. And with cost at under 1 USD it’s definitely not very expensive. But of course since this environment is not noisy at all, the conditions were primed for the LLM to succeed. There were no noisy custom apps or users doing what users do best, deviate from the norm.

To all of you reading this blog: Have fun hunting through this dataset, try to establish baselines, discover unused endpoints that are not triggered by normal behaviour anymore and build alerts that are actionable for your Analysts. Happy hunting.

Further reading

1. Migrate Azure AD Graph apps to Microsoft Graph
2. Important Update: Azure AD Graph Retirement
3. AADGraphActivityLogs schema documentation
4. ROADtools
5. AADInternals
6. Compliant Device Bypass using Intune Company Portal
7. Azure AD Graph default permissions (EntraScopes)
8. Entra ID Diagnostic Settings
9. Azure Monitor log reference: AADGraphActivityLogs
10. Invictus IR: The Missing Link: AADGraphActivityLogs Finally Arrives