Introduction
In this lab, you will learn how to adjust the thread count in Hydra, a powerful network login cracker, to optimize its performance. We will set up a basic SSH server on the LabEx VM and then use Hydra to perform password cracking attempts with different thread counts (16, 32, and 4). By comparing the speed and observing the effects of these different settings, you will understand how to optimize Hydra attacks by adjusting thread counts based on available resources and target service characteristics.
Set Up SSH Server
In this step, we will set up a basic SSH server on the LabEx VM. SSH (Secure Shell) is a cryptographic network protocol for operating network services securely over an unsecured network. It's commonly used for remote command-line login and remote command execution.
First, we need to install the OpenSSH server. OpenSSH is a suite of security-related network-level tools based on the Secure Shell protocol, and it's the most common SSH implementation.
Open a terminal in the LabEx VM. You can use the default Xfce terminal.
Execute the following command to update the package lists:
sudo apt update
This command synchronizes the package index files from their sources. It's a good practice to run this before installing any new software. You might be prompted for your password, but remember that the labex user has sudo privileges without a password.
Next, install the OpenSSH server:
sudo apt install openssh-server -y
The -y flag automatically answers "yes" to any prompts during the installation, making the process non-interactive.
After the installation is complete, the SSH server should start automatically. You can check its status using the following command:
sudo service ssh status
To confirm that the SSH server is running, you can check if the SSH port (port 22) is listening. Use the netstat command:
netstat -tulnp | grep 22
You should see output similar to this:
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
This indicates that the SSH server is listening on port 22 for both IPv4 and IPv6 connections.
Now that the SSH server is set up, you can connect to it from another machine using an SSH client. However, for this lab, we will focus on using Hydra to crack the SSH password with different thread configurations.
Run Hydra with Default 16 Threads
In this step, you will use Hydra to attempt to crack the password for the labex user on your SSH server. You will start by using Hydra's default thread count, which is 16.
The password list has already been downloaded during the setup process. The file ~/project/password.txt contains the unix_passwords.txt wordlist from the Metasploit framework, which includes hundreds of common Unix passwords. This larger wordlist will provide a better demonstration of thread performance differences compared to a small manual list.
You can verify the password list is available and check its size:
ls -la ~/project/password.txt
wc -l ~/project/password.txt
This will show you the file details and the number of passwords in the wordlist (should be several hundred entries).
Now, execute the Hydra command. The -l option specifies the username to attack (labex), -P specifies the path to your password list (~/project/password.txt), and -V enables verbose mode to show each attempt. ssh://localhost indicates that you are targeting the SSH service on the local machine.
hydra -V -l labex -P ~/project/password.txt ssh://localhost
Hydra will now begin attempting to log in to the SSH server using each password in your password.txt file. Since you did not specify the -t option, Hydra will use its default of 16 threads, meaning it will try 16 password attempts simultaneously. The -V flag will show you each attempt in real-time.
Important Note about the -V flag:
The -V (verbose) parameter is crucial for observing the attack process. Without it, Hydra only shows summary information and the final result, but you won't see the individual [ATTEMPT] lines that show each password being tested. This verbose output helps you understand how the threading affects the attack speed and pattern.
You will see output similar to this as Hydra progresses:
Hydra vX.Y (c) YYYY by van Hauser/THC - Use freely but only for legal purposes.
Hydra starting at YYYY-MM-DD HH:MM:SS
[DATA] max 16 tasks per 1 server, overall 16 tasks, XXX login tries (l:1/p:XXX), ~XX tries per task
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: !@#$%
[ATTEMPT] target: localhost - login: labex - pass: !@#$%^
[ATTEMPT] target: localhost - login: labex - pass: 000000
...
[22][ssh] host: localhost login: labex password: labex
1 of 1 target successfully completed, 1 valid password found
Hydra finished at YYYY-MM-DD HH:MM:SS
With the larger wordlist, you'll notice that Hydra takes more time to find the correct password, making the thread count differences more apparent. Observe the timing information that Hydra provides when it completes.
Increase to 32 Threads and Compare Speed
In this step, you will increase the number of threads Hydra uses to 32 and observe the impact on the cracking speed. Increasing the thread count can potentially speed up the process by allowing more simultaneous attempts, but its effectiveness depends on your system's resources and the target service's limitations.
Execute the following command in your terminal to run Hydra with 32 threads:
hydra -V -t 32 -l labex -P ~/project/password.txt ssh://localhost
This command is identical to the previous one, except for the addition of -t 32, which explicitly tells Hydra to use 32 threads. The -V flag ensures you can see each password attempt.
Observe the output. You should notice that Hydra reports starting 32 tasks/threads:
Hydra vX.Y (c) YYYY by van Hauser/THC - Use freely but only for legal purposes.
Hydra starting at YYYY-MM-DD HH:MM:SS
[DATA] max 32 tasks per 1 server, overall 32 tasks, XXX login tries (l:1/p:XXX), ~XX tries per task
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: !@#$%
[ATTEMPT] target: localhost - login: labex - pass: !@#$%^
[ATTEMPT] target: localhost - login: labex - pass: 000000
...
[22][ssh] host: localhost login: labex password: labex
1 of 1 target successfully completed, 1 valid password found
Hydra finished at YYYY-MM-DD HH:MM:SS
Comparing Speed:
With the larger wordlist, you should be able to observe more noticeable timing differences between the 16-thread and 32-thread runs. Pay attention to:
- The start and finish times reported by Hydra
- The "tries per task" calculation, which shows how the workload is distributed
- The overall time taken to complete the attack
With 32 threads, you might observe faster completion times, especially if the target password is located later in the wordlist. However, you may also notice increased system resource usage and potentially more connection attempts being made simultaneously.
Reduce to 4 Threads and Observe
In this step, you will reduce the number of threads Hydra uses to 4 and observe the impact on performance. This scenario is useful when you have limited system resources or when the target service might have aggressive rate limiting that could block too many simultaneous connection attempts.
Execute the following command in your terminal to run Hydra with 4 threads:
hydra -V -t 4 -l labex -P ~/project/password.txt ssh://localhost
This command is similar to the previous ones, but now you are explicitly setting the thread count to 4 using -t 4. The -V flag will show you each password attempt in detail.
Observe the output. You should see that Hydra starts only 4 tasks/threads:
Hydra vX.Y (c) YYYY by van Hauser/THC - Use freely but only for legal purposes.
Hydra starting at YYYY-MM-DD HH:MM:SS
[DATA] max 4 tasks per 1 server, overall 4 tasks, XXX login tries (l:1/p:XXX), ~XX tries per task
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: !@#$%
[ATTEMPT] target: localhost - login: labex - pass: !@#$%^
[ATTEMPT] target: localhost - login: labex - pass: 000000
...
[22][ssh] host: localhost login: labex password: labex
1 of 1 target successfully completed, 1 valid password found
Hydra finished at YYYY-MM-DD HH:MM:SS
Observing the Impact:
With only 4 threads and the larger wordlist, you should notice a significant difference in performance:
- The "tries per task" number will be much higher, as each thread has to handle more passwords
- The overall completion time should be noticeably longer compared to the 16 and 32 thread runs
- You'll see fewer simultaneous [ATTEMPT] messages, as only 4 attempts are running concurrently
This experiment demonstrates that a lower thread count will generally result in slower performance, but it can be a necessary adjustment in certain situations, such as when trying to avoid detection by a target system's security measures or when operating on a resource-constrained machine.
Analyze Thread Impact on Performance
In this step, you will analyze the impact of the number of threads on Hydra's performance based on your observations from the previous steps. You have experimented with 4, 16 (default), and 32 threads using a substantial wordlist from the Metasploit framework.
Key Considerations for Thread Count:
- System Resources: The optimal number of threads is heavily influenced by your system's available resources, including CPU cores, memory, and network bandwidth. If you set the thread count too high, your system might become overloaded, leading to performance degradation due to context switching overhead and resource contention.
- Target Service Limitations: The target service (in this case, SSH) may have rate limiting or other security mechanisms in place. If the service limits the number of login attempts per unit of time, increasing threads beyond a certain point will not improve performance and could even trigger security alerts or temporary blocks.
- Network Latency: High network latency between Hydra and the target service can also limit the effectiveness of increasing thread counts. Each thread needs to establish and maintain a connection, and high latency can make these operations slow, negating the benefits of parallelism.
- Wordlist Size: With larger wordlists like the one used in this lab, thread count differences become more apparent. The unix_passwords.txt wordlist contains hundreds of entries, making the performance impact of different thread counts more observable.
Observations and General Guidelines:
- 4 Threads: This setting is generally slower but is suitable for systems with limited resources or when attacking services with strict rate limiting. It's less likely to cause system overload or trigger immediate security alerts. With the large wordlist, you should have observed significantly longer completion times.
- 16 Threads (Default): Hydra's default of 16 threads is often a good balance between performance and resource usage for many systems and target services. It provides a reasonable level of parallelism without typically overwhelming the attacking machine or the target.
- 32 Threads: Increasing the thread count to 32 can potentially improve performance, especially if your system has ample resources (e.g., multiple CPU cores) and the target service does not have aggressive rate limiting. However, it's crucial to monitor your system's resource usage to ensure it doesn't become a bottleneck.
Performance Metrics to Consider:
When evaluating thread performance, consider these factors:
- Total execution time: How long it takes from start to finish
- Attempts per second: The rate at which password attempts are made
- System resource usage: CPU, memory, and network utilization
- Target service response: Whether the service becomes unresponsive or implements blocking
Conclusion:
There is no single "best" thread count for Hydra; the optimal setting depends on a variety of factors specific to your attacking machine and the target service. It is important to experiment with different settings and monitor both your system's performance and the target's response to find the most efficient balance between speed and resource usage. Understanding these dynamics allows you to optimize your Hydra attacks for different scenarios.
Summary
In this lab, you have learned how to adjust Hydra's thread count and its impact on performance using a substantial password wordlist. You started by setting up a basic SSH server on your LabEx VM. You then used Hydra to perform password cracking attempts against this SSH server with varying thread counts: the default 16, an increased 32, and a reduced 4, using the unix_passwords.txt wordlist from the Metasploit framework. By observing the speed and completion time for each scenario with a realistic-sized wordlist, you gained practical insight into how thread count affects Hydra's efficiency. This lab demonstrated the importance of optimizing thread counts based on available system resources and the characteristics of the target service to achieve the best performance in password cracking operations.
