Credential reuse

Credential reuse is one of the most reliable pivots in an intrusion: people (and configurations) tend to repeat the same password across places. A key found in one service rarely stays in that service.

The spots where credentials that later work elsewhere most often appear:

• Configuration files of web apps (configuration.php, wp-config.php, .env, settings.py, connection strings), usually with the database password in cleartext.
• History files of the shell (.bash_history), of PowerShell or of commands with the password passed as an argument.
• Database dumps, backups, deployment scripts and notes.

The attack pattern is simple: once you have a password, try it everywhere else, especially against the system's real users (those with a shell in /etc/passwd) over SSH, and against other services (SMB, WinRM, databases, panels).

# search for credentials in common config files
grep -rniE 'password|passwd|secret|api[_-]?key' /var/www /opt /home 2>/dev/null
cat /var/www/app/config/configuration.php | grep -i password
cat /etc/passwd | grep -i 'sh$'        # users with a shell
ssh <user>@<ip>                        # same password

# try the same credential against EVERY service (netexec)
netexec smb   <ip> -u <user> -p '<pass>'
netexec winrm <ip> -u <user> -p '<pass>'
netexec ssh   <ip> -u <user> -p '<pass>'
netexec ldap  <ip> -u <user> -p '<pass>'
# spray / credential-stuffing against a list of hosts or users
netexec smb <targets.txt> -u <user> -p '<pass>' --continue-on-success

How to detect it. Reuse is not an exploit but a valid login in the wrong place, so detection is about anomaly, not signature. The signal is a successful authentication (4624 on Windows, sshd Accepted on Linux) of an account from an unusual host, service or time for it: the same credential suddenly appearing on SMB/WinRM/SSH when that account only ever touched a web panel. A service account that suddenly logs on interactively, or a user authenticating against systems it never touched, are the patterns. A baseline of "who accesses what" helps a lot; without it, reuse blends into legitimate traffic. Prior access to the config file holding the credential (a 4663/auditd) is the early clue.

Defence. Distinct passwords per service and per account, secret managers instead of credentials embedded in files, service accounts without interactive logon and rotation after any exposure. Related to password spraying, which applies the same idea at scale across many accounts.