Hunting Exposed Secrets

Before You Exploit, Just Look

You’ve mapped the box. Before reaching for a single clever technique, ask the lazy question:

Did someone just leave a password lying around?

They do. Constantly.

Leaked credentials are the fastest, most reliable way up. A reused password beats a kernel exploit every time: no crash risk, no version matching, no exploit to find.

So you check for secrets first. This note is about the two places they hide.

Two Kinds of Trail

Every secret on the box is one of two kinds:

That static vs live split is the whole mental model. We’ll take each in turn.

User Trails: What People Leave in Files

People stash secrets in their home directory, tucked into files hidden by a leading dot. These are dotfiles, and the dot is why a plain ls never shows them.

Three places to look, in order of payoff.

Environment Variables

Admins sometimes shove a password straight into an environment variable so a script can authenticate. Dump them all:

One line stands out from the noise:

SCRIPT_CREDENTIALS=lab

To confirm it’s permanent (set on every login, not just a fluke of your shell), check the dotfile that exports it:

There it is: a cleartext password, exported every time a shell starts. .bashrc runs on every new terminal, which is exactly why it’s a favorite hiding spot.

History and Config Files

Two more static goldmines:

• .bash_history, every command the user typed, sometimes with a password passed inline on the command line
• Config and dotfiles (.ssh/, application .conf files), credentials sitting in cleartext for some service

Turning a Find Into root

Finding the password is half the job. Now you spend it. Two moves:

1. Try it directly.

If it drops you into another user instead, immediately check what that user is allowed:

A result of (ALL : ALL) ALL is game over, that user can run anything as root:

2. Turn one password into a pattern.

A password like Lab123 isn’t just one password. It leaks a scheme: the word Lab followed by three digits.

Feed that pattern to crunch to build a tiny, targeted wordlist, then let hydra spray it at another user over SSH:

A leaked secret is rarely just one secret. It reveals how this team thinks about passwords, and that pattern often unlocks the next account.

This is the loop, and it’s the same one from Windows:

found secret → new user → sudo -l → maybe root. Re-enumerate after every hop. New user, new file permissions, new secrets in reach.

Service Footprints: What the Machine Leaks While Running

Now the cleverer half. The secrets here aren’t sitting in a file, they flash past as the system does its work. Catching them rests on two facts.

Fact 1: Process Arguments Are Public

A process’s command-line arguments are visible to every user on the box. Even root’s processes.

So when a root daemon runs something like:

sshpass -p 'Lab123' ssh -t eve@127.0.0.1 sleep 5

you, an unprivileged user, can read that password just by listing processes. You can’t read root’s memory or kill its process, but the command line is wide open.

The catch: that process might live for only a second, firing on a timer. So you don’t look once, you watch, refreshing every second to catch the flash:

You’re not reading a file, you’re waiting for a moment. A credential-bearing process that runs for one second a minute is invisible to a single ps, and obvious to watch.

Fact 2: You Might Be Able to Sniff Traffic

Local services constantly talk to each other over the loopback interface (127.0.0.1), and often in plaintext.

Capturing traffic needs root, but here’s the opening: troubleshooting and IT accounts are frequently granted tcpdump via sudo. If yours is one, point it at loopback and grep for credentials in flight:

After a few seconds, a cleartext login flies past:

user:root,pass:lab

A service that authenticates over 127.0.0.1 assumes nobody’s listening. If you can run tcpdump, you are.

Where This Leads

Hunting secrets is the low-hanging fruit, and it’s astonishing how often it’s the whole box: one exported password, one leaked process argument, and you’re root.

When the machine is clean of loose secrets, you escalate the harder way: by abusing things the system is configured to run with high privilege but leaves you able to change. The first and most classic of those is the cron job, in Abusing File Permissions.