How LinPEAS finds credentials and secrets

Where it appears in the output#

Credential searches are spread across Users Information, Software Information and Other Interesting Files, with the dedicated regex section (api_keys_regex) enabled by -r. LinPEAS checks shell history files, SSH directories and keys, .env and config files, database credential files, logs, backups, environment variables and the command lines of running processes.

╔══════════╣ Searching passwords in history files
.bash_history: mysql -u root -pSuperSecret
╔══════════╣ Searching ssl/ssh files
/home/user/.ssh/id_rsa (private key, readable)
╔══════════╣ API keys regex [-r only]
/opt/app/.env: AWS_SECRET_ACCESS_KEY=...

How to read a credential finding#

• Treat any surfaced credential as sensitive — and as a potential lateral or vertical move.
• Private SSH keys, database passwords in shell history, and .env/config secrets are the most common wins.
• Credentials in process command lines (/proc/<pid>/cmdline) are visible to every user — a classic misconfiguration.
• The regex section (-r) is noisy and can take minutes to hours; expect false positives among the real hits.
• A found password should be tried only within your authorised scope — e.g. su to another local user, or supplied to LinPEAS itself via -P.

Reproduce the searches manually#

grep -RiaE 'password|passwd|secret' ~/.bash_history ~/.zsh_history 2>/dev/null
ls -la ~/.ssh/ /home/*/.ssh/ /root/.ssh/ 2>/dev/null
find / -maxdepth 4 -name '.env' 2>/dev/null
env | grep -iE 'pass|secret|token|key'      # your own environment
cat /proc/*/cmdline 2>/dev/null | tr '\0' ' ' | grep -iE 'pass|pwd'  # others' cmdlines

The -r regex search: what to expect#

The -r flag enables filesystem-wide regular-expression hunting for API keys, tokens and hashes. It is the slowest LinPEAS mode — on large filesystems it can run for a very long time — so use it deliberately:

• Run it targeted when possible: ./linpeas.sh -r -o api_keys_regex runs only the regex section.
• Or scope it to a folder with -f /path, which also enables the regexes on a limited check set.
• Triage hits by file context: a key in /opt/app/.env matters; a key-shaped string in a minified JS bundle usually does not.
• Remember the output file now contains secrets — protect it accordingly.

What to do with a found credential (authorised scope)#

1. 1

2. 2

3. 3

4. 4

How to fix credential findings (defensive)#

• Set HISTCONTROL=ignorespace / HISTIGNORE and never put secrets on command lines — they land in history and /proc.
• SSH private keys: 600, owned by the user, ideally passphrase-protected; never shared between accounts.
• Move secrets out of .env-in-repo into a secrets manager or environment injected at deploy time.
• Scrub old secrets from shell history and logs after rotation — and rotate any credential LinPEAS surfaced.
• Restrict /proc visibility with hidepid=2 so users cannot read each other's command lines.
• Re-run LinPEAS after cleanup to confirm the findings are gone.

SSH keys: the full checklist#

Private keys are the highest-value credential LinPEAS surfaces — they bypass passwords entirely. When LinPEAS flags one, work through:

• Is it readable by you? (ls -l — anything looser than 600 on a private key is a finding by itself.)
• Does it have a passphrase? Try ssh-keygen -y -f key — if it prints the public key without prompting, there is none.
• Where is it trusted? Check authorized_keys files and ssh -i key user@host only against in-scope targets.
• Is it shared or duplicated? The same key in multiple homes (or committed to a repo) multiplies the blast radius.
• Is there a matching agent socket? SSH_AUTH_SOCK with loaded keys can be abused without ever reading the key file.

ls -la ~/.ssh/ /home/*/.ssh/ 2>/dev/null
find / -name 'id_rsa' -o -name 'id_ed25519' 2>/dev/null | head -20
ssh-keygen -y -f ./id_rsa 2>&1 | head -2   # passphrase? (empty prompt = none)

Cloud and API keys: blast radius#

A cloud API key found by the -r regexes is categorically different from a local password: it may control infrastructure far beyond the compromised host. Rules:

• Never test a cloud key beyond read-only identity calls (aws sts get-caller-identity) without explicit cloud scope.
• Assume the key is logged somewhere — rotate it as part of remediation, then verify the old one is dead.
• Long-lived keys in code or .env files should become short-lived role credentials (IAM roles, managed identities).
• Alert on the key's first use from an unexpected network — that is what CloudTrail / Activity Log is for.

Cleaning up after yourself#

An audit that leaves secrets behind is worse than no audit. Close out every run:

• Delete LinPEAS output from the target (shred -u where available) once you have exfiltrated it through approved channels.
• Clear any passwords from shell history on both ends (history -c, check ~/.bash_history).
• Redact secrets before the output enters reports, tickets or shared drives.
• Rotate every credential the scan surfaced — assume exposure, even in a lab.
• Remove tools you uploaded (linpeas.sh, pspy) from the target.

False positives to expect#

Not every regex hit is a secret. Common noise in the -r output:

• High-entropy strings in minified JavaScript and compiled assets.
• Example keys from documentation and test fixtures (AKIAIOSFODNN7EXAMPLE).
• Hashes in package lockfiles — integrity hashes, not credentials.
• Your own LinPEAS output from a previous run, if you scan the directory containing it.

Triage by file context and by whether the “secret” actually authenticates to something in scope — never by entropy alone.

Concepts: environment variables, file permissions. Related: the -r flag, saving output safely.