Kudu console to managed-identity token: stopping App Service credential theft

Azure App Service ships with the Kudu SCM advanced-tools debug console, and any principal with Contributor can run commands inside the running app. That execution surface is a direct path to the app’s own credentials.

How the attack works

The attacker opens an interactive Kudu SCM session on a production web app, then lists deployment credentials and downloads the site publish profile, exposing the basic-auth deployment user and password. Next they call the instance metadata identity endpoint from inside the worker and receive an access token for the app’s system-assigned managed identity. That token then reads secrets from Key Vault and lists blobs in a storage account the app was permitted to reach. In ATT&CK terms this chains T1059, Command and Scripting Interpreter, with T1552, Unsecured Credentials, and T1078.004, Valid Accounts: Cloud Accounts.

Why it works

The app allowed interactive SCM access with basic auth, and its managed identity carried broad role assignments. The console is not an exploit, it is a feature, so the only thing standing between Contributor and Key Vault was the breadth of the identity’s rights.

How to fix it

You cannot recall an Entra access token that has already been issued. A managed-identity token is only as powerful as the identity’s role assignments, so remove those assignments and the live token authorizes nothing. Rotate the publish profile so the downloaded credentials are dead, and disable basic and SCM auth so the console path cannot be reused. Fleet-wide, deploy only through the pipeline identity and scope every managed identity to least privilege. Scope the access from Key Vault and Storage diagnostic logs plus the identity’s Entra sign-in records, since role assignments show capability, not activity.

Practice it

We built this as a GraphLattice Range scenario so administrators can rehearse the Kudu session, the token mint, and the strip-the-rights containment that neutralizes it.