Do Son 
The remote management functionality of Azure Arc, designed to centralize administration across hybrid infrastructures, has proven unexpectedly useful not only to system administrators and DevOps teams, but also to adversaries. A security study published by researcher Andy Gill illustrates how this feature can be repurposed to establish a full-fledged command-and-control (C2) channel—bypassing conventional detection mechanisms.
Introduced in November 2019, Azure Arc remained largely overlooked by cybersecurity professionals until recently. Its primary role is to manage infrastructure beyond Azure, including physical servers, virtual machines, and Kubernetes clusters across other cloud platforms and on-premises data centers. Visually and logically, these connected systems are represented within the Azure interface and treated as native resources. Ironically, this very integration has become an appealing vector for malicious exploitation.
An attacker with local administrator privileges on a target machine and “Contributor” access to the corresponding Azure resource can leverage Arc to register the device and install its agent. The process is routine and arouses little suspicion: a script is generated via the Azure Portal, executed on the target host, and authenticated through a browser. The device then appears in the Azure control panel, where various “extensions”—including the built-in SSH agent—can be deployed.
Access to the compromised machine is conducted directly via Azure Cloud Shell or CLI, and commands are executed under the identity of the connected user. Crucially, no additional malware is required: all operations are carried out through Microsoft’s legitimate, authenticated agent, which communicates over encrypted channels.
Particular emphasis in Gill’s report is placed on the Custom Script Extension—one of Azure Arc’s built-in features, enabling the upload and execution of arbitrary PowerShell or Bash scripts on registered devices. This effectively transforms Arc into a covert remote code execution pipeline. Given that the agent runs with SYSTEM-level privileges, an attacker can effortlessly escalate access. The provided script examples demonstrate capabilities such as file creation, system reconnaissance, and network command execution.
The Arc extension framework also supports downloading scripts from external sources, including GitHub and Azure Storage, facilitating dynamic command delivery without the need for persistent presence on the target machine.
From a defensive standpoint, the report offers several key recommendations. These include monitoring for activity associated with azcmagent.exe, himds.exe, and CustomScriptHandler.exe processes; tracking connections to domains such as *.arc.azure.com and *.guestconfiguration.azure.com; and analyzing changes within system directories and the Windows registry. Gill also supplies detection rules for Splunk and Elastic aimed at identifying anomalous Arc agent behavior and suspicious child processes.
A critical observation is that Custom Script Extension is seldom used beyond initial setup; therefore, its reactivation may indicate a breach. Moreover, while Azure logs the creation or update of an extension, it does not retain the contents of the executed script—requiring retrieval directly from the compromised host.
Gill further highlights the possibility of interacting with Arc resources via REST API, enabling command execution without relying on storage layers or leaving conspicuous traces on the client side, thus enhancing operational stealth.
Like many enterprise-grade services, Azure Arc reveals itself to be a double-edged sword: when misconfigured or accessed by even minimally privileged actors, it can serve as a stealthy control mechanism across hybrid environments. This raises a pressing concern—do organizations possess adequate visibility and monitoring capabilities to detect abuse of such “legitimate” communication channels?
Donate