The function that leaks its own identity
An Azure Function with a managed identity can fetch its own token from a local endpoint. A code-injection bug or an SSRF turns that into the function's cloud rights in an attacker's hands. Here is how, and the fix.
There is no secret to steal, which is exactly why this one slips by. The function hands out its own token.
What it is
Azure Functions and App Service reach a local endpoint to get an Entra token for their managed identity, with no secret stored. An attacker who achieves code execution or SSRF in the function queries that endpoint, receives a token for the managed identity, and calls Azure as the function: Key Vault, storage, role assignments, whatever the identity can do. This is T1552 (unsecured credentials) into T1078 (valid accounts).
Why it works
The token comes from a trusted local endpoint, so there is nothing to leak in code, and the calls are the function’s own identity, so they blend in. The blast radius is whatever the managed identity was granted, usually more than the function needs.
How to detect it
Watch for the managed identity calling Azure APIs outside its normal pattern or from unexpected resources, and for application-layer signs of injection or SSRF in the function.
The fix that holds
Least-privilege the managed identity, patch and harden the function against SSRF and injection, restrict outbound egress, and alert on the identity reaching resources it does not normally use. Do not grant a single function broad subscription rights.
Practice it
We built an Azure Function managed-identity theft scenario in GraphLattice Range so teams learn why one app bug becomes cloud access, and how to bound it.