What is a cloud administration command attack?
What if the most dangerous tool in a cloud attack isn’t malware at all, but the same “Run Command” button your ops team clicked last Tuesday to patch a server?
That is the short answer. In a cloud administration command attack, someone abuses legitimate cloud management services to execute commands inside virtual machines. Think AWS Systems Manager Run Command, Azure Run Command, and automation runbooks. These services push scripts into VMs through an agent that is already installed, already trusted, and usually running with the highest privileges on the box.
For anyone already working in IT, this one should feel familiar. You have probably used these tools yourself to restart a service, pull logs, or fix a broken config without opening RDP or SSH. That familiarity is exactly why this technique is a great blue team topic: the defender’s job is not to learn an exotic exploit, it is to look at a tool you already know from the other side of the table.
One detail matters more than the rest: this technique assumes the attacker already has administrative access to the cloud control plane. This attack is rarely the break-in. It is what happens after someone steals an admin identity. Keep that in mind, because it shapes every control and detection later in this post.
There is also a second route: an attacker who compromises a service provider or a delegated administrator account can ride that trusted relationship to run commands in a customer’s VMs.
How attackers exploit cloud administration commands
The pattern is simple: steal an identity that can talk to the control plane, then let the cloud do the dirty work. A typical chain looks like this:
- Get an admin identity. Phishing, MFA fatigue, help-desk social engineering, leaked access keys in a repo, or a compromised partner account with delegated admin rights.
- Find the targets. List VMs, check which ones have a running agent (SSM Agent on AWS, the Azure VM Agent), and pick the valuable ones: domain controllers, jump boxes, database servers.
- Send the command. One API call or one console click runs a script on one VM or on hundreds at once, usually as SYSTEM on Windows or root on Linux.
- Act on objectives. Dump credentials, drop a backdoor, create local accounts, disable the EDR, deploy ransomware, or wipe the machine.
Why attackers like it:
- No network path needed. The command travels through the cloud provider’s management channel, not through RDP, SSH, or your firewall.
- It looks like admin work. The process that runs the script is the cloud agent itself, a signed and expected binary.
- It scales. The same feature that lets ops patch 500 servers in one go lets an attacker hit 500 servers in one go.
- It blends in. Many teams never baseline who uses Run Command, so there is no “normal” to compare against.
Documented cases show the range of who uses it, from state-sponsored groups to free, open-source tools:
| Actor or tool | What they did |
|---|---|
| APT29 | Used Azure Run Command and Azure Admin-on-Behalf-of (AOBO) to execute code on VMs, abusing delegated admin privileges from service providers |
| VOID MANTICORE | Abused built-in remote wipe and factory reset commands in a cloud device management platform to wipe laptops, servers, and mobile devices |
| AADInternals | Open-source tool that can run commands on Azure VMs through the VM agent |
| Pacu | Open-source AWS exploitation framework that can run commands on EC2 instances through Systems Manager Run Command |
The VOID MANTICORE example widens the idea beyond VMs: any cloud console that can push an action to managed endpoints, including device management (MDM) platforms, has the same risk profile. That is exactly what the real case below shows.
Real case: the Stryker wipe (March 2026)
On March 11, 2026, US medical technology company Stryker had tens of thousands of corporate devices wiped in a few hours, and no malware was involved. BleepingComputer reported that, according to a source, the attacker used the remote wipe command in Microsoft Intune, Stryker’s cloud endpoint management service, to erase devices.
What was reported:
- Who: The Iran-linked hacktivist group Handala claimed the attack. Security researchers track Handala as part of the VOID MANTICORE cluster, a group with a documented history of abusing cloud management consoles.
- How: The attacker compromised an administrator account and then created a new Global Administrator account. How the first admin account was compromised has not been publicly confirmed.
- When: The wipes ran between roughly 5:00 and 8:00 a.m. UTC on March 11.
- Scale: A source told BleepingComputer nearly 80,000 devices were wiped. Handala claimed more than 200,000 devices and large-scale data theft; those claims have not been verified, and investigators reportedly found no sign of exfiltration.
- Collateral damage: Some employees’ personal phones enrolled in Intune were also wiped.
- Business impact: Electronic ordering went offline, and customers had to order through sales reps while systems were restored. Stryker stated it was not ransomware and that its medical devices remained safe to use.
Why this case matters: the attacker didn’t need an exploit, a wiper binary, or a foothold on a single laptop. They needed one identity with the right role in a cloud management console. Every wipe command came from trusted Microsoft infrastructure, which is why endpoint tools had little to catch.
The response was big enough that, on March 18, 2026, CISA issued an alert urging organizations to harden their endpoint management systems, Intune and others. We use those recommendations in the next section.
Through the Threat & Control Method lens:
- Inventory: Was the Intune admin console listed as a critical asset, on the same tier as domain controllers? In most orgs, it isn’t.
- Threats: “An admin identity gets stolen and pushes a destructive action at scale” is a scenario few threat models write down.
- Controls: A second approver on mass wipe actions would have turned one stolen account into a stalled request.
- Scale: The same reasoning applies to AWS Systems Manager, Azure Run Command, your RMM tool, and anything else that can push a command to many machines.
How to prevent cloud administration command abuse
Since this attack starts with a stolen admin identity, prevention is mostly identity security. The good news for IT pros: these are controls you already know how to configure, just applied to the management plane with more discipline.
1. Treat the management plane as Tier 0. Cloud consoles, Run Command, Systems Manager, Intune, and RMM tools deserve the same protection and change control as your domain controllers. If it can push code to every machine, it is a crown jewel.
2. Cut standing privileges. Limit the number of accounts that can run commands on VMs, and keep them out of day-to-day use. In Azure, limit who holds Virtual Machine Contributor or higher, and use just-in-time (JIT) role activation instead of permanent assignments. In AWS, restrict ssm:SendCommand and ssm:StartSession to specific roles, documents, and tagged instances.
3. Require a second approver for destructive actions. After the Stryker attack, CISA urged organizations to enable Multi Admin Approval in Intune for high-impact changes such as device wipes, scripts, apps, and RBAC changes. The same principle applies elsewhere: put approvals on Run Command and Automation runbooks where your platform supports it.
4. Use phishing-resistant MFA for every privileged account. FIDO2 keys or passkeys, not SMS or push approvals. CISA and Microsoft both call this out.
5. Lock admin access with Conditional Access. Allow admin portals only from compliant, managed devices and expected locations. If stolen credentials show up from an unknown device, block, don’t just prompt for MFA.
6. Scope roles tightly. Use least-privilege RBAC and scope tags so an Intune admin for one region can’t wipe the whole company, and an ops role for one app can’t run commands on every VM.
7. Protect the agent and the identity behind it. Restrict which managed identities or instance roles can call management APIs. Don’t let a VM’s own identity hold rights to run commands on other VMs.
8. Keep backups out of reach of the same admin. Offline or immutable backups, managed with separate credentials. If one admin account can delete both the machines and the backups, you have a single point of failure.
9. Watch your partners. Review delegated admin relationships (such as Microsoft partner GDAP and older DAP/AOBO access) and remove what you no longer need. APT29 used exactly this route.
How to detect cloud administration command abuse
Detection works on two layers that must be correlated: the control plane (who asked the cloud to run something) and the guest OS (what actually ran inside the machine). The key is to compare cloud activity logs with host-level process and script execution.
Where to look
| Platform | Control plane log and event | Inside the VM |
|---|---|---|
| AWS | CloudTrail: SendCommand and StartSession from ssm.amazonaws.com | SSM Agent logs (/var/log/amazon/ssm/ on Linux, C:\ProgramData\Amazon\SSM\Logs on Windows); processes spawned by ssm-agent-worker / ssm-document-worker |
| Azure | Activity Log: Microsoft.Compute/virtualMachines/runCommand/action (and runCommands/write for managed Run Command) | Scripts dropped by the Run Command extension under C:\Packages\Plugins\Microsoft.CPlat.Core.RunCommandWindows\ (Windows) or /var/lib/waagent/run-command/ (Linux); child processes of the VM agent |
| Azure Automation | Activity Log: runbook create, update, and job start events | Hybrid worker job logs on the target machine |
| Google Cloud | Cloud Audit Logs for OS Config and metadata changes such as startup scripts | Guest agent and OS Config agent logs |
| Microsoft Intune | Intune audit logs: wipe, retire, and script deployment actions; Entra ID audit logs for new role assignments | Device-side, often nothing useful after a wipe, which is why control plane alerts matter most |
What should trigger an alert
- A Run Command, SSM command, or device wipe from an identity that has never used it before.
- Commands outside maintenance or change windows, or with no matching change ticket.
- The same command sent to many machines in a short time. Stryker’s wipes ran across about three hours; a volume threshold would have fired early.
- A brand-new privileged account (for example, a new Global Administrator) followed shortly by management actions. That sequence is the clearest warning sign in the Stryker reporting.
- Admin sign-ins from unfamiliar devices, countries, or IP ranges right before management activity.
- Scripts that do security-sensitive things: credential dumping, adding local admins, disabling Defender or EDR, downloading tools, deleting shadow copies.
- A cloud command in the logs with no matching process on the host, or a process from the agent with no matching cloud call. Either mismatch deserves a look.
A starting point for your SIEM
If you run Microsoft Sentinel, a first hunting query for Azure Run Command could look like this:
AzureActivity
| where OperationNameValue =~ "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION"
| where ActivityStatusValue == "Success"
| summarize Count = count(), VMs = make_set(_ResourceId) by Caller, CallerIpAddress, bin(TimeGenerated, 1h)
| order by Count descStart by hunting, not alerting. Run it over 30 days, learn who normally uses Run Command, then turn the outliers into an alert. The same logic applies to CloudTrail SendCommand events in AWS.
If you don’t have a baseline today, that is your first finding. Write down who is allowed to use these features, and you suddenly have something to detect against.
Where to learn more about cloud administration command abuse
Go to the primary sources first. They are free, current, and written by the people who track these attacks:
- AWS Systems Manager Run Command documentation to understand exactly what the feature can do and which IAM actions control it.
- Microsoft: Run scripts in your VM by using Run Command for the Azure side.
- Microsoft Threat Intelligence on NOBELIUM (APT29) abusing delegated admin privileges, the case behind the trusted-relationship route.
- Unit 42: Iranian Cyber Threat Evolution on VOID MANTICORE’s shift from wipers to identity weaponization.
- CISA’s March 18, 2026 alert on hardening endpoint management systems after the Stryker attack.
A practical next step: open your own cloud tenant (or a free-tier lab account), run one harmless command through Run Command or Systems Manager, then go find it in the logs. Tracing your own action from console to CloudTrail or Activity Log to the process on the VM teaches more than any slide deck.
And notice what just happened. Cloud admins, sysadmins, and endpoint engineers already understand these tools better than most people who apply for SOC jobs. Detecting this attack is your existing IT knowledge, pointed at a new question. Cybersecurity is not rocket science; it is the same infrastructure, viewed through a threat lens.
Next steps
If you want to build that lens on purpose, the blue team career path shows how IT experience maps to defensive roles. And if you want the full method behind this post, from Inventory to Scale, our program walks IT professionals through it step by step.
For one practical breakdown like this every week, join the Keep IT Safe newsletter.
