Detect cloud infrastructure discovery by monitoring for enumeration of accounts, subscriptions, projects, instances, networks, security groups, and storage. Look for bursts of read-only API calls, broad listing actions, and activity from identities that usually administer only a narrow resource set. Discovery often precedes lateral movement, privilege escalation, and data theft.
What cloud infrastructure discovery looks like in practice
cloud infrastructure discovery is usually visible as enumeration, not exploitation. The behaviour often includes repeated listing of tenants, subscriptions, projects, instances, networks, security groups, buckets, and similar control-plane objects. The important distinction is breadth: normal automation tends to touch a narrow, predictable scope, while discovery expands across assets and metadata to map the environment.
Security teams should treat broad read-only activity as meaningful when it comes from an identity that normally manages only a small resource set. That mismatch is often more useful than any single API call, because discovery behaviour is designed to stay low-noise while building a target map for the next stage.
How to recognise discovery in cloud telemetry
Good detection starts with API and control-plane telemetry, then adds identity context. Bursts of list, get, describe, and enumerate actions across multiple resource types are stronger signals than one-off reads. So are access patterns that cross account boundaries, region boundaries, or project boundaries when the principal rarely operates that widely. The same logic applies whether the source is a human administrator, a workload, or an automation identity, because discovery is about access pattern shape, not user type.
It also helps to baseline what each identity normally touches. A role that usually changes one application stack but suddenly inspects storage, IAM-like objects, network policy, and compute inventory is far more suspicious than a role that simply performs its expected maintenance tasks. Cloud Security Guide is a useful reference for the wider control-plane context, including logging, shared responsibility, and cloud inventory discipline.
Why discovery matters before lateral movement
Discovery is often an early stage in cloud attacks because it reduces attacker uncertainty. Once an adversary understands how accounts, projects, networks, and storage are arranged, they can choose better targets, look for exposed trust paths, and identify where privilege is thin. That makes discovery a precursor to lateral movement, privilege escalation, and data theft rather than a harmless reconnaissance step.
In cloud environments, the same discovery pattern can also expose weak governance. Broad enumeration may reveal stale resources, over-permissioned roles, open security groups, shadow projects, or shared storage that was never meant to be widely visible. Cloud PAM and CIEM Guide helps frame why effective permissions and privilege boundaries matter when discovery activity starts to widen beyond an identity’s normal scope.
How to separate noisy admin work from hostile discovery
Detection is stronger when teams combine volume, scope, and identity behaviour. A temporary burst of inventory reads from a deployment pipeline may be legitimate, while the same pattern from a seldom-used role or from an identity with narrow administrative history deserves escalation. Correlate control-plane reads with unusual source IPs, new geographies, non-standard user agents, and follow-on actions such as permission checks, key lookups, or storage enumeration.
Cloud discovery often also overlaps with misconfiguration review and asset sprawl, so detections should be tuned to avoid drowning analysts in benign enumeration. Infrastructure as Code Security Guide is relevant where discovery follows drift, undocumented resources, or inconsistent deployment patterns that make inventory and ownership unclear.
Risk and Threat Considerations
Cloud discovery creates risk even before an attacker touches a workload. The main concern is that control-plane visibility can expose where to pivot next, which identities are powerful, and which storage or network paths are most exposed. At scale, discovery becomes a mapping exercise for compromise, not just a search for information.
Failure mechanism: Attackers or malicious insiders abuse read-only and enumeration permissions to build an accurate model of the cloud estate, then use that model to identify privilege gaps, trust relationships, and high-value data paths.
Impact: The result can be faster privilege escalation, better-targeted lateral movement, and more efficient data theft, especially when discovery is not correlated with identity baselines or control-plane alerting.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1619 — Cloud Service Discovery | Directly covers cloud enumeration and discovery behaviour |
| Recommendation — Map cloud enumeration to T1619 and alert on broad control-plane listing across services. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Cloud discovery is detected through anomalous control-plane activity |
| DE.AE-03 — Potentially Adverse Events Are Analyzed | Discovery becomes meaningful when unusual reads are analysed as precursor activity | |
| Recommendation — Monitor cloud API telemetry for unusual enumeration bursts and scope expansion. Triage broad read-only enumeration as possible precursor behaviour and investigate context. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Cloud discovery detection depends on analysing audit logs and API events |
| AC-2 — Account Management | Discovery often exploits identities with excessive or unexpected visibility | |
| Recommendation — Review cloud audit logs for high-volume listing and cross-scope enumeration. Constrain accounts so enumeration access matches the role’s expected scope. | ||
Practitioner Guidance
What to prioritise: Baseline enumeration by identity and by resource family, then alert on identities that move from narrow administrative behaviour to broad multi-service listing. Prioritise control-plane telemetry that shows account, project, network, compute, and storage enumeration in the same session or timeframe.
What to verify: Check whether the principal is authorised to inventory that scope, whether the access comes from a known automation path, and whether the pattern is consistent with recent change activity. If the answer is unclear, treat the behaviour as a possible precursor to compromise rather than as routine administration.
Practitioner takeaway: The most useful signal is usually not a single suspicious API call, but a broad, cross-resource enumeration pattern that does not fit the identity’s normal operating footprint.
Related resources from NHI Mgmt Group
- How should cloud security teams detect and contain attempts to modify compute infrastructure for defense evasion?
- How should security teams implement cryptographic discovery across cloud, code, and infrastructure?
- Why are NHIs a critical concern for security teams?
- What steps should security teams take to prevent Shadow AI risks?