Azure Arc: From a Heartbeat to Heart Attack

Azure Arc: From a Heartbeat to Heart Attack

Speakers: Sharan Patil, Security Consultant, Reversec

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=OL6Okw0fLuc

Overview

Sharan Patil, a security consultant at Reversec (formerly F-Secure, formerly MWR), presented original exploit research demonstrating how an attacker with local access to an Azure Arc-enrolled server can hijack the machine's enrollment, transferring it to an attacker-controlled Azure tenant — without compromising the original tenant. The attack exploits a lack of metadata validation in the Azure Arc extension service, combined with the ability to crash and impersonate the Hybrid Instance Metadata Service (HIMDS). Patil disclosed a CVE (still in pre-release) that was pseudo-patched in Azure Arc agent version 1.53, and demonstrated how Azure Arc can serve as an effective command-and-control channel using Microsoft-signed binaries.

Background

▶ Watch: Introduction — hijacking a server enrolled in one tenant into an attacker's t... (0:30)

Azure Arc is Microsoft's hybrid management product that allows organizations to manage on-premises servers through the Azure portal, released in 2019 with significant adoption growth since 2022. It is now installed by default in Windows Server 2025, appearing in Server Manager and the system tray. Organizations are increasingly onboarding critical infrastructure — including domain controllers — onto Azure Arc, dramatically expanding the attack surface.

The architecture consists of two components: the local agent (HIMDS and extension services running on the server) and the Azure tenant (Entra ID, Azure portal/CLI). HIMDS synchronizes metadata and distributes access tokens to extension services, which install, update, and manage extensions that execute as NT AUTHORITY\SYSTEM — the highest privilege level on Windows. Extensions include Custom Script Extension, Microsoft Defender for Endpoint (MDE), Azure Monitor Agent, and third-party extensions from vendors like Datadog and Dynatrace.

The product was previously abused by the threat actor Peach Sandstorm in documented campaigns, and Microsoft has published limited details about that activity.

Key Findings

▶ Watch: Key difference between HIMDS and IMDS — HIMDS requires authentication via key... (6:00)

Extension service executes as SYSTEM. Azure Arc extensions run under NT AUTHORITY\SYSTEM, meaning any code executed through the extension mechanism has the highest Windows privilege level. This makes Azure Arc a high-value target for both lateral movement and command-and-control.

HIMDS communicates over HTTP, not HTTPS. The local REST API on port 40342 uses unencrypted HTTP, meaning access tokens are transmitted in plaintext on the local network. An attacker capable of sniffing local traffic can capture access tokens without any exploitation.

Extension service does not validate metadata origin. When HIMDS is unavailable, the extension service blindly trusts metadata provided by any listener on port 40342 — including an attacker's service. There is no validation that the metadata (subscription ID, tenant ID, VM ID) belongs to the server it's running on. Patil demonstrated that feeding metadata from a different server enrolled in a different tenant causes the extension service to accept it without question.

Key file read primitive. The extension service's token retrieval process — where HIMDS writes a key file and the extension service reads it — can be exploited to force the extension service to read arbitrary files. Combined with the lack of metadata validation, this creates a powerful local privilege escalation primitive.

Service restart does not require admin privileges. A critical finding: low-privilege users can restart the MSI service that triggers HIMDS repair functionality, creating the window needed for the attack. This eliminated what would have been a significant barrier to exploitation.

Technical Deep Dive

▶ Watch: 'The S in HTTP stands for security which doesn't exist' — local traffic is un... (12:00)

The attack chain exploits the interaction between HIMDS and the extension service:

1. Understanding the token flow. The extension service requests an access token from HIMDS via a GET request to http://localhost:40342. HIMDS responds with a 401, writing a key file to C:\ProgramData\AzureConnectedMachineAgent\Tokens\. The extension service reads the key file and sends it back. HIMDS validates the key and returns an access token. The extension service uses this token (with the VM ID) to communicate with the Azure tenant.

1. Adversary-in-the-Middle positioning. Patil positions as a proxy between the extension service and HIMDS — acting as HIMDS for the extension service, and as a client for the real HIMDS service.

1. Metadata substitution. When the extension service requests metadata, the attacker returns metadata from a different server enrolled in the attacker's tenant. The extension service accepts this without validation.

1. Key file exploitation. The attacker intercepts the key file write location, allowing the extension service to read it. However, a complication: HIMDS invalidates previous keys on restart (maintained in memory), and keys are deleted every 10 minutes, creating a narrow exploitation window.

1. Service crash via MSI repair. Using the msiexec repair functionality (a separate CVE in version 1.48's scheduled task), the attacker crashes HIMDS and performs port squatting on 40342. Since no two processes can listen on the same port, the attacker's listener takes over when HIMDS goes down.

1. Tenant hijacking. With the extension service now communicating with the attacker's listener (serving attacker-controlled tenant metadata), the server effectively re-enrolls in the attacker's Azure tenant. The attacker deploys Custom Script Extension to download and execute arbitrary payloads — all running as SYSTEM, all through Microsoft-signed binaries.

Lab setup: Server 2022 (attacker-controlled, enrolled in attacker's tenant), Server 2025 (target), Kali Linux (running the fake HIMDS service).

The full 200-401-200 request cycle is deterministic and never changes, making the attack reliable once the preconditions are met.

Demo / Proof of Concept

▶ Watch: Critical discovery — extension service blindly accepts metadata from any tena... (14:00)

Patil described the full exploitation flow but did not release the complete proof of concept, noting that the original PoC took 20 minutes to execute (coincidentally matching his talk slot). He showed the extension service receiving and installing the attacker's Custom Script Extension, with logs confirming the payload download from attacker-controlled Azure Blob Storage and execution as SYSTEM. The CVE is in pre-release status, pseudo-patched in version 1.53 (June release).

Defensive Implications

▶ Watch: Full exploitation — Custom Script Extension deployed from attacker's tenant, ... (18:00)

Patch immediately. Version 1.53 introduced HTTPS on a new REST API port (40321) with certificate pinning, mitigating the plaintext HTTP interception and metadata substitution attacks. Organizations running Azure Arc agents below 1.53 should treat this as critical.

Audit Azure Arc enrollment scope. Organizations onboarding domain controllers and other critical infrastructure to Azure Arc should understand that local compromise now provides a path to tenant-level access. The risk profile of Azure Arc enrollment should be evaluated against the sensitivity of enrolled servers.

Monitor extension installations. The extension service logs are verbose and stored at known locations. Unexpected extension installations — particularly Custom Script Extension — should trigger alerts. Log deletion is a strong indicator of compromise.

Restrict outbound access. Azure Arc requires outbound connectivity to specific Microsoft endpoints (documented with wildcards). Azure Service Bus and Blob Storage URLs can serve as C2 channels. Network monitoring for unexpected outbound connections from Arc-enrolled servers to these services is advisable.

Evaluate tenant restrictions. The extension service blindly trusts whatever tenant metadata it receives. Outbound tenant restrictions may provide some mitigation, though Patil noted he had not fully tested Conditional Access Policies against this attack.

Be aware of C2 potential. Multiple recent blog posts (3-4 in the past 3 months) document using Azure Arc extensions for command-and-control. Microsoft-signed binaries executing attacker payloads create a living-off-the-land scenario that is difficult to detect with traditional endpoint security.

Key Takeaways

• Azure Arc's extension service blindly accepts metadata from any listener on port 40342 when HIMDS is unavailable — enabling tenant hijacking without compromising the original tenant.
• Extensions execute as NT AUTHORITY\SYSTEM, making Azure Arc a high-value C2 channel using Microsoft-signed binaries.
• The local HIMDS REST API used HTTP (not HTTPS) prior to the version 1.53 patch, exposing access tokens to local network sniffing.
• Low-privilege users could restart the MSI service, removing a key exploitation barrier.
• Azure Arc is installed by default in Windows Server 2025 and is increasingly deployed on domain controllers, dramatically expanding the hybrid attack surface.
• Version 1.53 introduced HTTPS with certificate pinning as a mitigation, but further research into custom extensions and C2 channels is ongoing.

About the Speaker(s)

Sharan Patil is a security consultant at Reversec (formerly F-Secure, formerly MWR InfoSecurity) based in the UK. He specializes in network security and infrastructure penetration testing, with multiple CVEs in Azure Arc. His research bridges traditional network exploitation with cloud hybrid architectures.