Mitigate Leaked Password Damage with Honeypots

Published:28 March 2022 - 7 min. read

Azure Cloud Labs: these FREE, on‑demand Azure Cloud Labs will get you into a real‑world environment and account, walking you through step‑by‑step how to best protect, secure, and recover Azure data.

The decision to ban breached passwords in your organization should be a no-brainer. Allowing users to use previously leaked passwords is an open invitation to infiltrate your network. Even if an organization enforces multi-factor authentication (MFA), there will always be exceptions.

These exceptions may include service or shared accounts, application passwords, legacy systems, and some VIPs. Organizations must ensure that these accounts are not using previously leaked passwords in addition to enforcing strong passwords.

What are the dangers of allowing breached passwords? How do you mitigate the risks and hit the potential problem head-on before it becomes a firefight? And do you think strong, complex passwords are enough?

This post is kindly sponsored by Specops Software.

The Danger of Breached/Leaked Passwords

One leaked password is all it takes to tear a gaping security hole in your network. Suppose that Gene from HR used the password qwerty123. A password spraying attack could reveal Gene’s password — imagine the wealth of information the hacker can acquire from this misstep.

Once an attacker gets in, they can start deploying a lateral movement attack and drop ransomware, exfiltrate data, or take control of the network with botnets. Such incidents can result in substantial financial loss and damage to a company’s reputation.

These security breaches happen, but you only probably heard about those that caused big headlines. For example, the Colonial Pipeline Ransomware Attack in May 2021 may have started with a stolen password.

The company CEO clarified that the password was a complicated (complex) one and it was not a Colonial123-type password”, which begs the question — are complex passwords not enough anymore?

Breached Password Lists

One way to effectively ban breached passwords is by checking them against one or more breached password lists. These lists can either be something your organization creates, often referred to as a custom dictionary, or third-party collections of known breached passwords.

The term more commonly used for breached or leaked passwords are pwned passwords. Therefore, the lists containing these pawned passwords are called pwned passwords databases.

Some of the most famous breached passwords lists are:

This list came from the HIBP database as a one-off provision to NCSC.

The Specops and HIBP databases receive regular updates from their respective publishers. These lists are at least 5GB to 18GB in size and continue to grow as the number of hacks increases.

At this rate, keeping up with these breached passwords lists would only become difficult or impossible. And even then, you may still stumble upon a complicated password in one of these pwned databases.

For example, the password friendofYOUCANMAKE$200- may seem complex. There are lowercase and uppercase letters, special characters, and numbers. But this password exists in the NCSC Top 100K breached password list, which makes it weak.

This situation may indicate that password hackers are aware and operate within the rules of password complexity requirements. Is compliance with password complexity standards alone still enough to keep your information safe?

Why Honeypots Are the Next Step

It is safe to assume that hackers generate new passwords and use them to launch brute force or password spraying attacks. And because breached passwords databases contain previously leaked passwords only, these live passwords are probably not on any pwned databases yet.

How do you proactively prevent using bad passwords in the wild, then? That’s where honeypots come into play. Deploying honeypots can help organizations understand the type of attacks and capture the attackers’ passwords in real-time.

Organizations can then analyze the honeypot data to develop a custom dictionary of bad passwords, perform more research, and evaluate their existing security strategies. But, establishing in-house honeypots may not be for everyone as they require resources and additional overheads.

In situations where dedicated honeypot resources aren’t practical, breached password lists are already available that can provide the same well-researched honeypot data. In July 2021, Specops released the version of their Breached Password Protection list, which now includes passwords observed in real attacks.

How Honeypots Work

In the simplest terms, honeypots are baits for cyber attackers. A honeypot masquerades as a legitimate system but is intentionally left vulnerable in a controlled manner, like a server with applications, data, and services.

Honeypots work differently depending on the type and purpose. For example, a spam honeypot (or email trap) deploys dummy email domains and addresses. Spammers would target these fake email addresses with backscatter or directory harvesting attacks.

The spam content that these systems receive can then be used to improve an organization’s email content scanning, spam, and phishing prevention methods.

Email traps can also act as open relay servers where spammers attempt to submit malicious messages for delivery. The SMTP logs would reveal where these attempts originate, which can then be included in the deny list or blacklist in the production email service.

A malware honeypot is another type used for deliberately allowing malware attacks. Content security experts would use these infections to analyze the malware and contribute to improving malware detection and threat mitigation.

There are honeypots whose purpose is to accept password login attempts and capture every password into a local or central log. For example, Remote Desktop Protocol (RDP) and Secure Shell (SSH) are two of the favorite targets of password spraying and brute force attacks.

The passwords that these honeypots capture can now be part of an organization’s proactive password blacklist.

Getting Started with a Honeypot

This section serves as a demonstration and proof of the concept of using a honeypot. You’ll learn to deploy a quick-to-build fake SSH server to capture authentication attempts using a username and password combination.

Requirements

You’ll need an Ubuntu server with Python 2.7 and PIP installed for this honeypot deployment. This honeypot example will run on Ubuntu Server 18.04.

Changing the Real SSH Port

The idea of this honeypot is to record password login attempts to the fake SSH server. The honeypot will be more successful if the fake SSH service runs on the default port 22. To avoid locking yourself out of the server, you should first configure the real SSH service to listen on a different port.

1. Log in to your Ubuntu server via SSH.

2. Open the file /etc/ssh/sshd_config file in a text editor like nano.

3. Look for the line that says #Port 22. Next, remove the # sign and replace the number 22 with another number. In this example, the new port number will be 5656. The result will look like the screenshot below. Save the file and close the text editor.

Changing the SSH port number
Changing the SSH port number

Ensure that the new port number you specify is open in the network or the firewall (if any).

4. Restart the ssh service for the new port change to take effect.

sudo systemctl restart ssh

5. Now, log out of your current SSH session.

exit

6. Finally, log in to the server again via SSH. Specify the new SSH listening port number after the -p argument.

ssh username@ip_address -p port_number
Logging in to SSH with a custom port number
Logging in to SSH with a custom port number

Installing PSHITT

The fake SSH software that this honeypot will use is called the Passwords of SSH Intruders Transferred to Text (PSHITT), an open-source Python script.

To install PSHITT, run the below command to clone the PSHITT repository from Github to your home directory.

cd ~
git clone <https://github.com/regit/pshitt.git>
Cloning the PSHITT repository
Cloning the PSHITT repository

Lastly, install the PSHITT dependencies paramiko and python-daemon. PSHITT uses paramiko as the underlying SSH server.

pip install paramiko python-daemon

Running the SSH Honeypot

Now that you’ve cloned the PSHITT repository and installed the dependencies, it’s time to run your honeypot.

1. Run the below command to start your honeypot on port (-p) 22. The parameter -o specifies the output log file, which, in this example, is in password_trap.json.

If you do not specify a custom port number, pshitt will use port 2200 by default. Using any port numbers below 1024 (privileged ports) requires sudo.

# Change the working directory to the pshitt repository
cd pshitt
# Start pshitt as a daemon (-D) and output (-o) the log to password_trap.json
sudo ./pshitt.py -o password_trap.json -p 22
Starting the Honeypot
Starting the Honeypot

2. Now, open a new SSH terminal window and test logging in with the username root and any made-up password. Make the password as basic or as complex as you want.

ssh root@ip_address

Since you entered an invalid password, you should get a permission denied message as below.

Logging in to the fake SSH with a wrong password
Logging in to the fake SSH with a wrong password

You may want to repeat this step multiple times so that PSHITT can capture many password attempts in the log.

3. Finally, open a new real SSH session to the server and inspect the password_trap.json logfile.

cat password_trap.json

As you can see below, there are several login attempts. Most passwords in the log are long and complex.

Viewing the honeypot passwords log
Viewing the honeypot passwords log

You can now process these logs and add these passwords to your custom bad password dictionary as you see fit.

Instead of an SSH Honeypot, you may also want to test an RDP Honeypot. There are many available RDP honeypot implementations that you can try, such as RDPPOT and RDPY.

Specops Password Policy with Breached Password Protection

There’s no denying the significance of honeypots in password security. But the prospect of running an in-house honeypot to gather bad passwords may be more appropriate for small projects or specific use case scenarios. The overhead may not justify the (limited) results in the long run.

The good news is, Specops already did all the live attack password gathering for you, which you can access through their Specops Password Policy (SPP). You can also take advantage of its GPO integration, wherein you can create password policies for your Active Directory, also protecting Azure AD in a hybrid setup.

SPP has pre-canned policies that follow best practice recommendations from Microsoft, NCSC, NIST, and NSA. These templates make complying with industry standards less complicated.

Specops Password Policy Templates
Specops Password Policy Templates

And with the Breached Password Protection list, organizations can block over two billion compromised passwords (and counting). These compromised passwords include known breached passwords lists and those observed in real attacks.

Lastly, Specops ensures that:

“Our research team’s attack monitoring data collection systems update the service daily and ensure networks are protected from real-world password attacks happening right now.”

Hate ads? Want to support the writer? Get many of our tutorials packaged as an ATA Guidebook.

Explore ATA Guidebooks

Looks like you're offline!