Privilege Escalation on Azure

Privilege Escalation in Azure environments often exploits misconfigured role assignments, overly permissive service principals, and inadequate resource access controls. Unlike traditional web applications, Azure's privilege escalation vulnerabilities leverage the cloud platform's identity and access management (IAM) capabilities to gain unauthorized elevated permissions.

One common pattern involves Service Principal abuse. When applications authenticate using managed identities or service principals with excessive permissions, attackers can exploit these credentials to escalate their privileges. For example, a compromised web app might use a service principal with Contributor role on a subscription, allowing the attacker to create new resources, modify existing ones, or even elevate to Owner-level access.

// Vulnerable: Service principal with excessive permissions
const { DefaultAzureCredential } = require("@azure/identity");
const { KeyVaultSecretClient } = require("@azure/keyvault-secrets");

const credential = new DefaultAzureCredential();
const client = new KeyVaultSecretClient(
    vaultUrl, 
    credential
);
// This service principal likely has more permissions than needed
// If compromised, attacker gains access to all secrets in the vault

Another Azure-specific escalation vector involves Managed Identity privilege chains. When a managed identity is assigned to multiple resources with different permission levels, attackers can move laterally between resources. For instance, a managed identity with Reader access to a storage account and Contributor access to a web app could be used to modify the web app's configuration, potentially leading to code execution and further privilege escalation.

Azure Resource Manager (ARM) template deployments present another attack surface. If deployment templates contain hard-coded administrative credentials or use overly permissive service principals, attackers can modify these templates to include malicious resources or escalate existing permissions. This is particularly dangerous in CI/CD pipelines where ARM templates are automatically deployed.

// Vulnerable: Overly permissive role assignment in ARM template
param subscriptionId string
param resourceGroupLocation string

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: 'storage${uniqueString(resourceGroup().id)}'
  location: resourceGroupLocation
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

// Dangerous: Granting Contributor role to a service principal
// that might be compromised or overly broad
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
  name: guid(storageAccount.id, 'contributor')
  properties: {
    roleDefinitionId: '/subscriptions/${subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c'
    principalId: 'service-principal-object-id'
    principalType: 'ServicePrincipal'
    scope: storageAccount.id
  }
}

Cross-tenant privilege escalation is another Azure-specific concern. When organizations use B2B collaboration features, misconfigured guest user permissions can allow attackers to elevate privileges across tenant boundaries. This often occurs when guest users are granted Owner or Contributor roles on resources without proper validation of their organizational affiliation.

Detecting privilege escalation vulnerabilities in Azure requires specialized scanning that understands the platform's unique security model. middleBrick's Azure-specific scanning examines role assignments, service principal permissions, and resource configurations to identify potential escalation paths.

The scanner analyzes Azure Active Directory role assignments to detect overly permissive configurations. It examines the PrincipalId, RoleDefinitionId, and Scope properties of role assignments to identify where users or service principals have been granted excessive permissions. For example, it flags situations where a service principal has Contributor or Owner roles on entire subscriptions rather than specific resource groups.

// Example finding from middleBrick Azure scan
{
  "severity": "high",
  "category": "Privilege Escalation",
  "title": "Service Principal with Excessive Subscription Permissions",
  "description": "The service principal 'app-identity' has Contributor role on the entire subscription 'sub-12345', allowing potential privilege escalation.",
  "remediation": "Restrict the service principal to specific resource groups and use least-privilege principles.",
  "impact": "High - Attacker could create, modify, or delete any resource in the subscription",
  "location": "azure://management.azure.com/subscriptions/sub-12345/providers/Microsoft.Authorization/roleAssignments/abc-123"
}

middleBrick also scans for Managed Identity configurations that could enable privilege escalation. It examines the identity assignments across resources to identify chains where a single managed identity has varying permission levels across different resources. The scanner specifically looks for patterns where a managed identity with read-only access to one resource and write access to another could be exploited for lateral movement.

Azure Resource Manager template analysis is another critical detection capability. The scanner parses Bicep and ARM templates to identify hard-coded credentials, overly permissive role assignments, and dangerous deployment patterns. It resolves $ref references and cross-references template definitions with actual deployed resources to identify discrepancies between intended and actual security postures.

For AI/ML workloads running on Azure, middleBrick's LLM security features detect prompt injection vulnerabilities that could lead to privilege escalation through AI systems. This includes scanning for system prompt leakage, excessive agency detection, and unauthenticated LLM endpoints that could be exploited to gain unauthorized access to sensitive data or functions.

Remediating privilege escalation vulnerabilities in Azure requires implementing the principle of least privilege and using Azure's native security features. The primary approach is to implement Role-Based Access Control (RBAC) with minimal necessary permissions and regularly audit role assignments.

For service principals and managed identities, use Azure's built-in roles judiciously and avoid custom roles unless absolutely necessary. When custom roles are required, define them with the minimum permissions needed for the specific task. Use the "NotActions" property to explicitly deny permissions that shouldn't be available, even if they're included in a broader role.

// Secure: Principle of least privilege implementation
param resourceGroupLocation string

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: 'storage${uniqueString(resourceGroup().id)}'
  location: resourceGroupLocation
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

// Secure: Custom role with minimal permissions
resource customRole 'Microsoft.Authorization/roleDefinitions@2020-04-01-preview' = {
  name: 'storage-reader-writer-20231001'
  properties: {
    roleName: 'Storage Reader Writer'
    description: 'Can read and write to storage but cannot delete or modify permissions'
    permissions: [
      {
        actions: [
          'Microsoft.Storage/storageAccounts/blobServices/containers/read',
          'Microsoft.Storage/storageAccounts/blobServices/containers/write'
        ]
        notActions: [
          'Microsoft.Storage/storageAccounts/delete',
          'Microsoft.Storage/storageAccounts/queueServices/queues/write'
        ]
      }
    ]
    assignableScopes: [
      '/subscriptions/${subscriptionId}/resourceGroups/${resourceGroup().name}'
    ]
  }
}

// Secure: Assign minimal role to service principal
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
  name: guid(storageAccount.id, 'storage-reader-writer')
  properties: {
    roleDefinitionId: customRole.id
    principalId: 'service-principal-object-id'
    principalType: 'ServicePrincipal'
    scope: storageAccount.id
  }
}

Implement Azure AD Privileged Identity Management (PIM) to control and monitor privileged role assignments. PIM provides just-in-time access to privileged roles, requiring approval for role activation and providing audit trails of privilege usage. This significantly reduces the attack surface for privilege escalation by limiting the time window during which elevated permissions are active.

Use Azure Policy to enforce security standards across your Azure environment. Create policies that restrict role assignments, enforce naming conventions for service principals, and require justification for privileged role assignments. For example, you can create a policy that prevents Contributor or Owner roles from being assigned to service principals unless explicitly approved.

// Secure: Azure Policy to prevent excessive role assignments
resource privilegeEscalationPolicy 'Microsoft.Authorization/policyDefinitions@2021-06-01' = {
  name: 'prevent-excessive-role-assignments'
  properties: {
    policyType: 'Custom'
    mode: 'All'
    displayName: 'Prevent Excessive Role Assignments'
    description: 'Prevent assignment of Contributor or Owner roles to service principals'
    metadata: {
      version: '1.0.0'
      category: 'Security'
    }
    policyRule: {
      if: {
        allOf: [
          {
            field: 'type'
            equals: 'Microsoft.Authorization/roleAssignments'
          }
          {
            field: 'properties/roleDefinitionId'
            contains: 'b24988ac-6180-42a0-ab88-20f7382dd24c' // Contributor
          }
          {
            field: 'properties/principalType'
            equals: 'ServicePrincipal'
          }
        ]
      }
      then: {
        effect: 'deny'
      }
    }
  }
}

Regularly audit Azure AD sign-in logs and Azure Activity logs to detect suspicious privilege escalation attempts. Use Azure Monitor to create alerts for unusual role assignment patterns, such as multiple role assignments being created in a short time period or role assignments being created outside of normal business hours.

For applications using managed identities, implement resource-specific permissions rather than subscription-wide permissions. Use Azure's resource-specific RBAC roles to limit the scope of what each managed identity can access. For example, instead of granting Contributor access to an entire resource group, grant specific permissions to individual resources like storage accounts, key vaults, or web apps.