Microsoft Publishes a Cloud Web App Attack Playbook and Names the Weak Spots Nobody Wants to Own

Key points

• Microsoft has published a Cloud Web Applications Threat Matrix that maps attacks against Azure App Service, AWS Lambda and Google Cloud Functions to the MITRE ATT&CK framework, an industry-standard catalogue of hacker behaviour.
• The matrix flags the Azure App Service Kudu console, a built-in admin terminal, as a repeat offender when deployment credentials leak.
• Subdomain takeover, where an attacker claims a web address a company forgot to clean up, sits in the very first tactic of the matrix.
• It covers eleven attack stages, from setting up infrastructure through to causing damage, all specific to cloud-hosted apps.
• Microsoft frames it as a follow-on to its earlier matrices for Kubernetes and cloud storage.

Microsoft's Security Response Center has put out a new threat matrix for cloud-hosted web applications, and if you run anything on Azure App Service or Google Cloud Functions, read it with a red pen close by. We've covered Microsoft's cloud security moves steadily this quarter, including the perfect-10 Azure AI Foundry flaw patched on 18 September, and this matrix is the more systematic companion to that kind of reactive patching.

A threat matrix is a grid. Down one side are the stages of an attack. Across the top are specific tricks attackers use at each stage. Microsoft has done this before for Kubernetes, the software that runs containerised apps, and for cloud storage. This one covers web apps and serverless functions, meaning code that runs on demand without a server the customer manages.

What is actually new here?

The matrix is new; the attacks aren't. What Microsoft has done is put them in one place and label them with the MITRE ATT&CK vocabulary that security teams already use for tracking attackers. That matters because, in practice, most breach investigations in cloud environments fall apart at the seam between the app team and the platform team. One side owns the code. The other owns the cloud account. Attackers walk through the gap.

Eleven tactics are covered, from Resource Development at the start to Impact at the end.

Which bits should platform teams actually worry about?

The Kudu console entry will land hardest. Kudu is the administrative back end that ships with every Azure App Service. If deployment credentials leak, an attacker with those credentials can browse files and run commands inside the running app. The failure mode is boring and common: credentials pasted into a repo or a shared password manager that too many people can read.

Subdomain takeover keeps appearing in postmortems. A team spins up an app on a provider endpoint, points marketing.example.com at it, then deletes the app and forgets the DNS entry. Someone else registers the same endpoint name and now owns a subdomain that still looks like yours. It's been used to serve malware and harvest logins for years, and it's in the matrix because it still works.

Serverless trigger injection is the newer shape. A user uploads a file to an S3 bucket, which fires a Lambda function that processes it. If the function trusts the file's contents without validation, the attacker has executed code inside your account without ever touching a login page. It's the kind of path that only shows up in postmortems, never in pre-launch threat models.

Should you worry if you don't run cloud infrastructure?

Not today. This is a defenders' document, not a warning about a live breach. But the attacks it catalogues are the ones behind the data leaks that eventually reach customers as breach notification letters. If your bank or retailer runs its web app in the cloud, and almost all of them do, this is the map their security team should be checking against.

One concrete action: if you own an Azure tenant, check whether any App Service has its Kudu endpoint reachable from the public internet, then rotate deployment credentials that predate the last time anyone changed jobs. That's a two-hour audit that most teams haven't done.