May the Least Privilege Be With You

May the Least Privilege Be With You

Speakers: Marios Gyftos (Senior Cyber Security Consultant); Nikos Vourdas (Senior Offense Security Consultant)

Conference: Cloud Village

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

Overview

In the evolving landscape of cloud security, organizations are increasingly aware of the need to secure user identities. However, a significant blind spot often remains: the security posture of service principals and enterprise applications within cloud environments like Microsoft Azure. This talk, "May the Least Privilege Be With You," delivered by Marios Gyftos and Nikos Vourdas at Cloud Village, meticulously dissects the dangers posed by excessive privileges assigned to these non-user entities. The speakers present a compelling case for why these overlooked components represent a critical attack surface, demonstrating how they can be abused in real-world scenarios to achieve high-impact compromises, from full Azure subscription access to sensitive data exfiltration and code execution.

The core premise of the presentation is that while robust controls like multi-factor authentication (MFA), Conditional Access policies, and risky sign-in detections are increasingly enforced for human users, the equivalent rigorous security measures are frequently absent for applications and their underlying service principals. These applications, often deployed for automation, scalability, and seamless integrations across DevOps, backups, and identity management, inherently require elevated permissions. The talk aims to raise awareness among both defenders and attackers, providing actionable insights into detecting and mitigating these vulnerabilities, or conversely, leveraging them in offensive operations.

Gyftos and Vourdas don't just highlight the problem; they offer concrete, engagement-tested examples of how these privileges can be chained and exploited. They introduce four distinct attack scenarios, ranging from well-known vectors to novel techniques, culminating in the release of a custom tool, AppHunter, designed to swiftly identify over-privileged service principals. This comprehensive approach underscores the urgent need for organizations to extend their least privilege principles and monitoring capabilities beyond human users to encompass the burgeoning ecosystem of enterprise applications and their powerful service principal identities.

Background

▶ Watch: Introduction to Azure service principles and privilege abuse (0:00)

The modern security landscape, particularly within cloud environments, has seen a significant shift towards strengthening user-centric security. Organizations are now routinely implementing sophisticated controls such as Conditional Access policies, requiring trusted devices, enforcing geo-fencing, and leveraging risky sign-in implementations to protect user accounts. While these measures are crucial and effective, they often create a false sense of comprehensive security by overlooking other powerful entities within the environment.

In Microsoft Azure, users are not the sole actors with privileges. A burgeoning ecosystem of enterprise applications plays a pivotal role in enabling automation, scalability, and seamless integrations across various services like DevOps, backup solutions, and device/user management. Each of these enterprise applications is intrinsically linked to a service principal, which acts as its identity within Microsoft Entra ID (formerly Azure Active Directory) and holds the permissions required for the application to function. The pervasive adoption of these applications in modern corporate environments means they hold significant sway and, consequently, significant risk if not adequately secured.

The fundamental problem identified by the speakers is a widespread failure to apply the principle of least privilege to these service principals. Many organizations grant overly broad permissions to applications, either out of convenience, a lack of understanding of the exact permissions required, or simply because they are not monitored with the same scrutiny as user accounts. This creates an expansive attack surface where a compromised service principal, even if tied to a seemingly innocuous application, can be leveraged for lateral movement, privilege escalation, or data exfiltration.

The speakers acknowledge and build upon prior research in this domain, specifically shouting out contributions from major players like Dick Jam Research (Secureworks), Mandiant, and SpecterOps, who have previously highlighted the abuse of service principals. Their work takes these foundational insights a step further, presenting additional attack vectors and real-world scenarios derived from their extensive experience in offensive security engagements. The talk emphasizes that the question isn't whether these applications are being used, but rather "how are they being secured, and what kind of privileges do they possess?"—a question too often met with insufficient answers.

Key Findings

▶ Watch: Building on prior research, showcasing new attack vectors (4:40)

The presentation by Marios Gyftos and Nikos Vourdas unveiled several critical findings regarding the security posture of service principals and enterprise applications in Azure environments. Their research and real-world engagement experience underscore that these entities are frequently over-privileged and represent a prime target for attackers, often overlooked by traditional security controls focused on human users.

The overarching key findings include:

• Pervasive Over-Privilege: A significant number of service principals and enterprise applications are configured with excessive permissions, routinely violating the principle of least privilege. This common misconfiguration creates a substantial attack surface.
• New Post-Exploitation Techniques: The speakers demonstrated novel methods for abusing existing permissions, particularly focusing on less-documented or overlooked API permissions and default configurations that enable high-impact attacks. These techniques are directly informed by their red teaming and purple teaming engagements.
• Four Real-World Attack Scenarios: The core of their findings is encapsulated in four distinct, practical attack paths:

1. Elevating from an Application Owner to Full Azure Access: Demonstrated how an attacker, by compromising a user who owns an enterprise application with the Application.ReadWrite.All permission, can gain User Access Administrator or Contributor roles on an Azure subscription, or even Global Administrator in Entra ID.
2. Covert Email Eavesdropping: Showcased how a compromised Cloud Application Administrator can leverage a service principal with Mail.Read and Mail.ReadWrite permissions to read and potentially modify sensitive emails, bypassing Conditional Access policies through service principal exclusions.
3. Arbitrary Code Execution via Intune Line-of-Business Applications: Revealed a powerful technique to abuse the DeviceManagementApps.ReadWrite.All permission, allowing an attacker to deploy custom applications to Intune-enrolled Windows hosts, executing code with NT AUTHORITY\SYSTEM privileges.
4. Azure DevOps Administrator to Azure Subscription Owner: Highlighted how the seemingly less-privileged Azure DevOps Administrator role, combined with the ability to claim orphaned DevOps organizations and exploit vulnerable pipeline configurations, can lead to the extraction of service principal credentials with Owner rights on Azure subscriptions.

• Undocumented Abuse Vectors: The research brought to light specific permissions, such as DeviceManagementApps.ReadWrite.All, whose full abuse potential (e.g., uploading arbitrary executables) is not widely documented, creating significant blind spots for defenders.
• Default Configuration Weaknesses: Critical default settings, like the disabled enable-shell-tasks-arguments-validation in Azure DevOps pipelines, were shown to be exploitable for command injection and credential extraction.
• AppHunter Tool: To address the difficulty in identifying these issues manually, the speakers developed and showcased AppHunter, a custom tool designed to quickly enumerate and highlight dangerous permissions assigned to service principals across both Entra ID and Azure resources.

These findings collectively emphasize that a comprehensive cloud security strategy must extend far beyond user identities, focusing equally on the meticulous management and continuous monitoring of service principals and the applications they represent.

Technical Deep Dive

▶ Watch: Presenting new post-exploitation techniques for enterprise apps (6:00)

Marios Gyftos and Nikos Vourdas presented four detailed scenarios illustrating how excessive privileges assigned to Azure service principals can be exploited. Each scenario provided a unique attack vector, demonstrating the breadth of potential compromises.

Scenario 1: From Application Owner to Azure Full Access

This scenario begins with the compromise of a standard user, like "Labroscopas," who, despite not being a Global Admin, holds a critical role: owner of an enterprise application named "Pal Management." Crucially, this application possesses the highly potent Application.ReadWrite.All permission. This permission allows the application to modify properties of any other service principal in the tenant, including adding new credentials.

The attack path unfolds in two variations:

1. Azure Resources Compromise:

• The attacker, acting as "Labroscopas," logs into the "Pal Management" application.
• Using the Application.ReadWrite.All permission, the attacker creates new credentials (a client secret) for the "Pal Management" service principal itself.
• With these new credentials, the attacker authenticates as the "Pal Management" service principal.
• The attacker then identifies another service principal, perhaps "Subscription Manager," which holds high-privilege roles like User Access Administrator or Contributor on an Azure subscription.
• Leveraging Application.ReadWrite.All again, the attacker creates new credentials for the "Subscription Manager" service principal.
• By authenticating with the "Subscription Manager" credentials, the attacker gains full control over the target Azure subscription, capable of adding users, deleting resources, or performing any action permitted by the Contributor role. The speakers noted that in "9 to 10 times" of their engagements, this leads to User Access Administrator or Contributor roles.

1. Entra ID Global Admin Compromise:

• Following the initial steps of compromising "Pal Management" and using its Application.ReadWrite.All permission, the attacker targets a service principal that has the RoleManagement.ReadWrite.Directory permission.
• This permission allows the service principal to manage directory roles.
• The attacker uses the Graph API to add their own service principal, or any other user, to the Global Administrator role in Entra ID. This directly elevates the attacker to the highest administrative privilege within the identity provider.

Scenario 2: Email Eavesdropping via Over-Privileged Service Principal

This scenario focuses on exploiting a different set of permissions to access sensitive information. The starting point is a compromised user, "Nikos Kiris," who holds the Cloud Application Administrator role. This role is powerful because it allows the user to manage all enterprise applications in the tenant.

The target is a service principal named "Email Protection," which is configured with Mail.Read and Mail.ReadWrite permissions. These permissions allow the service principal to read and modify emails in any mailbox within the organization. A common defensive measure, a Conditional Access policy, is shown to have an exclusion for users working from the office, often bypassing MFA requirements for certain network locations. However, the attack focuses on the service principal, which typically bypasses such user-centric policies.

The attack steps are:

• The attacker, as the compromised "Nikos Kiris" (Cloud Application Administrator), connects to the Graph API.
• Using their administrative privileges, the attacker interacts with the "Email Protection" service principal.
• Leveraging the Mail.Read and Mail.ReadWrite permissions held by "Email Protection," the attacker can now query mailboxes of target users, such as a CEO or executive.
• The demonstration showed reading a sensitive email subject and then decoding an attached file (converted from ASCII) to extract its content, effectively eavesdropping on internal communications. This highlights how data exfiltration can occur without directly compromising a user's mailbox, but rather by compromising an application with broad email access.

Scenario 3: Code Execution via Intune Line-of-Business Applications

This scenario presents a novel technique for achieving code execution on Intune-enrolled Windows hosts by abusing specific device management permissions. The starting point is an enterprise application, "Intune Manager," which possesses the DeviceManagementApps.ReadWrite.All API permission. A low-privilege user is assumed to be the owner of this "Intune Manager" application.

The speakers noted that existing documentation primarily focuses on exploiting device management configuration settings, not the application management aspect. Their research uncovered a critical undocumented capability: DeviceManagementApps.ReadWrite.All allows not just reading/writing application properties, but also uploading and deploying arbitrary custom applications.

The attack process involves four key steps:

1. Payload Creation: The attacker first creates a malicious payload, for the demo, a simple whoami.exe (or mkdir C:\whoami) compiled executable.
2. Packaging for Intune: Microsoft requires custom applications to be in the .intunewin format for deployment via Intune. The attacker uses Microsoft's IntuneWinAppUtil tool to package their whoami.exe into the required .intunewin format. This tool is straightforward, requiring source folder, output folder, and the source file.
3. Uploading and Configuration: Directly interacting with Intune APIs for upload is complex. The speakers leveraged the MS-EndpointManager-IntuneWin32App GitHub project, a PowerShell module.

• After obtaining a Graph access token for the "Intune Manager" service principal (whose owner previously created a secret), the attacker uses the Add-IntuneWin32Application module function.
• This requires specifying the .intunewin payload, detection rules (e.g., file existence), installation/uninstall commands, and operating system requirements (e.g., Windows 10 minimum).
• Crucially, the Intent for the application assignment must be set to Required, ensuring automatic deployment rather than optional installation.

1. Deployment and Execution:

• The Set-IntuneWin32AppAssignment module function is then used to assign the newly uploaded application to a target group (e.g., an Entra ID group containing Intune-enrolled devices) or a specific user/device.
• Upon the next synchronization cycle (typically every 30 minutes or on reboot), Intune-enrolled devices pull the required application.
• The payload executes on the target Windows hosts with NT AUTHORITY\SYSTEM privileges, providing a powerful mechanism for privilege escalation, lateral movement, or persistence from the cloud to on-premise endpoints. The demo successfully showed whoami executing as NT AUTHORITY\SYSTEM in the C:\whoami directory.

Scenario 4: Azure DevOps Administrator to Azure Subscription Owner

This advanced scenario demonstrates how a seemingly less-privileged role, Azure DevOps Administrator, can be leveraged to gain significant control over Azure subscriptions. The scenario assumes a user, "Anarchin," holds this role.

The premise involves an orphaned DevOps organization (e.g., "RebelOps") where the original owner ("Jedi Master") has been deleted or is inactive, leaving the organization without an active administrator.

The attack steps are as follows:

1. Enumerating Orphaned Organizations: A key challenge is that Azure DevOps Administrators cannot typically view orphaned organizations through the UI or standard CLI commands. The speakers discovered a unique method: creating a new DevOps organization, then navigating to Microsoft Entra ID and using a "download" button which generates a list of all DevOps organizations within the tenant, including their URLs. This revealed the existence and URL of "RebelOps."
2. Claiming Ownership: When attempting to access the URL for "RebelOps," the attacker (as "Anarchin") is presented with a "Claim Ownership" button. This feature is only available for truly orphaned organizations and allows the Azure DevOps Administrator to seize control.
3. Discovering Vulnerable Pipelines: Once ownership is claimed, the attacker gains access to the "RebelOps" organization and its projects. They investigate a project, identifying a service connection named "DevOps Automations" which has a secret associated with it. This service connection is used by a pipeline.
4. Exploiting Pipeline Injection: The attacker examines the pipeline's YAML file and a backup.sh script. The script pulls an encryption key from a Key Vault and uploads a backup to storage, indicating the underlying service principal has permissions to interact with these Azure resources.

• The critical vulnerability lies in a default configuration: the enable-shell-tasks-arguments-validation setting in the pipeline is off by default. This allows for command injection through parameters passed to the pipeline script.
• The attacker injects commands (e.g., ls, sudo -L) into a pipeline parameter (e.g., filename). The logs confirm successful execution of these commands on the pipeline agent, demonstrating arbitrary code execution on the agent itself.

1. Extracting Service Principal Credentials: The attacker's goal is not the agent, but the service principal's credentials. By injecting env | grep SERVICE_PRINCIPAL into the pipeline, environmental variables related to the service principal are revealed. While Microsoft's logging masks clear text credentials with asterisks, the attacker uses base64 encoding (echo $SERVICE_PRINCIPAL_KEY | base64) to bypass this masking and retrieve the service principal ID and its secret in clear text.
2. Subscription Compromise: With the extracted credentials for the "DevOps Automations" service principal, the attacker authenticates using the Azure CLI. A quick check of its assignments reveals that this service principal is an Owner on an Azure subscription, granting the attacker full administrative control over that subscription.

These scenarios vividly demonstrate that a holistic approach to cloud security must consider the intricate relationships between users, applications, permissions, and default configurations to truly minimize the attack surface.

Demo / Proof of Concept

▶ Watch: Scenario 1: App owner to Azure full access (6:50)

A crucial part of the talk was the demonstration of AppHunter, a custom-built tool designed by the speakers to address the challenges of manually identifying excessive privileges assigned to service principals. The impetus for AppHunter stemmed from the practical difficulty of assessing service principal permissions through the Azure portal, where permissions for each service principal must be checked one by one, a process that is prohibitively time-consuming in large environments.

AppHunter is a powerful utility aimed at both offensive (red teamers, security researchers) and defensive (security analysts) operations. Its primary purpose is to quickly enumerate and highlight overly privileged permissions granted to service principals across both Microsoft Entra ID and Azure resources.

During the demo, Nikos Vourdas showcased the tool's functionality:

1. Authentication: AppHunter supports two authentication methods using the device code flow.

• The first authentication is for the Graph API scope, necessary to query Entra ID permissions.
• A second authentication, including the ARM (Azure Resource Manager) scope, is required to query permissions related to Azure subscriptions and resources. This modular approach allows users to tailor the token scope based on their specific enumeration needs.

1. Enumeration Modules: After successful authentication, AppHunter executes several modules to identify dangerous configurations:

• service-principles-dangerous-permissions: This module scans all service principals in the tenant for API permissions that are considered dangerous or highly abusable. The tool maintains a predefined list of such permissions, which the speakers commit to continually updating based on new research and trends. During the demo, it highlighted permissions like Application.ReadWrite.All (from the "Intune Manager" example) and Mail.Read / Mail.ReadWrite (from the "Email Protection" example). The speakers noted that while Mail.Read and Mail.ReadWrite might not directly escalate privileges, they enable significant data exfiltration or manipulation.
• privilege-role-assignment: This module specifically checks for service principals that have been assigned privileged roles within Entra ID. For instance, it would detect if a service principal has been granted Global Administrator privileges, as was demonstrated in the first scenario's Entra ID compromise path.
• subscription-owners-contributors: This module focuses on Azure resource permissions, identifying service principals that hold the highly impactful Owner or Contributor roles on Azure subscriptions. These roles grant extensive control over Azure resources, as showcased in both the first and fourth attack scenarios. The speakers emphasized these two roles because of their potential for maximum damage within an Azure environment.

1. Output: AppHunter's output clearly highlights the identified dangerous permissions and roles, making it easy for users to quickly pinpoint over-privileged service principals without sifting through countless manual portal checks.

The demo effectively illustrated AppHunter's utility as a rapid assessment tool, transforming a complex and time-consuming manual audit into an efficient automated process for both red teams seeking initial access or privilege escalation vectors, and blue teams striving to identify and mitigate critical security gaps.

Defensive Implications

▶ Watch: Step-by-step attack path: abusing Application ReadWrite.All (8:00)

The detailed attack scenarios presented by Marios Gyftos and Nikos Vourdas highlight critical vulnerabilities in how service principals and enterprise applications are managed in Azure. For defenders, the implications are clear: a shift in focus is needed to extend robust security practices beyond human users to encompass these powerful non-human identities.

Here are the key defensive implications and recommended remediations:

1. Comprehensive Audit Log Monitoring:

• Action: Implement continuous and granular monitoring of audit logs for all service principal-related activities. This includes changes to service principal configurations, credential updates (secrets, certificates), role assignments, and API permission grants.
• Why it matters: Audit logs are the primary source of truth for detecting unauthorized modifications or suspicious activity involving service principals. Any change to an application's credentials or permissions should trigger an alert.

1. Leverage Microsoft Workbooks and Reporting:

• Action: Utilize Microsoft Entra workbooks, specifically the Sensitive Operation Report workbook. This workbook is designed to provide alerts on critical changes related to service principals.
• Why it matters: While currently a premium feature, this workbook can significantly reduce the detection time for malicious activity by providing pre-configured alerts for high-risk operations.

1. Enable Azure DevOps Advanced Security Features:

• Action: For organizations heavily relying on Azure DevOps, enable and configure Advanced Security features.
• Why it matters: These features can help detect secrets in code, identify vulnerable dependencies, and provide other security insights that could prevent pipeline exploitation like the one demonstrated.

1. Strict Enforcement of Least Privilege:

• Action: Re-evaluate and rigorously enforce the principle of least privilege for all service principals. Grant only the absolute minimum permissions required for an application to function, and no more.
• Why it matters: Excessive permissions like Application.ReadWrite.All, DeviceManagementApps.ReadWrite.All, or Mail.ReadWrite are goldmines for attackers. Regular audits using tools like AppHunter are crucial to identify and remediate these over-privileges. Understand that some applications are designed by vendors to require broad permissions; in such cases, isolate these applications and monitor them intensely.

1. Treat Enterprise Application Owners as High-Sensitive Users:

• Action: Any user designated as an owner of an enterprise application should be classified and monitored as a high-sensitive user.
• Why it matters: As demonstrated, compromising an application owner can be a direct path to escalating privileges or compromising other service principals, even if the owner's individual user account doesn't have global administrative roles.

1. Mandate Multi-Factor Authentication (MFA) Universally:

• Action: Enforce MFA requirements via Conditional Access policies for all user authentications, irrespective of network location (e.g., inside or outside the corporate network).
• Why it matters: While the talks focused on service principals, the scenario involving Conditional Access exclusions for office networks highlights a common user-centric bypass. Eliminating such exclusions strengthens the overall identity perimeter.

1. Regularly Review Default Configurations:

• Action: Proactively review default configurations in services like Azure DevOps (e.g., enable-shell-tasks-arguments-validation). Do not assume defaults are secure.
• Why it matters: Defaults that favor convenience over security, like disabled argument validation in pipelines, create easy exploitation paths. Configure these settings to be as secure as possible.

1. Proactive Identification with Tools like AppHunter:

• Action: Regularly use tools like AppHunter to scan your environment for over-privileged service principals.
• Why it matters: Manual enumeration is impractical. Automated tools provide a fast and efficient way to discover vulnerabilities before attackers do.

By implementing these defensive strategies, organizations can significantly reduce their attack surface, improve their detection capabilities, and strengthen their overall security posture against the sophisticated threats targeting service principals and enterprise applications in Azure.

Key Takeaways

• Service Principals are a Critical Attack Surface: Organizations must shift their security focus beyond human users to rigorously secure and monitor service principals and enterprise applications, as they are frequently over-privileged and targeted.
• Excessive Permissions Lead to High-Impact Compromises: Permissions like Application.ReadWrite.All, DeviceManagementApps.ReadWrite.All, Mail.ReadWrite, and RoleManagement.ReadWrite.Directory are highly abusable and can lead to full Azure subscription control, arbitrary code execution as NT AUTHORITY\SYSTEM, or sensitive data exfiltration.
• Azure DevOps Administrator is a Powerful Role: Despite not being classified as "privileged" by Microsoft, the Azure DevOps Administrator role can be leveraged to claim orphaned organizations, exploit vulnerable pipelines (especially with enable-shell-tasks-arguments-validation off by default), and extract service principal credentials with Owner rights on Azure subscriptions.
• Default Configurations Often Create Vulnerabilities: Critical security settings, such as disabled argument validation in Azure DevOps pipelines or the undocumented capabilities of DeviceManagementApps.ReadWrite.All, can be exploited if left in their default, less secure states.
• AppHunter is an Essential Tool for Discovery: The custom-developed AppHunter tool provides a fast and efficient way for both offensive and defensive teams to identify over-privileged service principals across Microsoft Entra ID and Azure resources, addressing a significant manual enumeration challenge.
• Comprehensive Monitoring and Least Privilege are Paramount: Continuous monitoring of audit logs for service principal changes, strict enforcement of least privilege for all non-human identities, and treating enterprise application owners as high-sensitive users are non-negotiable for a robust cloud security posture.

About the Speaker(s)

Marios Gyftos is a Senior Cyber Security Consultant with extensive experience in offensive and defensive security operations. His expertise spans various cloud environments, including Azure and AWS, as well as DevOps practices. Marios has a strong background in leading red team and purple team engagements, focusing on identifying and exploiting vulnerabilities to help organizations enhance their security posture.

Nikos Vourdas is a Senior Offense Security Consultant known for his deep knowledge in offensive security. He holds several certifications and has significant experience in ICAS (Identity and Cloud Access Security) and Tyberu TPTs. Nikos is also a proud member of the CFP board of Offensive X, and is active on social media under the handle "Nick V." His work often involves uncovering and demonstrating advanced post-exploitation techniques in complex cloud and hybrid environments.