One read can empty an Azure Key Vault
A Key Vault holds the credentials that unlock everything else. With a broad grant on a network-open vault, one identity can list and read every secret in seconds. Here is how, and the lockdown that holds.
The vault that protects all your other credentials is only as safe as who can read it, and from where.
What it is
Access to an Azure Key Vault is governed by access policies or RBAC, and by the vault’s network settings. When an identity has broad Get and List on secrets, and the vault accepts traffic from the public network, a single compromised or over-privileged identity can list and read every secret in seconds, then move laterally everywhere those secrets work. This is T1555 (credentials from password stores).
Why it works
Applications read individual secrets all day, so a burst of reads can blend in unless you watch for breadth. And once the secrets are read, recreating the vault does not help, because the attacker already holds the values.
How to detect it
In the Key Vault diagnostic logs, look for a List of all secrets plus Get on many of them in quick succession, from an identity or IP that does not normally read them, often from a public source.
The fix that holds
Use Azure RBAC over legacy access policies, with least privilege per identity. Restrict the vault to a private endpoint or firewall, separate vaults by sensitivity, enable purge protection, and alert on bulk secret List and Get operations. Treat a dump as a keys-to-the-kingdom event and rotate every secret in the vault.
Practice it
We built a Key Vault mass-secret-theft scenario in GraphLattice Range so teams work the detection, the lockdown, and the full rotation that recovery actually requires.