Azure Key Vault secret harvest
A burst of secret, key or certificate reads from an Azure Key Vault.
What it detects
A burst of secret, key or certificate reads from an Azure Key Vault.
A Key Vault is where an organisation puts the things it decided were too sensitive to leave in config: database connection strings, service-principal passwords, signing keys, API tokens for everything the estate talks to. An application reads the one or two it needs, when it starts, and then does not read them again.
Reading MANY in a minute is not an application. It is an enumerator walking the vault, and the reason it matters more than most credential access is that everything it retrieves is a working credential for something else — the vault is a directory of the next hops. By the time this is investigated the secrets are gone and the only sound response is rotation.
Grouped by the calling identity so one compromised principal is one finding, and so the evidence names every secret it touched.
MITRE ATT&CK mapping
False positives and triage
Deployment pipelines and secret-sync agents legitimately read in bulk, and in a mature estate they will be the first thing this finds — identify them once and allowlist the service principal rather than raising the count, because the count is not what separates them. What does separate them is regularity and origin: a pipeline reads the same set on a schedule from the same agent addresses, while an enumerator reads everything once from somewhere new. Check whether the caller has read this vault before at all, whether the read set matches what that identity needs, and whether the address belongs to the subscription's own infrastructure. A first-time caller sweeping a whole vault is the finding; treat every secret named in the evidence as compromised and rotate, because a read leaves no trace of what was done with it afterwards.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/azure_keyvault_secret_harvest.yaml, licensed under the Apache License 2.0.
id: cloud.azure.keyvault_secret_harvest
version: 1.0.0
status: stable
severity: critical
confidence: 0.7
platforms: [application]
mitre_techniques: [T1552.001, T1555.006, T1078.004]
description: |
A burst of secret, key or certificate reads from an Azure Key Vault.
A Key Vault is where an organisation puts the things it decided were too
sensitive to leave in config: database connection strings, service-principal
passwords, signing keys, API tokens for everything the estate talks to. An
application reads the one or two it needs, when it starts, and then does not read
them again.
Reading MANY in a minute is not an application. It is an enumerator walking the
vault, and the reason it matters more than most credential access is that
everything it retrieves is a working credential for something else — the vault is
a directory of the next hops. By the time this is investigated the secrets are
gone and the only sound response is rotation.
Grouped by the calling identity so one compromised principal is one finding, and
so the evidence names every secret it touched.
match:
provider: AzureActivity
event_action_contains_any:
- "Microsoft.KeyVault/vaults/secrets/getSecret"
- "Microsoft.KeyVault/vaults/secrets/read"
- "Microsoft.KeyVault/vaults/keys/read"
- "Microsoft.KeyVault/vaults/certificates/read"
- "Microsoft.KeyVault/vaults/secrets/backup/action"
- "Microsoft.KeyVault/vaults/keys/backup/action"
threshold:
# Ten reads in a minute is scripted by definition; an application's start-up
# fetch is a handful, and a human in the portal cannot click this fast.
count: 10
window_seconds: 60
group_by: [user_name]
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
Deployment pipelines and secret-sync agents legitimately read in bulk, and in a
mature estate they will be the first thing this finds — identify them once and
allowlist the service principal rather than raising the count, because the count
is not what separates them. What does separate them is regularity and origin: a
pipeline reads the same set on a schedule from the same agent addresses, while an
enumerator reads everything once from somewhere new. Check whether the caller has
read this vault before at all, whether the read set matches what that identity
needs, and whether the address belongs to the subscription's own infrastructure.
A first-time caller sweeping a whole vault is the finding; treat every secret
named in the evidence as compromised and rotate, because a read leaves no trace
of what was done with it afterwards.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.