Process secret hunting
Warning
Run these techniques only on systems you are explicitly authorized to test. Process arguments and environment variables may expose live secrets. Capture only what you need, avoid writing sensitive output to disk, and handle results per scope and retention rules.
Secrets show up most often in command-line arguments, environment variables, and unit ExecStart lines.
Wide process view
What you should see:
Full command lines including flags. Look for
--password,--token,-p,Authorization, JDBC URLs, and inline creds.Custom app paths under
/opt,/srv,/var/www, or user home directories.
Next move:
Pick a suspicious PID and pull args and environment from procfs.
Pull a single process args and environment
Set $PID to a target PID you saw in ps.
Interpretation:
If creds are in
cmdline, you can usually reuse them immediately.If creds are in
environ, they often match.envfiles or systemd Environment entries. Hunt the source file next.
Identify files and sockets the process uses
What to do with results:
Config file paths and log paths are the fastest pivot. Open the config file and look for static secrets.
Established connections reveal internal targets and ports. That becomes lateral movement planning later, but you can capture hostnames now.
Hunt for likely secret flags across all processes
If the box is noisy, focus on common runtimes:
systemd ExecStart and environment (when readable)
If you have access to service definitions, you can often read the full command line and referenced config.
Interpretation:
ExecStartpoints at the real binary and flags. If flags include secrets, capture them.If it references a config path, open it and confirm whether the secret is static.
References
-
proc(5) manualman7.org/linux/man-pages/man5/proc.5.html (opens in new tab)
cmdline/environ behavior
-
wide output flags
-
lsof(8) manualman7.org/linux/man-pages/man8/lsof.8.html (opens in new tab)
open files and sockets by PID
Was this helpful?
Your feedback helps improve this page.