Detecting and Mitigating Cloud Administration Command Abuse (T1651)

Cloud Administration Command (T1651) is an Execution technique on IaaS. Adversaries abuse cloud management services to run commands inside virtual machines.

Services such as AWS Systems Manager, Azure RunCommand and Runbooks let users run scripts remotely in VMs through installed agents. Nobody needs network access to the VM, only the right cloud permission.

How attackers use it

MITRE says an adversary with administrative access to a cloud environment may use these services to execute commands in the environment's VMs. An adversary who compromises a service provider or a delegated administrator account may do the same through a Trusted Relationship in connected VMs.

Examples listed: APT29 used Azure Run Command and Azure Admin-on-Behalf-of (AOBO) to run code on virtual machines. Pacu can run commands on EC2 instances with AWS Systems Manager Run Command. AADInternals can execute commands on Azure VMs using the VM agent. VOID MANTICORE abused built-in remote wipe or factory reset commands to wipe devices managed in a cloud management solution, affecting laptops, servers and mobile devices.

How to detect it

MITRE's analytic is to watch for suspicious use of cloud native administrative command services (AWS Systems Manager Run Command, Azure RunCommand, GCP OS Config). Anomalies include commands or scripts run by unexpected users, execution outside maintenance windows, or commands started by service accounts not normally tied to administration. Correlate cloud control plane activity logs with host level execution such as process creation and script execution, to confirm whether the command actually ran in the guest.

That join is the useful part. The control plane log tells you who sent the command. The host log tells you what happened. Having only one of them leaves a gap.

How to reduce the risk

MITRE lists Privileged Account Management. Limit the number of cloud accounts that can remotely execute commands on virtual machines, and keep them out of daily work. In Azure, limit accounts holding the Virtual Machine Contributor role and above, and consider temporary Just in Time roles instead of permanent assignment.

Check your own environment

Read-only (AWS CLI, audit credentials):

aws ssm list-commands --max-items 20

Also check:

• Who can run Systems Manager, Run Command or equivalent in each account and subscription?
• Do you review delegated administrator and partner access?
• Are control plane logs and guest logs both retained, and can you join them by instance and time?
• Do you have a defined maintenance window to compare against?

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK T1651 Cloud Administration Command