Many teams are confident they have virtual machine access under control.
Interactive access is tightly restricted.
SSH and RDP are only available through jump hosts.
Privileged sessions are brokered via tools like CyberArk.
Local administrator credentials are rotated, logged, and reviewed.
From an operating system perspective, this model often works well. The problem is that these controls only protect one access path. They do not apply to the Azure control plane.
Run Command allows authorized users to execute scripts directly on a VM through the Azure management layer. There is no interactive login, no network connectivity requirement, and no involvement from the jump host or PAM tooling. Authorisation is based entirely on Azure RBAC permissions assigned to the VM resource.
This creates a second execution path that is easy to overlook.
A user may be correctly blocked from logging into a production VM yet still be able to run arbitrary commands inside that VM if they have been granted broad VM permissions for operational convenience. In many environments, these permissions are assigned to support teams, platform engineers, or automation roles without a clear understanding of their full impact.
When a managed identity is attached to the VM, the situation becomes more serious.
Any code executed via Run Command runs inside the VM context. That code can access the Azure Instance Metadata Service and request access tokens for the managed identity. Once a token is retrieved, it can be exfiltrated and used from outside the VM to call Azure APIs.
This is a form of privilege escalation, even though no vulnerability is exploited.
The user starts with permissions to manage a VM resource. They end up with the permissions of the managed identity, which may include access to Key Vault, storage accounts, databases, or even broader management scopes. The escalation happens entirely through legitimate Azure features, making it difficult to detect with traditional security tooling.
Why this is hard to spot
Run Command activity often looks like routine operational work. Token access through managed identities is expected behaviour for applications. Individually, these actions raise few alarms.
The risk only becomes clear when you connect identity permissions, VM access, and managed identity scope into a single attack path. Most security reviews do not model this end-to-end.
What teams can do about it
There are practical steps to reduce this risk:
Review who has permissions that allow Run Command execution on VMs
Separate VM lifecycle management from in-guest command execution
Scope managed identity permissions tightly and avoid broad roles
Avoid reusing managed identities across multiple high-value workloads
Monitor and alert on Run Command usage, especially in production
Treat managed identities as sensitive credentials, even though they are secretless
Most importantly, teams need to reason about control plane permissions with the same rigor they apply to OS-level access.
Final thought
Cloud privilege escalation rarely looks like a break-in. It looks like normal operations combined in the wrong way.
When execution paths bypass the controls you rely on, assumptions about safety no longer hold. Understanding and modeling these paths is now a core part of securing Azure environments.
This is not a configuration bug. It is a permission design issue.
ARGOS identifies identity-to-resource attack paths across Azure, including scenarios where VM access can be leveraged to extract managed identity tokens.
If you have not explicitly checked for this, you are relying on assumption rather than evidence.