DET0169: Detection Strategy for Cloud Infrastructure Discovery
This detection strategy matters because cloud infrastructure discovery is often how an intruder or misused identity learns what IaaS resources exist before...
Analyst context for executives and security teams
This detection strategy matters because cloud infrastructure discovery is often how an intruder or misused identity learns what IaaS resources exist before deciding what to access, copy, disrupt, or further abuse. Even though this ATT&CK detection-strategy object does not provide official detection logic, its relationship to Cloud Infrastructure Discovery (T1580) points leaders and defenders toward a practical question: can the organization see and explain cloud API or CLI activity that enumerates instances, virtual machines, snapshots, storage, databases, and similar resources?
Executive priority
Treat this as a cloud visibility and identity-governance priority rather than a single alert rule. Security leaders should confirm whether cloud audit logs, identity context, and SOC workflows can distinguish expected administrative inventory activity from unusual discovery. This supports incident response scoping, audit evidence for cloud monitoring, and prioritization of least-privilege access to IaaS inventory APIs.
Technical view
The supplied relationship states that DET0169 detects T1580: Cloud Infrastructure Discovery, a discovery technique for IaaS environments. SOC and detection engineering teams should validate monitoring around cloud provider APIs and CLI-driven enumeration of compute, snapshot, storage, and database resources. Because the ATT&CK object provides no official detection text, teams should derive local analytics from observed administrative baselines, cloud audit events, user/service-account context, source location, session patterns, and the sensitivity of the enumerated resource types.
Likely telemetry
- Cloud provider audit logs for API calls and CLI-backed actions
- Identity and access logs for users, roles, and service accounts
- Cloud control-plane events related to listing or describing compute resources, virtual machines, snapshots, storage, and databases
- Session context such as source IP, user agent, authentication method, and assumed role details where available
- Change-management or administrative activity records to separate approved inventory work from suspicious discovery
Detection direction
- Validate that IaaS control-plane logging is enabled and retained for resource-enumeration activity.
- Baseline normal discovery activity by cloud administrators, automation, inventory tools, and managed services to reduce false positives.
- Prioritize anomalies involving newly created identities, unusual roles, unexpected source locations, rare user agents, or broad enumeration across multiple service categories.
- Correlate discovery events with preceding authentication changes or subsequent access to sensitive resources to improve incident triage.
- Account for blind spots where logs are not centralized, service-account activity is poorly attributed, or legitimate automation performs frequent enumeration.
Mitigation priorities
- Ensure cloud identities and service accounts have least-privilege permissions for infrastructure inventory and discovery APIs.
- Centralize and retain cloud control-plane audit logs so IR teams can reconstruct enumeration activity.
- Require strong identity controls for privileged cloud roles, including review of who can list or describe sensitive resources.
- Document expected administrative and automation discovery patterns to support SOC tuning and compliance evidence.
- Use incident response runbooks that treat unusual infrastructure discovery as a potential scoping signal, not proof of compromise by itself.
Analyst notes and limits
This take is based on the official ATT&CK detection-strategy object DET0169 and its relationship indicating it detects T1580 Cloud Infrastructure Discovery. The most decision-useful context comes from the related technique: adversaries may use cloud provider APIs or CLIs to discover IaaS resources such as instances, virtual machines, snapshots, storage, and databases.
The object has no official description, no official detection text, no specified tactics, and no specified platforms. The IaaS and discovery context comes from the related T1580 technique, not from DET0169’s own platform or tactic fields. Local cloud providers, logging configuration, identity model, and administrative baselines are required before writing production detections or assessing coverage.
Detection Strategy for Cloud Infrastructure Discovery
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1580 | Cloud Infrastructure Discovery | This object detects Cloud Infrastructure Discovery. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 27558243a241… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0169Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.