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

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.

EnterpriseT1578.005Sub-techniqueObject v3.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

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.

Official MITRE ATT&CK definition

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.

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1578 Modify Cloud Compute Infrastructure This object subtechnique of Modify Cloud Compute Infrastructure.
Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

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
3.0
Created
Modified
Raw hash
f193fd730a07b2be...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 3.0 Current bundle f193fd730a07…
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.

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]
    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. [2]
    Microsoft Azure Policy

    Microsoft. (2023, August 30). Azure Policy built-in policy definitions. Retrieved September 5, 2023.

    Open source URL
  3. [3]
    mitre-attack T1578.005
    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.