IBM X-Force Uncovers Azure Arc Flaws: Hybrid-Cloud Tool Becomes Stealthy RCE & Privilege Escalation Vector
Ddos 
Token privileges assigned when executing commands through WAC | Image: IBM
IBM X-Force has peeled back the layers on Microsoft Azure Arc, uncovering how the hybrid-cloud management tool—meant to unify on-premises and cloud environments—can become an overlooked vector for code execution, privilege escalation, and stealthy persistence. The study follows an engagement where IBM’s red team stumbled upon a hardcoded Azure Service Principal secret in a PowerShell script, triggering a deep dive into Azure Arc’s operational and security intricacies.
“We ended up being able to use techniques documented in prior research… to gain code execution on a domain controller and pivot back up into Microsoft Azure,” the author writes, illustrating how a single misstep can lead to complete domain compromise.
Azure Arc allows administrators to bring Azure-native management capabilities to non-Azure environments, including on-premises Windows/Linux servers, Kubernetes clusters, and VMware deployments. Once onboarded, these machines are treated as first-class Azure resources, with support for policy enforcement, update management, monitoring—and most notably—remote command execution.
But as the IBM study warns, “Arc is great in that it is a legitimate Microsoft product and communicates directly back with well-known API endpoints within Azure, meaning it is typically overlooked by Endpoint Detection and Response (EDR) products.” This invisibility makes it ripe for exploitation.
The research digs into multiple enterprise deployment methods—PowerShell scripts, SCCM, Group Policy Objects (GPO), and Ansible—each potentially leaking the keys to the kingdom. Among the most eye-opening findings:
- Hardcoded Secrets: The default Arc onboarding script generated by Azure includes a hardcoded Service Principal secret.
- Recoverable Credentials: When Arc is deployed via GPO, the Service Principal secret is often encrypted using DPAPI-NG, which “allows any member of the domain computers group to decrypt it.”
- Overscoped Roles: The Service Principal used for deployment is often inadvertently granted the Azure Connected Machine Resource Administrator role, enabling full code execution capabilities on all Arc-managed clients.
“This understandable oversight… allowed us to escalate privileges through Arc and take over the client’s on-premises environment,” the researcher recounts.
Once an attacker gains a foothold in Azure Arc, they can exploit two main execution mechanisms:
- Run Commands: These pseudo-extensions execute arbitrary commands in the context of NT AUTHORITY\SYSTEM without even showing up in the extension list. “The command that is passed in is written to a PowerShell script… and ultimately run in the context of NT_AUTHORITY\SYSTEM,” the researcher explains.
- Custom Script Extensions (CSEs)
These allow not only command execution but also file downloads via the fileUris parameter, turning Arc into a stealthy C2 (command and control) channel. “You could create a script that would copy files… breaking a static detection dependent on identifying executions from the previously noted CSE downloads folder,” the researcher states.
Inspired by Andy Gill’s research, IBM X-Force demonstrates how Arc can be used as a fallback C2 mechanism:
“If you have a high-integrity context on a host… you can deploy your own Arc client and manage it through your own Azure tenant.”
This ability to manage compromised hosts from an attacker-controlled Azure environment—while appearing as legitimate Azure activity—makes Arc a powerful tool for long-term persistence.
To counter these threats, IBM X-Force recommends:
- Role Hygiene: Never assign overly privileged roles like Azure Connected Machine Resource Administrator to Service Principals unless absolutely necessary.
- Restrict Script Access: Especially for GPO or file-share-based deployments, limit access to deployment scripts and secrets.
- Monitor Deployment Footprints: Look for artifacts such as the AzureConnectedMachineAgent folder, arcproxy.exe, or the auto-generated GPO [MSFT] Azure Arc Servers Onboarding.
- Audit and Alert: Watch for role assignment changes and run-command executions in the Azure Activity Log.
Related Posts:
- Arc Browser Development Ceases: Meet Dia, The Browser Company’s New Focus
- Mirai Okiru: The first new Linux ELF malware designed to infect ARC CPUs
- Vulnerabilities exist in some of Intel Arc A750 and A770 GPU may result in denial of service or information disclosure
- Microsoft Patches Four Critical Azure and Power Apps Vulnerabilities, Including CVSS 10 Privilege Escalation
- Hardcoded Cloud Credentials Found in Popular Mobile Apps: A Major Security Flaw
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
