Ignore Hydra Restore Files

Introduction

In this lab, we will explore how Hydra handles interrupted attacks and how to resume them effectively. We'll simulate an interrupted Hydra attack against the SSH service on localhost by creating simple username and password lists, launching an attack, and then manually interrupting it using Ctrl+C.

The lab then guides you through restarting the attack with the -R option and observing the delay, followed by using the -I option in conjunction with -R to skip the delay and ensure a fresh start. Finally, you'll confirm that the attack restarts as expected, ignoring any previous restore files.

Skills Graph

Simulate Interrupted Attack

In this step, we will simulate an interrupted Hydra attack. This will help us understand how Hydra handles interruptions and how we can resume attacks later. We'll start by launching a basic Hydra attack and then manually interrupt it.

First, let's create a simple password list. Open a terminal in the ~/project directory and use nano to create a file named passwords.txt:

nano passwords.txt

Add a few common passwords to the file, one password per line. For example:

password
123456
qwerty

Save the file and exit nano (Ctrl+X, then Y, then Enter).

Now, let's create a simple username file. Use nano to create a file named users.txt:

nano users.txt

Add a single username to the file:

root

Save the file and exit nano.

Next, we'll launch a Hydra attack against the SSH service on localhost. We'll use a simple command that will likely succeed quickly, but we'll interrupt it manually to simulate a longer attack.

Execute the following command:

hydra -L users.txt -P passwords.txt localhost ssh

This command tells Hydra to:

• -L users.txt: Use the users.txt file for usernames.
• -P passwords.txt: Use the passwords.txt file for passwords.
• localhost: Target the localhost.
• ssh: Attack the SSH service.

While the attack is running (you should see Hydra trying different username/password combinations), press Ctrl+C to interrupt it.

You should see output similar to this (the exact output may vary):

Hydra v9.6 starting, press Enter to test creds or Ctrl+C to exit
[DATA] 1 task, 1 server, 1 userfile, 1 passfile, max 1 task(s) per 1 server, overall 1 task(s)
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost  login: root  password: password
[ATTEMPT] target: localhost  login: root  password: 123456
[ATTEMPT] target: localhost  login: root  password: qwerty
^C
3 of 3 target(s) completed, 0 valid password(s) found

The ^C indicates that you interrupted the process. This simulates a scenario where the attack was stopped prematurely. We will use this interrupted state in the next steps to explore Hydra's resume capabilities.

Restart with -R and Note Delay

In this step, we will restart the interrupted Hydra attack from the previous step using the -R option. This option tells Hydra to resume the attack from where it left off. We will also observe the delay that Hydra introduces when resuming an attack.

To restart the attack, execute the following command:

hydra -R -L users.txt -P passwords.txt localhost ssh

This command is similar to the previous one, but with the addition of the -R option.

• -R: Resume previously aborted/crashed session.
• -L users.txt: Use the users.txt file for usernames.
• -P passwords.txt: Use the passwords.txt file for passwords.
• localhost: Target the localhost.
• ssh: Attack the SSH service.

Observe the output. You should notice a delay before Hydra starts attempting passwords again. This delay is intentional and is designed to avoid detection by intrusion detection systems (IDS). Hydra stores the progress of the attack in a temporary file, and when you use the -R option, it reads this file to determine where to resume the attack.

The output will look something like this:

Hydra v9.6 starting, press Enter to test creds or Ctrl+C to exit
Resuming previous session
[DATA] 1 task, 1 server, 1 userfile, 1 passfile, max 1 task(s) per 1 server, overall 1 task(s)
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost  login: root  password: qwerty
3 of 3 target(s) completed, 0 valid password(s) found

Note: The delay might be very short in this example because we only had a few passwords in our list. However, with larger password lists, the delay will be more noticeable. Also, since we interrupted the attack after it had already tried 'password', '123456', and 'qwerty', it may complete very quickly.

Use -I with -R to Skip Delay

In this step, we will use the -I option in conjunction with the -R option to skip the delay that Hydra introduces when resuming an attack. The -I option tells Hydra to ignore existing session files and start a new session, effectively bypassing the delay.

Execute the following command:

hydra -I -R -L users.txt -P passwords.txt localhost ssh

This command includes both the -I and -R options:

• -I: Ignore an existing session file / do not create a new one.
• -R: Resume previously aborted/crashed session.
• -L users.txt: Use the users.txt file for usernames.
• -P passwords.txt: Use the passwords.txt file for passwords.
• localhost: Target the localhost.
• ssh: Attack the SSH service.

Observe the output. You should notice that Hydra starts attempting passwords immediately, without the delay that was present when using only the -R option.

The output will look something like this:

Hydra v9.6 starting, press Enter to test creds or Ctrl+C to exit
[DATA] 1 task, 1 server, 1 userfile, 1 passfile, max 1 task(s) per 1 server, overall 1 task(s)
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost  login: root  password: password
[ATTEMPT] target: localhost  login: root  password: 123456
[ATTEMPT] target: localhost  login: root  password: qwerty
3 of 3 target(s) completed, 0 valid password(s) found

By using -I with -R, we are essentially telling Hydra to resume the attack but to ignore any existing session data. This can be useful in situations where you want to restart an attack quickly without waiting for the delay. However, be aware that skipping the delay might increase the risk of detection.

Confirm Fresh Start

In this step, we will confirm that using the -I option with -R effectively starts a fresh attack, ignoring the previous session's progress. To do this, we'll modify the password list and observe that Hydra attempts all passwords from the beginning.

First, let's modify the passwords.txt file. Open it with nano:

nano passwords.txt

Add a new password to the beginning of the file:

newpassword
password
123456
qwerty

Save the file and exit nano.

Now, execute the Hydra command with -I and -R again:

hydra -I -R -L users.txt -P passwords.txt localhost ssh

Observe the output. You should see that Hydra starts by attempting the newpassword password, which was the first password in the modified list. This confirms that Hydra is starting a fresh attack and not resuming from the previous session's progress.

The output will look something like this:

Hydra v9.6 starting, press Enter to test creds or Ctrl+C to exit
[DATA] 1 task, 1 server, 1 userfile, 1 passfile, max 1 task(s) per 1 server, overall 1 task(s)
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost  login: root  password: newpassword
[ATTEMPT] target: localhost  login: root  password: password
[ATTEMPT] target: localhost  login: root  password: 123456
[ATTEMPT] target: localhost  login: root  password: qwerty
4 of 4 target(s) completed, 0 valid password(s) found

This step demonstrates that the -I option, when used with -R, provides a way to start a new Hydra attack, effectively ignoring any previous session data. This can be useful when you want to ensure that all passwords are tested, regardless of whether a previous attack was interrupted.

Summary

In this lab, we simulated an interrupted Hydra attack against the SSH service on localhost. We created users.txt and passwords.txt files containing usernames and passwords, respectively. We then launched a Hydra attack using these files, targeting the SSH service.

During the attack, we manually interrupted the process using Ctrl+C. This allowed us to observe how Hydra behaves when an attack is prematurely terminated, setting the stage for exploring how to resume or restart attacks effectively in subsequent steps.