lolcreds

Public credential defaults and exposure patterns for authorized security testing.

HashiCorp Vault

HashiCorpidentity8 credentials

Credentials8 documented
01

Vault Token

hashicorp-vault / vault-token

Vault tokens are the core credential used to authenticate requests to Vault. HashiCorp documents service, batch, and recovery token prefixes, including hvs., hvb., and hvr. for Vault 1.10 and later.

generated on installuser definedsecrettoken

Looks like

example
example

Vault 1.10+ service token

hvs.XXXXXXXXXXXXXXXXXXXXXXXX
example

Vault 1.10+ batch token

hvb.XXXXXXXXXXXXXXXXXXXXXXXX
example

Vault 1.10+ recovery token

hvr.XXXXXXXXXXXXXXXXXXXXXXXX
example

pre-1.10 service token format

s.XXXXXXXXXXXXXXXXXXXXXXXX
example

pre-1.10 batch token format

b.XXXXXXXXXXXXXXXXXXXXXXXX
example

pre-1.10 recovery token format

r.XXXXXXXXXXXXXXXXXXXXXXXX

Location

environment
VAULT_TOKEN
http header
X-Vault-Token, Authorization

Vault API accepts X-Vault-Token or Authorization Bearer token headers

config file
~/.vault-token

default local token helper file used by the Vault CLI

config file

Vault Agent token sink files, application config, .env files, deployment manifests

secret store

CI/CD variables, Kubernetes Secrets, cloud secret managers, orchestration secrets

logs

CLI output, HTTP traces, application debug logs, Vault Agent logs

source code

automation scripts, Terraform providers, tests, notebooks, committed examples

Notes

Root tokens are Vault tokens with root policy. HashiCorp recommends root tokens only for initial setup or emergencies and revoking them when no longer needed. Treat any Vault token as a bearer credential scoped by its policies, TTL, namespace, and renewal properties.

02

Initial Root Token

hashicorp-vault / initial-root-token

Vault initialization produces an initial root token for a non-dev server, and the dev server also outputs a root token. This is the first authentication method for a new Vault and carries root privileges until revoked or expired.

generated on installsecrettoken

Looks like

example
example

generated root token on Vault 1.10+ when token prefixes are enabled

hvs.XXXXXXXXXXXXXXXXXXXXXXXX

Location

logs

vault operator init output, dev server console output, install transcripts

artifact

initialization JSON, runbooks, screenshots, bootstrap archives, ticket attachments

secret store

break-glass vaults and bootstrap secret stores

config file
~/.vault-token

CLI login can cache the initial root token locally

Notes

Do not treat this as a static default. The value is generated per initialization. Exposure is high impact because root policy bypasses normal least-privilege boundaries.

03

Unseal / Recovery Key Share

hashicorp-vault / unseal-key

Vault initialization generates unseal key shares for Shamir-sealed clusters or recovery keys for auto-unseal and recovery workflows. A quorum of key shares can unseal Vault or authorize sensitive operations such as generating a root token.

generated on installsecretsecret value

Looks like

example
example

unseal and recovery key shares are high-entropy opaque strings; identify by initialization output or operator-runbook context

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Location

logs

vault operator init output and initialization transcripts

artifact

init JSON files, printed shares, screenshots, ticket attachments, backup bundles

secret store

HSM-backed stores, password managers, enterprise vaults, escrow stores

config file

unsafe bootstrap files or copied operator notes containing key shares

Notes

A single share is usually not enough to unseal Vault, but enough shares or recovery keys can authorize critical operations. Treat leaked shares as incident material and rotate/rekey according to quorum procedures.

04

AppRole RoleID / SecretID

hashicorp-vault / approle-role-id-secret-id

The AppRole auth method lets machines authenticate with a RoleID and a SecretID. The RoleID identifies the role; the SecretID is the sensitive credential used during login to receive a Vault token.

generated on installuser definedsecretsecret value

Looks like

pattern
pattern

AppRole RoleID in config or command output; RoleID is often less sensitive than SecretID

role_id\s*[:=]\s*[0-9a-fA-F-]{20,}
pattern

AppRole SecretID in config or command output; the value is credential material

secret_id\s*[:=]\s*[0-9a-fA-F-]{20,}

Location

config file

Vault Agent auto-auth config, application config, .env files, deployment manifests

environment
VAULT_ROLE_ID, VAULT_SECRET_ID
secret store

Kubernetes Secrets, CI/CD variables, cloud secret managers

logs

provisioning output, curl traces, Vault Agent logs, CI logs

source code

bootstrap scripts, Terraform, Ansible, Helm values, committed examples

Notes

RoleID alone may be public in some designs, but RoleID plus SecretID is sufficient to authenticate as the AppRole and receive a Vault token. SecretID wrapping is common; unwrap tokens should be treated as bearer credentials during their TTL.

05

Username / Password Auth Credential

hashicorp-vault / userpass-password

Vault's userpass auth method allows users to authenticate with a username and password. Successful login returns a Vault token governed by the auth method, policies, and identity mapping.

user definedsecretusername/password

Location

public interface
/ui, /v1/auth/userpass/login/<username>
secret store

password managers, identity-provider vaults, enterprise secret stores

config file

automation config or test fixtures that store userpass credentials

source code

scripts, test suites, demos, notebooks, committed .env files

logs

CLI command history, debug logs, HTTP traces containing login payloads

Notes

No universal Vault userpass default is documented. Userpass passwords are operator-defined and should be rotated if found in automation or logs.

06

Database Secrets Engine Credential

hashicorp-vault / database-generated-credential

Vault's database secrets engine can generate dynamic database usernames and passwords or manage static-role passwords for existing database users. Clients read the creds endpoint to receive a leased credential.

generated on installsecretusername/password

Looks like

pattern
pattern

generated database username shown in Vault database secrets engine output

username\s+v-[A-Za-z0-9_-]+-[A-Za-z0-9_-]+
pattern

generated database password shown in Vault CLI table output; identify by database/creds context

password\s+[^\s]+

Location

http response

database/creds/<role> responses containing username, password, lease_id, and lease_duration

logs

CLI output, application debug logs, CI job logs, database connection logs

environment

application runtime variables populated from Vault database credentials

secret store

application secret caches and orchestration-managed secret sync targets

config file

rendered templates from Vault Agent or sidecars containing leased database credentials

Notes

Dynamic credentials expire with the Vault lease. Static-role credentials map one Vault role to one database username and may be rotated by Vault.

07

KV Secret Value

hashicorp-vault / kv-secret-value

The key/value secrets engine stores arbitrary operator-defined secrets, including API keys, passwords, certificates, and application tokens. These values are not a Vault authentication credential, but Vault is a primary storage location for other products' credentials.

user definedsecretsecret value

Location

database

Vault storage backend data encrypted by Vault's barrier

http response

KV read responses returning data fields

config file

Vault Agent templates, rendered config files, synced secret files

environment

application runtime variables populated from KV secrets

logs

CLI output, application debug logs, template rendering logs

secret store

downstream secret sync targets and external secret stores

Notes

Classify recognizable KV values under their underlying product entry as well. In this Vault entry, KV documents the storage location and leak surface for arbitrary secrets.

08

TLS Client Auth Private Key

hashicorp-vault / tls-client-private-key

Vault's TLS certificate auth method can authenticate clients using a client certificate and matching private key. The private key is the secret half of the credential.

user definedsecretkey pair

Looks like

pattern
pattern

PEM private-key header; the full key is multi-line and not useful as an example

-----BEGIN (RSA |EC |OPENSSH |)PRIVATE KEY-----

Location

config file

client certificate/key files, Vault Agent config, mTLS client config

secret store

Kubernetes TLS Secrets, certificate managers, cloud secret managers

source code

accidentally committed test cert bundles, examples, or deployment fixtures

artifact

backup archives, support bundles, CI artifacts, container/VM images

Notes

The public certificate alone is not secret; the private key is. A leaked key can authenticate to Vault where the cert auth role trusts the corresponding certificate identity.

Scope

Authorized use

LOLCreds helps map the credential surface of real products: known defaults, generated values, credential locations, and exposure patterns.