T1578.005: Modify Cloud Compute Configurations
Adversaries may modify settings that directly affect the size, locations, and resources available to cloud compute infrastructure in order to evade defenses. These settings may include service quotas, subscription associations, tenant-wide policies, or other configurations that impact available compute. Such modifications may allow adversaries to abuse the victim’s compute resources to achieve their goals, potentially without affecting the execution of running instances and/or revealing their activities to the victim.
For example, cloud providers often limit customer usage of compute resources via quotas. Customers may request adjustments to these quotas to support increased computing needs, though these adjustments may require approval from the cloud provider. Adversaries who compromise a cloud environment may similarly request quota adjustments in order to support their activities, such as enabling additional Resource Hijacking without raising suspicion by using up a victim’s entire quota.[1] Adversaries may also increase allowed resource usage by modifying any tenant-wide policies that limit the sizes of deployed virtual machines.[2]
Adversaries may also modify settings that affect where cloud resources can be deployed, such as enabling Unused/Unsupported Cloud Regions.
Analyst context for executives and security teams
This technique matters because an attacker with enough cloud permissions may change compute-level guardrails—such as quotas, subscription associations, tenant-wide policies, or allowed deployment locations—to make misuse of cloud resources harder to notice. For leaders, the issue is not only whether workloads are running securely, but whether the controls that limit compute growth, region use, and resource sizing can be changed without timely review.
Executive priority
Prioritize this as a cloud governance and resilience risk. Changes to compute limits or deployment policies can affect cost exposure, defensive visibility, compliance evidence, and the organization’s ability to prove that cloud resources are constrained by approved policy. Executives should ask who can request or approve quota and policy changes, how those changes are audited, and whether SOC and cloud operations teams receive actionable alerts when compute guardrails are modified.
Technical view
This is an IaaS defense-impairment sub-technique under Modify Cloud Compute Infrastructure. SOC, cloud security, and IR teams should validate monitoring for administrative changes that affect available compute capacity, allowed VM sizes, tenant-wide compute policies, subscription associations, and enabled or newly used cloud regions. Because ATT&CK does not provide official detection text for this object, detection engineering should be driven by cloud control-plane audit data and the related DET0492 detection strategy where available. Investigations should correlate configuration changes with the acting identity, approval workflow, timing, affected subscription or tenant scope, and subsequent compute activity.
Likely telemetry
- Cloud control-plane audit logs for compute quota, policy, subscription, and region-related changes
- Identity and access management logs showing the user, role, service principal, or automation account performing the change
- Cloud policy configuration history and change records
- Quota request and approval records where available
- Compute deployment metadata showing new instance sizes, locations, or resource growth after configuration changes
Detection direction
- Alert on changes to tenant-wide or subscription-level compute policies, quota limits, allowed VM sizes, and enabled deployment regions, especially outside approved change windows.
- Correlate compute configuration changes with the identity and privilege path used, including whether the actor normally administers those settings.
- Tune for legitimate cloud operations activity by comparing against approved change records and known capacity planning events.
- Look for relationship-driven context: changes that enable additional compute may precede or support Resource Hijacking or use of Unused/Unsupported Cloud Regions, both referenced by the ATT&CK description.
- Validate that logs cover the management plane, not only running workload telemetry; this technique may not affect existing instances directly.
Mitigation priorities
- Enforce user account management and least privilege for identities that can modify compute quotas, tenant-wide policies, subscription associations, and region settings.
- Require review or approval workflows for changes that expand compute capacity or deployment locations.
- Audit cloud configuration changes regularly and retain evidence suitable for investigation and compliance review.
- Separate routine workload administration from permissions that alter organization-wide compute guardrails.
- Periodically compare current compute policies and quotas against approved baselines to identify drift.
Analyst notes and limits
The supplied ATT&CK object is focused on IaaS cloud environments and the defense-impairment tactic. The strongest practical takeaway is that cloud compute governance settings are security controls, not just operational preferences. Detection and response readiness depends on whether the organization can observe and explain changes to those settings with identity context and approved business justification.
MITRE provides no official detection text for this technique in the supplied fields. The external references are Microsoft-focused examples, but the ATT&CK platform is IaaS, so local implementation will vary by provider and logging configuration. No claim is made here about active exploitation, specific attribution, or guaranteed detection coverage.
Modify Cloud Compute Configurations
Adversaries may modify settings that directly affect the size, locations, and resources available to cloud compute infrastructure in order to evade defenses. These settings may include service quotas, subscription associations, tenant-wide policies, or other configurations that impact available compute. Such modifications may allow adversaries to abuse the victim’s compute resources to achieve their goals, potentially without affecting the execution of running instances and/or revealing their activities to the victim.
For example, cloud providers often limit customer usage of compute resources via quotas. Customers may request adjustments to these quotas to support increased computing needs, though these adjustments may require approval from the cloud provider. Adversaries who compromise a cloud environment may similarly request quota adjustments in order to support their activities, such as enabling additional Resource Hijacking without raising suspicion by using up a victim’s entire quota.[1] Adversaries may also increase allowed resource usage by modifying any tenant-wide policies that limit the sizes of deployed virtual machines.[2]
Adversaries may also modify settings that affect where cloud resources can be deployed, such as enabling Unused/Unsupported Cloud Regions.
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.
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1578 | Modify Cloud Compute Infrastructure | This object subtechnique of Modify Cloud Compute Infrastructure. |
All related ATT&CK context
Mitigation direction
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 | 3.0 | Current bundle | f193fd730a07… |
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]
Microsoft Cryptojacking 2023
Microsoft Threat Intelligence. (2023, July 25). Cryptojacking: Understanding and defending against cloud compute resource abuse. Retrieved September 5, 2023.
Open source URL -
[2]
Microsoft Azure Policy
Microsoft. (2023, August 30). Azure Policy built-in policy definitions. Retrieved September 5, 2023.
Open source URL -
[3]
mitre-attack T1578.005Open 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.