Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1578: Modify Cloud Compute Infrastructure

An adversary may attempt to modify a cloud account's compute service infrastructure to evade defenses. A modification to the compute service infrastructure can include the creation, deletion, or modification of one or more components such as compute instances, virtual machines, and snapshots.

Permissions gained from the modification of infrastructure components may bypass restrictions that prevent access to existing infrastructure. Modifying infrastructure components may also allow an adversary to evade detection and remove evidence of their presence.[1]

EnterpriseT1578TechniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Modify Cloud Compute Infrastructure matters because it turns normal cloud administration capabilities into a way to evade defenses. If an adversary can create, delete, revert, or modify cloud compute resources, they may bypass restrictions on existing infrastructure or remove evidence that responders need. For leaders, this is less about a single server change and more about whether cloud control-plane activity is governed, logged, and reviewable during an incident.

Executive priority

Prioritize this as a cloud resilience and evidence-preservation issue for IaaS environments. The key business questions are: who can change compute infrastructure, are those changes audited, and can incident responders reconstruct what happened if instances, snapshots, or configurations are altered or deleted? This technique supports decisions around least privilege, account lifecycle governance, cloud audit readiness, and response playbooks for potentially tampered compute resources.

Technical view

This enterprise ATT&CK technique applies to IaaS and is mapped to defense impairment. SOC, detection engineering, and IR teams should validate visibility into cloud compute control-plane actions involving instance creation, deletion, reversion, snapshot activity, and compute configuration changes. The related sub-techniques provide useful scoping: Create Snapshot, Create Cloud Instance, Delete Cloud Instance, Revert Cloud Instance, and Modify Cloud Compute Configurations. Official ATT&CK detection text is not provided, so teams should use local cloud audit data, account-permission context, and the related DET0308 detection strategy if available to define concrete analytics.

Likely telemetry

  • Cloud control-plane audit logs for compute service API and console activity
  • Records of compute instance or virtual machine creation, deletion, modification, and reversion
  • Snapshot, volume, virtual disk, or backup creation and restoration events
  • Cloud identity and account activity tied to users, roles, service accounts, or administrative sessions
  • Configuration change records for compute quotas, subscription associations, tenant-wide policies, or other compute-impacting settings

Detection direction

  • Confirm that cloud audit logging is enabled and retained for IaaS compute management activity, not only workload-level operating system logs.
  • Baseline expected administrative patterns for compute changes and alert on unusual users, roles, times, regions, accounts, or rapid create/delete/revert sequences.
  • Correlate compute infrastructure changes with identity context and authorization changes, since the related mitigation emphasizes user account management and least privilege.
  • Treat deletion or reversion of instances and snapshots as potential evidence-risk events, especially when they occur after suspicious activity or outside approved change processes.
  • Tune detections to reduce false positives from approved automation, maintenance, scaling, backup, and disaster recovery workflows while preserving visibility into who or what initiated the change.

Mitigation priorities

  • Enforce user account management and least privilege for accounts, roles, and service identities that can create, delete, revert, snapshot, or modify cloud compute infrastructure.
  • Use auditing as a primary control: record cloud control-plane activity and systematically review compute infrastructure changes for anomalies and compliance evidence.
  • Define change-management expectations for high-risk compute actions such as instance deletion, snapshot creation, restoration, and tenant or quota changes.
  • Ensure incident response procedures account for evidence loss when cloud instances are deleted or reverted, including retention of audit records independent of the affected compute resource.
  • Regularly review privileged cloud accounts and deprovision or modify access when roles change or accounts are no longer needed.
Analyst notes and limits

The ATT&CK object describes a parent technique with five related sub-techniques that clarify the main behavior categories. The supplied relationship context identifies User Account Management and Audit as mitigations, which makes identity governance and control-plane logging the most defensible priorities. The Mandiant M-Trends 2020 reference is cited by ATT&CK, but the supplied fields do not provide enough detail to make claims about specific campaigns, prevalence, or active exploitation.

Official ATT&CK detection guidance for this object is not provided in the supplied fields. Platform scope is limited to IaaS. Detection feasibility depends on local cloud audit configuration, retention, identity model, automation patterns, and whether deleted or reverted resources leave sufficient independent records for investigation.

Official MITRE ATT&CK definition

Modify Cloud Compute Infrastructure

An adversary may attempt to modify a cloud account's compute service infrastructure to evade defenses. A modification to the compute service infrastructure can include the creation, deletion, or modification of one or more components such as compute instances, virtual machines, and snapshots.

Permissions gained from the modification of infrastructure components may bypass restrictions that prevent access to existing infrastructure. Modifying infrastructure components may also allow an adversary to evade detection and remove evidence of their presence.[1]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

5 rows
Domain ID Name Relationship / procedure
Enterprise T1578.001 Create Snapshot Sub-technique Create Snapshot subtechnique of this object.
Enterprise T1578.003 Delete Cloud Instance Sub-technique Delete Cloud Instance subtechnique of this object.
Enterprise T1578.004 Revert Cloud Instance Sub-technique Revert Cloud Instance subtechnique of this object.
Enterprise T1578.002 Create Cloud Instance Sub-technique Create Cloud Instance subtechnique of this object.
Enterprise T1578.005 Modify Cloud Compute Configurations Sub-technique Modify Cloud Compute Configurations subtechnique of this object.
Relationship explorer

All related ATT&CK context

subtechnique of · Technique T1578.001: Create Snapshot Enterprise mitigates · Mitigation M1018: User Account Management Enterprise detects · Detection Strategy DET0308: Detection Strategy for Modify Cloud Compute Infrastructure Enterprise subtechnique of · Technique T1578.003: Delete Cloud Instance Enterprise subtechnique of · Technique T1578.004: Revert Cloud Instance Enterprise mitigates · Mitigation M1047: Audit Enterprise subtechnique of · Technique T1578.002: Create Cloud Instance Enterprise subtechnique of · Technique T1578.005: Modify Cloud Compute Configurations Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Mitigation Enterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
b98e37581eb8b35a...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle b98e37581eb8…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Mandiant M-Trends 2020

    Mandiant. (2020, February). M-Trends 2020. Retrieved November 17, 2024.

    Open source URL
  2. [2]
    mitre-attack T1578
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use