Azure Key Vault stores secrets (connection strings, API keys, passwords), cryptographic keys, and certificates. Attackers who gain access to a Key Vault via a compromised service principal, managed identity, or stolen token can enumerate and exfiltrate all secrets in seconds. Key Vault diagnostic logs record every access operation including caller IP, identity type, and operation result. These logs must be routed to Log Analytics or a SIEM to enable detection.
Key indicators of compromise include bulk SecretGet operations (all secrets accessed in a single session), access from unexpected IPs or countries, and access by service principals that do not normally interact with the vault.
☰ Table of Contents
01 — BACKGROUND
TECHNIQUE OVERVIEWKey Vault access is controlled by Azure RBAC (role assignments on the vault resource) or the legacy Access Policy model. Diagnostic logging under the AzureDiagnostics or AzureKeyVault resource-specific table captures all data-plane operations. Common attacker actions: authenticate as a service principal using a stolen client secret or certificate, then call SecretList + SecretGet for every secret, or KeyGet + decrypt to exfiltrate encrypted data.
| Field | Value |
|---|---|
| MITRE Technique | T1552.001 — Credentials in Files, T1555 — Credentials from Password Stores |
| Log Table | AzureDiagnostics (ResourceType == "VAULTS") or resource-specific AzureKeyVault |
| Key Operations | SecretGet, SecretList, KeyGet, KeyDecrypt, CertificateGet, CertificateList |
| Caller Identity Types | ServicePrincipal, ManagedIdentity, User, Application |
| Detection Priority | HIGH — any bulk enumeration (5+ SecretGet in one session) requires investigation |
02 — IDENTIFICATION
2 INDICATORSAttackers with Key Vault access permissions immediately call SecretList followed by SecretGet on every secret in one burst. A legitimate application accesses only the specific secrets it needs — bulk enumeration across all secrets in a vault within a short window is a strong indicator of credential harvesting activity.
- 1Confirm that Diagnostic settings are enabled and sending
AuditEventto a Log Analytics workspace or SIEM. If not enabled, historical logs are unavailable — enable now and note the gap. - 2Open Log Analytics and run the KQL below to find all callers who accessed 5 or more distinct secrets in a 30-minute window.
- 3For each flagged caller, identify the identity type (ServicePrincipal, ManagedIdentity, User) and the caller IP address.
- 4Cross-reference the caller IP against known application deployment ranges. Access from a public IP that does not match any known workload is highly suspicious.
- 5Record all secret names that were accessed — these are the secrets that must be considered compromised and rotated immediately if a true positive is confirmed.
| Pattern | Meaning | Action |
|---|---|---|
| 5+ SecretGet in <5 min | Bulk enumeration — all secrets accessed in rapid succession | ESCALATE — presume compromised |
| SecretList + SecretGet burst | Classic enumerate-then-dump pattern | Revoke caller identity NOW |
| Access from public IP | Vault accessed from internet, not VNet/private endpoint | Verify caller identity and IP |
| Unauthorized operation result | Access denied — attacker probing without sufficient permissions | Identify the caller, track escalation attempts |
Key Vault access from an unexpected service principal, from a country or IP not in the organization's normal footprint, or from a time outside the application's operating hours is a strong indicator that a service principal credential has been compromised and is being used from an attacker-controlled host.
- 1Search for the service principal OID identified in I1. Review its sign-in history — is the IP/country consistent with prior sessions?
- 2Navigate to Entra ID → App registrations → [App] → Certificates & secrets and check when the client secret was last created or rotated. A recently created secret may indicate an attacker created a new credential after compromising the app registration.
- 3Check if the service principal has permissions it should not have: Entra ID → Enterprise applications → [SP] → Permissions.
- 4Run the KQL below to get the geographic breakdown of Key Vault access by this caller over the last 30 days to identify the anomalous IP.
- 5If the IP resolves to a VPN exit node, hosting provider, or foreign country not in the application's normal deployment regions, treat as confirmed attacker access.
Managed Identity access to Key Vault will always originate from Azure infrastructure IPs (e.g., 168.63.129.16) or the VM's private IP. If you see a Managed Identity sourced from a public internet IP, this indicates the identity token was stolen and replayed from outside Azure.
03 — CONTAINMENT
IMMEDIATE ACTION- 1Revoke the compromised service principal credential: Entra ID → App registrations → [App] → Certificates & secrets → Delete the compromised secret.
- 2Add an IP network rule to the Key Vault firewall to deny all public access: Key Vault → Networking → Firewalls and virtual networks → Allow access from selected networks only.
- 3If the vault is already network-restricted, verify the allowlist is correct and does not contain attacker-controlled CIDRs.
- 4Rotate all secrets that were confirmed accessed (as identified in I1). Notify all application teams that depend on these secrets that credentials will be rotated immediately.
- 5If the vault contains cryptographic keys used for data encryption, assess whether decryption of data using the stolen key is possible — this may require escalating to a data breach assessment.
04 — ERADICATION
CLEANUP- 1Audit all service principals and users with Key Vault Secrets Officer or Key Vault Administrator RBAC roles — remove any that are not actively needed.
- 2Enable Soft-delete and Purge protection on all Key Vaults if not already enabled — prevents secret deletion covering tracks of attacker activity.
- 3Create a Sentinel analytics rule to alert on any
SecretGetburst (>5 in 10 minutes) from a single caller for continuous monitoring. - 4Enable Private endpoint for Key Vault and disable public network access entirely where application architecture permits.
- 5Rotate all application credentials that were stored as secrets in the compromised vault even if not confirmed accessed — assume all secrets in scope are compromised.
- Compromised service principal credential revoked
- All accessed secrets rotated and applications updated
- Key Vault network access restricted to known CIDRs only
- RBAC access list audited and pruned
- Sentinel alert rule for bulk SecretGet created
- Soft-delete and purge protection enabled
05 — ESCALATION
ESCALATION PATHS| Condition | Severity | Action | Notify |
|---|---|---|---|
| Bulk enumeration confirmed, cryptographic keys accessed | SEV1 | Full IR, data breach assessment, rotate all secrets | CISO → Legal → affected app owners |
| All vault secrets accessed from anomalous IP | SEV1 | Revoke all credentials, audit all systems using those secrets | SOC Lead → CISO → App teams |
| Single-secret access from unknown IP, SP credential possibly leaked | SEV2 | Revoke SP secret, rotate affected secret, full audit | SOC Lead → App owner |
| False positive — new pipeline runner IP | INFO | Update network allowlist, update baseline, close ticket | None |
Any confirmed Key Vault secret breach where the secrets include database connection strings or third-party API keys must be treated as a potential data breach — immediately assess what data those credentials protect and initiate a breach notification assessment.
Stay Threat-Ready
Follow CyberHawk Threat Intel for daily SOC analyst playbooks, detection engineering guides, and threat intelligence.