AN1103: Analytic 1103
Adversary uses cloud-native APIs or CLI (e.g., AWS Systems Manager, Azure Resource Graph) to list installed software on cloud workloads.
Analyst context for executives and security teams
This analytic is about recognizing when someone uses cloud-native APIs or command-line tools to enumerate installed software on IaaS workloads. For leaders, the significance is not the software inventory query by itself; it is that the same visibility used by administrators can help an intruder understand what systems exist, what software may be vulnerable, and where to focus next. Coverage depends heavily on whether cloud control-plane activity is logged and reviewed.
Executive priority
Prioritize this as a cloud security and incident-response readiness question: can the organization prove who queried workload software inventory, from where, and for what purpose? This matters for vulnerability prioritization, audit evidence, and containment decisions because software inventory access can reveal exploitable exposure across cloud workloads. Security leaders should ask whether cloud API and CLI usage is centrally logged, tied to identities, retained long enough for investigations, and reviewed for unusual access patterns.
Technical view
The supplied ATT&CK object is an IaaS detection analytic for cloud-native API or CLI use, such as AWS Systems Manager or Azure Resource Graph, to list installed software on cloud workloads. Because no official detection logic is provided, SOC and detection teams should validate the underlying telemetry first: cloud control-plane/API audit logs, CLI-originated activity where available, identity context, target workload scope, and inventory-query events. Detection should focus on unusual software inventory enumeration relative to normal administrative, vulnerability management, and asset management activity.
Likely telemetry
- Cloud control-plane audit logs for IaaS APIs
- Cloud CLI/API request metadata, including caller identity, source location, user agent, and timestamp
- Inventory or resource graph query logs where available
- Identity and access management logs for principals authorized to query workload inventory
- Asset, vulnerability management, or configuration management records to establish expected inventory activity
Detection direction
- Baseline expected software inventory queries from administration, vulnerability management, compliance, and asset management processes before alerting aggressively.
- Look for unusual principals, source locations, automation accounts, time windows, regions, accounts, subscriptions, or projects performing broad inventory enumeration.
- Correlate inventory queries with identity events such as new credentials, changed permissions, or unusual API access patterns when local telemetry supports it.
- Tune false positives for legitimate cloud operations, patching, compliance scans, and inventory reconciliation jobs.
- Identify blind spots where cloud API logs, resource graph queries, or systems management inventory events are not enabled, not centralized, or not retained.
Mitigation priorities
- Confirm least-privilege access for identities allowed to query installed software inventory on IaaS workloads.
- Centralize and retain cloud API, CLI, and inventory-query logs for SOC monitoring and incident response.
- Separate normal inventory tooling identities from human administrator identities so anomalous use is easier to detect.
- Review permissions for systems management, resource graph, and inventory services as part of cloud security governance.
- Use asset and vulnerability management processes to define legitimate inventory behavior and support alert tuning.
Analyst notes and limits
This Glexia take is based only on the supplied ATT&CK analytic AN1103. The object describes cloud-native API or CLI enumeration of installed software on IaaS workloads and gives examples of AWS Systems Manager and Azure Resource Graph. No tactics, relationships, labels, or official detection text were supplied, so recommendations are framed as validation and readiness guidance rather than a specific detection rule.
The source object does not provide official detection logic, event IDs, query syntax, data component mappings, related techniques, or threat group context. Local cloud provider configuration, enabled logging, IAM design, and normal administrative workflows are required to determine detection feasibility and priority.
Analytic 1103
Adversary uses cloud-native APIs or CLI (e.g., AWS Systems Manager, Azure Resource Graph) to list installed software on cloud workloads.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 02d600071661… |
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 AN1103Open 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.