Brute Force Attacks Challenge — LetsDefend

Challenge Name: Brute Force Attacks Description: Analyze the Brute Force attacks. Our web server has been compromised, and it’s up to you to investigate the breach. Dive into the system, analyze logs, dissect network traffic, and uncover clues to identify the attacker and determine the extent of the damage. Are you up for the challenge? File location: /root/Desktop/ChallengeFile/BruteForce.7z Role: Incident Responder Skill Level: Medium

What is Brute Force Attack

A Brute Force Attack is a technique where an attacker repeatedly tries different usernames, passwords, PINs, encryption keys, or authentication tokens until the correct one is found.

Differences Between Common Password Attacks

Common Brute Force Attack Entry Points

A brute-force attack can occur against any authentication interface (entry point) where a username, password, PIN, token, or key is required. When investigating a brute-force alert, first identify where authentication is occurring.

Let us start solving the challenge. To access the challenge files, there is a folder named ChallengeFile. Inside this folder, you will find a file named BruteForce.7z. After extracting it, you will see a folder named BruteForce. Inside this folder, there are two files: BruteForce.pcap and auth.log. The archive is password-protected, and the password is “infected”.

BruteForce.pcap contains the raw network packets captured during the attack, allowing us to identify the attacker IP, victim IP, ports, protocols, and the actual network communication flow. auth.log contains the Linux authentication logs generated by the victim server, showing login attempts, targeted usernames, successful and failed authentications, and timestamps related to the brute-force activity.

1) What is the IP address of the server targeted by the attacker’s brute-force attack?

Inside the PCAP file, there are a total of 23,237 packets. For this question, we need to identify the target server IP address or victim machine IP address. To do this, open the PCAP file in Wireshark, then navigate to Statistics -> Conversations and select the IPv4 tab.

The Conversations tab groups packets into source-to-destination communication pairs, making it easier to identify attacker IPs, victim IPs, targeted ports, and traffic volume. It helps analysts quickly determine who communicated with whom and focus on suspicious network connections without having to manually review every packet.

Here, you need to double-click on the conversation entry. We can clearly see that the destination IP address 51.116.96.181 is being targeted by the source IP address 192.168.190.137. A total of 4 MB of data was exchanged during this communication, indicating significant activity between these two hosts.

There is another way to verify this. Go to Statistics -> IPv4 Statistics and select either All Addresses or only the Destination Addresses option.

You will notice that most of the IP addresses are internal, while 51.116.96.181 is an external IP address associated with Microsoft Limited.

You can also apply the filter http.host == 51.116.96.181 to examine the HTTP traffic related to this host.

By reviewing the packets, especially under the HTML Form URL Encoded section, we can observe the usernames and passwords that were submitted during the login attempts, helping you determine whether authentication failures occurred.

2) Which directory was targeted by the attacker’s brute-force attempt?

Here, the question is asking for the directory where the attacker performed the brute-force attack. There are multiple ways to find this information.

The first method is to go to Statistics -> HTTP -> Requests in Wireshark.

Here, you can see all the HTTP requests made during the communication.

From the list, we can identify that /index.php is the directory targeted by the attacker. Along with this, we can also see the destination IP address associated with the requests.

The second method is to use the http.request filter in Wireshark.

This will display all HTTP requests present in the packet capture. By reviewing the Request URI values, we can identify the commonly used URL being accessed throughout the traffic. Although this is a more manual approach, it is still an effective way to determine the directory targeted during the brute-force attack.

3) Identify the correct username and password combination used for login.

Answer Format: username:password

Here, we need to identify the correct username and password combination that was successfully used by the attacker during the brute-force attack.

To do this, first apply the http filter in Wireshark to display all HTTP-related packets. Next, use the Find (magnifier) option and configure it to search for a specific keyword in the packet details. Make sure the search target is set to Packet Details and not Packet Bytes. Then select String and search for the keyword >correct. This will help you locate the packet containing the successful login response.

The Follow -> HTTP Stream option in Wireshark reconstructs the complete HTTP conversation between the client and server, presenting the requests and responses in a readable format rather than as individual packets. This feature helps analysts view URLs, login credentials, form data, cookies, uploaded files, and server responses during web-based attacks and investigations.

By following the HTTP stream of the identified packet, we can see the username and password submitted during the successful login attempt.

The credentials used were username: web-hacker and password: admin12345. The server responded with HTTP 200 OK, confirming that the login was successful.

4) How many user accounts did the attacker attempt to compromise via RDP brute-force?

We can filter for the RDP protocol in Wireshark to view the packets related to RDP authentication and the corresponding server responses. To identify the usernames used during the brute-force attack, we can apply the filter rdp.neg_type == 0x01.

Using this filter, we can observe the RDP Negotiation Request packets and identify the usernames targeted by the attacker. The usernames found are t3m0, MoSalah, Messi, web-hacker, kareem, Mostafa, mmox, Mohamed, Ali, and Mohsen. In total, there are 10 unique usernames that were targeted during the brute-force attack. Out of these, 7 user accounts were successfully compromised through the brute-force attempts.

The Wireshark filter rdp.neg_type == 0x01 displays RDP Negotiation Request packets, which are sent by the client when initiating a new RDP connection to a remote system. This filter helps identify RDP connection attempts and is particularly useful for detecting RDP brute-force activity, as it highlights repeated connection requests from an attacker to a target host.

5) What is the “clientName” of the attacker’s machine?

To find the clientName of the attacker’s machine, we can use the rdp.client.name filter in the Wireshark search bar. After applying the filter, open one of the matching packets and expand the Remote Desktop Protocol section. Inside it, you will find a section called ClientData, and under that, clientCoreData. Within this section, there is a field named clientName, which contains the hostname of the machine initiating the RDP connection. In this case, the attacker’s machine clientName is t3m0-virtual-ma.

The Wireshark filter rdp.client.name displays the hostname (computer name) that the RDP client sends to the remote server during the RDP connection process. This helps identify the attacker’s or user’s machine name and can be valuable during investigations.

Another way to find this information is by using the Find (magnifier) option in Wireshark. Select String as the search type and search for the keyword clientName. Wireshark will locate the packet containing this field, making it easier to identify the client machine name without manually browsing through the packet details.

6) When did the user last successfully log in via SSH, and who was it?

Answer Format: username:time (HH:MM:SS)

Here, we need to identify the last successful SSH login and note the corresponding time. To solve this question, we will use the auth.log file. First, copy the auth.log file from the extracted archive and place it in a working folder on your desktop. Open that folder in the terminal and run the following command: grep -i “accepted” auth.log.

This command will display all log entries containing the word “accepted” from the entire auth.log file. The entries are listed in chronological order, so the last entry represents the most recent successful login. From the output, we can see that the last successful login was performed by the user mmox on Feb 25 at 11:43:54. According to the challenge answer format, the final answer should be: mmox:11:43:54

You can also use the following command to obtain similar results: cat auth.log | grep -i “Accepted password”

The command grep -i “accepted” auth.log searches the auth.log file for all lines containing the word “accepted” in a case-insensitive manner. It is commonly used to identify successful authentication events. During SSH investigations, it helps analysts find successful login attempts by displaying details such as the username, source IP address, authentication method, and timestamp of the accepted login.

7) How many unsuccessful SSH connection attempts were made by the attacker?

We can determine the number of unsuccessful SSH connection attempts using the auth.log file. To do this, we need to search for entries containing the “Failed Password” string, which indicates failed SSH login attempts. To count the total number of failed password attempts, run the following command in the terminal: grep -i “Failed Password” auth.log | wc -l

The output shows that the total number of failed password attempts is 7480.

The command grep -i “Failed Password” auth.log | wc -l searches the auth.log file for all lines containing “Failed Password” in a case-insensitive manner and then counts the total number of matching lines. The resulting output represents the total number of unsuccessful SSH login attempts recorded in the log file.

8) What technique is used to gain access?

Answer Format: MitreID

To find the MITRE ATT&CK ID, we can search for “Brute Force MITRE” on Google.

If we review the MITRE ATT&CK Matrix for Enterprise, we can see that Brute Force falls under the Credential Access tactic.

To identify the specific MITRE ATT&CK technique ID associated with brute-force activity, we can navigate to the corresponding MITRE ATT&CK technique page. From the MITRE ATT&CK framework, the technique ID for Brute Force is T1110.

This technique describes attempts by an attacker to gain access to accounts by systematically trying different username and password combinations until a valid credential pair is found.

Key Learning for the above challenge

1. http.host == 51.116.96.181 -> Displays all HTTP traffic related to the specified host IP or domain.
2. http.request -> Shows all HTTP requests made by clients.
3. http.request.method == “POST” -> Displays HTTP POST requests, commonly used for login forms.
4. http -> Shows all HTTP-related packets.
5. rdp.neg_type == 0x01 -> Displays RDP Negotiation Request packets and helps identify RDP connection attempts.
6. rdp.client.name -> Displays the client hostname sent during an RDP connection.
7. rdp -> Shows all RDP-related traffic.
8. ssh -> Displays all SSH traffic.
9. tcp.port == 3389 -> Filters RDP traffic on the default RDP port.
10. tcp.port == 22 -> Filters SSH traffic on the default SSH port.
11. http.response.code == 200 -> Displays successful HTTP responses.
12. http.response.code == 401 -> Displays unauthorized HTTP responses.
13. frame contains “password” -> Searches packets containing the word “password”.
14. frame contains “username” -> Searches packets containing the word “username”.
15. tcp.flags.syn == 1 && tcp.flags.ack == 0 -> Displays TCP SYN packets, useful for detecting scans and connection attempts.
16. grep -i “accepted” auth.log -> Finds all successful authentication events.
17. grep -i “Failed Password” auth.log -> Finds all failed SSH login attempts.
18. grep -i “Failed Password” auth.log | wc -l -> Counts total failed SSH login attempts.
19. cat auth.log | grep -i “Accepted Password” -> Alternative way to find successful logins.
20. grep -c “Failed password” auth.log -> Counts failed password entries directly.
21. grep “Failed password” auth.log | wc -l -> Counts failed password attempts.
22. grep “Accepted password” auth.log -> Displays successful SSH logins. wc -l -> Counts the number of lines in the output.

With this, the “Brute Force Attacks” challenge is successfully completed.