LetsDefend— Brute Force Attacks Challenge Walkthrough

Investigating a Brute Force Attack with Wireshark and Auth.log

9 min readSep 15, 2024

Introduction:

Welcome to my weekly walkthrough! Imagine this: a web server has been compromised, and you’re handed a network packet capture file along with the server’s authentication log to figure out what was accessed and how it happened. If this sounds exciting to you, you’ve stumbled on the right blog!

This week’s mission is the Brute Force Attacks incident response challenge from LetsDefend. To solve this challenge, we’ll use Wireshark to discover the scope of a brute force attack, including the server’s IP, the targeted directory, the number of login attempts made, and which accounts were ultimately compromised. But that’s not all. Using the web server’s auth.log file, we’ll also determine if the attacker was targeting SSH and if they were able to brute force their way into any accounts. Sounds like a fun time, right? Let’s get to it!

And hey, if you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!

Challenge Link: https://app.letsdefend.io/challenge/brute-force-attacks

Challenge Scenario:

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?

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

Let’s get going! The first thing we need to do is extract the BruteForce.7z archive from within the ChallengeFile folder on the Desktop. Once it’s extracted, we’ll have two evidence files:

BruteForce.pcap
auth.log

The first file, BruteForce.pcap is a network packet capture file that we can open with Wireshark. The second, auth.log, is the web server’s authentication log that will help us find successful and failed logins. Throughout this investigation, we’ll use both the web server log and the network traffic log to investigate.

To tackle Question 1, let’s check out BruteForce.pcap first. We can double-click the file to open it Wireshark where we can start to analyze the packets.

Since there are thousands of packets to sort through, let’s start with a birds-eye view to understand what the IP addresses have the most traffic. This will help us narrow down which addresses we want to analyze further.

To do this in Wireshark let’s utilize the Statistics > Endpoints > IPv4 view. This will provide a summary of all the IPv4 addresses in the pcap.

Using this view, we see several private IP addresses (192.168.190.x) and several public IP addresses. But notice the number of packets — there are only two IPs responsible for the overwhelming amount of traffic.

Remember, we’re looking for the target IP address of a web server which are usually internet-facing. Using our powers of deduction, the target server is the one with the public IP address of 51[.]116[.]96[.]181.

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

Okay, now that we know the IP address of the web server let’s do some further investigating in Wireshark.

Since web servers typically accept connections on ports 80 (HTTP) and 443 (HTTPS), let’s use Wireshark’s filter toolbar focus on the HTTP protocol. This will let us see the captured HTTP requests sent to the server.

After filtering for HTTP, we now see hundreds of HTTP POST requests sent to the web server targeting the index.php directory.

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

Yikes! Based on the question, the attacker was able to find a valid username/password combination and gained access to the server.

To answer Question 3, we have to find the credentials used for authentication within the pcap. Fortunately, we can find this information quickly by leveraging Wireshark’s search function to search the packets for a keyword.

But first, we need to figure out what we are searching for exactly. For each HTTP POST request, the web server returns a response. Look at any of the responses sent from the server:

Each incorrect response returns the message >incorrect in red. So, maybe correct responses return >correct? Let’s find out! Rather than manually review all these records, let’s finally use Wireshark’s search functionality.

Press CTRL + F or press the magnifying glass to bring up the find/search bar, then select String, and finally select Packet details so we can search within the middle “packet details” window.

Now enter >correct into the search box.

Hey, we’ve got a hit! Now, right-click the packet and select Follow > HTTP Stream.

With visibility into the complete HTTP Stream of the “correct” login, we can now identify the username and password sent in the POST request to the server!

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

Now let’s determine how many usernames the attacker tried to brute force. To do this, let’s adjust our filters to narrow the scope from all HTTP traffic to only show the HTTP POST requests to the web server.

http && ip.dst==51.116.96.181

Do you see that each one captured a username form item?

Scrolling through the packets, we will see a few user accounts listed, but we can search much more efficiently with another method outside of Wireshark. To start, we’ll export the displayed packets to a plain text file.

Press File > Export Packet Dissections > As Plain Text…

Now, choose a File name and press Save. This will export the packets we have filtered into a text file. For this walkthrough, I’ll call my output file HTTPexport.txt.

Now, we’ll open the terminal and use grep to search the text file, displaying only the lines matching “username” and then removing any duplicate entries.

cat HTTPexport.txt | grep -i "username" | uniq

Using this method provides us the total number of user accounts targeted by the attacker!

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

Previously we focused only on HTTP protocol traffic. Now we need to zoom out and search the rest of the pcap since the attacker’s machine name is not available in the HTTP request data.

But what are we looking for exactly? Let’s take the question literally and perform a search for the string “clientname” like we did back in Question 3.

This search will identify Remote Desktop Protocol (RDP) traffic directed towards the web server. In the packet details pane, the attacker’s client name will be visible in the clientName field of the Remote Desktop Protocol ClientData.

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

Now, rather than focus on HTTP or RDP events like we have in the previous questions, we’re going to look for Secure Shell (SSH) events — there’s just one problem, we can’t find them in Wireshark. That’s Okay! For this task we’ll pivot to the second challenge file, auth.log.

Open the log file in any text editor. Once it’s open, we’ll simply use the built-in search/find tool and look for ssh.

There are thousands of hits! Let’s review some of the ssh logging events and observe that successful login attempts contain the string “Accepted password” along with the username, IP address, and source port.

This means we can search the log for entries containing “Accepted password” to determine how many times the attacker logged and then navigate to the last result (it’s in ascending order) to find the last login and answer Question 6.

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

From the information we gathered in Question 6, we know that successful ssh logins generate an “Accepted password” log entry, but you also may have noticed that unsuccessful logins generate a “Failed password” entry.

So, let’s just simply search in the text editor for “Failed password” which should give us the total number of failed login attempts captured in this log!

Question 8: What technique is used to gain access?

Okay! We’ve now analyzed the HTTP, RDP, and SSH traffic and determined that the attacker tried thousands of guesses over these different protocols to gain access to the web server. With the sheer number of attempts, we can conclude that the web server was the victim of a brute force attack.

Let’s pivot to MITRE ATT&CK, a popular knowledge base of adversary tactics, techniques, and procedures to get more information and find the correct MITRE ID for this technique…

Brute Force

Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password…

attack.mitre.org

Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained.[1] Without knowledge of the password for an account or set of accounts, an adversary may systematically guess the password using a repetitive or iterative mechanism.[2] Brute forcing passwords can take place via interaction with a service that will check the validity of those credentials or offline against previously acquired credential data, such as password hashes.

Now that we have located the correct technique ID from MITRE ATT&CK, let’s submit our answer and wrap up this investigation!

Conclusion:

Great job! Going through this investigation, we’ve gathered the required evidence and scoped the damage caused by this brute force attack. With Wireshark, we started to paint a clearer picture of the attacker’s brute force methods and targets by pinpointing the server IP, the specific targeted directory, the number unsuccessful and successful login attempts made, and the compromised accounts. Then, by examining the web server’s auth.log file, we were able to determine the full scope of the SSH brute force attack including the number of successful and unsuccessful logins and what credentials were compromised.

A big thank you to LetsDefend for creating another cool and engaging challenge. The sheer volume of events generated during a brute force attack makes searching through the data all the more difficult, so this challenge was really helpful to practice log analysis in the context of a brute force attack. Personally, I hadn’t had much exposure or need to look through Linux auth.log files before. After seeing how much valuable information they hold, I will definitely remember this one during future Linux investigations. I also pick up something new every time I go hands-on with Wireshark. This time, seeing what packet details are available in the HTTP POST responses was really fascinating. Thanks for reading along!

If you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!

Until next week’s challenge — stay curious and be safe out there!

Tools & References:

Wireshark: https://www.wireshark.org/

Wikipedia — POST (HTTP): https://en.wikipedia.org/wiki/POST_(HTTP)

MITRE ATT&CK — Brute Force (T1110): https://attack.mitre.org/techniques/T1110/