Recover credentials from Linux user, service and process trails

Needs: Read access to the artifact; exact account/service context; session/agent access must include a usable live identity

Shell commands

# Baseline
history 2>/dev/null
find /home /root -maxdepth 3 -type f \
  \( -name '.*history' -o -name '*.conf' -o -name '*.ini' -o -name '*.env' \
     -o -name 'id_*' -o -name '*.pem' -o -name '*.key' -o -name '*.bak' \) \
  -readable 2>/dev/null

grep -RniE 'pass(word)?|secret|token|api[_-]?key|connection(string)?' \
  /var/www /opt /srv /etc 2>/dev/null | head -n 200

# Inspect process arguments and readable process environment
ps auxww
ps eww -u root 2>/dev/null
tr '\0' ' ' < /proc/PID/cmdline 2>/dev/null; echo
tr '\0' '\n' < /proc/PID/environ 2>/dev/null

Check reusable local sessions/agents only when their sockets are accessible

# Check reusable local sessions/agents only when their sockets are accessible
w; who; last -n 20
env | grep -E 'SSH_AUTH_SOCK|TMUX|STY'
tmux ls 2>/dev/null
screen -ls 2>/dev/null
find /tmp /run -maxdepth 3 -type s -ls 2>/dev/null

Next: identify the value's user/service context, validate the smallest relevant transition (su, sudo, SSH or application authentication), then re-enumerate. Use credential handling for cracking/reuse.

Shell commands

Next: identify the value's user/service context, validate the smallest relevant transition (su, sudo, SSH or application authentication), then re-enumerate. Use credential handling for cracking/reuse.

# Baseline
find /home /var/www /opt /srv -type f \
  \( -iname '*.conf' -o -iname '*.ini' -o -iname '*.env' -o -iname '*.bak' \
     -o -iname '*.old' -o -iname '*.key' -o -iname '*.pem' \) 2>/dev/null

rg -ni 'password|passwd|token|secret|api[_-]?key|connection(string)?' \
  /var/www /opt /srv 2>/dev/null

Verify → Record source, exact material type and validated identity/service; keep real secrets in private lab records.

If it fails → Stale examples and unrelated tokens are common. A denied process read is a visibility limit, not evidence that no credentials exist elsewhere. More detail ↓

If → then

A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
Needs: Artifact provenance and format; possible local/domain/application identity and compatible protocol
A password tied to a plausible user and service → Validate known passwords and context-specific reuse
Needs: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state
A MySQL-compatible service and valid application/database credentials → Use MySQL/MariaDB data and file primitives
Needs: Database authentication and exact schema/file privileges; secure_file_priv and server filesystem identity constrain file actions

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Recover credentials from Linux user, service and process trails

USE WHEN: Readable configuration, shell history, environment, process arguments or session sockets
STARTING ACCESS: A verified Linux foothold with a known effective UID, groups and filesystem context
RESULT: Typed credentials or an explicitly authorized usable session capability

Recognize the clue

Follow observed application processes and directories into readable configuration, history and environment; prioritize paths tied to actual services.

ps auxww
history
find /opt /var/www /srv -maxdepth 3 -type f -readable 2>/dev/null

SYNTHETIC EXAMPLE OUTPUT

Process: APP_SERVICE --config /opt/APP/config.ini
Readable file: /opt/APP/config.ini
Setting: database_user=DB_USER; password=PASSWORD

Means: An actual service's readable configuration supplies an identity-labelled secret candidate.

Confirm: Read the named config/history/process artifact and record the user, service and host it belongs to. Classify a recovered password/key, test one matching service context and verify the accepted identity before trying reuse elsewhere.

After validation: The secret works in its verified identity/service context: use that access and re-enumerate.
Ruled out in this context: The value is a stale example and no longer accepted: reject that credential pairing.
Still inconclusive: A token-like string without service/account context requires provenance work before reuse.

Troubleshooting: Stale examples and unrelated tokens are common. A denied process read is a visibility limit, not evidence that no credentials exist elsewhere.

Additional prerequisite checks

history
ps auxww
env
find /opt /var/www /srv -maxdepth 3 -type f -readable 2>/dev/null

Inspect process arguments and readable process environment:

Check reusable local sessions/agents only when their sockets are accessible:

An agent, tmux/screen or daemon socket needs effective socket access and a useful authenticated/privileged session. Presence alone is not session hijacking.

Next: identify the value's user/service context, validate the smallest relevant transition (su, sudo, SSH or application authentication), then re-enumerate. Use credential handling for cracking/reuse.

Why it works

Secrets can outlive the operation that created them. Process visibility and readable environment depend on permissions; finding a socket does not prove the right to use the associated session.

Worked example · hypothetical

Observation: a service command line contains a database password. Test: identify its service/account scope and validate the source login. Illustrative output: database access works but the same OS username does not. Interpretation: enumerate database rights instead of assuming universal reuse.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗