AN0692: Analytic 0692
IAAS (Cloud images/VMs): A new VM/instance is launched from a non-approved or newly-seen image (AMI/GCP Image/Azure Image). On first boot, cloud-init/user-data or embedded agents download code, spawn system utilities, or open outbound C2/mining traffic. The analytic correlates Instance/Image Creation → Instance Start → in-guest Process/Command Execution and/or anomalous network traffic.
Analyst context for executives and security teams
This analytic matters because cloud VM images can become a hidden path to rapid compromise or policy drift: a new instance launched from an unapproved or never-before-seen image may execute boot-time code, run unexpected commands, or generate suspicious outbound traffic as soon as it starts. For leaders, the decision point is whether the organization can prove which images are approved, detect exceptions quickly, and correlate cloud control-plane activity with what happens inside the guest system.
Executive priority
Prioritize this as a cloud governance and incident-readiness control. The business risk is not just the launch of a VM; it is the possibility that an unauthorized image becomes a repeatable deployment source for unwanted code, unmanaged agents, or outbound command-and-control/mining-like traffic. Executives should ask whether image approval is enforced, whether new or newly-seen images are reviewed, and whether SOC teams can connect instance/image creation, instance start events, endpoint activity, and network behavior into one investigation trail.
Technical view
For Windows cloud VMs, validate whether detections can correlate three evidence layers: cloud control-plane events for image or instance creation, instance start activity, and in-guest process/command execution and/or anomalous outbound network traffic. The supplied ATT&CK object does not provide a formal detection rule, so teams should treat this as an analytic design pattern: identify instances launched from non-approved or newly-observed images, then enrich with first-boot execution activity such as cloud-init/user-data or embedded agent behavior where available, plus outbound traffic anomalies. Because no ATT&CK tactics or relationships are supplied, local cloud inventory, image allowlists, and baseline behavior are required to make the analytic actionable.
Likely telemetry
- Cloud control-plane logs for image creation, instance creation, and instance start events
- Cloud asset inventory showing image IDs, image age, ownership, approval status, and first-seen timestamps
- Guest operating system process and command execution telemetry from Windows instances
- Boot-time or provisioning metadata where available, including user-data or agent-driven startup activity
- Network telemetry for outbound connections from newly started instances
Detection direction
- Build or validate correlation from image/instance creation to instance start to early in-guest execution and outbound network behavior.
- Tune around approved image catalogs and known automation pipelines to reduce false positives from legitimate golden-image updates, autoscaling, and CI/CD infrastructure.
- Flag non-approved, newly-seen, or unusual image sources for review before relying only on post-boot behavior.
- Pay special attention to the first boot window, where embedded agents, user-data, or initialization logic may execute before routine monitoring is fully active.
- Confirm telemetry coverage for Windows guest execution; cloud control-plane visibility alone may show that an instance started but not what it executed.
Mitigation priorities
- Maintain and enforce an approved image catalog for cloud VM deployments.
- Require governance review or automated policy checks for newly-seen or non-approved images.
- Ensure Windows VM endpoint telemetry is active early enough to capture first-boot process and command execution.
- Centralize cloud control-plane, endpoint, and network logs so incident responders can reconstruct the launch-to-execution sequence.
- Use network egress monitoring and policy controls to identify or restrict unexpected outbound traffic from newly launched instances.
Analyst notes and limits
This is an ATT&CK detection analytic, not a technique description. Its value is in validating cross-domain visibility: cloud image provenance, VM lifecycle events, guest execution, and network behavior. The object specifically references IaaS cloud images/VMs and examples such as AMI, GCP Image, and Azure Image, while the supplied platform field is Windows. Treat the platform scope conservatively as Windows guest workload visibility within cloud VM environments.
The official detection field is not provided, tactics are not specified, and no relationship context was supplied. This take does not assert active exploitation, attribution, impact, or guaranteed detection. Local cloud architecture, approved image policy, logging configuration, and endpoint coverage determine whether this analytic can be implemented effectively.
Analytic 0692
IAAS (Cloud images/VMs): A new VM/instance is launched from a non-approved or newly-seen image (AMI/GCP Image/Azure Image). On first boot, cloud-init/user-data or embedded agents download code, spawn system utilities, or open outbound C2/mining traffic. The analytic correlates Instance/Image Creation → Instance Start → in-guest Process/Command Execution and/or anomalous network traffic.
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 | 6d3459fab9e4… |
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 AN0692Open 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.