Password Reuse and Lateral Movement

Introduction

Password security guidance tends to focus on creating a strong password that will be resilient to both direct password guessing and offline cracking. This is good guidance but doesn’t include the risks when your password is directly compromised…which is far more likely than you may think!

Password compromise can happen many different ways and once an adversary has a valid username/password combination for a user, they can often be reused on many other systems and services. Once logged in they can do anything you could in the service, which could include transferring money, unlocking doors, or accessing sensitive data.

Credential Access Methods

If you are a penetration tester, you can take advantage of the user tendency to reuse passwords if you are able to do access some of the following:

Website Login

Probably the most common method for credential capture is a fake login page created as part of a phishing scam. If you are able to spoof a valid page and give a reason like updating information, a user can often be tricked into giving you their credentials to the real service. Sophisticated phishing sites can even redirect the user to the real page after logging in to make it even less suspicious!

If you have access to modify a legitimate web site login page, a more advanced options is to change the code to save off legitimate credentials to a file or send to another system you control. Inserting code in this manner bypasses transport protections of HTTPS and any secure hashing functions protecting the local storage of accounts. To find opportunities for this, check web server configurations like http.conf and nginx.conf to see where local application configruation directories are and if you can control them.

Database Access Credentials

It is very common for websites with active content (like php or aspx) to use a connection to a back-end database for authentication and storage of web site content. Typically this will be in the root of the web server (e.g. /var/www/html/) or in the root directory of an application. Because these files are needed by the web service itself, they often have very permissive access. As a penetration tester, if you find yourself with shell access to a web server, it is always a good idea to look for these!

Database Compromise

Once you have credentials to access a database, it can be enumerated to look for authentication information for the web application. This often includes password hashes, or possibly even plaintext passwords if it is an insecure application! Specific access methods vary by application, but often the table is called ‘users’ or ‘authentication.’

Development Repository Secrets

If a developer isn’t using good practices to manage system secrets they may get saved in their development repository. This can include senstive passwords related to system deployment or tokens for cloud service access all of which can be exploited to access additional resources. Possibilities for finding data like this includes:

• Public project repositories like GitHub – clone the repository and search through its contents and history for sensitive files
• Accidentally exposed repositories on a development web server – these are more likely to contain secrets if the developer never expected them to become public. Check for the presence of a .git folder on a web server (scanners like nikto automatically do this). If one is found, you may be able to directly clone it with git clone or have to use a tool like gitdumper to get the files to examine on your system.

Web Browser Profiles

Most modern web browsers allow users to store passwords for websites. While this is very convenient for the user, it results in the passwords being stored locally and accessible to a red-teamer who gains access to their system. The browsers usually offer an optional master password, but all too often this is not used!

Firefox

Firefox credentials can be found encrypted in the logins.json file stored in your user profile folder, either ~/.mozilla on Linux, or %APPDATA%\Roaming\Mozilla on Windows. The easiest way to dump them is with the firefox_decrypt tool which can be found on github and easily run with python:

python firefox_decrypt.py

Chrome

Similar to Firefox, the Chrome profile stores per-user saved passwords and they may even be synched across devices. You can use a tool like chrome decryptor or chromium password decryptor to decrypt the password stores with local access.

Credentials in Other Files

One of the first things to do as a penetration tester when you get access to a new system is check local user files for ‘interesting’ contents. There is no one right answer for every system, you need to figure out what applications the user uses and then look for stored credentials or other authentication secrets. This is especially useful when running as a privileged user as you will be able to see all local files for all users.

Examples of things to check for:

• Passwords found in .bash_history commands
• Authentication keys in a users’s .ssh folder
• Plaintext passwords in .htpasswd files in web directories
• Kubernetes secrets in local mysecret files
• Passwords and API access tokens for other services like AWS in .csv or .txt note files that the user thought were private
• Servers recently accessed in web access logs, which can lead to new places to try any found credentials

Keyloggers

An attacker with privileged access to a system can install a keylogger as part of post-exploitation. Since this will capture all input text on a system, the output can be parsed to look for password entries based on known URLs or email addresses.

Possible keylogger output:

www.gmail.com<enter>bob@gmail.com<tab>#1Password<enter>Hey Jerry...

Command Line Arguments and Environment Variables

Process command line arguments are visible to all users on a system and can be an excellent source of information if you have low-privilege access to a server. Use a tool like pspy on Linux or Process Explorer on Windows to view the arguments to current and recurring user processes which can include interesting information like passwords or other process secrets. Additionally, system environment variables can include application configuration data and sometimes even authentication secrets so it also a good idea to check them on a system with env on Linux or set on Windows.

Countermeasures and Conclusion

The best defense against password reuse attacks is to generate a strong, unique password for every website/service using a password manager. This means you don’t have to generate these yourself or even remember them as the manager can generate truly random passwords and securely store them associated with the appropriate login URL or application. The password manager itself is secured using some form of a master password which is the only thing you have to memorize going forward.

Your identity can be further secured by leveraging available multi-factor authentication (MFA) like a FIDO/U2F hardware token, fingerprint reader or authenticator app on a mobile device. If these are in use, an attacker will not be able to successfully log in even if they have stolen a valid password. Modern multi-factor authentication is usually minimal extra effort to use making it a low-cost, high reward option to significantly harden personal security.

Additionally when breaches happen, services like haveibeenpwned are a user-friendly way of allowing users to see if any of their passwords may have been compromised. If you find yourself on one of these lists, you need to change passwords associated with that email or username ASAP!

Conclusion

By combining best practices of using a password manager, securing it with MFA, and being aware of when possible breaches occur, you can rest assured that your identity will be very difficult to steal or misuse.