Entra offensive tool user agent
A cloud sign-in whose client string names a known directory-enumeration tool — AzureHound, ROADrecon, AADInternals and the like.
What it detects
A cloud sign-in whose client string names a known directory-enumeration tool — AzureHound, ROADrecon, AADInternals and the like.
Directory enumeration is otherwise close to invisible: reading Entra ID is not an auditable event, so a tenant can be mapped end to end with almost nothing written to the audit log. What IS written is the sign-in the tool used to get its token, and these tools ship a default user agent that names them outright (azurehound/v2.0.4). That is the whole detection — not clever, but it is the one reliable artefact the technique leaves.
Confidence is high because nothing legitimate sends these strings; the weakness is the opposite one, that it is trivially evaded by an operator who sets a custom agent. Treat a hit as strong, and its ABSENCE as meaning nothing at all.
MITRE ATT&CK mapping
False positives and triage
An authorised red team or a purple-team exercise produces exactly this and is the only realistic benign source — confirm against the engagement window and the tester's source addresses before escalating. A security team running AzureHound for its own posture review will also trip it; that is worth knowing, not suppressing, so prefer allowlisting the specific reviewing account over removing the rule. Note the account that signed in matters as much as the tool: an enumeration run under a service account nobody uses interactively is a stronger signal than one under a known admin.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/cloud/entra_offensive_tool_user_agent.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_offensive_tool_user_agent
version: 1.0.0
status: stable
severity: high
confidence: 0.8
platforms: [application]
mitre_techniques: [T1482, T1087.004, T1069.003]
description: |
A cloud sign-in whose client string names a known directory-enumeration tool —
AzureHound, ROADrecon, AADInternals and the like.
Directory enumeration is otherwise close to invisible: reading Entra ID is not an
auditable event, so a tenant can be mapped end to end with almost nothing written
to the audit log. What IS written is the sign-in the tool used to get its token,
and these tools ship a default user agent that names them outright
(`azurehound/v2.0.4`). That is the whole detection — not clever, but it is the one
reliable artefact the technique leaves.
Confidence is high because nothing legitimate sends these strings; the weakness is
the opposite one, that it is trivially evaded by an operator who sets a custom
agent. Treat a hit as strong, and its ABSENCE as meaning nothing at all.
match:
event_category: authentication
user_agent_contains_any:
- "azurehound"
- "roadrecon"
- "roadlib"
- "aadinternals"
- "graphrunner"
- "o365spray"
- "msolspray"
- "teamfiltration"
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
An authorised red team or a purple-team exercise produces exactly this and is the
only realistic benign source — confirm against the engagement window and the
tester's source addresses before escalating. A security team running AzureHound
for its own posture review will also trip it; that is worth knowing, not
suppressing, so prefer allowlisting the specific reviewing account over removing
the rule. Note the account that signed in matters as much as the tool: an
enumeration run under a service account nobody uses interactively is a stronger
signal than one under a known admin.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.