How do you detect AzureHound discovery activity in Microsoft Entra ID?

What AzureHound is doing when it looks around your tenant

AzureHound is an attack path mapping tool, so its discovery phase is usually about collecting the graph needed to understand who can reach what. In microsoft entra id, that means enumerating directory objects, relationships, roles, applications, and devices at a scale and pace that normal admin work rarely matches.

The key detection challenge is not a single query, but the pattern: repeated reads across many object types, short bursts of broad enumeration, and access that appears “legitimate” at the API level but abnormal for the account, time, or device. That is why baselining normal admin behavior matters as much as alerting on volume.

Discovery also becomes more suspicious when it lines up with privilege changes or token activity. An account that suddenly receives new permissions, begins non-interactive access, or starts querying Entra objects it has never touched before is closer to reconnaissance than routine administration.

Which Entra ID signals matter most

Focus first on the reads that reveal tenant structure. High-volume requests for users, groups, roles, applications, service principals, devices, directory role assignments, and app permissions are the core objects AzureHound needs to build a relationship graph. That is why bulk directory reads from a low-trust or rarely used account are more meaningful than a single suspicious sign-in.

Look for repeated Microsoft Graph or Entra API calls that sweep across multiple endpoints in a way that is hard to explain as user support, provisioning, or reporting. Broad discovery usually leaves a trail of near-duplicate queries, pagination through large object sets, and access to fields or object classes that are unnecessary for ordinary work.

Also watch for access context. Discovery from non-interactive sign-ins, new service principals, unusual user agents, unfamiliar locations, or accounts outside the admin team is more concerning than the same query pattern from a known tenant operator. The question is whether the access pattern fits the account’s role and history, not just whether the query succeeded.

How to separate discovery from normal administration

Start by defining what “expected” looks like for your tenant. In practice, a helpdesk operator, compliance reviewer, cloud engineer, and identity administrator all generate different API patterns. A useful baseline is one that compares object mix, query frequency, time of day, and source identity, not just raw request counts.

Correlate discovery with privilege signals. If enumeration follows a role assignment, consent grant, app registration change, or token issuance, treat that as an escalation in severity because the activity may have moved from curiosity to usable access. The same is true when discovery is paired with new access from a device, IP range, or authentication method that is not typical for that identity.

For broader identity hardening, use the Active Directory and Entra ID Hardening Guide to tie detection back to privileged group hygiene, delegation, and exposure reduction. The better your privilege model is constrained, the easier it becomes to spot discovery that should never have been possible in the first place.

Risk and Threat Considerations

Discovery is often the first observable stage of tenant abuse because it reveals where privilege, applications, and trust relationships live. Once an attacker can map Entra ID, they can choose the fastest path to privilege escalation, app abuse, or persistence, and they can do it with much less noise than a direct exploit.

Failure mechanism: Broad read access, excessive permissions, or stolen credentials let an adversary enumerate identities and relationships at scale, then pivot toward the highest-value paths without needing a second foothold.

Impact: Successful reconnaissance can expose privileged roles, sensitive applications, ownership gaps, and high-value targets, which increases the chance of account takeover, consent abuse, and follow-on lateral movement.

Practitioner Guidance

What to prioritise: Tune detections around discovery bursts from accounts that do not need tenant-wide visibility, then enrich those alerts with role changes, consent events, and non-interactive sign-ins. That combination is far more useful than alerting on Graph activity alone.

What to verify: Confirm whether the account actually needs the breadth of objects it is reading. If the same identity is suddenly touching users, groups, roles, apps, and devices, check whether the access was approved, scripted, or delegated, and whether the source device and sign-in method are expected.

Practitioner takeaway: The best AzureHound detections are graph-aware, not volume-only, because the real signal is unauthorized breadth of visibility plus a context shift that shows the tenant is being mapped for follow-on abuse.

Related resources from NHI Mgmt Group

• What should you monitor to detect suspicious device activity in Microsoft Entra ID?
• How do you access and review activity logs in Microsoft Entra ID?
• How do you detect applications using the ROPC authentication flow in Microsoft Entra ID?
• How do you detect Conditional Access policy changes by unapproved actors in Microsoft Entra ID?