From Shell to Cloudshell: The Escalation Path Attackers Use After VM Breach

Introduction

Gaining Remote Desktop Protocol (RDP) or Secure Shell (SSH) access to an Azure virtual machine (VM) might sound like an old school attack, but it remains a serious cloud security threat. Many Azure VMs are still protected only by basic passwords or keys, and their management ports (3389 for RDP, 22 for SSH) are sometimes exposed to the internet. Attackers constantly scan and brute force these ports,  Microsoft has observed “tremendous number of brute-force attacks” targeting Azure VM logins. If an attacker succeeds in logging into your VM, they don’t just own that single server, they may also gain a foothold into your broader Azure environment. In cloud terms, a VM is not an isolated box, it’s a gateway that can lead deeper into connected services.

Why This Happens: Built-In Access to the Cloud 

Azure VMs aren’t standalone servers, they come with a built-in gateway to Azure. Any process on the machine can talk to the Instance Metadata Service (IMDS) at “169.254.169.254”. If the VM has a Managed Identity, IMDS will hand back an OAuth token that logs the caller into Azure resources, no password needed. So, once an attacker lands on the VM, they can grab that token and act as the VM in the cloud. Combine that with any keys or connection strings the OS stores for admins, databases, or storage, and a single host breach can snowball into full control of your Azure environment.

Real-World Examples

In October 2023, Microsoft detailed an intrusion in which attackers used a SQL-injection flaw to reach a SQL Server running inside an Azure VM. After turning on ‘xp_cmdshell’ they ran Windows commands, exfiltrated data through webhook.site, and then attempted an HTTP call to the Instance Metadata Service (169.254.169.254) to steal the VM’s Managed-Identity token, exactly the credential that would have let them act as the VM in Azure Resource Manager and touch any resource the identity could reach. The pivot failed only because of a configuration error, but Microsoft published the chain as a warning that a single VM exploit can become cloud-wide.

Real Attack Flow Example

1. Initial Breach (RDP / SSH) -

Attacker brute forces weak RDP credentials or uses a stolen SSH key to enter a public facing VM. Once inside, they have local-admin rights to run tools, drop malware, and map the environment.

2. Connect to the VM machine (Linux):

Linux VM → Connect via SSH: ssh -i <path/to/key.pem> azureuser@<VM_PUBLIC_IP>

3. IMDS Abuse(Steal the VM’s cloud identity) -

A simple curl to 169.254.169.254 (with Metadata:true) returns a short lived Azure AD token for the VM’s Managed Identity. This bearer token can impersonate the VM toward any service it’s allowed to reach (e.g., ARM, Key Vault, Storage). 

Retrieve the Managed Identity Token:

Token:

4. Get Azure Managed Identity Role Assignments and Permissions:

 - Authenticate the CLI using the VM’s system-assigned managed identity:
azureuser@AttackSimulatorLinuxVM:~$ az login --identity

- Get Principal ID:

- Get Role Assignments and Permission:

5. Cloud Pivot & Escalation -

Using that token or any other stolen credentials, the attacker begins calling Azure’s management APIs. With high-privilege roles (Contributor, Owner), they can create resource groups, read Key Vault secrets, snapshot disks, or delete critical resources.
However, even least-privileged roles such as Reader or Storage Blob Data Contributor can be abused. Misconfigured role assignments, overly permissive custom roles, or “break-glass” policies allow an attacker to chain privilege escalations, ultimately gaining subscription wide control and exfiltrating data at scale.

- List all VMs:

- Or list resource groups:

Detection & Mitigation

1. Monitor IMDS Misuse - Alert when a VM unexpectedly queries 169.254.169.254/metadata/identity, then check Activity Logs for that managed identity creating or deleting resources it never touched before. A sudden spike usually signals token theft.
2. Enable Just in Time VM Access - RDP and SSH stay closed until an admin requests them, opening only for a short, IP-locked window. This dramatically reduces brute force exposure and leaves a clear audit trail.
3. Use Azure Bastion for Remote Management - Admins connect through the Azure Portal over TLS, so RDP/SSH ports never expose a public IP address. Logins inherit Azure AD protections such as MFA and Conditional Access, blocking internet facing attacks while keeping operations straightforward.
4. Enforce Least Privilege Roles - Attach a managed identity only when required, and grant it the smallest possible scope, for example, Storage Blob Data Reader instead of Subscription Contributor. Regularly review your cloud permissions to help strip unused rights and shrink the blast radius of any compromise.
5. Harden VM Login - Use unique, strong passwords or SSH keys, disable password authentication on Linux where possible, and restrict management traffic to trusted IPs via NSGs or Azure Firewall. Pair RDP with Azure AD sign-in plus MFA to stop credential-stuffing before it starts.
   

Conclusion

An Azure VM might seem like just another server, but in a cloud context, it can be a launchpad for broader attacks if compromised. Once an attacker gets in via RDP or SSH, they can exploit the VM’s cloud identity and connections to pivot deeper into your environment. This turns a single host breach into a potential subscription-wide incident. Therefore, protecting your VMs is as important as protecting any cloud service. By securing remote access, monitoring for suspicious activity, and limiting what a VM can do in Azure, you effectively cut off the attacker’s easy paths to move from “owning a box” to “owning your cloud.”