Let's investigate the oldest logs by browsing page number 50 of the logs.
Perform a standard search by typing *
in the search bar and selecting All time
in the date filter.
From the logs below, we can deduce several key pieces of information about what transpired:
- The date and time of the logs are consistent across multiple entries, indicating a brute-force attack.
- All HTTP requests are of type GET, and the URLs vary for each log entry.
- The URLs suggest that someone attempted a brute-force attack to load a local path through a GET parameter.
- The name of a well-known brute-forcing tool; Fuzz Faster U Fool v2.0.0-dev.
- The attacker's IP address.
Based on this information, it becomes evident that, for this part of the analysis, we are dealing with a brute-forced LFI (Local File Inclusion) attack.
To further explore the potential damage caused by the LFI (Local File Inclusion) vulnerability, we will apply specific filters to assess the impact of the LFI attack.
Let's proceed by implementing the following search filter:
"GET" AND "200" AND "Fuzz Faster U Fool"
We have identified 97 events (or log entries), indicating that the hacker successfully accessed the content of 97 files on the server.
To verify this, we can independently confirm by copying and pasting the URL into a web browser.
OS Information
Users (/etc/passwd) Information
In the challenge, a second attack is mentioned. Therefore, let's utilize the information we have gathered to exclude the first attack.
To accomplish this, we will include the attacker's IP address and exclude the LFI attack:
"192.168.178.83" AND NOT "Fuzz"
It appears that following the LFI attack, the attacker attempted another assault, this time focusing on brute-forcing the SSH credentials.
Key observations include:
- A high volume of requests occurring each second.
- Numerous instances of "Failed login for ironhack from 192.168.178.83," where the IP address 192.168.178.83 corresponds to the attacker.
- The utilization of the ssh2 service in the attack.
Now, our focus shifts to the SSH logs. Let's examine the frequency of the attacker's unsuccessful login attempts.
"Failed password for ironhack from 192.168.178.83" AND NOT "repeated"
Similarly, we can verify whether there are any SSH login requests other than those that resulted in a failed attempt.
"from 192.168.178.83" AND NOT "Failed"
The screenshot above indicates that the attacker successfully found the correct password through brute-forcing SSH.
To answer the last question (#13), a quick search for "fail2ban" on Google should provide the necessary information.
From a very quick search, we see that fail2ban
is classified as an Intrusion Prevention software. Therefore, the correct answer is Intrusion Prevention System.
Q: What is the technique used for the first attack?
A: brute-force.
Q: What is the name of the attack used by the technique intended above?
A: Local File Inclusion.
Q: What is the name of the tool the attacker used to perform the attack?
A: Fuzz Faster U Fool.
Q: What is the IP address of the attacker?
A: 192.168.178.83.
Q: How many files did the attacker successfully expose?
A: 97.
Q: What's the technique used for the second attack?
A: brute-force.
Q: What is the service the attacker targeted for the second attack?
A: ssh.
Q: What is the username used by the attacker for the second attack?
A: ironhack.
Q: In which file, previously exposed, did the attacked find the username?
A: /etc/passwd.
Q: How many failed attempts has the attacker performed?
A: ssh.
Q: Was the attacker able to successfully log in into the server? (y/n)
A: y.
Q: What is the process ID (PID) associated with the SSH session in relation to the question above?
A: 51362.
Q: What mechanism would you implement to block such attack?
A: Intrusion Prevention System.