How T1580 cloud infrastructure discovery exposes an intruder mapping your IaaS estate
If a credential or session with cloud read access is active and you need to know whether it is being used to map instances and resources, look for enumeration bursts across compute, storage and metadata APIs from an identity that does not normally perform inventory work. T1580 Cloud Infrastructure Discovery is the technique in which an adversary who already has access to a cloud environment lists the infrastructure inside it, such as virtual machines, storage, networks and their configuration, so it can choose its next target. It sits under the MITRE ATT&CK tactic TA0007 (Discovery), which ATT&CK describes as the adversary trying to figure out your environment. In intrusions, T1580 usually appears after initial access to a cloud account, a leaked access key or a stolen session, and before lateral movement or data access. Because the activity uses the provider's own read APIs, it can look like routine administration unless you compare it against a baseline for each identity.
This page targets Enterprise ATT&CK version 20.0, which MITRE released on 2026-10-13 according to the attack-stix-data repository index. Technique IDs, sub-technique structure, data component names and mitigation mappings can change between releases, since MITRE can rename, deprecate or revoke entries. Before you write or tune a detection, confirm the technique and its detection strategies in the version your monitoring stack actually maps to, and record that version in your detection documentation. The MITRE ATT&CK tactic page for Discovery is the starting point for checking how the tactic is described in the current version, and the ATT&CK updates page lists what changed in each release.
The decision you face is scope. Start by listing which identities, roles and service accounts in your cloud accounts have legitimate read access to instance and storage inventories, and which of them should never enumerate across accounts or regions. Those lists set the baseline against which T1580 activity stands out. Confirm with your cloud provider how its audit logs record list and describe calls, whether events arrive in your SIEM with the calling identity, source address and user agent, and how long they are retained. If any of those fields are missing, the detection will be guesswork, so resolve that gap before tuning alerts.
Which cloud telemetry reveals instance, storage and metadata enumeration
This table maps the three telemetry families named for T1580 to the cloud control-plane and data-plane logs that record them, the signal to look for, and the open-source collector or SIEM component that can ingest it. Read each row as a question to answer for your own IaaS accounts, since log names and retention differ by provider. Host-level data components such as Process Creation and Command Execution only apply to activity from workloads inside the estate.
| Telemetry family | Where it is recorded | Signal to look for | Open-source ingestion point |
|---|---|---|---|
| Instance enumeration | Control-plane audit logs for describe and list calls on compute resources | Unusual principal listing instances across many regions or accounts in a short window | Collector pulling provider audit logs into Wazuh or a SIEM index (confirm supported cloud modules) |
| Cloud storage enumeration | Control-plane and data-plane logs for bucket or container list operations | Bucket list calls from identities that do not normally touch storage, or from new source addresses | Log pipeline into Security Onion or Elastic-based SIEM, with storage access logs enabled |
| Instance metadata access | Metadata service requests logged on the host or through network telemetry, where the provider exposes them | Requests to the instance metadata endpoint from processes or containers that do not normally need it | Host agent such as Wazuh or Velociraptor, plus Zeek or Suricata where metadata traffic is visible (confirm per provider) |
| Host activity inside IaaS workloads | Process Creation (DC0032) and Command Execution (DC0064) on guest operating systems | Cloud CLI or SDK binaries run interactively on hosts that have no admin role | Wazuh or Sysmon-based collection feeding Sigma rules |
| Identity context | Identity provider sign-in and token issuance logs | Enumeration calls made with a session created minutes earlier from an unfamiliar location | Log forwarding to the SIEM, correlated with control-plane events by principal ID |
| Gap check | Not every provider logs every list or metadata call by default | Missing records for one of the three families during a rehearsal | Confirm logging settings with each provider and test them in the cyber range before relying on them |
Detection logic for T1580 that a SOC can tune
The four ideas below turn T1580 Cloud infrastructure discovery into alerts a SOC can tune against a known baseline. Each one looks at who is calling, what they are calling and from where, so that routine inventory traffic can be separated from enumeration. Thresholds and baselines should be set per account and per environment, then reviewed as tooling and workloads change.
Burst of describe and list calls
Flag one principal issuing describe or list calls across many resource types inside a short window, such as compute, storage, networking and identity, within the same account. Tune the threshold on the count of distinct resource types per principal per window, not raw call volume, because that is what separates sweeping enumeration from a single service reading its own resources. Build the baseline from several weeks of logs per account and per role. Expected false positives include inventory and cloud asset management tools, CMDB sync jobs and cost reporting, which all read broadly on a schedule. Allow-list them by named principal and role, and alert when those identities appear from an unexpected source.
Enumeration from a dormant identity
Alert when an identity that has rarely or never called discovery APIs starts doing so, especially a service account, CI runner role or human user whose normal activity is limited to a few services. The key tuning input is the history of which API actions each identity has used over a defined lookback period. Watch for the first use of list or describe actions by an identity, and weigh it higher when the identity was created recently or was recently granted new permissions. Expected false positives include newly onboarded tools, a team starting a migration, and automation deployed by a pipeline change. Confirm these with the change record before closing the alert.
Instance metadata reads from unexpected workloads
Watch for instance metadata service requests from workloads that do not normally query it, particularly processes that were not part of the image's startup or configuration tooling. Where your platform logs metadata access, baseline which processes, containers and service accounts read it and how often. Treat a new reader that then requests credentials or role information as a higher priority than a simple read of instance identity. Expected false positives include configuration agents, container orchestration components, monitoring agents and backup software that read metadata on boot or on a schedule. Confirm what the platform exposes and logs before writing the rule, since coverage differs by provider and configuration.
Enumeration from unfamiliar networks and clients
Flag cloud API calls from source networks, egress addresses or user agents that have never appeared for a given identity, and treat a change in client signature as a separate signal from a change in volume. Build the baseline from known corporate egress ranges, CI runner ranges and vendor tool user agents. Pair this with geographic or ASN checks only where your organization already operates across those locations. Expected false positives include VPN pool changes, new SaaS integrations, remote workers on new networks and vendor support sessions. Route alerts to the identity owner for confirmation, and record the outcome so the baseline improves over time.
How to confirm the T1580 detection fires before you trust it
This sequence proves that the T1580 detection fires on approved, non-production cloud enumeration, that alerts reach the SOC queue, and that the results match the ATT&CK mapping you intend to rely on. It produces an evidence record you can review before treating the detection as operational.
Agree scope and success criteria in writing
Before any activity, the detection engineer, SOC lead, cloud platform owner and the person accountable for risk sign a short test plan. The plan names the non-production cloud account or project, the IaaS services in scope, the telemetry sources expected for Instance Enumeration, Cloud Storage Enumeration and Instance Metadata, the ATT&CK version targeted, and the rollback contact if a test disrupts a shared service. Done means every signatory has approved the plan and no activity starts without it.
Provision a dedicated test identity
Create a single-purpose test identity in the non-production account with only the permissions the emulation needs, and tag it so every resulting log entry can be traced back to the exercise. Keep the identity out of production groups and record its name, creation time and permission set in the test plan. Done means the identity is documented, its activity is attributable in the cloud audit logs, and the platform owner has confirmed it is isolated from production.
Run approved enumeration in the test account
The red team or range operator runs the agreed cloud enumeration activity against the non-production account, limited to the scenarios in the plan. Do not improvise beyond the plan. The operator logs each action in a run sheet with start and end times, the identity used and the target resource type. Done means the run sheet matches the executed activity one to one and no action was performed outside the approved scope.
Record timestamps, principals and expected events
Compare the run sheet with the cloud control plane audit records and the sensor data your Wazuh, Security Onion or cloud logging pipeline received. Confirm that each enumeration event carries the test identity, a timestamp and the source address, and note the gap between the action and the moment the event was indexed. Done means every run sheet entry maps to an event in the logs, or to a documented gap with a reason.
Confirm each alert reaches the SOC queue
Trace each rule match from the detection platform into the case or ticket system that analysts use. Check that the alert carries the rule identifier, rule version, ATT&CK technique mapping and affected account, and that it arrives in the queue an analyst monitors, not only in a dashboard. Record the alert IDs against the run sheet entries. Done means every expected alert has an ID, a queue entry and a timestamp, and any missing alert is logged as a finding.
Compare results with the ATT&CK mapping
Review the outcome against the detection strategy and analytics for T1580 in the ATT&CK version you named in the plan, and against the data components the rule depends on. Identify which scenarios fired, which did not, and which fired on activity outside the mapping. Done means a written comparison exists that states, for each scenario, whether it was detected, detected late, detected under a different technique or missed.
Record evidence and close gaps
Write up the test with alert IDs, rule versions, the ATT&CK version targeted, detection latency per scenario, the test identity and the telemetry sources used. For each gap, assign an owner and a fix, such as a missing log source, a rule threshold change or a SOC routing correction, then rerun the affected scenario to confirm the fix. Keep the record for compliance evidence and future regression runs. Done means every gap is either closed with a passing rerun or accepted as a documented residual risk by the named owner.
Preventive controls that reduce T1580 exposure
T1580 becomes much easier for an adversary when a stolen or misused cloud identity can list instances, buckets and metadata across the whole account. The cards below focus on the identity and scope decisions that limit what a discovery attempt can see, and on the checks that confirm those decisions hold in your own IaaS environment.
Least-privilege read scopes
Inventory tooling usually needs to list instances, volumes, networks and storage metadata, but it rarely needs read access to every project, subscription or region. Start from the actions each inventory job actually calls, then bind those actions to the narrowest account, project or resource scope your provider supports. Wide read grants on the root account are the single change that most shortens an adversary's path to T1580. Confirm the scope of every read role against your provider's documentation, because the mapping between permissions and API actions differs across IaaS platforms.
Separate inventory roles from administration
Inventory and reporting identities should not also hold the ability to change IAM policies, create keys or modify network controls. When one identity can both enumerate resources and change access, a single credential compromise gives an adversary a map and the means to act on it. Keep read-only inventory roles, administrative roles and break-glass accounts distinct, with separate credentials and separate logging. Ask your team to produce a list of every identity that can both list resources and modify permissions, and treat any overlap as a finding to close.
Periodic review of broad read access
Read access tends to accumulate. Contractors, migration projects and monitoring integrations often keep broad visibility long after the work ends. Schedule a recurring review of identities, service accounts and API keys that hold account-wide list or describe permissions, and record who approved each one. Remove grants that no longer match a current job, and rotate credentials that have not been used recently. The review cadence and owner should be written into your access management procedure so the review survives staff changes.
Service accounts and workload identities
Automation identities, such as CI pipelines, backup agents and asset scanners, are a frequent source of over-broad read access because they were granted wide permissions for convenience. Assign each workload its own identity, restrict it to the resource types it inspects, and prefer short-lived credentials over long-lived keys where the platform supports them. Confirm with your provider which workload identity options are available in your accounts and how their token lifetimes are set.
Network segmentation for IaaS
ATT&CK maps Network Segmentation (M1030) to several discovery techniques, including T1580. In IaaS, segmentation is applied through virtual networks, subnets and security groups, so its effect on T1580 depends on whether enumeration calls are restricted by network path, not only by identity. Confirm with your provider whether control-plane APIs can be restricted by source network, and document which management paths are reachable from workloads that do not need them.
Audit configuration for discovery calls
ATT&CK maps Audit (M1047) to discovery techniques, and the control only helps if the events it produces reach a place where someone reviews them. Confirm that control-plane audit logging is enabled in every account and region, that list and describe calls are recorded, and that retention meets your own policy. Mitigation value comes from detection in the log pipeline, which is covered on the detection sections of this page.
Triage steps when a T1580 alert fires in your cloud account
When a T1580 alert fires, the first decision is whether the activity is approved or unexplained. Start by identifying the principal that made the calls: the user, role, service account or workload identity, along with its session origin, source address, user agent and the time window of the enumeration. Then compare that record against your approved inventory, infrastructure-as-code runs, configuration management jobs and scheduled automation for the same account and time. A discovery burst from a known pipeline that ran as scheduled is a closed alert once the pipeline owner confirms it. A burst from an interactive session, a human identity with no change ticket, or a principal that has never enumerated the account before needs escalation. Confirm these facts with the owners of your automation, not from memory, and record the answers in the ticket.
Next, look for follow-on activity from the same principal and session. The detection tells you someone or something listed resources; the question now is whether it moved on to reading data. Review storage access logs for object listing or reads on buckets and volumes the principal had not touched before, and check whether any instance metadata service requests came from the affected workloads. Also check for new or modified credentials, role assumptions into other accounts, and changes to security groups or access policies. If the principal shows any of these, treat the alert as an active incident. Where the cloud provider logs are retained only briefly in your environment, confirm the retention period with your provider and export the relevant events before they age out.
If the activity is unexplained, decide whether to disable the credential first and rotate it second. Disabling stops further calls while preserving the identity for investigation, which is usually the right first step for a human or long-lived access key. Rotation follows once you have confirmed which workloads depend on the key, so a planned rollover does not cause an outage. Preserve logs by exporting the audit trail, the principal's configuration history and relevant storage and metadata access records to write-protected storage with a documented chain of custody. Then document the incident: timeline, principal, decisions taken, who approved them and what remains open. Feed the outcome back into your baseline and into the User Account Management controls, including least-privilege review of the role that was used.
Rehearsing T1580 detection and response in a private cyber range
The range should mirror the production IaaS account structure closely enough that the telemetry behaves the same way. Build a sandbox account or project that is separated from production, with the same cloud control-plane audit logging, storage access logging and instance metadata access paths enabled as in the live estate. Feed those logs into an open-source SIEM through a collector, and run a test workload such as a small set of instances, a storage bucket and a few identities so there is something real to enumerate. Confirm with your cloud provider exactly which control-plane events and data access events are recorded by default and which need explicit enablement, because gaps here are the most common reason a rehearsal looks clean but proves nothing.
- Logging parity: Enable the same audit trails in the sandbox that production uses, and record which ones are off by default.
- Collector path: Route cloud audit events through the same collector and parser chain used in production, so field names match your detection content.
- Test workload: Deploy a few instances, a storage container and a test role so enumeration has visible targets.
- Time synchronization: Keep range hosts and the SIEM on one time source so event ordering is trustworthy during the exercise.
- Isolation: Confirm that range identities cannot reach production accounts, and that exercise data is labeled so it is never mistaken for live activity.
Before the first exercise, check that a known test action produces the expected event in the SIEM within a window your team agrees in advance.
Injects are scripted actions the exercise team runs on purpose, so the blue team can measure what it sees. Use a dedicated test identity to perform scripted enumeration of instances, storage and metadata, and keep a written record of the timestamps, identity and actions so results can be compared afterward. Pair this with a benign inventory job that performs similar read-only listing on a schedule, since this is the false positive your analysts will meet most often. Add a credential misuse variant in which the test identity is used from an unexpected network location or at an unusual hour, to test whether context enrichment changes the triage outcome.
- Scripted enumeration: A test identity lists instances, storage objects and instance metadata in a controlled sequence, recorded in an exercise log.
- Benign inventory job: A scheduled read-only inventory from an approved automation identity, used to test whether analysts can separate routine activity from hostile activity.
- Credential misuse variant: The same test identity is used from an unexpected source, to test anomaly and location-based context.
- Volume variation: Run both a narrow sweep and a broad sweep, so you learn where thresholds fire and where they miss.
- Unannounced timing: Include at least one inject the blue team does not know about in advance, so the result reflects operational readiness.
Illustrative example: if the benign inventory job produces alerts that analysts close without review, the detection logic needs an allow list tied to the service identity and its expected source.
A rehearsal is only useful if the team agrees on what success looks like before the exercise begins. Define success in terms of observable outcomes: an alert is raised within an agreed window, the alert carries enough context to triage, the analyst records findings in a consistent form, and the team completes a lessons-learned record that leads to specific changes. The window and thresholds should be set by your own security operations leadership, not copied from a vendor default, and should be checked against the detection content for the ATT&CK version your team targets.
- Alert within window: The alert appears in the SIEM within the window your team sets, and the window is written down before the exercise.
- Triage notes: The analyst records the identity, source, target type, time, whether the activity matched the benign job, and the decision taken.
- Escalation path: The exercise confirms who is paged, how the incident is opened, and how containment such as disabling the test identity is approved.
- Lessons-learned record: Each gap becomes a tracked action with an owner, covering missing telemetry, noisy rules, unclear runbooks or slow approvals.
- Repeat cycle: Re-run the failed injects after changes, and keep the results as evidence for internal review or external assessment.
Check that the exercise output names the ATT&CK version, the detection content version and the mitigation User Account Management status, so the next rehearsal can be compared like for like.
Questions detection engineers ask about T1580 in IaaS
How do I separate inventory automation from attacker enumeration in IaaS logs?
Start by building a baseline of which identities, source networks and tooling already call describe and list APIs every day. Inventory jobs, configuration management, asset scanners and monitoring agents usually run from known roles, at predictable intervals and against known regions. Attacker enumeration tends to show a new principal or a known principal from an unfamiliar network, unusual breadth across regions and services in a short window, and calls that fail with access denied before succeeding elsewhere. Write detection logic as a combination of these attributes rather than as a single API name, because the same API name appears in both benign and hostile activity. Review the allowlist with the platform team every time a new tool or automation account is added, so that the baseline reflects reality.
How should I handle detection across a multi-account cloud organization?
Make sure audit trails from every account and region flow into one central store that your detection platform can query, and confirm that member accounts cannot disable or alter that trail. Normalize the account identifier, role and source fields so that a rule written for one account works in all of them. Expect some legitimate discovery to be centralized in a security or management account, and tag those principals explicitly so they do not raise noise. Also watch for enumeration that moves between accounts through assumed roles, since a single identity can appear under several account identifiers within minutes. Confirm your provider's options for organization-wide trails and for delegated administration of security services, because the exact options differ by provider.
Why does the MITRE ATT&CK version matter for T1580 detection mappings?
ATT&CK releases can rename, deprecate or revoke techniques, and v18 moved detections into detection strategies and analytics while deprecating data sources. A mapping written against one version can point to a data component or detection that no longer exists in another. Record the exact version in every rule and coverage report, for example as metadata on each detection. Before a release, diff the technique and data component references in your own mapping against the new version's content so that coverage gaps appear before they matter. The MITRE updates pages list each release's changes and are the right place to start that review.
How can I test T1580 detections without touching production?
Use a private cyber range or a separate non-production account that mirrors your logging configuration, identity model and network paths. Seed it with representative resources, then run controlled enumeration from a dedicated test identity so that every event can be traced back to your test plan. Record the expected outcome for each step, including the calls you expect to fail, and compare that record with what your detection platform produces. Keep the test identity narrowly scoped, time-bound and documented, and make sure the test traffic cannot reach production data. The range also gives you a place to tune rules before they reach live tenants.
How do I tune rules for read-heavy monitoring and backup tools?
Read-heavy tools such as posture management scanners, backup software and cost tools generate large volumes of list and describe calls that look like discovery. Identify each tool's service principal, its source network and its usual schedule, then suppress or lower the severity of its activity only when all of those attributes match. Do not suppress by principal name alone, because a compromised tool credential would then go unseen. Review suppressions on a fixed schedule, and alert when a suppressed principal starts calling APIs it has never used or runs outside its window. Keep a written record of each exception and its owner.
What should I confirm with my cloud provider about log availability?
Confirm which management and data events are recorded by default, which require explicit configuration, and whether read-only API calls are included in the trail. Ask about retention periods, delivery latency, whether logs can be exported to your own storage, and whether they can be made immutable. Also confirm whether logs for some services or regions are delivered to a different location, and whether there are limits on the volume you can query. Get the answers in writing from the provider's current documentation or account team, since logging behavior changes over time and differs between providers.
Can my own team run T1580 detection work, or is outside help needed?
A team that already operates its cloud logging, SIEM and identity platform can usually build and test the basic rules internally, provided it has time, a test environment and clear ownership of the baseline. The work that tends to take the most effort is the baseline itself, the cross-account normalization and the range exercises that prove the rules fire. DeployOpen implements open-source detection platforms in the client's own environment and runs cyber range exercises, and engagements are fixed-scope, with the scope agreed in writing before work starts. Ask any provider to state which of these items it covers, who owns the outputs and how the handover is documented.
How DeployOpen builds T1580 detections and cyber range scenarios
DeployOpen starts every T1580 detection engagement with a written, fixed scope that names the cloud accounts, regions, IaaS services and identity providers in play, the log sources the client can actually export, and the ATT&CK version the mapping will target. Because ATT&CK releases can rename, deprecate or revoke techniques, the scope records the version explicitly, such as Enterprise ATT&CK 20.0, so the detection mapping stays traceable. The client's own environment and the written scope define the work: which control plane audit events are in scope, who approves changes to logging, and which accounts may be used during testing. Confirm these decisions with your cloud platform team before any rule is written.
Implementation then focuses on collection and rules that run inside your environment. For T1580 this usually means ingesting cloud control plane audit trails for instance enumeration, storage listing and instance metadata access into your existing pipeline, often Wazuh or a Security Onion deployment, and writing Sigma-style rules that flag unusual volumes of describe or list calls by a single principal, calls from unfamiliar source networks, and enumeration bursts across several regions. Baselines are built from a period of normal administrative activity, and thresholds are tuned with the operations team so that infrastructure automation does not generate alerts every hour. Ask the provider to show how each rule is versioned and where the detection logic is stored.
Purple team exercises then test whether those rules fire under realistic operator conditions. DeployOpen plans them with your detection, cloud and incident response staff, and runs the range scenarios in a private cyber range that mirrors your account structure without touching production data. Scenarios are illustrative of the behaviour to be tested, such as a low-privilege role listing instances and storage buckets across regions, and each scenario records expected alerts, actual alerts and time to triage. Hand-over includes the rule set, data source mappings, tuning notes, runbooks for triage and response, and the test evidence. Ongoing testing and upgrades are available as retainers. Confirm the handover format, support terms and any compliance evidence needs in the written quote.
