Azure SQL exfiltration: no password to reset, just a managed identity

Managed identities remove passwords, which is good, but if you over-grant one, the attacker who compromises the app inherits the data access. There is no SQL login or password to reset, because the principal is the identity itself.

How the attack works

A web application’s managed identity was granted db_datareader, and in practice broader, on an Azure SQL database holding customer records. After compromising the app, the attacker uses that identity’s token to authenticate to SQL, which looks normal at first, then shifts to broad SELECT across customer and PII tables, far outside the app’s usual narrow queries. They initiate a BACPAC export of the whole database to a storage account outside the expected resource group, and the copy is written to attacker-reachable storage. The SQL audit log captures the query-pattern shift, the Activity Log records the export, and the destination storage diagnostics confirm where it landed. In ATT&CK terms this is T1213, Data from Information Repositories, with T1537, Transfer Data to Cloud Account.

Why it works

The identity held read of everything when the app needed only a few views, and no row or column controls narrowed it. The over-grant was the whole vulnerability.

How to fix it

Resetting a SQL admin password or rotating a connection string is irrelevant to token auth. Because the principal is the managed identity, you strip its database role memberships, revoking db_datareader and any broader grant, then block the export storage target and isolate the compromised app host. Afterward, right-size the identity to least privilege with only the views and columns the app needs, enforce row and column controls, and audit every database principal’s grants against actual query patterns.

Practice it

We built this as a GraphLattice Range scenario so responders revoke the identity’s database roles instead of resetting a password that does not exist here.