Introduction

Azure Arc is supposed to be a bridge that extends the Azure platform into your environment. Based on our high-level review, it seems to be a pretty nice tool that could help in better integration and management of on-premises assets. Azure Arc was first released in 2020 and after observing uptake within customer environments, we decided to do some research to understand its design and operation. This resulted in the discovery of multiple local privilege escalation vulnerabilities.

The service has even been abused by threat actors in the wild for Command and Control (C2) purposes. Microsoft has revealed that Peach Sandstorm, an Iranian nation-state threat actor, was found to abuse Azure Arc as “C2” in one of their campaigns. However, this was after they had exploited the victim’s host and enrolled the server in Peach Sandstorm’s Azure tenant. Our literature review revealed few researchers had discovered local privilege escalation methods and reported them to Microsoft Security Response Center (MSRC).

Security researchers also started posting about their research and experiments with Azure Arc, which helped us understand in-depth the working and potential abuse of the Azure Arc’s local agents installed on the on-premises servers. Azure Arc’s use as C2 did not offer the features found in the commonly used C2 frameworks such as cobalt-strike, sliver, havoc, etc.

As an introduction to Azure Arc’s architecture and previous security vulnerabilities, we recommend reading the following articles:

Other honourable mentions of exploitation techniques that were useful during our research:

Overview

Azure Arc is a bridge that extends the Azure platform into your environments. Machines onboarded onto Azure tenants will be assigned to a managed identity, which can be used to access Azure resources using Role-Based Access Control (RBAC). This enables organizations to leverage the power of Azure from their on-premises servers. Official documentation is available here. For now, we need to understand two components of Azure Arc:

  • A local agent which is installed on the on-premises machine and responsible for communication with the Azure tenant.
  • Azure tenant, responsible for enrolling and configuring the managed identity.

NOTE: It is recommended to read the above blogs before proceeding to have a better understanding of Azure Arc.

Vulnerabilities

Our initial research spanned over a month between 24th of December 2024 and 24th of January 2025 and again in July 2025. During this period, we reported eight vulnerabilities to MSRC. We identified some more interesting behaviour of the local agent, which are pending research or implementation of new features in the future updates. Some of our observations are listed below.

Installer Bugs

Installer bugs do not need any special introduction, especially race conditions. Race condition exploitations are tricky, as it is not always possible to determine the exact moment (in our context) a process or thread utilizes certain resources. Successful exploitation usually leads to denial-of-service attacks or arbitrary code execution under the privileges of the process or the thread. Race conditions during installation or repair actions are prime targets as these actions are usually performed by a privileged user. So, what if we can identify these bugs and are able to time our exploits? Our research revealed multiple avenues for LPE during various phases of Azure Arc’s local agent life cycle. Azure Arc Enabled Server: Installer Elevation of Privileges explains some of these installer bugs in depth and provides a proof-of-concept for exploiting CVE-2025-26627.

Right To Repair

No, we are not talking about the movement, we are talking about Microsoft Software Installer’s (MSI’s) repair functionality. The MSI repair functionality has been a handy feature which has allowed low-privilege users to escalate their privileges when the CustomActions or the repair steps themselves have some logic bugs.

Console Popup - Blink and You Miss

Popup ads are annoying, we all hate them, but what if it is a console popup? Good old console popup exploits still exist where if you blink, you miss the popups. These vulnerabilities are difficult to exploit as the time required to click and pause a console popup at the exact moment is in milliseconds. Best practices recommend suppressing these popups, yet we still find these popups every now and then. One of them is similar to CVE-2023-26078. Luckily, there are methods where you can increase the efficiency of these exploits, if we are able to monitor the process and identify the files used by the process. Azure Connected Machine Agent Elevation of Privilege Vulnerability: Console Popup explains the introduction of the vulnerability and a reliable method to increase the exploit success rate to 100%.

When One Thing Leads to Another

If you were able to understand how Azure Arc works, you should have noticed that the entire architecture revolves around the local agent. We have a few questions for you:

  • Have you wondered what would happen if the local agent were to disappear, but the other components are still functioning normally?
  • Is there an opportunity for a low-privileged user to escalate their privileges?
  • Is there a single point of failure?

The following vulnerabilities cover spoofing techniques that chain multiple functions to achieve LPE:

This advisory explains the vulnerability and the steps where a host enrolled in Azure tenant A was hijacked and enrolled into an attacker controlled tenant B as a low-privileged user. No special permissions or privileges were required in tenant A or the host. This exploit is possible when a host has already been configured with Azure Connected Machine Agent.

Processes dependent on other services even within the same host should implement integrity checks. This advisory highlights the vulnerablity that could be exploited due to missing integrity checks when executing a task as a privileged user.

Further Research

So far, we have spoken about the issues we have reported to MSRC, but we never mentioned that our research was completed. The more complex a software is, the more the chances of unexpected consequences. We are now shifting our focus from exploitation to post-exploitation.

Responsible Disclosure Policy

Reversec follow our own responsible disclosure policy along with the vendors disclosure policy. It is important to adhere to these policies in order to protect our clients, the users of these products and the vendor. Microsoft’s Coordinated Vulnerability Disclosure policies can be found on their website.

Advisory Links

Similar Posts

Breaking Down Azure DevOps: Techniques for Extracting Pipeline Credentials

High-Profile Cloud Privesc

High-Profile Cloud Privesc

Detecting Attacks against Azure DevOps