DET0449: Detection Strategy for Modify Cloud Compute Infrastructure: Create Cloud Instance
DET0449 is a MITRE detection strategy object for detecting Create Cloud Instance behavior, linked to ATT&CK technique T1578.002. The business significance...
Analyst context for executives and security teams
DET0449 is a MITRE detection strategy object for detecting Create Cloud Instance behavior, linked to ATT&CK technique T1578.002. The business significance is that unauthorized or unexpected cloud instance creation can let an adversary operate from new infrastructure inside an IaaS account and potentially bypass controls applied to existing instances. For leaders, this is less about a single alert and more about whether cloud governance, SOC visibility, and incident response processes can quickly distinguish approved scaling or deployment activity from suspicious compute creation.
Executive priority
Prioritize this as a cloud control-validation and audit-evidence issue: can the organization prove who can create IaaS compute, when new instances are created, and whether those instances inherit expected network, identity, and security controls? Because the related technique is categorized under defense impairment, executives should ask whether new cloud resources can appear without detection, tagging, ownership, logging, or baseline security enforcement. This matters for operational resilience, incident scoping, and compliance readiness in cloud environments.
Technical view
The supplied ATT&CK object does not include official detection logic, platforms, or tactics, but it detects T1578.002 Create Cloud Instance, whose related platform is IaaS and tactic is defense-impairment. SOC and detection teams should validate visibility into cloud control-plane events for compute instance or VM creation, correlate those events with identity context, change-management records, network/security policy assignments, and any snapshot or volume-mount activity where available. IR teams should be prepared to determine whether a new instance was approved, who created it, what credentials or roles were used, what security groups or firewall policies were attached, and whether it was used to access data or evade existing host-based controls.
Likely telemetry
- Cloud control-plane audit logs for compute instance or VM creation events
- Cloud identity and access logs showing the principal, role, session, and source context used to create the instance
- Configuration and asset inventory records for newly created compute resources
- Network/security policy assignment records, such as firewall or security group attachment changes
- Volume, snapshot, or storage attachment logs where collected
Detection direction
- Validate that instance-creation events are collected centrally and retained long enough for incident investigation.
- Tune detections to compare new instance creation against approved automation, deployment windows, expected accounts, regions, projects, and owners.
- Prioritize anomalies involving unusual identities, roles, regions, source locations, security policy changes, or missing asset tags.
- Correlate new instances with permissive network/security settings or storage attachments, since the related technique notes potential bypass of controls on existing instances.
- Account for false positives from autoscaling, disaster recovery, CI/CD, and infrastructure-as-code workflows; require allowlisting to be specific and auditable.
Mitigation priorities
- Establish least-privilege controls over who and what can create IaaS compute resources.
- Require centralized cloud audit logging and asset inventory for all accounts or projects where compute can be created.
- Enforce baseline security policies for new instances, including ownership metadata, approved network policy, and monitoring enrollment.
- Use change-management or infrastructure-as-code records to create a defensible baseline of expected instance creation.
- Review permissions and guardrails regularly, especially for roles used by automation and administrators.
Analyst notes and limits
This take is based on DET0449 and its relationship to T1578.002 Create Cloud Instance. MITRE provides no official description or detection text for DET0449 in the supplied fields, so the practical guidance is derived from the relationship context and kept at a control-validation level. Local cloud architecture, logging configuration, and approved deployment patterns are required to turn this into reliable detections.
The detection strategy object has no official detection content, no specified platforms, and no specified tactics. The only platform and tactic context comes from the related ATT&CK technique: IaaS and defense-impairment. No active exploitation, attribution, or guaranteed detection coverage is implied.
Detection Strategy for Modify Cloud Compute Infrastructure: Create Cloud Instance
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 | T1578.002 | Create Cloud Instance Sub-technique | This object detects Create Cloud Instance. |
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 | 2036549b5d9c… |
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 DET0449Open 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.