Analyzing Log Files — Juicy Details

Published on 2022-01-22

This is a write-up for GEEZET1's TryHackMe Juicy Details room. The main purpose of this room is to get familiar with analyzing log files, which is crucial when identifying cyber threats and vulnerabilities.

We are given a scenario where we are a SOC Analyst for one of the biggest juice shops in the world, and an attacker has infiltrated our network. We are provided with three log files and must identify the techniques used to breach our environment.

Reconnaissance

The three log files are briefly shown below:

After a brief glance at each log, it looks like access.log is a good starting point to find the information we need to determine the techniques used to penetrate our environment. Access logs are typically found on web servers and show all requests for files someone has requested from a website. auth.log holds information about authentication attempts, such as someone trying to log into an account using a password. vsftpd.log is an FTP server log for Unix systems (indicating we’re analyzing logs from a Unix system), containing events that occur on FTP.

Now, we can start scanning the access.log file for events that may indicate techniques used by the attacker.

From the beginning of the log file, as shown above, we can already tell that Nmap is being used. Nmap is a popular network scanner that can identify devices connected to a network. It can also provide deeper information on the services running on a network and more. It appears they have used it to scan our network, so we can include it as a tool used against us.

After some scrolling and scanning for services, I found Hydra entries. Hydra is a tool used to brute-force usernames and passwords for different services. From the logs, there are a lot of occurrences of Hydra, indicating they were likely brute-forcing us.

Continuing through the logs, I found entries related to sqlmap. SQL itself is a programming language used to create and manage databases. Sqlmap is a tool created to exploit SQL injection vulnerabilities. Since we are analyzing a server, it's common to have some sort of database located here.

In the log screenshot above, we identify two more techniques. The first one is curl, which is used to transfer data to and from a server. Since we are on a server, it's very likely they used it to transfer some data. The second technique is Feroxbuster, which is used to perform forced browsing on a web application.

We are now at the end of the log file and have discovered all of the techniques that have been used. We need to figure out which endpoint was vulnerable to a brute-force attack. We have already noted that Hydra was our brute-forcing tool, especially after scrolling through all those log events.

As you can see above, Hydra was targeting /rest/user/login. We know that we have been exploited, and this was the only target that was brute-forced, so we can conclude that this was the vulnerable endpoint.

Next, we need to identify which endpoint was vulnerable to SQL injection. We know that sqlmap was the tool used for SQL injection, so let's look at it again.

From the logs, /rest/products/search was the only intended target for sqlmap, so we can say that it is vulnerable to SQL injection. The parameter used for the SQL injection is indicated by the q parameter in the query string.

Now, we want to find the endpoint that the attacker exploited to retrieve files. The only tool used that can directly retrieve files is Feroxbuster.

Feroxbuster targeted several directories, but under /ftp, it seems two .bak files were located.

Stolen Data

After conducting reconnaissance on the log files, we now want to find what data was stolen. We need to look out for the attacker’s movement on the website, response codes, and abnormal query strings.

We aim to find where a hacker could scrape user email addresses from our website. By scanning the logs, we find that product reviews are a common place where users would comment, as shown above.

We know that a brute-force attack was launched against us, but was it successful?

From the above log entries, there are many 400, 500, and 501 status codes, which are error messages indicating unsuccessful attempts. However, there is one 200 status code hiding in there, which means the attack was successful at that point. The time and date for the successful attack are 11/Apr/2021:09:16:31 +0000 (In TryHackMe, you may have to enter 32 seconds).

Since we know that we were hit by a SQL injection attack, we need to determine what information may have been stolen through it.

At the very end of the SQL injection attack by sqlmap, we can see a section containing "email" and "password". This was also accessed using curl immediately afterward.

Previously, we found out that two .bak files (coupons_2013.md.bak and www-data.bak) were attempted to be downloaded using Feroxbuster. We also know that the FTP service was used to gain access to those files because they were in the /ftp directory. If you need a refresher, refer to the screenshot below.

We have all of this information, but now we want to know what account or username was used to access these files. Since FTP was the service used, let's check out our vsftpd.log file to look for login attempts.

In the vsftpd.log file, it appears that an anonymous user accessed those two .bak files.

For our final step in analyzing these log files to complete the room, we have to figure out what service and username were used to gain shell access to the server.

In the above screenshot, you can see that the SSH service (used for shell access) was accessed, and a password was accepted for a user named www-data.

Conclusion

This marks the end of the lab. Analyzing log files is a critical skill in cybersecurity, allowing us to uncover and understand malicious activities within a network. I want to thank GEEZET1 for creating an excellent log analysis room!