---
{
  "title": "Cloud Infrastructure Discovery",
  "summary": "Cloud infrastructure discovery enumerates resources such as instances, networks, and storage relationships.",
  "topic": "forensics",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1580"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1580: Cloud Infrastructure Discovery",
      "url": "https://attack.mitre.org/techniques/T1580"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Cloud infrastructure discovery enumerates resources such as instances, networks, and storage relationships. It can reveal valuable targets and possible access paths.


## An investigation example

An unusual identity lists infrastructure broadly, then acts on a few selected compute resources.

## Evidence to examine

Review inventory API activity, caller role, enumeration scope, resource relationships, and follow-on operations.

## A common analytical pitfall

Resource visibility does not automatically imply permission to modify or retrieve every listed resource.

## Response considerations

Preserve the query-to-action sequence and assess effective permissions and unnecessary inventory exposure in context.


## Resource metadata can reveal the environment's shape

Cloud infrastructure discovery examines components such as compute instances, storage, networks, snapshots, and databases. The information can expose relationships and potential targets. Visibility depends on the querying identity's permissions and the provider's interfaces. A successful listing does not automatically grant permission to read stored data or change the resource.

Different queries have different scope. A response may cover one project, region, subscription, or resource type rather than the whole organization. Record that context when estimating impact. Resource names and tags can also be incomplete or stale, so they should not be treated as authoritative business ownership without verification.

## A fictional unusual inventory

An academy's cloud audit trail shows a reporting identity enumerating storage and compute resources outside its normal workload. A later event attempts to modify a storage setting. Analysts preserve the request identities, scope, outcomes, and session context, then compare the activity with approved automation and recent changes.

The listing is discovery; the modification attempt is a separate behavior. A denied change can demonstrate that an authorization boundary held, while still providing evidence of concerning intent. Review how the identity's credentials were used and whether its visibility and action permissions fit its purpose. Avoid automatically granting broad reader roles merely because they cannot modify resources.

## Map one fictional identity

Draw a cloud project with an application, database, storage bucket, and backup snapshot. Mark which metadata a service identity can list and which content or settings it can access. Identify the audit events that would show each operation. Use a training tenant or paper model rather than querying an unfamiliar account.

Consider data sensitivity in resource metadata itself. Names, tags, and configuration can reveal internal structure even without customer records. A proportionate access review should therefore consider both discovery capability and modification authority, while preserving the visibility legitimate operations need.

## Related concepts

- [[digital-forensics]]
- [[incident-timeline]]
- [[logs-and-telemetry]]
- [[active-scanning]]
- [[cloud-service-discovery]]