Azure Automation Public Configuration: Detecting and Mitigating Cross-Tenant Identity Takeover

Introduction

A critical security issue has emerged concerning the default configuration of Azure Automation, specifically regarding public network exposure and a chain of code flaws. Microsoft has addressed a configuration that is public-by-default, which, combined with specific vulnerabilities, creates a vector for cross-tenant identity takeover.

For defenders, this is a high-priority event. The potential impact allows an attacker to seize the identity of another tenant, subsequently accessing data, credentials, and cloud workloads belonging to unrelated organizations. This breach of tenant isolation undermines the fundamental trust model of shared cloud infrastructure. Immediate action is required to audit Automation Accounts for public exposure and restrict access.

Technical Analysis

Affected Platform

Product: Microsoft Azure Automation
Component: Automation Account Network Configuration and Webhook/Management endpoints

The Vulnerability Chain

The issue stems from two primary factors:

Public-by-Default Configuration: Historically, Automation Accounts were configured to allow public network access by default unless explicitly restricted. This exposure includes the management endpoints and potentially webhooks used to trigger runbooks.
Code Flaws (Identity Takeover): A chain of code flaws was identified that, when combined with public accessibility, allows attackers to manipulate authentication flows. Specifically, attackers can leverage the exposed endpoints to impersonate or seize the managed identities (RunAs accounts) associated with the Automation Account.

Attack Mechanism: An attacker scans for Azure Automation Accounts with public network access enabled. By interacting with the exposed endpoint and exploiting the code flaws, they can perform actions outside their intended tenant context. This allows them to:

Authenticate as the Automation Account's Managed Identity.
Access resources in the victim tenant (e.g., Key Vaults, Storage Accounts, SQL Databases) that the identity has permissions for.
Dump credentials or secrets stored within the Automation Account variables.

Exploitation Status

While Microsoft has addressed the code flaws, the configuration risk remains prevalent in environments where legacy settings persist. No CVE identifiers were provided in the initial advisory, requiring defenders to focus on the configuration posture and detection of anomalous authentication attempts involving Automation identities.

Detection & Response

Sigma Rules

The following Sigma rules target suspicious modifications to Automation Account settings and anomalous access patterns associated with the RunAs identity.

YAML

---
title: Azure Automation Public Network Access Enabled
id: 9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects when the Public Network Access setting for an Azure Automation Account is set to Enabled, increasing exposure to cross-tenant attacks.
references:
  - https://learn.microsoft.com/en-us/azure/automation/automation-managed-identities
author: Security Arsenal
date: 2026/05/15
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    OperationName|startswith: 'Microsoft.Automation/automationAccounts/write'
    Properties|contains: 'publicNetworkAccess'
  condition: selection
falsepositives:
  - Legitimate administrative configuration changes
level: high
---
title: Azure Automation RunAs Identity Anomalous Usage
id: 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects successful authentication events using an Azure Automation RunAs (Managed Identity) principal from an unusual IP address or location.
references:
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/05/15
tags:
  - attack.credential_access
  - attack.t1078.004
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    AppDisplayName|contains: 'AzureAutomation'
    ServicePrincipalCredentials|startswith: 'MSI'
    Status: 'Success'
  filter:
    NetworkLocationDetails|contains:
      - 'TrustedMicrosoftServices'
  condition: selection and not filter
falsepositives:
  - Rare legitimate manual execution by administrator
level: high
---
title: Azure Automation Webhook Secret Export
id: 2b3c4d5e-6f7a-8b9c-0d1e-2f3a4b5c6d7e
status: experimental
description: Detects attempts to list or export secrets for Azure Automation Webhooks, a potential precursor to unauthorized trigger.
references:
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/05/15
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  product: azure
  service: activitylogs
detection:
  selection:
    OperationName: 'microsoft.automation/automationAccounts/webhooks/list/action'
  condition: selection
falsepositives:
  - Auditing or diagnostic script runs
level: medium

KQL (Microsoft Sentinel)

This query hunts for Automation Accounts where public network access is currently enabled, providing an immediate remediation list.

KQL — Microsoft Sentinel / Defender

AzureResources
| where type =~ 'microsoft.automation/automationaccounts'
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| where isnull(publicNetworkAccess) or publicNetworkAccess =~ 'Enabled'
| project SubscriptionId, ResourceGroup, Name, publicNetworkAccess, Location
| order by ResourceGroup asc

Velociraptor VQL

This VQL artifact hunts for processes on administrative workstations that are using Azure PowerShell to modify Automation Account properties, specifically looking for Set-AzAutomationAccount or Update-AzAutomationAccount invocations.

VQL — Velociraptor

-- Hunt for Azure PowerShell commands modifying Automation Account Network Settings
SELECT 
    Pid, 
    Name, 
    CommandLine, 
    Exe, 
    Username, 
    CreateTime
FROM pslist()
WHERE Name =~ 'pwsh.exe' OR Name =~ 'powershell.exe'
  AND CommandLine =~ 'Set-AzAutomationAccount'
  AND (CommandLine =~ 'PublicNetworkAccess' OR CommandLine =~ '-DisablePublicNetworkAccess')

Remediation Script (PowerShell)

This script enumerates all Automation Accounts across accessible subscriptions and disables public network access to mitigate the risk of cross-tenant takeover.

PowerShell

# Remediation Script: Disable Public Network Access for Azure Automation Accounts
# Requires Az PowerShell module

Connect-AzAccount -Identity

$subscriptions = Get-AzSubscription

foreach ($sub in $subscriptions) {
    Write-Host "Processing Subscription: $($sub.Name)"
    Set-AzContext -SubscriptionId $sub.Id | Out-Null
    
    $automationAccounts = Get-AzAutomationAccount
    
    foreach ($account in $automationAccounts) {
        $currentAccess = $account.PublicNetworkAccess
        
        if ($currentAccess -ne 'Disabled') {
            Write-Host "Hardening Automation Account: $($account.AutomationAccountName) in Resource Group: $($account.ResourceGroupName)" -ForegroundColor Yellow
            
            try {
                # Set PublicNetworkAccess to Disabled
                $account.PublicNetworkAccess = 'Disabled'
                Update-AzAutomationAccount -ResourceGroupName $account.ResourceGroupName `
                                           -Name $account.AutomationAccountName `
                                           -PublicNetworkAccess Disabled
                                           
                Write-Host "Successfully disabled public access for $($account.AutomationAccountName)." -ForegroundColor Green
            }
            catch {
                Write-Error "Failed to update $($account.AutomationAccountName): $_"
            }
        }
        else {
            Write-Host "Automation Account $($account.AutomationAccountName) is already secured." -ForegroundColor Cyan
        }
    }
}
Write-Host "Remediation complete."

Remediation

To fully secure your environment against this threat, perform the following steps immediately:

Audit Automation Accounts: Review all existing Automation Accounts in your Azure estate. Identify any that have Public Network Access set to Enabled.
Disable Public Network Access: Configure the Public Network Access property to Disabled for all Automation Accounts. This prevents external access to management endpoints and webhooks from the public internet.
- Path in Azure Portal: Automation Account -> Networking -> Public network access -> Disabled.
Configure Private Endpoints: For access requirements, implement Azure Private Endpoints to ensure connectivity only occurs from within your virtual network.
Review Managed Identity Permissions: Conduct a least privilege review of the System Assigned and User Assigned Managed Identities used by your Automation Accounts. Ensure they do not have excessive permissions (e.g., Owner, Contributor) on production resources unless strictly necessary.
Rotate Credentials: If an Automation Account was exposed with public access, rotate the Run As certificates and any connection credentials stored in the Account immediately.

Official Vendor Advisory: Refer to the latest Azure Security Updates for official guidance on the code flaw patches and configuration best practices.

Related Resources

Security Arsenal Alert Triage Automation AlertMonitor Platform Book a SOC Assessment platform Intel Hub