PS Product SecurityKnowledge Base

🟦 Azure Cloud Attack Chains

Intro: In Azure, the decisive expansion step is often the jump from application compromise to Microsoft Entra-backed identity: managed identity, workload identity, service principal, or a service connection used by delivery tooling.

What this page includes

  • common Azure-native attacker paths
  • managed identity and service principal abuse patterns
  • AKS and CI/CD expansion routes
  • what to hunt in Activity Log, Entra sign-in logs, and AKS logs

Azure Cloud Attack Chain Figure: Common Azure sequence from workload foothold to Entra token abuse and subscription-level control.

Chain 1 — SSRF or app compromise to IMDS to managed identity token abuse

Typical flow

  1. the attacker gets SSRF or command execution in a VM-hosted or container-hosted workload;
  2. they query the Azure Instance Metadata Service or a managed identity token endpoint;
  3. they obtain an access token for the system-assigned or user-assigned managed identity;
  4. they use that token against Key Vault, Storage, ARM, Microsoft Graph, or another Azure API;
  5. the incident expands based on the identity's role assignments.

Why this chain repeats

Managed identity is the right pattern, but it becomes dangerous when:

  • the application can reach the metadata endpoint without meaningful guardrails;
  • one identity is reused across unrelated workloads;
  • the identity has broad rights at resource group, subscription, or tenant scope;
  • defenders do not monitor managed identity sign-ins or downstream token usage.

First things to scope

  • what exact managed identity was used?
  • what roles does it have, and at which scopes?
  • did it access Key Vault secrets, storage, or deployment resources shortly after the first suspicious event?

Chain 2 — leaked service principal secret or certificate to control plane abuse

Typical flow

  1. the attacker finds an app registration secret, certificate, or service connection credential;
  2. they authenticate as a service principal;
  3. they enumerate subscriptions, role assignments, Key Vault access, storage, and deployment resources;
  4. they modify infrastructure or extract secrets and data;
  5. they establish persistence through additional credentials, automation, or role changes.

Service principal credentials are still widely used in older automation. If the credential is long-lived, broadly scoped, and shared across environments, the attacker gets a stable path that outlasts the original foothold.

High-value evidence

  • service principal sign-ins in Microsoft Entra;
  • Azure Activity Log entries for role assignments, deployment changes, networking updates, or diagnostic setting changes;
  • unusual Key Vault secret reads or storage access patterns.

Chain 3 — AKS workload identity or cluster RBAC mis-scope to broader Azure access

Typical flow

  1. the attacker compromises an AKS workload;
  2. they recover the projected service account token and exploit workload identity federation or overly broad Kubernetes permissions;
  3. they reach Azure resources with the mapped Entra identity;
  4. they pull secrets, storage data, or control-plane information;
  5. they pivot back into AKS with better knowledge or stronger privileges.

Why this chain matters

AKS incidents often look like “just Kubernetes” at first. In reality, an AKS workload can become the gateway to Azure-native data and control-plane resources if workload identity, Key Vault access, or service connections are over-scoped.

AKS-specific hunt pivots

  • kube-audit-admin or kube-audit logs for reads or changes to secrets, bindings, and pods;
  • new exec sessions, privileged pod creation, or suspicious namespace activity;
  • Microsoft Entra sign-ins for the federated app or managed identity tied to the workload.

Chain 4 — CI/CD service connection compromise to environment takeover

Typical flow

  1. the attacker steals a pipeline credential, service connection, or secret from CI;
  2. they use it to access Azure resources or AKS clusters;
  3. they push changed manifests, update app settings, replace images, or alter release definitions;
  4. the next deployment turns the incident into persistence.

The defensive lesson

Azure estates often have strong production perimeter controls and weak delivery trust boundaries. Treat service connections like privileged identities, not like generic project plumbing.

Chain 5 — storage, publish profile, or app-level credential exposure to lateral movement

Typical flow

  1. the attacker obtains a Storage SAS, publish profile, or app secret from source control, logs, or an exposed admin surface;
  2. they read deployment artifacts, configuration, or code;
  3. they recover additional credentials or operational details;
  4. they move into the subscription or workload plane with better context.

Why it is underestimated

The first leaked credential is not always the credential that causes the biggest harm. Often it only unlocks the next more privileged identity.

Azure hunting priorities

1) activity and identity timeline

Start by building a joined timeline across:

  • Azure Activity Log for control-plane changes;
  • Microsoft Entra sign-in logs for interactive, service principal, and managed identity activity;
  • AKS resource logs and cluster audit logs where Kubernetes activity may explain the Azure-side calls.

2) look for role or trust expansion

Priority pivots include:

  • new or modified role assignments;
  • newly added federated credentials or app secrets;
  • diagnostic setting changes;
  • unexpected Key Vault reads and secret version access.

Azure CLI pivots

# recent control-plane actions in a resource group
az monitor activity-log list \
  --resource-group <rg-name> \
  --offset 2d

# inspect AKS cluster identity and add-on profile
az aks show -g <rg-name> -n <cluster-name>

# list role assignments for a suspect principal
az role assignment list --assignee <principal-id>

# inspect a managed identity
az identity show -g <rg-name> -n <identity-name>

Defensive defaults that break Azure chains early

  • minimize scope on managed identities and service principals;
  • prefer workload identity patterns over shared long-lived secrets;
  • monitor service principal sign-ins and managed identity sign-ins;
  • send Activity Log and AKS logs to a workspace with useful retention;
  • separate CI identities from runtime identities and from platform administration;
  • lock down Key Vault access by exact workload need, not convenience.