September 3, 2024
Slingshot challenges us to investigate a compromised web server, using ELK, to discover a web-based attack. We’re tasked with determining vulnerability exploitation, account compromise, and data exfiltration.
Slingway Inc., a leading toy company, has recently noticed suspicious activity on its e-commerce web server and potential modifications to its database. To investigate the suspicious activity, they’ve hired you as a SOC Analyst to look into the web server logs and uncover any instances of malicious activity.
To aid in your investigation, you’ve received an Elastic Stack instance containing logs from the suspected attack. Below, you’ll find credentials to access the Kibana dashboard. Slingway’s IT staff mentioned that the suspicious activity started on July 26, 2023.
By investigating and answering the questions below, we can create a timeline of events to lead the incident response activity. This will also allow us to present concise and confident findings that answer questions such as:
What vulnerabilities did the attacker exploit on the web server? What user accounts were compromised? What data was exfiltrated from the server?
What was the attacker’s IP?
We’ve been told that the suspicious activity began on July 26th, 2023, so we’ll start by filtering for any events that occurred on or after that date. We’ll also sort the events from Oldest -> Newest.
With our dates filtered and events sorted, we’ll look at the first event to get an idea of what fields were parsed by Elastic.
We see that the User-Agent was parsed as “request.headers.User-Agent” and that the source IP addresses are recorded as “transaction.remote_address”.
Let’s check what User-Agents are present in the logs.
We can do this by typing user-agent into the field search and clicking the request.headers.User-Agent field that appears.
We can see that over 60% of User-Agents were recorded as Gobuster, 16% were Hydra, and 1% was from Nmap.
Let’s filter for events that contain any of these user-agents to confirm that they were all executed from a single IP.
Our results show that 100% of these events are associated with the IP address 10.0.2.15.
What was the first scanner that the attacker ran against the web server?
Our results are already filtered from Old -> New, so the oldest event is the first one we see in our results.
With that, we can see that Nmap was the first tool that was run against the endpoint.
What was the User Agent of the directory enumeration tool that the attacker used on the web server?
We discovered this earlier when we did our analysis in Q1.
In total, how many requested resources on the web server did the attacker fail to find?
We’ll start by filtering for the malicious IP and checking the response code of the requests by checking the response.status field.
We’ll filter for only the results that contain a response code of 404.
What is the flag under the interesting directory the attacker found?
We’re looking for successful enumeration, so we’ll change our filters to exclude response codes 404 and 401.
To see the target of the requests we can use the Visualize tool on the request.request_line field.
In the visualization, screen we’ll change the display to a Table and increase the number of values to any value greater than the total number of unique requests.
Immediately we can see directory traversal in which the attacker attempted to access phpmyadmin/config-db.php.
Scrolling through the results we can see plenty of other malicious activity, including command execution.
We also see requests to the “backups” directory and a flag parameter.
What login page did the attacker discover using the directory enumeration tool?
Scrolling through the output we can see a login page request, but we’ll filter our results for requests from Gobuster just to be sure it is the correct one.
There doesn’t appear to be a login page within our current results, but perhaps it was a failed request.
Let’s include 401 status codes in our results to see if the requests were blocked.
And here we can see the login page.
What was the user agent of the brute-force tool that the attacker used on the admin panel?
We know that one of the tools used by the attacker was Hydra, a brute-force tool, so we’ve already got the answer to this question.
What username:password combination did the attacker use to gain access to the admin page?
We’ll filter for Hydra requests and analyze the results.
We want to see successful results so we’ll filter for status codes that aren’t 401 or 404 again.
Analyzing the data we can see an Authorization header with a base64 encoded string.
A quick trip to cyberchef will give us the answer.
What flag was included in the file that the attacker uploaded from the admin directory?
We can start by looking for POST requests.
We’ll use the visualization tool to look at a table of URLs again to see if we can spot anything interesting. Note: Though, really, we should have noted that there was a request to an upload URL when we analyzed the requests previously.
We see a POST request to admin/upload.php, so we’ll apply that request as a filter and return to the Discover tool.
Looking through the event information we can see the request.body field contains the plaintext file.
We can see the filename is easy-simple-php-webshell.php.
What was the first command the attacker ran on the web shell?
We already discovered command execution during our initial analysis, but we’ll refine the filter to make the commands more clear.
We’ll adjust our filter to include any requests to the shell script we identified previously.
What file location on the web server did the attacker extract database credentials from using Local File Inclusion?
We discovered LFI exploitation at the start of our investigation, but we’ll filter again to make the results more easily readable and to enhance our evidence.
We’ll adjust our filter to include web requests that contain the string “../../”
What directory did the attacker use to access the database manager?
We discovered access to a database previously, so we’ll pivot on our previous findings.
Back in Q5, we discovered GET requests to sql.php and tbl commands.
We can see that these commands' php scripts were run from the phpmyadmin directory.
What was the name of the database that the attacker exported?
Analyzing the same evidence we can see that the attacker exported a credit card database.
What flag does the attacker insert into the database?
Inserting an entry in a database would likely be a POST request, so we’ll filter for events with the http.method set as POST.
We can filter out some noise by removing results like the POST requests to ajax.php.
We’re left with only 5 requests to the export, tbl_replace, lint, and import.php files.
Looking through these events we can see the request to lint.php contains a SQL INSERT statement.
We’ll take the request body and URL decode it in CyberChef to make it easier to read.
The decoded results show us exactly what the attacker inserted into the database.
Previous post
Next post