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
pwnedpasswords. Therefore, the lists containing these pawned passwords are calledpwnedpasswords databases.
Some of the most famous breached passwords lists are:
- The Specops Breached Password Protection Database.
- The Have I Been Pwned (HIBP) Pwned Passwords List.
- The National Cyber Security Centre (NCSC) Top 100K PwnedPasswords List.
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.
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 ssh5. Now, log out of your current SSH session.
exit6. 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
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>
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
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_addressSince you entered an invalid password, you should get a permission denied message as below.
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.jsonAs you can see below, there are several login attempts. Most passwords in the log are long and complex.
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.
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.”
