Loot lives in backups, connection managers, and keyrings

When you land on a box, the fastest escalation is usually to read a credential someone already stored, not to crack or exploit anything. Admins keep credentials in predictable places, and the tools that hold them are reversible or crackable by design because the tool itself has to recover the password to use it. Three stores to check on every foothold, with the fix for each.

Leaked backups ship live data, not just code

An unauthenticated download exposes a deployment backup and it reads as "just a source-code leak." Inventory the archive for data, not only code: a backup very often ships the live database.sqlite rather than an empty one. Dump the schema, read the credential columns, and identify the hash format before deciding the passwords are out of reach, because the framework's documented default is not evidence of what the app actually stored.

sqlite3 database.sqlite '.schema users'
sqlite3 database.sqlite 'select email,password,api_token from users'

A 32-hex value with no $2y$ prefix and no salt column is raw unsalted MD5, not bcrypt, and an api_token column is often plaintext. That turns "a database leaked" into "the admin's cleartext password leaked" after one rockyou pass. One caution that burns people: verify your wordlist actually downloaded before trusting a "nothing cracked" result; a 404'd wordlist cracks an empty file and reports the same thing as a strong password.

Connection managers are a credential store

An admin's workstation or jump host stores the credentials for everything it connects to, and connection managers encrypt them with a key the tool can recover.

find / -type f \( -name 'sessions-backup.dat' -o -name '*.rdg' -o -name 'confCons.xml' \
  -o -name 'sitemanager.xml' -o -name 'recentservers.xml' -o -name '*.ppk' -o -name '*.kdbx' \) 2>/dev/null

Store	Tool	How it opens
sessions-backup.dat	Solar-PuTTY	decrypt with the session password, or crack (weak KDF, seconds)
confCons.xml	mRemoteNG	decrypt the stored secret
sitemanager.xml / recentservers.xml	FileZilla	base64, not encrypted
*.rdg	RDCMan	DPAPI under the saving user (see Windows credential access)
PuTTY registry keys	PuTTY	ProxyPassword is cleartext
*.ppk, id_rsa	SSH	crack the passphrase with ssh2john if set

The store's password is often already on the box: Solar-PuTTY's .dat is encrypted with a password the admin reused as their application password, recoverable from the app's own database. So the order is find the store, then look for a hash to crack in whatever the user was building (a SQLite db, a .env). If nothing turns up, crack the store directly; these formats use weak KDFs. The recovered credential is frequently for a higher-privileged account than the one you hold, so test it with su - locally before assuming it is only good for a remote host.

Readable keyrings decrypt without cracking

As a low-privilege user you can sometimes read another user's ~/.gnupg/ and there is an encrypted blob nearby (keyvault.gpg, a password store). Service and automation GPG keys frequently have no passphrase, so you decrypt directly, no cracking:

mkdir -p /dev/shm/h && cp -r /home/VICTIM/.gnupg /dev/shm/h/ && chmod -R 700 /dev/shm/h/.gnupg
gpg --homedir /dev/shm/h/.gnupg --list-secret-keys          # confirm a private key is present
gpg --homedir /dev/shm/h/.gnupg -d /home/VICTIM/backup/keyvault.gpg

--homedir is the whole trick: it points gpg at the copied keyring so the victim's own private key does the decryption. The decrypted blob is almost always the pivot credential. The same idea applies to any readable id_rsa or .kdbx you can reach: it is a reuse, not a crack, so it is instant and quiet.

Defense

The common fault is a reusable secret sitting somewhere a lower-privileged user can read.

• Backups must not carry live secrets. Scrub or exclude the database and config from any artifact that can be downloaded, encrypt backups at rest, and never expose .bak, .zip, or .git over the web. Store password hashes with a modern salted KDF (bcrypt, argon2), never unsalted MD5, and keep API tokens hashed, not plaintext.
• Do not save credentials in connection managers on shared or multi-user hosts. Where a tool must, treat its session files as secrets: restrict their permissions and assume the store password is crackable, so do not reuse it anywhere.
• Passphrase-protect private keys and keyrings, give service GPG and SSH keys a passphrase or scope them tightly, and keep ~/.gnupg, ~/.ssh, and .kdbx files unreadable by other accounts.
• Least privilege contains it: a foothold user that cannot read other users' homes, backups, or stores cannot harvest them.

Detection

File access is the signal: reads of session-store files (sessions-backup.dat, *.rdg, confCons.xml, *.kdbx), a copy of another user's ~/.gnupg or ~/.ssh into a world-writable path like /dev/shm, and a backup archive being downloaded unauthenticated. Cracking is loud too: sustained CPU with hashcat/john, or a wordlist being fetched. Audit reads on these paths by accounts that do not own them, and alert on a service account touching another user's keyring.

Use

Authorized and educational use only: your own systems, a lab you control, or an engagement with written permission. This is a post-exploitation enumeration method for an environment you are authorized to assess, shown with the defensive fix. It pairs with living off the land on Linux and Windows credential access.