Executive Summary

AzureHound is a data collection tool intended for penetration testing that is part of the BloodHound suite. Threat actors misuse this tool to enumerate Azure resources and map potential attack paths, enabling further malicious operations. Here, we help defenders understand the tool and protect against illegitimate use of it.

This look into AzureHound will discuss its capabilities and common usage, and map its tool usage to the MITRE ATT&CK framework. Focusing on relevant ATT&CK techniques, we provide examples of tool execution and highlight how the activity appears in Azure log sources as well as in Cortex XDR.

Tools like AzureHound allow threat actors to operate quickly and efficiently in cloud environments. Threat actors operating these tools often leave detectable evidence for defenders who know where to look. This article provides actionable intelligence for tuning detections, improving incident response processes, conducting threat hunting and managing a security function.

Palo Alto Networks customers are better protected from the threats described here through the following products and services:

• Cortex Cloud
• Cortex XSIAM
• Prisma Browser

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics	Azure, Control Plane, Data Plane, Security Logging

AzureHound Tool Background

AzureHound is an open-source data collection tool written in the Go programming language. It is available precompiled for Windows, Linux and macOS.

This tool collects data using the Microsoft Graph and Azure REST Application Programming Interfaces (APIs). It is designed to enumerate an Entra ID and Azure environment and gather information about identities and various other resources. The goal of this enumeration is to use the collected data to identify potential attack paths to privilege escalation within the target Azure environment.

AzureHound can send its output to JSON files, which BloodHound can then ingest. BloodHound is a visualization tool designed to graphically reveal hidden relationships and identify attack paths within an Entra ID, Azure or Active Directory (AD) environment.

The Microsoft Graph API provides developers with programmatic access to organizational data and identities within Microsoft 365 and Microsoft Entra ID.

Operating at the infrastructure layer, the Azure REST API provides access to Azure Resource Manager (ARM), the control plane for all Azure resources like storage, virtual machines and networks.

AzureHound does not need to be run from within the victim environment. This is because both the Microsoft Graph and Azure REST APIs are available externally.

Threat Actor Usage of AzureHound

AzureHound is intended to be used by security professionals — like defenders and red teams — to proactively find and fix cloud vulnerabilities. However, threat actors can also use it for discovery, after gaining access to a victim's Azure environment.

Threat actors use AzureHound to automate complex discovery procedures in Azure environments. This helps them discover user hierarchies and identify high-value targets.

Collecting internal Azure information helps threat actors uncover misconfigurations and indirect privilege escalation opportunities that might not be obvious without this full view of the target Azure environment.

Threat actors also run the tool after obtaining initial access to the victim environment, downloading and running AzureHound on assets to which they have gained access.

As recently as August 2025, threat actor activity with this tool highlights a continued focus on cloud environments as a critical attack surface. Publicly available research identifies AzureHound as part of several post-compromise operations:

• Unit 42 tracks the Iranian-backed group Curious Serpens (aka Peach Sandstorm), which has been active since at least 2013. The group has evolved to misuse Azure cloud environments in its attack chain, including using AzureHound to conduct internal discovery of the target's Microsoft Entra ID environment.
• In May 2025, Microsoft reported on a suspected nation-state threat actor it named Void Blizzard leveraging AzureHound during the discovery phase of their attacks to enumerate Entra ID configurations.
• In August 2025, Microsoft reported a campaign by a ransomware operator they identified as Storm-0501. Operating on-premises in a hybrid, multi-tenant Azure environment, the threat actor used AzureHound to enumerate the target's Entra ID tenants.

MITRE Tactic Discovery

The MITRE ATT&CK framework is a security practitioner and community-driven knowledge base of threat actor behaviors that describes the tactics, techniques and procedures (TTPs) of cyberattacks. The framework provides a common vocabulary for sharing intelligence and research. It aids in the structured analysis of cyberattacks and tracking of trends in threat actors’ activity.

Discovery within the MITRE ATT&CK framework refers to techniques that threat actors use to learn about their target environment after gaining initial access. MITRE ATT&CK recognizes that cloud techniques and procedures differ from their endpoint counterparts and identifies this cloud-focused subset of the Enterprise Matrix as the Cloud Matrix. We will focus on discovery techniques from the Cloud Matrix.

In Azure, discovery involves gathering details on the following:

• Users
• Groups
• Service principals
• Roles
• Devices
• Storage accounts
• Applications
• Permissions

Threat actors seek to understand the resources and relationships within the Azure environment to facilitate their attack.

AzureHound accelerates this process by giving threat actors an efficient means to collect data, which they then use to map potential attack paths against the target Azure environment. These attack paths include:

• Privilege escalation opportunities
• Lateral movement paths
• Relationships of high-value accounts such as Global Administrators or other privileged roles

MITRE Discovery Techniques

From the perspective of a threat actor using AzureHound, each discovery technique represents a step in building a comprehensive understanding of a target's cloud environment.

To understand a command-line tool like AzureHound, users typically reference online documentation as well as output from the tool's -h, --help or other usage parameter. Compared to the online documentation, a full listing via the list -h parameter in the 2.6.0 version of AzureHound reveals additional discovery options that are useful in the context of analyzing potential malicious usage. This includes some commands of particular interest to a threat actor such as:

• function-apps
• function-app-role-assignments
• storage-accounts
• storage-containers
• subscription-user-access-admins
• web-apps

The commands above give threat actors baseline information about services commonly exploited in cloud environments. The commands detailed in this analysis are based on the direct output from the tool.

T1087.004: Account Discovery: Cloud

To establish a foundational understanding of the target environment, a threat actor might first locate the identities operating within it. This initial enumeration provides a roster of potential targets for credential theft or impersonation. The tool automates the collection of all identities, including users, devices and service principals, along with their ownership relationships. This provides a detailed picture of the identities present in the tenant.

AzureHound parameters that facilitate the MITRE technique Account Discovery: Cloud Account include the following:

• list users
• list devices
• list device-owners
• list service-principals
• list service-principal-owners

AzureHound supports multiple means of authentication, including:

• Username and password
• Refresh tokens
• JSON web tokens (JWT)
• Service principal secrets
• Service principal certificates

Microsoft's Entra ID documentation provides a full discussion of Azure token types. For our example, we will use an Azure refresh token we generated using device code flow by following the guidance in the AzureHound CE reference docs.

Threat actors will use whatever means of authentication is available. They can combine a stolen username and password with multi-factor authentication (MFA) fatigue to affect a successful login. Alternatively, they may login with a stolen token. Infostealers such as Raccoon Stealer or Redline can extract cookies, credentials and session tokens from a user's browser. Researchers from Flare found that session tokens acquired from infostealers have exposed tokens from Azure.

As displayed by the list users request within Figure 1, the output of AzureHound command-line discovery can reveal information of interest to a threat actor. This example invocation of the command lists all Entra ID users and sends the output to a file called users.json.

The following data is among the fields returned by default for each user if available in the Entra ID User record:

• displayName
• jobTitle
• lastPasswordChangeDateTime
• mail
• userPrincipalName
• userType
• tenantId
• tenantName

Figure 2 shows a screen capture of the raw output from AzureHound with some of the fields listed above.

This data helps threat actors target key users in the target organization for successive stages in the attack. For example, a threat actor could dump all users to a JSON file and search it for job titles that indicate high-value targets including those containing words like:

• Administrator
• Application
• Identity
• Cloud

These targets are considered high value because these job roles would have elevated privileges within the Azure tenant.

T1069.003: Permission Groups Discovery: Cloud Groups

Once threat actors know the identities within the target environment, they need to understand the relationships between the identities by discovering permission structures.

This technique focuses on mapping out administrative roles and group memberships to find exploitable privilege escalation paths. This is achieved by collecting not just the groups and roles themselves, but the web of specific role assignments that connect identities to resources, revealing who has access to what.

For Permissions Groups Discovery: Cloud Accounts, AzureHound has the following capabilities:

• list groups
• list roles
• list group-members
• list group-owners
• list role-assignments
• list app-role-assignments
• list key-vault-access-policies
• list management-group-role-assignments
• list resource-group-role-assignments
• list subscription-role-assignments
• list virtual-machine-role-assignments

What data the options above return depends on the identity AzureHound uses to authenticate. AzureHound gathers information based on the permissions granted to the account under which it runs within Azure. These accounts can only enumerate policy definitions and assignments if they have roles like Reader or higher at the subscription or resource group level.

Figure 3 shows the result of a command to enumerate Groups within a tenant.

Threat actors enumerate Entra ID groups, roles and role assignments because they collectively define how access and permissions are distributed across users, applications and resources. Threat actors can identify highly privileged roles, such as Global Administrator or Privileged Role Administrator and determine which users or service principals are assigned to them. This information can also reveal privileged escalation paths through nested group memberships.

Role assignments can reveal excessive or misconfigured permissions. This information helps threat actors discover opportunities for privilege escalation, lateral movement and additional data collection.

AzureHound integrates with BloodHound to create graphs that visually map potential privilege escalation and architectural blueprint. It does so using a massive amount of raw data such as lists of users, groups, apps, subscriptions and their permissions.

Manually connecting these dots is slow and prone to error. As such, the BloodHound GUI becomes a useful analytical tool for threat actors.

By importing the collected data, the tool transforms lines of text into a living map of important relationships. This information about highly privileged users gives the threat actor a list of users to target for credential theft. Figure 4 shows users who have the Global Administrator role either directly assigned, or inherited through group membership.

For confidentiality, we have hidden or obscured labels for users and groups as well as tenant information.

T1619: Cloud Storage Object Discovery

A primary objective for many threat actors is data exfiltration, making it critical to identify where data is stored. This technique involves discovering cloud storage resources. A threat actor can use AzureHound to specifically target and enumerate Azure storage accounts and the blob containers within them, revealing the locations of potentially sensitive data.

AzureHound has two options for storage object discovery, covering both Azure storage accounts and containers:

• list storage-accounts
• list storage-containers

Figure 5 shows an example of storage account discovery via AzureHound, enumerating all storage accounts that the identity passed into the command has access to.

The output from the list storage-account command can reveal important information about the storage account configuration. The output comprises the entire storage account resource definition including:

• Name
• Location
• Key vault properties
• Replication type
• DNS endpoints
• Network access control lists (ACLs)

Microsoft's reference page shows examples of full storage account configurations.

Within this data, the name of the storage account is very important and tied to its service endpoints, which are publicly resolvable DNS names used to connect to the storage account. For example, a storage account blob container by default uses the storage account, container and blob names to define the service endpoint as follows:

hxxps[:]//mystorageaccount.blob.core.windows[.]net/mycontainername/myblobname

Storage accounts can also be tied to custom domain names, which would be in the output's customDomain key-value pair. Please refer to Microsoft's storage account overview for more information on custom domains and other details.

Threat actors seek to access the data in storage accounts for data exfiltration. However, these service endpoints can be secured by network ACLs on the storage account firewall. This information provides the threat actor an understanding of network allowlists and denylists comprising the firewall configuration.

Figure 6 shows that the storage account service has a default deny policy, allowing access only from two /24 network ranges and trusted Azure services like Azure Monitor, Backup and File Sync.

Trusted services in Azure refers to a predefined list of Microsoft-owned services that are, by default, granted permissions and access to other Azure resources, bypassing standard network ACLs. Microsoft manages the list and it’s specific to the resource type (e.g., storage blobs, key vaults).

T1526: Cloud Service Discovery

Beyond storage and identities, an actor will seek to understand what platform services are in use, as these can present unique paths for attack. By enumerating services like Web Apps, Function Apps and Kubernetes clusters (AKS), a threat actor can identify application platforms that may be misconfigured or vulnerable. This provides the threat actor with a menu of potential high-level service targets.

For Cloud Service Discovery, AzureHound has the following capabilities:

• list apps
• list web-apps
• list function-apps
• list logic-apps
• list automation-accounts
• list managed-clusters
• list vm-scale-sets
• list container-registries

With a list of applications, the threat actor’s search expands to the underlying resources. This allows them to map out automation pipelines, Kubernetes clusters and container registries for the cloud's crown jewels. A single misconfigured automation account could allow for the execution of the attacker's own code with high privileges.

This search also involves testing for publicly exposed container registries, pulling images for offline analysis to hunt for hard-coded credentials, API keys or vulnerable libraries. It could also uncover abandoned resources, providing new and powerful attack strategies.

For example, once a threat actor discovers a forgotten test automation pipeline, they can exploit its powerful identity and rights over a resource group. The attacker could then use this trusted identity to inject malicious code into the automation's runbook, waiting for a cloud pipeline to trigger, then executing their malicious code with those elevated permissions.

For a deeper look into cloud pipeline threats, see the Unit 42 analysis on the Anatomy of a Cloud Supply Pipeline Attack.

T1580: Cloud Infrastructure Discovery

To fully grasp the architecture of the target environment, a threat actor must discover the foundational infrastructure components. This technique involves enumerating core resources and the management constructs that contain them.

A threat actor can build a complete architectural map of the cloud deployment by listing the following:

• Virtual machines
• Key vaults
• The hierarchy of tenants, subscriptions and resource groups

For Cloud Infrastructure Discovery, AzureHound has the following capabilities:

• list tenants
• list subscriptions
• list resource-groups
• list management-groups
• list virtual-machines
• list key-vaults

Similar to the BloodHound user mapping previously shown, this use case shows how attackers visually examine infrastructure elements with BloodHound. Figure 7 displays these key vault findings. We have hidden or obscured labels and tenant information for confidentiality.

Instead of scrolling through output, the threat actor now has a complete, bird's eye view of key vaults in the tenant infrastructure. They can visually navigate the hierarchy from the tenant down to individual resources.

For example, in addition to key vaults, attackers can click on a node representing the Production subscription. They could then select virtual machines from the Descendent Objects list and instantly see all the virtual machines connected to it.

Defender Perspective

AzureHound relies on Microsoft Graph and Azure REST APIs to enumerate users, roles and permissions. This means that effective defense requires a layered approach that combines access control, endpoint security and visibility into the API activity. The goal is to make it significantly harder for threat actors to authenticate, execute and operate undetected in an organization's environment.

Mitigations

From a defender perspective, secure configurations are essential. As noted above in our discussion of MITRE discovery techniques, AzureHound can be used to obtain information about Azure users and resources within a specific tenant via publicly documented APIs. These API requests may also uncover security vulnerabilities within a tenant. By design, this information is accessible on a per-tenant basis to users with an Entra ID account with Read privileges in that tenant.

To bolster the security of your Azure account, we recommend customers follow Microsoft best practices. In addition, to help prevent the unauthorized access necessary for this technique to be successful, we recommend Admins implement additional security measures.

In addition to Microsoft's recommended best practices and additional security steps, the following mitigations can help further secure your organization. Some of these intersect with the best practices, and some are complementary controls or policy considerations that can be implemented to further harden your environment.

The first line of defense is strong identity and access control, which controls what a user, group or service principal can do. Organizations should implement phishing-resistant MFA for all accounts, especially those with access to sensitive data or administrative roles. Users performing highly privileged tasks, such as Global Administrators or Privileged Role Administrators, should maintain separate accounts for those duties.

Privileged Identity Management (PIM) solutions, such as Microsoft Entra ID PIM or broader Privileged Access Management (PAM) platforms, enable organizations to manage, control and monitor access to privileged identities. These solutions help prevent a compromise of standard user credentials from granting a threat actor elevated access.

In addition to identity and access control, Conditional Access Policies (CAPs) help mitigate exposure to AzureHound by restricting user and application access. CAPs are part of Entra ID and are enforced during authentication. They work by enforcing CAP-defined requirements including MFA, device compliance, trusted locations and client application restrictions. Because of this, CAPs can block AzureHound from accessing Microsoft Graph and Azure management APIs, even if an attacker has obtained valid credentials.

Another effective measure is token binding, which ensures that authentication tokens are tied to a specific device. This feature is known as Token Protection in Entra ID and moved to general availability in August 2025.

As discussed above, Void Blizzard has used stolen authentication tokens. These tokens can be used to authenticate to the target environment, including by AzureHound to the Microsoft Graph API. Token binding can help mitigate token theft attacks by making the stolen token invalid from a different device.

Additionally, secure browsers can provide similar protection by shielding access to private or privileged applications and ensuring that tokens issued are valid only from the secure browser. This renders the tokens invalid from the command line, for tools such as AzureHound.

In addition to identity controls, visibility at the endpoint level remains essential in detecting and preventing AzureHound and other threats. Ensure that endpoint detection and response (EDR/XDR) tooling is deployed across all assets, including to cloud workloads such as cloud detection and response (CDR).

The 2025 Unit 42 Global Incident Response Report discusses how threat actors target unmanaged assets. These assets are those defined as not having endpoint detection and response tools (EDR/XDR/CDR), with a reduced chance of threats being discovered.

It is also vital that organizations use a combination of cloud security posture management (CSPM) and CDR tools to detect attackers creating new compute instances (i.e., virtual machines, containers or serverless functions). This also helps ensure that cloud endpoint agents are properly installed and configured to maintain monitoring capabilities over newly created compute instances. Closing visibility gaps drastically reduces the threat actor's ability to evade detection.

AzureHound reveals which identities can register applications within the Azure tenant, so controlling app registrations is another effective mitigation against AzureHound. Threat actors often take advantage of default settings that allow users to register applications and grant themselves elevated permissions. This in turn can enable broad directory visibility without interactive logins or MFA.

Disabling user-initiated app registrations and requiring an admin consent workflow reduces the chances of a threat actor creating malicious service principals or bypassing MFA through tokenized app-based authentication.

Logging Considerations

Microsoft Graph activity logs have been available in preview since October 2023 and reached general availability in April 2024. This important capability allows defenders to monitor HTTP requests to the Graph service and detect suspicious enumeration patterns.

By default, Microsoft Graph activity logs are not enabled. Defenders should configure Microsoft Entra ID to export Microsoft Graph activity logs to destinations such as Azure Event Hubs. This allows integration with security information and event management (SIEM) solutions as well as EDR, XDR and CDR tools. These logs capture granular details of the API calls that have passed through the Graph API, including the endpoints targeted by tools like AzureHound.

Some AzureHound requests call the Azure REST API at the management.azure[.]com ARM endpoint. These requests to the ARM provider are logged differently than Graph API calls and present visibility challenges.

Activity logs collect subscription-level events from the ARM provider such as creating a new resource or deleting a storage account, which are events not associated with AzureHound requests. The read and list operations (REST GET calls) AzureHound invokes are not recorded in activity logs.

While diagnostic settings can be explicitly enabled for various resource types to capture resource provider level logging, this will only log service endpoint read operations at the data plane level (e.g., mystorage.blob.core.windows[.]net, or myvault.vault.azure[.]net). This does not occur at the control plane level where requests to the ARM provider take place. As a result, AzureHound enumeration calls to the Azure REST API, such as listing storage accounts (azurehound list storage-accounts) or key vaults (azurehound list key-vaults), will not appear in activity or resource logs.

The AzureHound GitHub repository provides additional context and information on which API an AzureHound command uses, and consequently which log to look in for the events.

For example, details on the azurehound list storage-accounts command discussed above can be found in the AzureHound API client code for storage accounts. Figure 8 illustrates AzureHound client code using the Azure REST API for storage account enumeration.

Figure 9 illustrates the AzureHound client code for role enumeration list roles command using the Graph API.

AzureHound list commands that go through the Azure REST API ARM endpoint and thus may not be visible in logs include the following:

• automation-accounts
• container-registries
• function-apps
• key-vaults
• logic-apps
• managed-clusters
• management-groups
• resource-groups
• storage-accounts
• storage-containers
• virtual-machines
• vm-scale-sets
• web-apps

This logging weak spot reveals unexpected behavior of AzureHound. All azurehound list commands are preceded by AzureHound test calls to the endpoints and APIs the tool uses. The endpoints and APIs called differ depending on the Azure environment (e.g., global Azure Cloud, U.S. government, China).

The global Azure Cloud environment uses the following authentication and API endpoints:

• Microsoft identity platform endpoint: login.microsoftonline[.]com
• Microsoft Graph API: graph.microsoft[.]com
• Azure REST API ARM endpoint: management.azure[.]com

Figure 10 shows an extract from the verbose output of AzureHound execution for these test calls.

The AzureHound call to the Microsoft identity platform endpoint login.microsoftonline[.]com is recorded in the Entra ID non-interactive sign-in logs. If Graph API logging is enabled as described earlier, the test call to the Microsoft Graph API (hxxps[:]//graph.microsoft[.]com/v1.0/organization) will be visible in the Microsoft Graph activity logs. Due to the logging limitations mentioned above, the test call to the Azure REST API at management.azure[.]com is not logged.

Table 1 below shows information from the logs for a list storage-accounts request given at 10:57 P.M. and a request for list groups given at 11:25 P.M. Recall that storage account enumeration uses the Azure REST API.

AzureHound Command Line	AzureHound API Calls	Logged Time	Logged RequestURI	Logged User-Agent
list storage-accounts	AzureHound test call to the Graph API to determine reachability[1]	8/1/2025, 10:57:35.185 PM	hxxps[:]//graph.microsoft[.]com/v1.0/organization	azurehound/v2.6.0
	Call to Azure REST API to enumerate storage account data.	Call to REST API at management.azure[.]com/[...]Microsoft.Storage/storageAccounts/list is not logged
list groups	AzureHound test call to the Graph API to determine reachability[1]	8/1/2025, 11:25:45.561 PM	hxxps[:]//graph.microsoft[.]com/v1.0/organization	azurehound/v2.6.0
	Call to Microsoft Graph API to enumerate group data.	8/1/2025, 11:25:45.651 PM	hxxps[:]//graph.microsoft[.]com/v1.0/groups?%24filter=securityEnabled+eq+true&%24top=99	azurehound/v2.6.0
[1]Although we only include the Graph API test call in the table, all three test calls mentioned above are invoked each time.

Table 1. Microsoft Graph API vs. Azure REST API request logging.

The data shows that while the list groups command logs the read operation for the group enumeration (Graph API: hxxps[:]//graph.microsoft[.]com/v1.0/groups?[...]), the list storage-accounts request has no associated RequestURI logged for the read operation of the storage accounts (Azure REST API: Microsoft.Storage/storageAccounts/list). This is the REST API logging weak spot that we previously referred to. However, we can match these test calls to information in other logs to gain more visibility into this activity.

For AzureHound list commands using the Azure REST API, the initial /organization Graph API request used to test the connection is logged. It can be used to correlate events by matching fields such as session ID, IP address, user ID and user-agent against other log activity in Microsoft Graph activity logs and Entra ID sign-in logs.

In addition to Microsoft Graph API and Azure REST API activity and resource logs, Entra ID sign-in logs and audit logs can provide additional context.

As the name implies, Entra ID sign-in logs record successful and failed sign-ins, but these logs also record the following:

• CAP policy evaluation
• Token issuance for API calls
• User-agent and device
• MFA details

The information contained in these logs can help identify suspicious login patterns such as:

• Unusual geography
• Impossible travel
• Sign-in to resources Microsoft Graph and Azure management APIs in quick succession
• Accounts signing in without MFA

Entra Audit logs track directory-level configuration changes in Microsoft Entra ID including:

• User and group modification (create, delete, update)
• Role assignments and removals
• App registration and service principal modification
• Application consent
• Conditional Access policy changes
• PIM role activations and deactivations

As such, audit logs are not very useful for directly detecting AzureHound activity. However, they are useful for finding follow-on activity after a threat actor has escalated privileges, such as the threat actor creating a new user for persistence and assigning it privileged roles.

It is also worth noting that in July 2025, Defender XDR introduced a new Advanced Hunting table, GraphApiAuditEvents, in public preview. This is a leaner version of Microsoft Graph Activity Logs that provides visibility into Entra ID Graph API calls without extra ingestion or storage costs. Its schema is simplified, including key fields like RequestURI and token identifiers. However, it lacks the UserAgent field and is limited to a default 30 days of data retention.

We will discuss in the next section how we use this information to hunt in Cortex XDR or XSIAM for related threat actor activity.

Threat Hunting

While Cortex Cloud includes various detections for Azure cloud discovery activity, an incident responder or threat hunter can also use Cortex XQL queries to drill down into the data for more detail on individual events. At the most basic level, this can be done by querying the Cortex cloud_audit_logs dataset for requests where the user agent contains an AzureHound identifier (default: azurehound/<version>).

Industry observations indicate that in many cases, threat actors operate tools using default configurations, including user-agent strings, providing an easy parameter for an initial hunt query.

Optionally, a filter for the API operation can be set to filter results for that respective operation. The following example searches for AzureHound activity (azurehound list users) that is querying the Microsoft Graph API for a list of Entra ID users.

Cortex ingests log data from Azure. The activity in Azure is surfaced through Microsoft Entra ID Microsoft Graph activity log and tied to its audit and sign-in monitoring capabilities. This provides visibility into HTTP requests made to the Microsoft Graph API within a tenant.

Figure 11 below shows a sample raw activity log entry representing an AzureHound list users request that has been sanitized for anonymity. Defenders can use many of the fields to create additional queries fitting the situation they are investigating. For example, filtering for a specific signInActivityId or callerIpAddress.

There are several other useful elements from the log extract:

• The user-agent string indicates that AzureHound was most likely used to make this request.
• The Request URI field indicates AzureHound is pulling user data via GET /users with a large attribute set (accountEnabled, createdDateTime, displayName, mail, userPrincipalName, etc.). This is consistent with discovery and privilege escalation mapping.
• In the App ID field, the value 1950a258-227b-4e31-a9cf-717495945fc2 is the Microsoft Azure PowerShell client ID. This is worth noting as PowerShell is often used by offensive tools and by threat actors.
• And finally, the UserPrincipalObjectID (454b1120-3507-4bbb-b559-87b7f64af7fa) is the Entra ID object ID of the user whose credentials were used. For more information, correlate the sign-in activity ID (frZ7H7lx8kSlDW0b-4MfAA) with Entra ID sign-in logs.

Identification of high volume API enumeration by a single identity is also a useful strategy for defenders to help identify suspicious discovery activity. AzureHound may generate bursts of API calls in a short time window when querying the Microsoft Graph or Azure REST APIs. This can happen during requests for high volume resources such as users, roles, virtual machines or applications, or simply when using azurehound list to enumerate the entire Azure environment at once. When combined with user-agent strings and the IP address of the calling entity, this can provide a signal for broad enumeration of an Azure environment.

The following XQL query helps surface this enumeration. The operation_name and operation_name_orig filters will limit the results to limit the search to Graph API GET requests which AzureHound uses as explained above.

The bin and comp stages together with the count() function are used to aggregate the data into 60-minute buckets for comparison with the apiCallCount threshold (500 calls per 60 minutes in the example). The apiCallCount should be adjusted to fit the size of the Azure environment. Larger organizations will likely see a higher number of requests as the number of users, roles, virtual machines and applications will typically be much larger than smaller organizations.

Cortex XQL queries allow defenders to drill into telemetry collected from sources like Microsoft Graph API activity logs to uncover detailed indicators of AzureHound activity. Queries that correlate request volume, user identity, caller IP and user agent over defined time windows can help defenders identify unusual enumeration patterns typical of AzureHound.

Conclusion

Threat actors make use of AzureHound’s capabilities for targeted cloud discovery. Its ability to enumerate users, groups, applications, permissions and resource relationships maps directly to MITRE ATT&CK TTPs. This gives threat actors like Curious Serpens and Void Blizzard a structured method to map environments, identify accounts for privilege escalation and locate the crown jewels of cloud environments.

Detecting this activity depends on telemetry visibility. Microsoft Graph activity logs provide a rich record of API calls, enabling defenders to identify discovery patterns. When paired with other Azure and Entra ID logs, these sources form a comprehensive monitoring layer that elevates threat detection and incident response.

Please refer to our Detecting Threats with Microsoft Graph Activity Logs guide for a walkthrough on configuring Graph API logging, integrating with Cortex XDR and using Cortex to investigate Microsoft Graph activity.

By aligning detections with the MITRE ATT&CK framework and leveraging these log sources, defenders can combine visibility with proactive control. The following are all critical actions that strengthen an organization’s ability to deny attackers success:

• Mapping legitimate discovery tools to threat scenarios
• Correlating data across systems
• Applying Conditional Access Policies
• Following the principle of least privilege
• Closely monitoring for deviations from normal behavior

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

• Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) as well as Identity Threat Detection and Response (ITDR) and provides clients with the necessary capabilities to improve their identity related security requirements. By providing visibility into identities, and their permissions, within cloud environments, to accurately detect misconfigurations, unwanted access to sensitive data and real-time analysis surrounding usage and access patterns.
• Prisma Browser applies multiple mechanisms to protect against token theft and enables administrators to enforce re-authentication during a session. This limits the lifespan of any hijacked session and narrows the attacker’s window of opportunity.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 00080005045107

Indicators of Compromise

User agent string:

• azurehound/<version>

Additional Resources

• Threat Brief: Escalation of Cyber Risk Related to Iran (Updated June 30) - Palo Alto Networks
• 2025 Unit 42 Global Incident Response Report: Social Engineering Edition - Palo Alto Networks
• Anatomy of a Cloud Supply Pipeline Attack - Palo Alto Networks
• Detecting Threats with Microsoft Graph Activity Logs - Palo Alto Networks
• Cortex XSIAM XQL - Palo Alto Networks
• Peach Sandstorm password spray campaigns enable intelligence collection at high-value targets - Microsoft
• New Russia-affiliated actor Void Blizzard targets critical sectors for espionage - Microsoft
• From Infection to Access: A 24-Hour Timeline of a Modern Stealer Campaign - The Hacker News
• Storm-0501’s evolving techniques lead to cloud-based ransomware - Microsoft
• SpecterOps/AzureHound - GitHub
• SpecterOps/BloodHound - GitHub
• BloodHound CE Collection - Specter Ops, Inc.
• ATT&CK® Matrix for Enterprise - MITRE
• ATT&CK® Cloud Matrix - MITRE
• Use the Microsoft Graph API - Microsoft
• What is Azure Resource Manager? - Microsoft