AN1318: Analytic 1318
Cause→effect chain in cloud consoles: (1) user clicks link then invokes instance/image creation via API, (2) instance/image originates from external AMI or unknown image, (3) instance immediately egresses or retrieves payloads.
Analyst context for executives and security teams
AN1318 highlights a cloud-risk pattern where a user interaction in a cloud console is followed by instance or image creation from an external or unknown AMI/image, and the new workload quickly reaches out to the internet or retrieves payloads. For leaders, the value is not the single API call; it is the chain of events that can indicate risky or unauthorized cloud workload introduction requiring fast validation.
Executive priority
Treat this as a cloud security and incident-readiness validation point. Executives and risk owners should ask whether teams can correlate console activity, image provenance, workload creation, and immediate network egress quickly enough to support containment decisions, audit evidence, and cloud control prioritization. The business issue is uncontrolled IaaS workload launch from untrusted image sources, which can create exposure before normal review processes catch up.
Technical view
For SOC, cloud security, and IR teams, validate whether IaaS telemetry can reconstruct the described cause-and-effect chain: user clicks or console session activity, API invocation for instance/image creation, image or AMI source classification as external or unknown, and near-immediate outbound network activity or payload retrieval by the new instance. Because ATT&CK provides no official detection logic for this analytic, local implementation should focus on correlation timing, trusted image baselines, identity context, and network behavior after workload creation.
Likely telemetry
- Cloud console audit logs and session activity
- Cloud control-plane API logs for instance and image creation
- Image or AMI metadata, ownership, and allowlist status
- Identity and access context for the user or role invoking creation APIs
- Network flow logs or egress telemetry from newly created instances
Detection direction
- Build correlation around the full sequence rather than alerting on a single event: console activity or user interaction, instance/image creation, untrusted image provenance, then rapid egress or payload retrieval.
- Maintain a known-good inventory of approved AMIs/images so external or unknown image use can be distinguished from sanctioned operations.
- Tune timing windows carefully: too narrow may miss delayed payload retrieval; too broad may increase false positives from normal provisioning workflows.
- Add identity and change-management context to reduce noise from approved administrators, automation, or infrastructure-as-code pipelines.
- Review blind spots where console logs, API logs, image metadata, or workload egress telemetry are retained in separate tools and cannot be joined during an investigation.
Mitigation priorities
- Define and enforce approved image or AMI sources for IaaS workload creation where business processes allow.
- Restrict who can create instances or images from external or unknown sources using least-privilege identity and access controls.
- Require logging for cloud control-plane activity, image provenance, and network egress from newly created workloads.
- Use egress controls and monitoring so new instances cannot freely retrieve payloads without visibility or policy review.
- Document investigation playbooks for newly created workloads with suspicious image provenance and immediate outbound activity.
Analyst notes and limits
This object is a detection analytic, not a technique or procedure. Its main decision value is as a correlation use case for cloud detection engineering and incident response readiness. Since no ATT&CK relationships or tactics were supplied, the take avoids mapping it to a specific adversary behavior beyond the official cause-effect chain.
Official detection content was not provided, tactics were not specified, and no relationship context was supplied. Local cloud architecture, logging coverage, image governance, and approved provisioning workflows are required to determine severity, tuning, and response actions.
Analytic 1318
Cause→effect chain in cloud consoles: (1) user clicks link then invokes instance/image creation via API, (2) instance/image originates from external AMI or unknown image, (3) instance immediately egresses or retrieves payloads.
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 | ec0afc4a1653… |
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 AN1318Open 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.