Key Vault audit logs: who read which secret, and when
Use Azure Key Vault audit logs (AuditEvent) to find who read which secret: SecretGet and SecretList, access policy changes, new principals and enumeration.
TL;DR. Secret reads are only visible in the Key Vault AuditEvent log, and only if a diagnostic setting was sending it somewhere before the incident. Look for SecretGet / SecretList by a principal that never touched the vault before, many distinct secrets read by one principal within an hour, and VaultAccessPolicyChangedEventGridNotification or Microsoft.KeyVault/vaults/accessPolicies/write just before. With the access-policy model, anyone holding Contributor on the vault can grant themselves data-plane access. If there are no logs, rotate every secret the identity could reach.
Key Vault is where attackers go right after they get a foothold with any real privilege, because that is where the database password, the payment API key and the backup encryption passphrase live. The good news: when logging is on, the Key Vault audit log is one of the most precise sources in Azure. Every request is recorded with the object URI, the caller identity and the IP.
What the AuditEvent log records
Microsoft's Key Vault logging reference documents the schema. The fields you use in an investigation:
| Field | Content | Investigation use |
|---|---|---|
time | UTC timestamp | Timeline |
operationName | SecretGet, SecretList, KeyDecrypt, VaultGet… | What was done |
identity.claim | Object ID (…/objectidentifier), appid, UPN for users, xms_mirid for managed identities | Who |
callerIpAddress | Client IP | From where |
properties.id | Full object URI, e.g. https://<vault>.vault.azure.net/secrets/<name>/<version> | Which secret, which version |
properties.clientInfo | User agent (SDK name and version, curl, python…) | How |
resultSignature / httpStatusCode | HTTP status | Success vs denied |
The same data lands in the AzureDiagnostics table (with flattened identity_claim_* columns) or the resource-specific AZKVAuditLogs table in Log Analytics. In a storage account it is written to the insights-logs-auditevent container. Microsoft says entries are available at most ten minutes after the operation.
Operation names that matter
Operation names follow an ObjectVerb pattern. The ones that matter for credential theft:
| Operation | Meaning | Forensic weight |
|---|---|---|
SecretGet | Read a secret value | The core evidence of credential access |
SecretList, SecretListVersions | Enumerate names, not values | Reconnaissance before bulk reads |
SecretBackup, KeyBackup | Export an encrypted backup blob | Exfiltration of the whole object |
KeyDecrypt, KeyUnwrap | Use a key without extracting it | Data decryption by proxy |
CertificateGet | Read a certificate's properties and public part; an exportable private key is read through the certificate's backing secret, so it shows up as SecretGet | Credential access |
SecretPurge, KeyPurge, CertificatePurge | Permanent deletion | Impact / anti-forensics |
VaultAccessPolicyChangedEventGridNotification | Access policy changed | Logged even without an Event Grid subscription |
Authentication | Authentication via the Entra endpoint | Context |
On the control-plane side, the Activity Log records Microsoft.KeyVault/vaults/accessPolicies/write (access-policy change), Microsoft.KeyVault/vaults/write (vault properties, including soft delete and purge protection) and Microsoft.KeyVault/locations/deletedVaults/purge/action.
The access-policy escalation
Key Vault has two permission models. With Azure RBAC, granting data-plane access requires Owner or User Access Administrator. With the legacy access policy model, Microsoft warns that users with Contributor, Key Vault Contributor or any role including Microsoft.KeyVault/vaults/write "can grant themselves data plane access" by editing the access policy (Azure RBAC vs. access policies).
In practice the chain looks like this, all within a few minutes:
- Activity Log:
accessPolicies/writeby principal X on vault V. - Key Vault log:
VaultAccessPolicyChangedEventGridNotificationon V. - Key Vault log:
SecretListby X from the same IP. - Key Vault log: a burst of
SecretGetby X, one per secret.
MITRE ATT&CK tracks reading cloud secret stores as T1555.006 Cloud Secrets Management Stores.
What the analyzer flags
| Rule | Detects | Level |
|---|---|---|
AZ-KV-001 | A principal read secrets, keys or certificates from a vault it never accessed during the 72-hour learning period | High |
AZ-KV-002 | One principal read at least 8 distinct secrets / keys / certificates from one vault within 60 minutes | High |
AZ-KV-003 | Access policy changed (Activity Log or Key Vault log) | Medium |
AZ-KV-004 | Soft delete or purge protection disabled, or vaults / objects purged | High |
AZ-ID-002 | A managed identity used from an IP it never used before — often a token stolen from a VM and replayed against Key Vault | High |
AZ-KV-002 counts distinct objects, not requests: an application that reads the same connection string every hour never triggers it; a script that walks the vault does. Configuration loaders that read every secret at start-up are the known false positive.
Triage questions
- Was logging on? Check the coverage block of the analyzer or the vault's diagnostic settings history in the Activity Log (
microsoft.insights/diagnosticSettings/writeand/delete). A deleted diagnostic setting is itself a finding (defense evasion). - Is the reader new? Compare with the baseline: which principals read this vault last week, from which IPs, with which client?
- How many distinct secrets? One secret read by a new principal can be an onboarding. Twelve in one minute from a Python SDK on a residential IP is not.
- Which client?
clientInfotells an application SDK fromcurlor an ad-hoc script. It can be spoofed, but a change is still informative. - Denied requests? A string of 403s before success is typical of an attacker discovering what the identity can do.
- What did the secrets unlock? Each secret read is a new incident scope: the database, the payment provider, the SFTP partner.
Remediation
- Rotate every secret, key and certificate read by the suspicious principal — and update the systems that consume them. Rotation without updating consumers causes an outage, so coordinate.
- Remove unexpected access-policy entries; plan the move to the Azure RBAC permission model.
- Ensure soft delete and purge protection are on.
- Enable the
AuditEventdiagnostic setting now if it was off, and protect it with Azure Policy.
FAQ
Does the Activity Log show Key Vault secret reads?
No. Reading a secret is a data-plane operation. It appears only in the Key Vault AuditEvent resource log, and only if a diagnostic setting sent that log somewhere before the read happened.
Can I recover Key Vault access logs if logging was not enabled?
No. Enabling the diagnostic setting now only records future operations. Assume every secret the compromised identity could read was read, and rotate them.
How quickly do Key Vault logs appear?
Microsoft states that logging information is available at most 10 minutes after the Key Vault operation, usually sooner.