# AutoWarp: Critical Cross-Account Vulnerability in Microsoft Azure Automation Service

Azure Automation sandboxes shared a host network; unauthenticated local MSI token endpoints on other tenants' ports leaked managed-identity JWTs, enabling cross-account Azure control.

- Payout: unconfirmed
- Severity: critical
- Program: Microsoft
- Credited: Yanir Tsarimi
- Disclosed: 2022-03-07
- Write-up quality: 8/10
- Original: https://orca.security/resources/blog/autowarp-microsoft-azure-automation-service-vulnerability/
- Library page: https://bugbountylibrary.com/r/blog%3Aorca-security-resources-blog-autowarp-microsoft-azure-automation-service-vulnerability
- Tags: domain:cloud impact:internal-access impact:privesc kind:bounty platform:blog sev:critical tech:azure technique:recon technique:source-review vuln:access-control vuln:auth-bypass vuln:info-disclosure

**Target:** Azure Automation sandbox host, localhost asset-retrieval/MSI token web service
**Root cause:** The per-sandbox managed identity token endpoint (MSIController at /oauth2/token) was exposed on the shared host network without authentication, and sandboxes were not network-isolated from each other, so any job could reach other tenants' identity endpoints on nearby ports.
**Steps:**
1. Create an Azure Automation account with a system-assigned managed identity (default enabled).
2. Run a Python automation script opening a reverse shell to explore the sandbox filesystem.
3. Read C:\temp\diags\trace.log; find `assetRetrievalEndpoint=http://127.0.0.1:40008`.
4. Decompile orchestrator DLLs with ILSpy; find `/oauth2/token` and `/metadata/identity/oauth2/token` mapped to MSIController.
5. POST to `http://127.0.0.1:<port>/oauth2/token` with header `Metadata: True` and body `resource=https://management.azure.com/`; receive a JWT.
6. Scan ports 40000-41000 with the same request; different ports return tokens for other tenants' managed identities.
7. Use token with Azure CLI (`az vm list`) after assigning a role to confirm it grants management access.
**How found:** Researcher explored the sandbox filesystem, noticed PathExt was set to only .CPL (anomaly), found Orchestrator/temp dirs, and read trace.log revealing a localhost asset-retrieval web service on a high random port. The high random port suggested a workaround for port contention, prompting a port scan and code review of the orchestrator DLLs.
**Exploitation:** Attacker runs code in their own Automation sandbox, scans localhost ports in the 40000+ range, and harvests JWTs from other tenants' MSI endpoints. Each token is bound to the victim's managed identity; if that identity holds Azure RBAC roles, the attacker gains control of the victim's resources and data. Scheduled jobs could repeatedly harvest tokens across many tenants.
**Escalation:** Continuous/scheduled scanning widened the set of compromised tenants; each captured token could be used to pivot into that tenant's Azure subscription depending on assigned roles.
**Insight:** High, seemingly random localhost ports in a shared-host sandbox are a tell that other tenants' services share the network namespace; scan the port range and probe for unauthenticated metadata/token endpoints rather than assuming sandbox isolation.