Threat Matrix: Mapping threats across cloud web applications

1. Executive summary

Microsoft has published a new MITRE ATT&CK-aligned "Cloud web applications threat matrix" cataloguing attack techniques against cloud-hosted web applications and serverless platforms (Azure App Service, AWS Lambda, GCP Cloud Run/Cloud Functions and equivalents). This is a defensive framework publication, not an incident report: no CVEs, no named actor, no observed victims. Its value to EMEA financial services clients is as a gap-analysis instrument — the matrix documents concrete, platform-specific attack paths (Kudu/SCM console abuse, deployment-slot swapping for defense evasion, IMDS/IDENTITY_ENDPOINT token theft, WebJob persistence, Logic Apps API-connection lateral movement, denial-of-wallet) that routinely cross the application/cloud boundary where most financial-sector detection programmes are weakest. No verified reference data resolved for this item; all technical detail below is single-sourced to the Microsoft blog and should be treated accordingly.

2. Regulatory framing

No specific NIS2 article is directly engaged by this item. The framework is generic guidance with no incident, victim, or exploit event to trigger NIS2 Art. 23 reporting duties; NIS2 Art. 21(2)(d) supply-chain security measures are addressed adequately through the DORA rows for financial-sector entities.

3. Technical analysis & attack chain

This is a framework publication, not an observed campaign — there is no single confirmed attack chain. The matrix organises techniques across eleven ATT&CK tactics. The technique catalogue below is single-sourced (Microsoft Security Blog, 2026-09-09); the platform-specific mechanics are the actionable content.

Resource Development

• Subdomain takeover: deleting a cloud application without removing its DNS record pointing at a reusable provider endpoint allows an actor to re-register the address, intercept traffic, serve malicious content or harvest credentials.

Initial Access

• Application vulnerability: public-facing apps with flaws in own code, framework, or third-party dependencies yield code execution in the web-app context.
• Code injection in connected repository: malicious commits to a repo auto-synced to production execute under legitimate workflows. Microsoft's worked example: commit access to a GitHub repository configured to deploy GCP Cloud Functions via Cloud Build triggers deploys attacker code through the legitimate pipeline.
• Compromised container images: write access to a private registry lets an actor plant or tamper images that execute on next pull.
• Exposed administrative interfaces: internet-exposed or misconfigured management planes. Named example: Azure App Service Kudu interface exposed to the internet — with sufficient credentials, command execution in the app environment.
• Event-driven trigger manipulation: crafted file uploads, queue messages or API calls force serverless functions to process attacker data. Worked example: modified image file with crafted payload uploaded via a legitimate web form → stored in S3 → triggers an AWS Lambda processing function → without validation, unintended behaviour up to RCE.
• Compromised deployment credentials: Azure App Service deployment/SCM credentials grant file access, command execution, or application modification without touching source code.

Execution

• Exploit public-facing application for RCE in the web-app context, then pivot to attached resources.
• Abuse built-in consoles: Azure App Service Kudu console — browse files, execute commands, tamper with application code.
• Malicious site extensions: Azure App Service site extensions run with the app's full permission set (request data, filesystem, environment variables) and install from a NuGet-based feed accepting third-party submissions — typosquashed or compromised packages execute in application context.

Persistence

• Scheduled/event-triggered job modification: creating or modifying an Azure App Service WebJob runs attacker code periodically regardless of application updates.
• Source-code modification: edits to git repo, container image, or deployment package propagate automatically via CI/CD and become canonical — tainted code is redeployed on every rebuild or scale-out.
• Valid cloud accounts: compromised Entra ID user with owner-level subscription permissions can read/modify function app resources in scope.

Privilege Escalation

• Workload identity credential abuse: web apps hold identities/service accounts with permissions over storage, databases, AI services; connection strings and keys sit in app configuration or environment variables.
• IMDS/identity endpoint token theft: in Azure App Services, the managed identity token is obtainable from the local identity endpoint defined in the IDENTITY_ENDPOINT environment variable — code execution on the instance yields an access token carrying the managed identity's permissions to other Azure resources.

Defense Evasion

• Staging/preview environment abuse: Azure App Service deployment slots, AWS Lambda aliases, GCP Cloud Run revision tags. An actor with slot-management permissions either swaps malicious code into production or runs it on the slot's separate URL while production telemetry stays clean.
• Disable or modify cloud logging: turning off diagnostic logging on the web app, deleting/altering log data, shortening retention, redirecting log output.

Credential Access

• Brute-force basic authentication: Azure App Service Kudu (SCM site) and FTP endpoints support basic auth; user-scoped deployment credentials are shared across all App Services in the subscription the user can access — one guessed password yields deployment access to multiple applications.
• Unsecured credentials in configuration: secrets in environment variables/config files. Named example: an Azure Function storing an Azure OpenAI resource key and endpoint in application settings — read access to the environment enables authorised data-plane API calls to the OpenAI resource.

Discovery

• Read cloud storage holding source: GCP Cloud Run function code is stored in a project bucket — a user with storage read access can review source code.
• Discover cloud resources from app config: service URLs, API endpoints, database connection strings, resource identifiers in environment variables, network connections, or code.
• Query cloud metadata API for instance details, network configuration, identity credentials.

Lateral Movement

• Abuse managed connectors: Azure Logic Apps API connections are standalone resources storing authenticated sessions to Office 365, Slack, SQL databases. An actor with resource-group permissions creates a new app reusing existing connectors — triggering actions on connected services via stored credentials without extracting the underlying secrets.

Collection

• Database access via app identity or hardcoded connection string — query, extract, modify; internet-accessible databases may need only read permission on the web app.
• Sensitive data in application logs: misconfigured verbose/debug logging leaks credentials, PII, internal paths, dependency versions, cloud resource names. Named example: AWS Lambda pipes all stdout to CloudWatch Logs — debug-level logging left on in production puts sensitive data in the log group; CloudWatch read access harvests it.

Impact

• Data deletion/corruption in app or connected storage/databases; data theft; content defacement for reputation damage or propaganda.
• Denial-of-wallet: request flooding forces scale-out and inflated charges; Microsoft's example is repeated invocation of a Cloud Function with high memory allocation inflating billing via execution time.
• Resource hijacking: cryptocurrency mining, mass scanning, traffic proxying on app compute/network/storage.

Confidence caveat: every technique and platform example above is single-sourced to the Microsoft blog. The mechanics are consistent with well-established cloud attack tradecraft, but no second source corroborates the specific Azure/GCP/AWS examples, and no observed-in-the-wild exploitation is claimed. Verify against your own telemetry before treating any technique as present in your environment.

4. Mitigation & containment

No vendor patch applies — this is a hardening framework. Actions below are drawn from Microsoft's stated defensive priorities plus the concrete platform mechanics in the matrix. Prioritise by the credential-shared-across-subscription and identity-endpoint issues, which give the widest blast radius.

P1 — within 24h (highest-leverage exposure checks)

• Audit Azure App Service Kudu/SCM and FTP endpoints for internet exposure; restrict SCM access to authorised networks. Check whether user-scoped deployment credentials (shared subscription-wide) are in use — where possible move to per-app or identity-based deployment credentials and rotate any user-scoped credentials that have existed for an extended period.
• Enforce MFA on all identities with deployment, slot-management, or owner-level subscription permissions — Microsoft's first recurring priority.
• Verify diagnostic logging is enabled and immutable on all production web apps and function apps; alert on any change to logging configuration, retention policy, or log redirection (this is the matrix's defense-evasion technique).

P2 — within 72h

• Inventory and restrict staging/preview surfaces: Azure deployment slots, Lambda aliases, Cloud Run revision tags. Confirm whether non-production slots are directly reachable at their separate URLs and whether promotion permissions are least-privilege.
• Review permissions on Logic Apps API connections and equivalent connector resources in each resource group; these store live authenticated sessions to third-party services.
• Audit scheduled/event-triggered jobs (WebJobs and equivalents) for unauthorised or unexplained entries — the matrix's primary persistence mechanism.
• Review repository-to-production sync paths (GitHub → Cloud Build → Cloud Functions, and equivalents): require branch protection, signed commits, and review on anything auto-deploying.
• Check for dangling DNS records pointing at deleted cloud applications/services (subdomain takeover exposure).

P3 — within 7 days

• Remove secrets, connection strings and resource keys from application settings, configuration files and source code; migrate to workload identities and managed secrets stores. Specifically inventory Azure Functions holding Azure OpenAI or other data-plane keys in environment variables.
• Restrict IMDS/identity endpoint exposure where platform controls allow; assume any code execution in an App Service yields the managed identity token and scope managed identity permissions accordingly (least privilege on storage, databases, AI services).
• Pin container images and verify registry provenance; restrict private registry write access. Restrict site-extension installation to trusted feed sources only.
• Apply resource quotas, concurrency limits, cost guardrails and spending alerts on function apps to blunt denial-of-wallet.
• Validate file-upload handling in any event-driven function (S3 → Lambda pattern) for payload validation before processing.
• Centralise security-relevant logs in protected locations; test backup and recovery for destructive-attack scenarios.
• Use the matrix itself as a coverage checklist: map each technique to an existing detection or control and document the gaps. Microsoft notes Defender for Cloud and Defender XDR surface related signals (cloud resource posture, workload activity, identity activity, cross-domain incidents) depending on configuration and telemetry.

5. Indicators of compromise

No indicators of compromise available in the source material. The publication is a threat-model framework with no observed intrusions, actors, malware samples, or atomic indicators.

Behavioural indicators (from the matrix's technique descriptions — these are attack-pattern indicators to hunt for, not observed campaign artefacts):

6. Detection

The sources contain no malware artefacts, file hashes, command-line strings, or distinctive threat strings — the matrix describes techniques, not samples. A YARA rule is not applicable. However, the matrix names concrete, loggable platform behaviours, so Sigma-style detection logic is authorable from the source material.

title: Azure App Service techniques from Microsoft Cloud Web Applications Threat Matrix
id: 8f3c2a91-6d47-4b8e-9f21-2c5ad0e77b41
status: experimental
description: >
  Detects management-plane behaviours corresponding to techniques in Microsoft's
  cloud web applications threat matrix: WebJob creation/modification (persistence),
  deployment slot operations (defense evasion), diagnostic logging changes
  (defense evasion), and SCM basic-auth brute force (credential access).
  Techniques, not campaign artefacts - tune to baseline before production use.
references:

  - https://www.microsoft.com/en-us/security/blog/2026/09/09/threat-matrix-mapping-threats-across-cloud-web-applications/
author: Adverse Trace
date: 2026-09-10
logsource:
  product: azure
  service: activitylogs
detection:
  selection_webjob:
    operationName|contains:

      - 'Microsoft.Web/sites/slots/webjobs/write'
      - 'Microsoft.Web/sites/webjobs/write'
  selection_slot:
    operationName|contains:

      - 'Microsoft.Web/sites/slots/slotsswap/action'
      - 'Microsoft.Web/sites/slotsswap/action'
  selection_logging:
    operationName|contains:

      - 'Microsoft.Web/sites/config/web/write'
    properties.httpLogs|exists: true
  condition: 1 of selection_*
falsepositives:

  - Legitimate CI/CD slot swaps and WebJob deployments - correlate with change windows
  - Routine diagnostic configuration changes by authorised operators
level: medium

title: Repeated failed basic authentication against Azure App Service SCM/Kudu site
id: c47e1b02-9a35-4f6d-8e10-71b9c3f4a2d8
status: experimental
description: >
  Credential-access technique from the cloud web applications threat matrix:
  brute force of user-scoped deployment credentials on the Kudu/SCM site or FTP
  endpoints. User-scoped credentials are shared across all App Services the user
  can access, so success has subscription-wide impact.
references:

  - https://www.microsoft.com/en-us/security/blog/2026/09/09/threat-matrix-mapping-threats-across-cloud-web-applications/
author: Adverse Trace
date: 2026-09-10
logsource:
  product: azure
  service: appservicehttplogs
detection:
  selection:
    csHost|contains: '.scm.'
    scStatus:

      - 401
      - 403
  filter_success:
    scStatus:

      - 200
  condition: selection and not filter_success | count() by csUriStem > 10 within 5m
falsepositives:

  - Misconfigured deployment agents with stale credentials
level: medium

Note: the Sigma field names above follow standard Azure log schemas; validate against your actual log pipeline before deployment, as the source does not specify exact field names.

7. Sources

• Microsoft Security Blog, "Threat Matrix: Mapping threats across cloud web applications," https://www.microsoft.com/en-us/security/blog/2026/09/09/threat-matrix-mapping-threats-across-cloud-web-applications/, 2026-09-09

8. Adverse Trace position

This is a framework publication, not an active threat: no severity rating, no CVEs, no CISA-KEV entries, no attribution, and no observed victims — and we will not manufacture any. Its significance for EMEA financial services is that it consolidulates the specific attack surface of cloud web apps and serverless estates — deployment credentials shared across subscriptions, identity-endpoint token theft, slot-swap evasion, connector-based lateral movement, denial-of-wallet — into an ATT&CK-formatted checklist that most client detection programmes have never systematically covered, because app-layer and cloud-layer telemetry are investigated separately. All technical content is single-sourced to Microsoft; we assess the mechanics as credible and consistent with established cloud tradecraft, but clients should validate technique coverage against their own environments rather than assume presence. Adverse Trace will use the matrix as the basis for cloud web-app coverage assessments in upcoming client reviews, will monitor for any follow-on Microsoft publications mapping real-world actor activity to these techniques, and will issue a supplemental advisory if exploitation of any named technique is observed in the financial sector.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.