The workflow that grants itself a role
An Azure Logic App runs as a managed identity that often holds standing subscription rights. Whoever can edit the workflow can act as that identity, read Key Vault, and assign a role. Here is the path, and how to close it.
The most over-privileged identity in the subscription is often the one nobody is watching: a workflow.
What it is
An Azure Logic App executes as a managed identity that frequently holds broad rights (sometimes Contributor) over the subscription. An attacker who can edit the workflow, or trigger one with an HTTP request, adds steps that act as that identity: read Key Vault, call the ARM API, or write a role assignment. The actions appear as the Logic App, not the attacker. This is T1648 (serverless execution) with T1098 (account manipulation) and T1552 (unsecured credentials).
Why it works
The managed identity is production-privileged but loosely guarded, and it is independent of any user, so resetting a developer’s password does nothing while the workflow keeps acting.
How to detect it
In the Azure Activity log, look for a workflow edit followed by its managed identity reading Key Vault or writing a role assignment, with no change ticket.
The fix that holds
Disable and revert the workflow, reverse the role it granted, and rotate any secrets it read. Then least-privilege the managed identity (not Contributor), control who can edit Logic Apps, and alert on role assignments made by managed identities.
Practice it
We built a Logic Apps managed-identity scenario in GraphLattice Range so teams learn to revert the workflow and reverse the grant, then least-privilege the identity.