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.
India’s Tata Electronics hit by cyber breach: Hacker target 630 GB record
Anthropic’s Mythos reportedly broke NSA classified systems in hours
OpenAI New Method “Deployment Simulation” Predicts AI Risks Before Deployment
AryStinger botnet infected thousands of D-Link routers globally
Hacker suspected of sending alerts across Brazil
CyberSentinel AI features 33 security tools like Nmap, SQLMap, and ZAP, utilizing Claude and GPT
Barracuda hosts Dhaka roundtable on cyber resilience
CISA Alerts Fortinet Users as FortiBleed Affects 86,644 FortiGate Devices
CISA: Splunk flaw under active exploit, patch by Sunday
Texas data breach exposes 3 million driver’s licenses
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.
