Unlock Access with Azure Key Vault

What this lab covers

You enumerate an Azure environment for situational awareness, identify a key vault your access can reach, retrieve secrets from it and use them to move further into the environment and its data.

The lab makes a point about centralisation. Key vaults are unambiguously better than secrets in configuration files, and the trade-off is that access control becomes the entire story rather than one control among many.

It assumes no prior Azure experience and is a good introduction to how Azure permissions differ from AWS, particularly the split between management and data plane.

How Key Vault access works

Azure Key Vault separates the management plane from the data plane. Management operations create and configure vaults and are governed by Azure roles. Data operations read secrets, keys and certificates and are governed either by legacy access policies or by role-based access control, depending on how the vault is configured.

That split creates a specific trap. An identity with management rights over a vault may not be able to read secrets directly, and can often grant itself the necessary data plane access, which turns a management permission into a data permission in one step.

Legacy access policies compound this because they are per-vault lists that grant broad verbs, such as the ability to list and get every secret in the vault. There is no per-secret scoping, so an identity that needs one secret is frequently granted access to all of them.

How to detect this in your own environment

Enable Key Vault diagnostic logging, which is not on by default, and treat secret retrieval as security-relevant telemetry. The log records which identity read which secret, and that is the most valuable record you can have here.

Alert on access policy and role assignment changes on vaults. An identity granting itself data plane access is a distinctive and high-confidence escalation signal.

Baseline which identities read which secrets. Applications read the same small set repeatedly, so an identity retrieving secrets it has never read, or enumerating the full list, is a clear anomaly.

How to prevent it

Use role-based access control for the data plane rather than legacy access policies, so permissions can be scoped to individual secrets rather than granted vault-wide.

Separate vaults by trust boundary. One vault per application or environment limits what any single compromised identity reaches, whereas a shared vault means the least sensitive consumer sits alongside the most sensitive secret.

Enable purge protection and soft delete, and restrict who holds management rights over vaults. Management access is a short step from data access, so it deserves the same scrutiny.

Real-world context

Secret stores are high-value targets precisely because the security advice to centralise secrets was correct and widely followed. The result is that many organizations have one place holding credentials for everything else.

The contractor and third-party angle matters too. Highly privileged accounts belonging to people outside the organization are frequently retained long after the engagement ends, and they often hold vault access granted for a specific task years earlier.

The pattern maps to MITRE ATT&CK T1555 Credentials from Password Stores, T1078.004 Cloud Accounts and T1098 Account Manipulation.

Applying this at work

• Enable diagnostic logging on every key vault and confirm the logs reach somewhere you can query.
• Migrate vaults from legacy access policies to role-based access control so secrets can be scoped individually.
• Review who holds management rights over vaults, since those identities can generally grant themselves data access.
• Split shared vaults by application or environment.
• Audit external and contractor identities for standing vault access and remove what is no longer needed.

Frequently asked questions

What is the difference between the management and data plane in Key Vault?

The management plane creates and configures vaults and is governed by Azure roles. The data plane reads secrets, keys and certificates and is governed by access policies or role assignments. They are separate permission systems.

Why are legacy access policies a problem?

They grant broad verbs across an entire vault, with no per-secret scoping. An identity needing one secret typically receives the ability to list and read all of them, so any compromise of that identity exposes everything in the vault.

Is Key Vault secret access logged by default?

No. Diagnostic logging must be enabled explicitly. Without it you have no record of which identity read which secret, which is the most important evidence during an investigation.

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.