AzureHound Attacks: How to Detect Cloud Reconnaissance
Updated April 2026
What AzureHound Is and Why Threat Actors Use It
AzureHound is the cloud-focused data collector within the BloodHound suite. It queries Microsoft Graph and Azure REST APIs, feeds the results into BloodHound's graph engine, and produces a visual map of every privilege escalation path in your Azure environment. SharpHound does the same for on-premises Active Directory. AzureHound does it for Entra ID and Azure.
Security teams use it for authorised red team exercises and attack path analysis. Threat actors use it to do the same thing, against your environment, once they have obtained a foothold and a valid token.
That distinction matters. AzureHound does not exploit a vulnerability. It authenticates as a user and calls the same APIs your legitimate tooling calls. The difference is intent and speed: an attacker with a valid credential can enumerate your entire Azure estate, users, service principals, role assignments, storage accounts, key vaults, in minutes. What looks like a flat set of permissions in the Azure portal becomes a prioritised attack plan once it is rendered as a BloodHound graph.
Cloud environments have become the primary target surface. For a broader view of how this shift fits into current threat tradecraft, see the 2026 security threat shifts article.
How Storm-0501 and Void Blizzard Are Using It Right Now
Threat actors have moved their primary focus from endpoints to cloud identities, and AzureHound is embedded in that tradecraft across both ransomware operations and nation-state campaigns.
Storm-0501 has shifted from deploying on-premises ransomware payloads to cloud-native attack chains (Microsoft). The group used AzureHound to map relationships and permissions in Azure environments, identifying privilege escalation paths before moving laterally across tenants.
In May 2025, Microsoft reported that Void Blizzard, assessed with high confidence as Russia-affiliated was using AzureHound. during the discovery phase of attacks targeting organisations across telecoms, government, and defence in NATO member states and Ukraine (Microsoft). The goal was enumerating Entra ID configurations to find paths worth pursuing before committing to the next stage.
This is not an emerging tactic. It is established tradecraft, and it is spreading. When nation-state actors and ransomware groups are independently converging on the same discovery tool, the underlying technique has proven itself against hardened targets.
The Logging Gap That Makes Cloud Reconnaissance So Hard to Detect
Many AzureHound requests call the Azure REST API at the management.azure.com ARM endpoint, which is logged differently from Graph API calls. Standard Azure activity logs often capture neither (Unit 42).
Microsoft Graph activity logs address this gap. They reached general availability in April 2024. Most organisations still have not enabled them.
In my experience working with enterprise security teams, gaps in logging are rarely deliberate decisions. They are defaults that nobody revisited after the initial Azure deployment. The assumption is that something is being captured. For Graph API activity, make a point of checking logging is correctly set.
Without Graph activity logging enabled, an attacker running AzureHound can silently:
- Map your entire user hierarchy and administrative structure
- Identify all Global Administrator accounts
- Enumerate storage accounts, key vaults, and service principals
- Discover misconfigured permissions and app registrations across the tenant
None of it triggers a standard alert. That is the gap that makes cloud reconnaissance a low-risk, high-return opening move and the reason enabling these logs and monitoring them is vital.
How to Download AzureHound
Security teams should run AzureHound against their own environment before threat actors do. The BloodHound graph output earns its place: it surfaces privilege escalation routes that are invisible in flat permission exports from the Azure portal.
Download the pre-compiled binary for your OS from the official BloodHound/AzureHound GitHub repository releases page. No installation is required, it is a standalone executable available for Windows, Linux, and macOS (Unit 42).
Test command using a JWT from an existing session:
.\azurehound.exe list -t TENANTID -j $JWT -o tenant.json
The output file ingests directly into BloodHound for graph visualisation. Run it against a non-production tenant first to understand the data model before analysing your live environment.
How Threat Actors Use Stolen Credentials to Run AzureHound
AzureHound runs as whatever identity it authenticates with. That is the design – it mirrors what legitimate tooling does. For threat actors, the objective is obtaining a credential type that provides the maximum reconnaissance window.
| Authentication Method | Source of Stolen Access | Security Status |
|---|---|---|
| Username/Password | Direct credential theft | Often blocked by MFA (unless MFA is weak or not enforced) |
| Refresh Token | Stolen via AiTM phishing or infostealer malware | Bypasses MFA; used to generate new Access Tokens for extended access |
| JSON Web Token (JWT) | Stolen from a live session (Access Token) | Grants immediate but shorter-term API access |
| Service Principal Secret | Stolen from a misconfigured Azure resource or Key Vault | Grants the principal's permissions, typically without MFA |
Refresh tokens and service principal secrets are the priority targets. A refresh token lets an attacker mint new access tokens continuously. AzureHound can run repeatedly without re-authentication. A misconfigured service principal often carries broader permissions than any human account in the tenant.
The reconnaissance phase always follows initial access.
Does MFA Stop AzureHound?
MFA alone does not stop AzureHound if a refresh token has already been stolen. A refresh token is issued after a successful MFA event. It is proof that authentication already succeeded. An attacker who steals that token can use it to generate new access tokens without repeating the MFA challenge.
This is why AiTM phishing and infostealer malware that harvest session tokens are prioritised by threat actors. The goal is to get past MFA.
Enforcing phishing-resistant MFA methods (FIDO2, hardware tokens) and enabling token protection in Entra ID significantly narrows this attack path. It does not close it entirely for tokens stolen before those controls were in place.
Why External Access Makes This Harder to Block
Microsoft Graph and Azure REST APIs are publicly accessible by design. AzureHound does not require network positioning inside your environment. A valid token from any external IP is sufficient to query your entire tenant.
Trying to block AzureHound at the tool level is a dead end. It uses the same Microsoft Graph and Azure REST APIs that your legitimate monitoring and management tooling calls every day. You cannot distinguish a malicious enumeration request from a valid one at the API layer.
The credential is the control surface. Conditional access policies block stolen tokens at the point of use. Token protection in Entra ID goes further, binding the token to the device it was issued on and making it unusable from anywhere else.
How to Detect AzureHound Activity in Your Azure Environment
Enable Microsoft Graph Activity Logs First
Configure Microsoft Entra ID to export Microsoft Graph activity logs to Azure Event Hubs, a Log Analytics workspace, or your SIEM (Unit 42). This is the prerequisite for everything that follows. Without it, the signals below have no data source.
Hunt for AzureHound Indicators in Your Logs
Once logs are flowing, look for:
- User-agent strings containing
azurehound - Rapid sequential calls across multiple Graph API endpoints from a single identity
- Bulk queries for users, groups, role assignments, and storage accounts in short succession
- Unusual spikes in Graph API activity, particularly outside business hours or from unexpected source IPs
Monitor specifically for the AzureHound collection commands list users, list groups, list role-assignments, and list storage-accounts (GBHackers). Executed in rapid succession from a single identity, these are a strong cloud reconnaissance signal.
For SIEM platform options, the SIEM comparison guide covers the main choices. If you are running the ELK stack, the ELK security monitoring guide covers log ingestion and detection rule setup.
Strengthen Identity Controls to Reduce the Credential Attack Surface
Conditional access policies reduce what a stolen token can reach. Priority configurations:
- MFA enforced for all administrative accounts, using phishing-resistant methods where possible
- Just-in-time access through Privileged Identity Management to remove standing privilege
- Restricted app registration permissions to prevent rogue OAuth application deployment
- Token protection to reduce the viability of stolen session tokens for repeated API calls
The Microsoft Intune security guide covers device compliance and conditional access policy configuration in detail.
The goal is raising the cost of each step in the credential chain. A stolen refresh token should not translate into unlimited, undetected reconnaissance time.
What the Full Attack Chain Looks Like
AzureHound does not appear at the start of an attack. By the time it runs, the attacker has already obtained initial access, confirmed an authentication method viable for API calls, and more often than not confirmed that Graph activity logging is absent or not alerting.
The sequence:
- Initial access obtained via credential theft, AiTM phishing, or a compromised service account
- Token or secret confirmed as viable for Microsoft Graph and Azure REST API calls
- AzureHound collection run launched from an external IP
- Resulting output fed into BloodHound for attack path analysis
- Shortest path to objective identified -- typically Global Administrator, a privileged service principal, or a targeted data store
Step 3 is where most organisations have a gap. Steps 1 and 2 happened upstream, potentially days earlier. The credential theft is the detection opportunity that prevents Step 3 from being invisible.
That shift in framing matters for how you prioritise controls. Preventing AzureHound specifically is less important than detecting stolen credential use upstream, and ensuring that if a token is compromised, Graph activity logging captures what it is used for.
Closing
The organisations that manage this risk effectively know what their own environment looks like from a BloodHound graph, have Graph activity logs flowing into their SIEM, and treat stolen session tokens as a detection priority.
Enable the logging. Run AzureHound against your own tenant in a controlled test. Know what an attacker would find before they do.
For the security controls that underpin cloud identity defence more broadly, the cloud security fundamentals guide covers IAM, network segmentation, and data protection across AWS and Azure environments.
Key Resources:
- Microsoft Graph Activity Logs Documentation
- BloodHound/AzureHound GitHub Repository
- Unit 42 Threat Research on AzureHound
- See how a stolen cookie bypasses passwords and 2FA
Member discussion