Exploit SQL Injection in Azure Function App

What this lab covers

You find and exploit an injection flaw in a serverless function, determine whether the function has an identity assigned to it, and use the token that identity can obtain to enumerate and act on Azure resources.

The point is the transition from application layer to cloud control plane. The SQL injection is ordinary, and what makes it consequential is that the compromised component can request tokens for an Azure identity.

It suits application security practitioners moving into cloud and Azure engineers who have not considered what their function identities can reach. No prior Azure experience is assumed.

How managed identity abuse follows application compromise

A managed identity is an Entra ID identity assigned to an Azure resource. The resource obtains tokens from a local endpoint without storing any credential, which is a genuine security improvement over connection strings and keys, and it is the correct pattern.

The consequence is that code execution in the resource is equivalent to holding that identity. Anything that can run code or make requests from inside the function, including an injection flaw with sufficient reach, can request a token and receive one.

Serverless changes the exposure profile in two directions. There is no host to persist on and no operating system to escalate on, which limits some options, and the identity is available immediately without any lateral movement, which removes several steps an attacker would otherwise need.

How to detect this in your own environment

Watch the managed identity's activity in Azure activity logs and resource logs. A function identity has a narrow and repetitive access pattern, so requests for resources outside that pattern are a strong signal.

Enable and monitor function application logs, including query errors. Injection testing generates distinctive database errors before it succeeds, and those errors are often collected and never examined.

Alert on token requests for scopes the application does not normally use. An identity that always talks to one database suddenly requesting a management scope is the moment application compromise becomes cloud compromise.

How to prevent it

Use parameterised queries. This is unglamorous and it is the actual fix, since injection is prevented by separating code from data at the database interface rather than by filtering input.

Scope the managed identity to the specific resources the function needs, at the narrowest role available. The identity is what an attacker inherits, so its assignments define the blast radius of every flaw in that function.

Prefer user-assigned identities with narrow scope over broad system-assigned ones on shared resources, and review role assignments on function identities as carefully as you would for a human administrator.

Real-world context

SQL injection remains among the most persistent application vulnerability classes despite being thoroughly understood, and it appears regularly in disclosures for current software. Serverless deployment does not change its likelihood.

What has changed is the consequence. In a traditional deployment, injection yields database access. In a cloud deployment with an assigned identity, it can yield access to storage, key vaults and management APIs, because the workload holds an identity that reaches them.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application, T1552.005 Cloud Instance Metadata API and T1078.004 Cloud Accounts.

Applying this at work

• Inventory which of your function apps and web apps have managed identities, and what role assignments those identities hold.
• Reduce those assignments to the specific resources and actions required. Broad Contributor assignments on function identities are common and rarely necessary.
• Confirm database access in your functions uses parameterised queries throughout.
• Enable resource logging on function apps and review query errors, which are the early signal of injection testing.
• Alert on token requests from application identities for scopes outside their normal pattern.

Frequently asked questions

Does using serverless reduce application security risk?

It removes host management concerns but not application vulnerabilities. Injection flaws behave the same way, and the assigned managed identity means the consequence can be broader than in a traditional deployment.

What is a managed identity and why is it a target?

An Entra ID identity assigned to an Azure resource, which obtains tokens without storing credentials. It is a target because any code execution in that resource can request a token, inheriting whatever the identity is permitted to do.

Are managed identities still the right approach?

Yes. They remove stored credentials, which eliminates a whole class of leak. The requirement is to scope their role assignments narrowly, so that inheriting the identity is not equivalent to inheriting the subscription.

Do I need my own Azure account to practice this?

No. The lab runs in a live Azure environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.