HashiCorp Vault
Secrets-management server on 8200. A leaked or low-priv token unlocks stored secrets, and the SSH secrets engine can mint one-time passwords or signed certs to log into hosts as a privileged user.
Ports
| Port | Proto | Notes |
|---|---|---|
8200 | tcp | Vault API / UI |
Fingerprint
- 'Vault' UI at /ui, /v1/sys/health returns sealed/version
Key files
| Path | Holds | Sensitive |
|---|---|---|
~/.vault-token | cached auth token | sensitive |
Exploitation primitives
- Any valid token → `vault kv get` every readable path for DB/app/SSH secrets
- SSH secrets engine: request a one-time password (`vault write ssh/creds/...`) or a signed cert to SSH in as a role's user
- Tokens leak in env vars, history, app configs and CI logs
Overview
Vault stores secrets behind a token-based API on 8200. The whole game is getting a token; after that you read what it’s authorised for, and the SSH engine often hands you a login.
Use a token
export VAULT_ADDR=http://<TARGET>:8200 VAULT_TOKEN=<TOKEN>List and read secret paths:
vault kv list secret/ && vault kv get secret/sshSSH secrets engine → host login
Request a one-time password for a role, then SSH in:
vault write ssh/creds/<role> ip=<TARGET_IP>ssh <user>@<TARGET_IP>Hardening
Scope tokens tightly, set short TTLs, audit secret reads, and never leave .vault-token or VAULT_TOKEN in shell history or app configs.