MITRE ATT&CK T1526 Cloud Service Discovery: Spotting Enumeration Early

Once an adversary holds a cloud identity, the first useful question is what services that identity can see, and the answer usually comes from your own management APIs. MITRE ATT&CK T1526 Cloud Service Discovery, in the Discovery tactic (TA0007), covers enumeration of the cloud services enabled in an environment: CI/CD, serverless functions, Entra ID, security services such as AWS GuardDuty and Microsoft Defender for Cloud, and logging services such as AWS CloudTrail and Google Cloud Audit Logs. ATT&CK v20 lists four platforms: IaaS, Identity Provider, Office Suite and SaaS. This guide is for cloud security, SOC and identity teams who need to see enumeration early, before it turns into credential theft or log tampering. It complements the T1580 and T1619 Cloud Infrastructure and Storage Discovery Guide, which covers instances, snapshots and buckets; this page covers the service and control plane layer above them.

Key takeaways

• Discovery aims at your defences. ATT&CK states that adversaries use what they learn to target data and credentials or to evade defences through T1685 Disable or Modify Tools and T1685.002 Disable or Modify Cloud Log.
• Stolen identities do the enumeration. Storm-0501 used the Entra Connect Directory Synchronization Account with AzureHound to enumerate users, roles and Azure resources, then mapped Azure Policy, resource locks and immutability policies, according to Microsoft.
• Read calls are not always logged by default. The Azure Activity log does not typically capture read operations, and Google Cloud Data Access audit logs are off by default except for BigQuery. Check this before you write detections.
• Behaviour beats single events. ATT&CK's detection strategy DET0402 looks for unusual volume, unusual user agents and enumeration tied to newly compromised sessions, not for any one API call.
• No ATT&CK mitigation is listed. v20 maps no M-series mitigation to T1526, so least privilege on workload identities and complete control-plane logging are the practical levers.

What the technique covers

ATT&CK describes adversaries enumerating cloud services after gaining access, with methods that differ across PaaS, IaaS and SaaS. In Azure, the Microsoft Graph API and Azure Resource Manager API can return applications, management groups, resources and policy definitions, and the relationships between them, that are visible to an identity. ATT&CK names two open source tools as examples: Stormspotter, which builds a graph of Azure resources, and Pacu, an AWS exploitation framework with several service discovery modules. The technique has no sub-techniques in v20.

T1526 sits beside several related Discovery techniques, each with its own ATT&CK entry and page:

For the account and group side, see the T1087 and T1069 Account and Permission Group Discovery Defensive Guide. The AI-system mirror of this technique in MITRE ATLAS is AML.T0075; see the AML.T0075 Enterprise Resource Discovery page.

How adversaries use it: cases from ATT&CK v20 and incident reporting

• Storm-0501 (G1053): ATT&CK records that the group discovered the victim's protections, including Azure policies, resource locks and Azure Storage immutability policies. Microsoft's August 2025 report adds that, after gaining Owner access, the actor ran a broad AzureHound discovery phase looking for sensitive data stores and backup resources, and later deleted snapshots, restore point collections and recovery vault protection containers, removed locks and immutability policies, and demanded payment. Discovery of protections came directly before their removal.
• AADInternals (S0677): can enumerate information about cloud services such as Office 365 and SharePoint instances and OpenID configurations. Microsoft also reports Storm-0501 using AADInternals to create a federated-domain backdoor.
• ROADtools (S0684): can enumerate Azure AD (Entra ID) applications and service principals, the non-human identities that most often hold standing API permissions.
• Pacu (S1091): can enumerate AWS services such as CloudTrail and CloudWatch, which tells an operator whether logging and alarms are in place.
• TruffleHog (S9009) and TeamPCP Cloud Stealer (S9041): ATT&CK records TruffleHog scanning code repositories and CI/CD platforms, and the TeamPCP stealer, used in the 2026 Trivy supply chain compromise, searching GitHub for Actions runner processes. CI/CD services are discovery targets because they hold deployment credentials.
• AI-Assisted Breach of Mexico's Government Infrastructure (C0064): ATT&CK records the adversary identifying and connecting to victim AWS databases and systems through client tools.
• Storm-2949 (2026): after taking Entra ID accounts through help desk impersonation and self-service password reset abuse, the actor used a custom script against Microsoft Graph to enumerate users and applications and to look for privileged roles, then read Key Vault secrets and storage account keys. See the Storm-2949 Azure attack analysis.

Where enumeration is visible, and where it is not

Detection fails most often because the read calls were never logged. Confirm coverage per platform before tuning any rule:

For the AWS side in depth, see the AWS CloudTrail Guide; for Entra ID, the Entra ID Sign-In and Audit Log Detection Guide.

What to detect: ATT&CK DET0402 in practice

DET0402 Detection Strategy for Cloud Service Discovery has four analytics, all built on the data component DC0083 Cloud Service Enumeration, correlated with session or account context:

NHI Mgmt Group recommends turning those analytics into four concrete detections:

1. Breadth per identity: count distinct services or API namespaces read by one principal in a short window. A deployment role touches a handful; an enumeration tool touches dozens.
2. Security and logging service reads by unusual principals: calls that describe CloudTrail trails, GuardDuty detectors, Defender plans, diagnostic settings, Azure Policy assignments, resource locks or immutability policies, from an identity with no operational reason to read them. These map directly to the evasion step that follows.
3. New session, then discovery: enumeration within minutes of a first sign-in from a new device, location or user agent, or after a password reset or MFA method change. Storm-2949 and Storm-0501 both followed this pattern.
4. Workload identity drift: a service principal, access key or managed identity that suddenly calls list or describe APIs outside its normal set. Machine identities have stable behaviour, so drift is a high-value, low-noise signal.

Managed detections help. Amazon GuardDuty raises Discovery:IAMUser/AnomalousBehavior when an identity makes unusual get, describe or list calls, and PenTest:IAMUser/KaliLinux, ParrotLinux and PentooLinux when API calls come from those operating systems. Microsoft names Defender for Cloud alerts such as "AzureHound tool invocation detected" and Defender for Cloud Apps "Suspicious use of AzureHound". See the Amazon GuardDuty Guide.

Noise and baselining

CSPM and CNAPP scanners, backup tools, cost tools and infrastructure-as-code pipelines enumerate constantly. Baseline them by principal and source, not by API name, and keep that allowlist tight: scanner identities are themselves attractive to steal, as the If your CNAPP and CSPM platform is compromised playbook explains. Alert when a known scanner identity is used from a new source IP or user agent, rather than suppressing it entirely.

Reducing what discovery can return

ATT&CK v20 maps no mitigation to T1526. The following are NHI Mgmt Group recommendations that limit the value of enumeration and make it louder:

• Scope read permissions: broad built-in roles such as Reader at subscription or management group scope, or AWS ReadOnlyAccess, let any compromised holder map the estate. Grant read at the narrowest scope that the job needs, and separate security-service read rights from general read. See the Least Privilege Techniques Guide.
• Protect directory sync and automation identities: Storm-0501 enumerated with the Entra Connect sync account. Microsoft recommends restricting its sign-ins to trusted IPs with Conditional Access. See How to audit the Entra Connect sync account.
• Restrict user access to directory data: in Entra ID, review whether non-admin users can read the full directory and register or consent to applications. See the Entra ID Applications and Consent Guide.
• Make protections hard to remove: discovery of locks and immutability is only valuable if the adversary can then delete them. Restrict who can delete locks and policies, and use Azure Backup, Key Vault purge protection and immutable storage, as Microsoft advises.
• Log completely, alert centrally: organisation-wide CloudTrail, Graph activity logs, Google Cloud Data Access logs for control-plane services, with logs written to an account or project the workload identities cannot modify.

Where identity fits

Every T1526 procedure in ATT&CK runs under an identity: a stolen user session, a synced account, an application credential or a CI/CD token. Non-human identities are the attractive ones because they rarely have MFA, often hold read access across many subscriptions, and are not watched by a person who would notice odd activity. Inventory service principals and access keys with broad read scope, remove the ones that are stale, and baseline the rest. See How to find and remove stale service principals in Entra ID and the How to Investigate CloudTrail for a Compromised Access Key guide.

How to test your coverage

1. Confirm logging: in a non-production account, subscription or project, make a handful of read calls against identity, logging and security services, and check that each appears in your SIEM with principal, source IP and user agent.
2. Run an approved enumeration exercise: with written authorisation, have your red team or an emulation platform run broad service enumeration under a test service principal and a test user. Record time to alert.
3. Replay the sequence: chain a new-location sign-in, an MFA method change and enumeration, as in the Storm-0501 and Storm-2949 reports, and check that the correlation rule fires.
4. Check suppression: run the same calls with a scanner identity from an unexpected source and confirm the alert is not suppressed.
5. Roll back: delete the test identities and keys, and remove any temporary allowlist entries.

Metrics that show the detection works:

• Percentage of cloud accounts, subscriptions and projects with read-event logging confirmed in the SIEM.
• Median time from first enumeration call to alert in exercises.
• Number of identities with estate-wide read access, tracked down over time.
• Percentage of workload identities with a behavioural baseline.
• False positive rate of the breadth-per-identity rule after tuning.

Common failure patterns

• Assuming the Activity log shows reads: teams build Azure discovery rules on AzureActivity and get nothing, because reads are not typically captured there.
• Blanket scanner allowlists: suppressing every call from a CSPM identity hides that identity's misuse.
• Alerting on single API names: one DescribeInstances call is routine; the signal is breadth, speed and context.
• Ignoring security-service reads: reads of GuardDuty, Defender, trails and diagnostic settings are the step before T1685.002, and are rarely alerted on.
• Unmonitored sync and automation accounts: the Entra Connect sync account and CI/CD service connections hold broad rights and are seldom baselined.

Framework mapping

For how Discovery fits the wider kill chain, see the ATT&CK Discovery Tactic (TA0007) Guide.

Practitioner checklist

• Confirm read and list calls are logged for every cloud and identity platform, including Graph activity logs and Google Cloud Data Access logs.
• Store control-plane logs where workload identities cannot change them.
• Build a breadth-per-identity enumeration rule with per-principal baselines.
• Alert on reads of logging, security and protection services by unusual principals.
• Correlate new-session events (new location, MFA change, password reset) with enumeration.
• Review every identity holding estate-wide read access, human and non-human.
• Restrict and monitor the directory sync account and CI/CD service connections.
• Enable managed detections such as GuardDuty and Defender for Resource Manager and route them to the SOC.
• Test with an authorised enumeration exercise at least yearly and measure time to alert.

Standards and references

• MITRE ATT&CK: T1526 Cloud Service Discovery
• MITRE ATT&CK: Storm-0501 (G1053)
• Microsoft Threat Intelligence: Storm-0501's evolving techniques lead to cloud-based ransomware
• Microsoft Learn: Microsoft Graph activity logs
• Microsoft Learn: Azure Monitor activity log
• Google Cloud: Cloud Audit Logs overview
• AWS: GuardDuty IAM finding types
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: CNAPP Guide, T1580 and T1619 Cloud Infrastructure and Storage Discovery Guide, Azure RBAC and Service Principals Guide, MITRE ATT&CK T1078 Valid Accounts Guide.