Cloud Service Discovery (T1526) is a Discovery technique. After gaining access, an adversary tries to learn which cloud services are running. MITRE lists IaaS, Identity Provider, Office Suite and SaaS as platforms, and covers infrastructure, platform and software as a service.
How attackers use it
MITRE explains that services can include CI/CD, Lambda functions and Entra ID, as well as security services such as AWS GuardDuty and Microsoft Defender for Cloud, and logging services such as AWS CloudTrail and Google Cloud Audit Logs.
In Azure, tools and APIs such as the Microsoft Graph API and Azure Resource Manager API can list applications, management groups, resources and policy definitions and their relationships, for any identity with access. MITRE names Stormspotter as an open source tool that enumerates Azure resources into a graph, and Pacu as an open source AWS exploitation framework with several methods to discover services.
The information then shapes next steps: going after data or credentials in the discovered services, or evading discovered defenses through Disable or Modify Tools or Disable or Modify Cloud Log.
How to detect it
MITRE's analytics:
- Unusual enumeration of services and resources through cloud APIs, such as AWS describe and list calls, Azure Resource Manager queries or GCP project listings, with anomalous volume and a link to recently compromised sessions.
- Enumeration of directories, applications or service principals through Microsoft Graph or the Okta API, such as unexpected listing of users, roles and apps.
- Discovery of SaaS services connected to Microsoft 365 or Google Workspace, such as listings of enabled services, integrations or OAuth apps.
- Discovery of connected apps and configuration in platforms such as Salesforce, Slack or Zoom.
A strong signal is an identity that suddenly issues dozens of read only calls across many services it never touched before. Baseline each identity's normal API pattern, then alert on departures.
How to reduce the risk
MITRE lists no mitigations, because this technique abuses legitimate features. Reduce the value of what can be seen: apply least privilege so a stolen identity can list little, protect logging and detection services from being disabled, and keep the audit logs in a place the same identity cannot edit.
Check your own environment
- Are cloud audit logs on in every account and region, and shipped to a separate account?
- Do you alert on bursts of list and describe calls from a single identity?
- Which identities can enumerate identity provider objects such as apps and service principals?
- Who gets notified when a logging or detection service changes state?
Quick check
Why do adversaries enumerate security and logging services?
To find out what could detect them, so they can plan to evade or disable it, as MITRE notes with Disable or Modify Tools and Disable or Modify Cloud Log.
