What happens when attackers find your secrets manager

HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — secrets managers are the keys to the kingdom. Database passwords, API keys, TLS certificates, SSH private keys: if an attacker can read your secrets manager, they can impersonate any service in your stack.

How attackers find Vault

The give-away is port 8200. Vault's default port is well-known, and any scanner that finds it open will immediately try GET /v1/sys/health to confirm it is Vault, followed by GET /v1/sys/seal-status to check whether it is sealed or open. An unsealed Vault is an open door.

After confirming the target is Vault, the next step is credential stuffing against the auth backends: POST /v1/auth/userpass/login/admin, POST /v1/auth/ldap/login/admin, and attempts to use a stolen token via GET /v1/auth/token/lookup-self. Automated tools run all of these in sequence.

What a Vault decoy catches

A decoy Vault instance responds to all of these probes exactly as a real Vault would — health check returns 200 with version and cluster ID, seal-status says unsealed, auth attempts return 401 or 400 with realistic error messages. The attacker has no way to tell it is fake.

But every probe is an alert. The health check is low severity — scanners run these constantly. The auth attempt is medium. The path /v1/secret/ or /v1/kv/ is high: someone is trying to read secrets. And a call to /v1/sys/policies/ or /v1/sys/auth is the highest severity — that is an attacker trying to modify Vault policy so they can come back later.

The real signal: lateral movement through secrets

The most dangerous scenario isn't an external attacker finding Vault — it is a compromised internal machine calling the Vault API from inside your network. A decoy Vault catches that and attributes it to a source IP. Combined with a Kandaro incident, you know which machine was compromised and what it was trying to steal.

Read about why identity providers are also high-value decoys, or deploy the HashiCorp Vault profile.