Skip to content

Beginner Friendly red team icon   azure

Execute Azure Credential Shuffle to Achieve Objectives

This beginner-friendly red team lab walks you through the Azure kill chain, showing how attackers work their way to privileged access by repeating cycles of enumeration, lateral movement, and privilege escalation. Starting from a single leaked password, you perform the classic credential shuffle across Entra ID, service principals, an Azure VM, and storage accounts until you reach sensitive data. It reinforces how password reuse and hardcoded credentials remain just as dangerous in Azure as they are on-premises.

Overview

This beginner-friendly red team lab walks you through the Azure kill chain, showing how attackers work their way to privileged access by repeating cycles of enumeration, lateral movement, and privilege escalation. Starting from a single leaked password, you perform the classic credential shuffle across Entra ID, service principals, an Azure VM, and storage accounts until you reach sensitive data. It reinforces how password reuse and hardcoded credentials remain just as dangerous in Azure as they are on-premises.

Scenario

After gaining initial access to Mega Big Tech, your red team recovered a password from the connection string of a compromised Azure Web App. You are tasked with turning that foothold into privileged access and reaching sensitive business data to demonstrate impact.

Lab prerequisites
  • Basic Windows command-line knowledge
  • Familiarity with Azure PowerShell (Az and AzureAD modules)
Learning outcomes
  • Enumerate Entra ID users, groups, administrative units, and scoped role assignments
  • Abuse the Authentication Administrator role to reset another user's password
  • Take over a service principal by adding a new client secret via Microsoft Graph
  • Request and inspect Azure access tokens (JWTs) with Get-AzAccessToken
  • Enumerate RBAC role assignments and read blobs from Azure storage containers
  • Move laterally to an Azure VM using PowerShell Remoting and Evil-WinRM
  • Perform VM post-exploitation, including querying the Instance Metadata Service and hunting Custom Script Extension files for hardcoded credentials
Real-world context

Any sufficiently complex cloud tenant becomes a tangled web of object-to-object control where password reuse and hardcoded credentials enable lateral and vertical movement. Defenders reduce this risk with strong credential hygiene, Key Vault, password rotation, and regular penetration testing.

KEY TAKEAWAY

Cloud intrusions are credential relay races rather than single compromises. Each identity is used to reach the next, so the useful defensive question is not how the attacker got in but which handoff you could have prevented or noticed.

What this lab covers

You work through a full Azure kill chain, moving between identities as each one gives access to the next, and reach an objective that none of the credentials could have reached alone.

The lab teaches structure rather than a single technique. Once you can see an intrusion as a sequence of handoffs, both attack planning and defensive prioritization become considerably clearer.

It assumes no prior Azure experience and works well as a capstone after the individual Entra ID labs.

How the Azure kill chain works

The chain has recognizable stages. Reconnaissance establishes the tenant and its identities, initial access obtains one credential, enumeration determines what that credential reaches, lateral movement acquires another identity, and the objective is reached with whichever credential finally permits it.

Service principals are the usual currency in the middle stages. They are numerous, they are not covered by the interactive controls that protect users, and an identity with rights over a service principal can add credentials to it and then authenticate as it.

The critical property is that no single step is remarkable. Reading the directory is normal, adding a credential to an application is an administrative task, and authenticating as a service principal is what service principals are for. The chain is visible only as a sequence, which is why per-event alerting struggles and sequence-aware detection is worth building.

How to detect this in your own environment

Build detections on transitions rather than events. Directory enumeration followed by a credential being added to an application followed by that application authenticating from a new source is a chain, and each link alone is noise.

Alert on credential addition to existing service principals specifically. This is the most common handoff in Azure intrusions and it is a low-volume, high-signal event.

Separate service principal sign-in monitoring from user sign-in monitoring, since non-human authentication is frequently excluded from dashboards built around people.

How to prevent it

Break the chain at its narrowest point rather than trying to prevent every stage. In most Azure environments that point is who can add credentials to service principals and who holds directory roles permitting it.

Reduce standing privilege with just-in-time elevation so the identities an attacker acquires are less often useful at the moment they are acquired.

Inventory and expire application credentials, since long-lived secrets on forgotten applications are the resting places these chains pass through.

Real-world context

Documented cloud intrusions consistently show multi-stage credential movement rather than a single compromise, and reporting on nation-state activity in Microsoft cloud environments has repeatedly described exactly this pattern of moving between users, applications and service principals.

The defensive implication is about where to spend effort. Preventing all initial access is unrealistic, and preventing the second or third handoff is often achievable, which is why chain analysis produces better priorities than a list of controls.

The pattern maps to MITRE ATT&CK T1087 Account Discovery, T1098.001 Additional Cloud Credentials and T1078.004 Cloud Accounts.

Applying this at work

  • List who can add credentials to service principals in your tenant. It is usually a longer list than expected and it is the key handoff.
  • Alert on credential addition to existing applications.
  • Move directory roles to just-in-time elevation so standing privilege is reduced.
  • Build one sequence-based detection rather than another single-event rule.
  • Map your own environment as a chain and identify the narrowest link, then spend your effort there.

Frequently asked questions

What is the Azure kill chain?

The sequence of stages in a cloud intrusion: reconnaissance, initial access, enumeration, lateral movement between identities, and reaching the objective. Each stage typically uses a different credential obtained from the previous one.

Why are service principals so central to lateral movement?

They are numerous, they are not protected by controls aimed at interactive user sign-in, and an identity with rights over one can add a credential and authenticate as it. That makes them the most common handoff point.

How should defenders prioritize against a chain?

By finding the narrowest link rather than trying to prevent every stage. Preventing all initial access is unrealistic, while preventing or detecting a specific handoff is often achievable and stops the chain.

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.

platform mock(1)

Cloud Security Training To Protect Your Business

Pwned Labs for Business gives your team access to dedicated business content, including labs and cyber ranges.

We also offer in-person or remote workshops, and our cloud penetration services are helping businesses become more secure!