InfoSecBulletin Cybersecurity for mankind
IBM X-Force has analyzed Microsoft Azure Arc, revealing how this hybrid-cloud management tool can pose risks for code execution, privilege escalation, and stealthy persistence. This study began when IBM’s red team found a hardcoded Azure Service Principal secret in a PowerShell script, prompting a closer look at Azure Arc’s operations and security issues.
“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.
Researchers show new technique to bypass AI safety guardrails in Grok and Gemini
About thousands of leaked AWS keys Held Full Admin Rights
US Bank investigates LockBit’s Data Breach Claims
Five new malware families actively targeting Asian Gov.t infra
T-Mobile Cuts Cables to Remove Chiness Salt Typhoon Hackers from Network
Splunk, Zyxel Patch Multiple Flaws Enabling RCE and Root Command Execution
“Zombie Card” attack revels expired Visa card may be used for contactless payments
Critical Zimbra RCE Flaw Actively Exploited in the Wild
Operation CameraSwarm
A single hacker compromise 1400+ Dahua camera worldwide
Cl0p Ransomware Listed 40+ Victims of PTC Windchill Campaign
Azure Arc enables administrators to manage non-Azure environments like on-premises Windows/Linux servers, Kubernetes clusters, and VMware with Azure tools. After onboarding, these machines function as Azure resources, allowing for policy enforcement, updates, monitoring, and 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 explores various enterprise deployment methods like PowerShell scripts, SCCM, Group Policy Objects (GPO), and Ansible, which may expose sensitive information. Key findings include:
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 capability allows attackers to maintain control over compromised systems using Azure, making Arc a valuable asset for staying unnoticed.
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.
