Skip to content

Instantly share code, notes, and snippets.

@aarcro
Last active June 25, 2025 14:23
Show Gist options
  • Save aarcro/6eebc17aa81f0ce30d396209f6652182 to your computer and use it in GitHub Desktop.
Save aarcro/6eebc17aa81f0ce30d396209f6652182 to your computer and use it in GitHub Desktop.

The Azure Arc agent itself does not allow arbitrary lateral movement or full remote control over on-prem hosts from the cloud—but it can be a control path, depending on how it’s configured.

What it can do:

Once a machine is onboarded with Azure Arc, Azure services can be applied to it from the cloud, including:

  • Policy enforcement (e.g. password policies, required services)
  • Install/update software via Guest Configuration
  • Run scripts via Custom Script Extension
  • Enable Defender for Endpoint or other security tools
  • Collect logs and metrics via Log Analytics

These are all intended and usually require admin rights on the machine when installing the agent.

Risk surface:

  • The agent communicates outbound via HTTPS, so it doesn’t open a direct inbound channel.
  • However, Azure Arc can become a control path—you can push scripts, install software, or apply changes from the cloud if someone has sufficient Azure RBAC permissions.
  • Misconfigured RBAC or policy could allow overreach, including affecting multiple Arc-connected machines.
  • The agent runs with local root/System privileges, so if compromised, it could be used for lateral movement—but that would be a post-exploit concern, not something Arc is designed to enable.

TL;DR

Arc doesn’t natively support lateral movement, but does allow privileged configuration and script execution from Azure, which can be used to control the host, intentionally or maliciously. It’s a powerful management plane and must be treated as such.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment