Venom Lab: Investigating Compromised Ubuntu Server

Scenario

We got you the /var/log folder of one of the compromised ubuntu server. Investigate the logs and figure out the point of entry of the attacker. You have raw logs (/var/log in Desktop), use your linux cli skills over the logs and answer the following.

Tools: LinuxCLI,  T1110,  T1190,  T1210

Investigation Submission

Q1. What CMS is running on the web server?

When we use the ls command to list the contents of the directory, we can see a variety of files and subfolders. Since our focus is specifically on CMS-related configurations or data, the most logical starting point is the apache2 folder, as it typically contains web server configuration files. We navigate into the apache2 folder and begin our investigation there to look for relevant information or answers.

After that, we’ll use the grep command to search for the most popular CMS and see if we get any results. grep -iR wordpress

• i → This option enables case-insensitive search.
• R → This option makes the search recursive, meaning it will search through all files in the current folder and its subfolders.

 

From the output, we can see GET requests for a WordPress page. In the root directory, we also notice Joomla, as WordPress was installed within the Joomla framework.  Answer: Joomla

Q2. What is the IP of the attacker? 

From the data, we can observe thousands of requests targeting various WordPress pages. This pattern strongly suggests a brute-force attack, where the attacker is attempting to identify legitimate pages or vulnerabilities on the site. Within each request, we can also see additional parameters, such as the Date and User-Agent, as well as the originating IP address. This IP address identifies the source of the requests and can be attributed to the attacker.

Answer: 192.168.1.29

Q3. What is the username that has been brute forced by the attacker?

To address this question, we will navigate to the /var/log directory, where system logs are stored. In this folder, we find a particularly relevant file called auth.log.  The auth.log file is a critical system log in Unix-like operating systems (such as Linux) that records authentication-related events. It contains details about user logins, failed login attempts, and authentication processes, including activities related to services like SSH or sudo. This log is an essential resource for monitoring system security, as it allows administrators to detect unauthorized access attempts, suspicious login activities, and other potential security threats.   

To analyze the auth.log file, we can search for specific events or patterns using the following command: 

cat auth.log | grep Failed

After analyzing the auth.log file, we notice numerous repeated login attempts that consistently use the same username but try different passwords with each request. This behavior is a clear indicator of a brute force attack.

A brute force attack is a hacking method used to gain unauthorized access to a system by systematically attempting all possible password combinations until the correct one is identified. These attacks typically involve:

• Automation: Attackers use scripts or tools to rapidly test a large number of password combinations.
• Time and Computing Power: The effectiveness of brute force attacks depends on the computational resources available and the strength of the password being targeted.
• Patterns: In this case, the repeated use of the same username with varying passwords shows the attacker is likely targeting a specific account.

Such attacks are a common tactic to exploit weak or commonly used passwords and are a significant security concern for systems with exposed login interfaces, especially if proper protections (e.g., rate-limiting or account lockouts) are not in place. 

Q4. What is the common name of the vulnerability exploited by the attacker?

To address the question, I utilized the OWASP Top 10 list as a guide to focus on common vulnerabilities, such as SQL Injection, Cross-Site Scripting (XSS), and Local File Inclusion (LFI). By understanding these common attack vectors, I was able to streamline my analysis and search the logs more effectively.

Methodology: Searching for Evidence of LFI Attacks

1. Understanding the Nature of LFI Attacks:

   • Local File Inclusion (LFI) attacks exploit vulnerabilities that allow an attacker to include files from the local server, often by manipulating file path parameters in HTTP requests.
   • Typical LFI attempts involve patterns like:
     • ../ (directory traversal to move up the directory structure)
     • include or require statements in suspicious logs.
     • Accessing sensitive files, such as /etc/passwd or application configuration files.

2. Searching Logs for Indicators of LFI:

   • I used the grep command to search all log files in the /apache directory for patterns characteristic of LFI attacks:
     bash

      

     

3. Findings in the Logs:

   • During my search, I observed suspicious GET requests in the logs. These requests included:
     • Paths containing ../ sequences, which are a hallmark of directory traversal.
     • Attempts to include sensitive system files like /etc/passwd or application configuration files.

Answer: Local File Inclusion

Q5. Attacker viewed the contents of several files. What is the first file? 

While analyzing the logs in the /apache directory, I utilized search techniques to detect possible Local File Inclusion (LFI) attacks by carefully examining GET requests and their corresponding HTTP response codes. These codes provided crucial clues about the success and nature of the attack attempts. Here’s what I found:

Key Indicators from the Logs:

1. 302 Redirection:

   • This status code indicates that the requested resource was temporarily moved to another location.
   • In the context of the logs, the presence of this status code suggested that some requests were intercepted or redirected to another page rather than directly displaying the requested files. This might have been part of an application’s defense mechanism to prevent direct file access.

2. 404 Not Found:

   • This status code shows that the requested resource could not be found on the server.
   • In this case, many 404 responses indicated that attackers were attempting to access files that either did not exist or were outside the application’s directory structure. For example, directory traversal sequences like ../../ were observed in these requests.

3. 200 OK:

   • This status code indicates that the server successfully processed the request and returned the requested resource.
   • Critical Finding: Among these responses, I discovered that a request for the /etc/passwd file received a 200 response. This confirmed that the LFI attack successfully retrieved the contents of the file, which is a key indicator of a vulnerability being exploited.

Answer: /etc/passwd

Q6. What is the username of the account that the attacker got access to? 

In this case, the root user used the sudo command to change the ownership of the /var/www/html/joomla directory. Specifically, the command updated the user and group ownership to www-data, which is typically the user associated with web server processes such as Apache or Nginx.

What Does This Information Tell Us?

1. Understanding the chown Command:

   • The chown command is used to change the ownership of files and directories.
   • The executed command ensured that the Joomla CMS files were owned by the www-data user and group, enabling the web server processes to interact with these files without permission issues.

Q7. What is the first command executed by the attacker?

If we go back to the apache2 folder and look at the logs, we see requests to the mail.log file near the end. In addition, we see the size of the response that the GET request returns.

If we look in the mail.log we can see the commands that the attacker executed.

Q8. What is the URL from which the attacker tried downloading a malicious file?

From the Apache2 logs, we observed evidence of the wget command being used. This command is typically used to download files from a remote source, and in this case, further analysis revealed that the downloaded file was directed to /tmp/poison. We will decode this with cyberchef

Answer: http://192.168.1.29:8080/poison