T1651: Cloud Administration Command
Adversaries may abuse cloud management services to execute commands within virtual machines. Resources such as AWS Systems Manager, Azure RunCommand, and Runbooks allow users to remotely run scripts in virtual machines by leveraging installed virtual machine agents. [1][2]
If an adversary gains administrative access to a cloud environment, they may be able to abuse cloud management services to execute commands in the environment’s virtual machines. Additionally, an adversary that compromises a service provider or delegated administrator account may similarly be able to leverage a Trusted Relationship to execute commands in connected virtual machines.[3]
Analyst context for executives and security teams
Cloud Administration Command matters because normal cloud management features can become a remote execution path into virtual machines when an adversary obtains administrative, service provider, or delegated administrator access. For leaders, this is not just a VM security issue; it is an identity, privilege, cloud operations, and incident response readiness issue because the activity may look like legitimate administration.
Executive priority
Prioritize validation of who can run cloud-native VM commands, how those actions are approved, and whether they are logged well enough for incident reconstruction. This technique should influence privileged access reviews, delegated administration governance, cloud audit evidence, and response playbooks for suspected cloud account compromise. The ATT&CK relationships to Privileged Account Management and to known groups/tools make it material for control assurance, but local exposure depends on whether IaaS management agents and command services are enabled.
Technical view
For IaaS environments, SOC and IR teams should validate visibility into cloud management services that execute scripts or commands inside VMs, such as AWS Systems Manager Run Command, Azure RunCommand, and Runbooks as named in the ATT&CK description. Detection should focus on administrative command execution events, the identity or delegated administrator context that initiated them, target VM scope, timing, command metadata where available, and follow-on host activity. Because MITRE provides no official detection text for this technique, teams should use the related DET0545 detection strategy as a mapping anchor while testing their own telemetry and alert logic.
Likely telemetry
- Cloud control-plane audit logs for VM command or script execution requests
- Identity and access management logs for privileged, administrative, service provider, or delegated administrator accounts
- Cloud management service logs from AWS Systems Manager, Azure RunCommand, or Runbooks where used
- VM agent activity and host logs showing remotely initiated script or command execution
- Authorization, role assignment, and privileged access review records
Detection direction
- Validate alerts for unusual or high-risk use of cloud administration command services, especially outside normal change windows or by rarely used privileged identities.
- Correlate command execution events with recent privilege changes, delegated administration activity, or new access paths.
- Tune for false positives from legitimate operations teams, automation, and maintenance workflows by baselining approved administrators, systems, and schedules.
- Confirm logs preserve enough context for investigation: initiating identity, source context, target VM, service used, time, and command or runbook reference where available.
- Account for relationship context: ATT&CK links this technique to AADInternals and Pacu, so cloud and identity detections should consider abuse of administrative or exploitation frameworks without assuming their presence.
Mitigation priorities
- Start with Privileged Account Management: enforce least privilege and restrict who can use cloud services capable of running commands inside VMs.
- Review administrative, service provider, and delegated administrator access paths for excessive scope or weak accountability.
- Require logging and auditing for privileged cloud management actions and retain evidence sufficient for compliance and incident response.
- Separate routine automation from emergency or break-glass command execution so anomalous use is easier to identify.
- Periodically test whether SOC and IR teams can trace a cloud-initiated command from identity event to affected VM.
Analyst notes and limits
ATT&CK classifies this as an Enterprise execution technique for IaaS. The object specifically describes abuse of cloud management services that leverage VM agents and notes risk from administrative access, service provider compromise, or delegated administrator relationships. ATT&CK relationships state that DET0545 detects it, M1026 mitigates it, APT29 and VOID MANTICORE use it, and AADInternals and Pacu use it; these should be treated as context for prioritization, not proof of activity in any environment.
The official ATT&CK object does not provide detection guidance, so detection specifics require local cloud provider configuration, logging availability, IAM model, and operational baselines. This take does not assert active exploitation, customer exposure, or guaranteed detection coverage.
Cloud Administration Command
Adversaries may abuse cloud management services to execute commands within virtual machines. Resources such as AWS Systems Manager, Azure RunCommand, and Runbooks allow users to remotely run scripts in virtual machines by leveraging installed virtual machine agents. [1][2]
If an adversary gains administrative access to a cloud environment, they may be able to abuse cloud management services to execute commands in the environment’s virtual machines. Additionally, an adversary that compromises a service provider or delegated administrator account may similarly be able to leverage a Trusted Relationship to execute commands in connected virtual machines.[3]
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.
Groups, software, and campaigns
G0016: APT29
APT29 is threat group that has been attributed to Russia's Foreign Intelligence Service (SVR).[1][2] They have operated since at least 2008, often targeting government networks in Europe and NATO member countries, research institutes, and think tanks. APT29 reportedly compromised the Democratic National Committee starting in the summer of 2015.[3][4][5][6]
In April 2021, the US and UK governments attributed the SolarWinds Compromise to the SVR; public statements included citations to APT29, Cozy Bear, and The Dukes.[7][8] Industry reporting also referred to the actors involved in this campaign as UNC2452, NOBELIUM, StellarParticle, Dark Halo, and SolarStorm.[9][10][11][12][13][14]
G1055: VOID MANTICORE
VOID MANTICORE is a threat group assessed to operate on behalf of Iran’s Ministry of Intelligence and Security (MOIS).[1] Active since at least mid-2022, VOID MANTICORE has targeted government entities, critical infrastructure, and private sector organizations across Albania, Israel, and the United States.[1][2] VOID MANTICORE conducts destructive cyber operations, combining wiper attacks with hack-and-leak campaigns. The group has operated under multiple public-facing personas, including HomeLand Justice in operations against Albania, Karma and Karma Below in campaigns targeting Israeli organizations, and Handala Hack, its current primary persona, which has claimed activity against Israeli and U.S. entities, including a March 2026 attack against Stryker Corporation.[1][3] VOID MANTICORE has been observed collaborating with Scarred Manticore, which has been linked to initial access operations preceding VOID MANTICORE’s activity.[4]
S0677: AADInternals
AADInternals is a PowerShell-based framework for administering, enumerating, and exploiting Azure Active Directory. The tool is publicly available on GitHub.[1][2]
S1091: Pacu
Pacu is an open-source AWS exploitation framework. The tool is written in Python and publicly available on GitHub.[1]
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 | 2.1 | Current bundle | 620a40436936… |
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]
AWS Systems Manager Run Command
AWS. (n.d.). AWS Systems Manager Run Command. Retrieved March 13, 2023.
Open source URL -
[2]
Microsoft Run Command
Microsoft. (2023, March 10). Run scripts in your VM by using Run Command. Retrieved March 13, 2023.
Open source URL -
[3]
MSTIC Nobelium Oct 2021
Microsoft Threat Intelligence Center. (2021, October 25). NOBELIUM targeting delegated administrative privileges to facilitate broader attacks. Retrieved March 25, 2022.
Open source URL -
[4]
mitre-attack T1651Open 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.