Snowflake lab: Unearthing Criminal Activities via Server Logs

cat access.log.1 | grep -v 404 | grep 200 | wc -l

A different way would be to use Goaccess and make a html report for a more visual representation of the access.log.1.

goaccess access.log.1 -o LogReport.html –logformat=COMBINED

Question 5: What Discovery ATT&CK Technique is this evidence of?

Based on the MITRE ATT&CK framework, the attacker’s activity aligns perfectly with T1083: File and Directory Discovery under the Discovery Tactic (TA0007). This tactic involves adversaries attempting to identify directories, files, and resources available on a system or web server.

Key MITRE ATT&CK Details

• Technique: File and Directory Discovery (T1083)
• Tactic: Discovery
• Description:
  • Adversaries often perform directory brute-forcing or reconnaissance to locate accessible files or directories.
  • These actions aim to discover valuable resources or understand the structure of a system/web server.

Why This Matters in the Scenario

• The attacker’s use of GET requests to directories, followed by 404 responses, strongly suggests automated directory enumeration or brute-forcing.
• The successful 200 responses confirm the discovery of valid directories, enabling further exploitation.

Question 6: Which interesting URLs from the initial reconnaissance phase did the attacker manually investigate, in order of them being accessed? Include only the last section of the URL.

Given that Access.log.1 contains all the logs related to the automated directory discovery, let’s shift our focus to Access.log.2 for this particular question. Many directory discovery tools, such as the well-known Gobuster, utilize a distinct user-agent string – for instance, “gobuster/3.1.0” by default. However, since we are investigating manual actions conducted by the attacker, we might encounter a different user-agent in the logs compared to Question 1. Additionally, the timestamps between each GET request serve as valuable indicators.  As we examine Access.log.2, we can identify which directories the attacker manually probed. It’s essential to disregard files with extensions like .gif and .ico, as these are likely associated with elements on the initially requested pages, such as logos or images.

Question 7 : What file was downloaded during this activity?

Following the attacker’s visit to the /database/ directory, we observe a subsequent GET request for the database file. 

The answer to Question 7: /IMPWeb/database/sqli.db

Question 8: What are the names of the users the attacker attempted to log into?

To address this question, we analyze the access.log.2 and mysql_general_log.csv to cross-reference login attempts with corresponding usernames. Starting with the POST request to /login.php at 07/Dec/2023:02:00:42, we correlate this timestamp with the SQL query logged in the database. This query reveals the first username associated with the login attempt. For the second username, we locate another query further down in the SQL logs, specifically on line 255, which provides a different username tied to another login attempt.

The answer to Question 8: administrator, admin

Question 9 & 10: In total (success or failure), how many login attempts were made for the first account?

To determine the number of login attempts for the users “administrator” and “admin”, I utilized the command line. By leveraging grep, I filtered the SQL queries specifically targeting these usernames and then used wc -l to count the occurrences.

cat mysql_general_log.csv | grep "WHERE user='administrator'" | wc -l

The answer to Question 9: 18  The answer to Question 10: 8

Question 11: At what time did the attacker successfully log in?

Upon examining access.log.2, it’s clear that every POST request resulting in a failed login attempt is followed by a 302 redirect to /login.php, followed by a GET /login.php that returns a 200 response. Further down the log, a distinct sequence emerges: a POST request to /login.php followed by a 302 redirect and then a GET /index.php with a 200 response. This pattern signifies a successful login attempt, where the user is redirected to the index.php page upon successful authentication. The timestamp associated with this successful login attempt is critical for further investigation and should be noted.

The Answer to Question 11: 07/Dec/2023:02:06:04

Question 12: We know the attacker uploaded a file. What time was this done?

I returned to the access.log.2 and search for POST requests to the /uploads folder. The answer to Question 12: 07/Dec/2023:02:14:00

Question 13: What is the name of the file?

After the upload of a file to the /IMPWeb/vulnerabilities/upload/ directory, a subsequent GET request reveals an unusual .php file. This file is then accessed with the parameter cmd=whoami, confirming the presence of a simple PHP web shell.

A PHP web shell is a malicious script covertly uploaded to a server, acting as a backdoor for attackers. It enables them to:

• Execute commands remotely (e.g., whoami to identify the current user).
• Manipulate the server’s file system.
• Maintain persistent access, posing a significant security risk.

This activity highlights the urgency of addressing vulnerabilities in file upload directories to prevent unauthorized access and mitigate such threats.

The answer to Question 13: snowshell.php

Question 14: What is the ATT&CK Technique ID for this activity? (Format: TXXXX.xxx)

Uploading a web shell is indeed a method of establishing persistence within a compromised environment. To explore this in the context of the MITRE ATT&CK Framework, navigate to:

• Techniques > Persistence > Server Software Component

Once there, search for “web shell” to find its corresponding technique.

Relevant Technique

• T1505.003: Web Shell
  • Tactic: Persistence
  • Description: Adversaries use web shells as a backdoor to gain and maintain persistent access to a server. These scripts enable remote command execution, file manipulation, and further exploitation.

This technique demonstrates how attackers leverage web servers to maintain control over compromised systems. Identifying and mitigating web shells is critical to preventing long-term damage and escalation within the environment.

Question 15: At what time did the attacker read a file that gives them information about system users?

The /etc/passwd file on Unix-based systems contains critical information about system users, including their usernames, user IDs (UIDs), group IDs (GIDs), home directories, and default shells. While it doesn’t store passwords directly (modern systems use /etc/shadow for that), it can still provide valuable insights to an attacker.

Given that the attacker has successfully uploaded a web shell, they can execute commands like cat /etc/passwd to read this file. This action allows them to:

1. Enumerate Users:

   • Identify all user accounts on the system, including system and service accounts.
   • Target specific accounts for privilege escalation.

2. Identify Privileged Users:

   • Look for users with UID 0 (root) or accounts with access to sensitive services.

3. Plan Further Exploitation:

   • Use the information to craft targeted attacks, such as brute-forcing passwords for specific accounts.

To confirm whether such activity has occurred, we need to scrutinize the logs for relevant signs. Upon analysis, we have identified a log entry containing the “cat” command and “/etc/passwd”. This log entry should provide us with the timestamp we need for our investigation.

Question 16: The attacker tried to establish further access to the server utilizing their existing access. What two languages were used in this attempt?

After uploading a web shell and obtaining the capability to execute commands, an attacker would logically aim to establish a reverse shell for persistent and interactive access. Leveraging Living Off the Land Binaries (LOLBins) is an effective way to achieve this while avoiding detection. Upon reviewing access.log.2, we can observe two distinct LOLBins being used to create a reverse shell:

Question 17: What directory did the attacker attempt to access multiple times?

The attacker’s use of the cd command to navigate a specific directory, followed by an unsuccessful attempt and the subsequent entry of wtf, indicates a moment of frustration or confusion when they encountered an unexpected issue.

The answer to Question 17: /home/WebAdmin

Question 18: What command gets the attacker another method of remote access?

The command nc+-nlvp+51337+-e+%2Fbin%2Fbash is a URL-encoded Netcat command. After decoding, it reads:

nc -nlvp 51337 -e /bin/bash

Breakdown of the Command:

1. nc:

   • Invokes the Netcat binary, a powerful networking tool.

2. Options (-nlvp):

   • -n: No DNS lookup, to avoid delays caused by hostname resolution.
   • -l: Listen mode, allowing the system to wait for an incoming connection.
   • -v: Verbose mode, enabling detailed output for troubleshooting.
   • -p 51337: Specifies the port 51337 for listening.

3. -e /bin/bash:

   • Executes the /bin/bash shell when a connection is established.
   • This effectively creates a reverse shell, granting the attacker remote command execution on the server.

Significance of the Command

• Purpose: The attacker is using Netcat to establish a backdoor, allowing them to execute bash commands remotely over the network.
• Port 51337: The choice of port 51337 is noteworthy as it resembles “elite” (leet-speak for 1337), a subtle indication of hacker culture.

Security Implications

• This command transforms the server into a listening backdoor, enabling full control for the attacker.
• Netcat is often misused in this way, despite its legitimate applications.

Question 20: What 2 accounts did the attacker fail to access the database on?

For this answer, we need to refer back to the mysql.general.log.
We’ll focus on column F in the log. Our objective is to identify a specific error message: “Access Denied”.
Using the find function (Ctrl + F), we can search for this error within the log. This search will lead us to the answer for question 20.

The answer to Question 20: www-data, admin

Question 23: What table does the attacker dump, and what is the output file name?

As we scroll down from line 340, we encounter some SQL queries being executed. In the screenshot provided, we observe that the attacker executes the query “SELECT * FROM USERS INTO OUTFILE path/to/output/file”. This query essentially means “select everything from the table Users and store it into an output file.” The answer to Question 23: users,out.csv