Access the room: https://tryhackme.com/room/linuxcli-aoc2025-o1fpqkvxti
.png)
This lab simulates an incident investigation scenario where The Best Festival Company (TBFC) is under ransomware attack by King Malhare’s Bandit Bunnies. Using Splunk as the SIEM tool, the investigation focuses on ingesting and interpreting log data, performing custom field extractions, and using Search Processing Language (SPL) queries to uncover how the ransomware infiltrated the system.
Skills Learned: Basics of Splunk log analysis, custom field extraction, SPL queries for event filtering, incident timeline reconstruction, anomaly detection
Step by step walkthrough
Initial Setup
Start the target machine and the AttackBox as instructed to access the lab environment.
Getting Started with Splunk
Upon accessing the Splunk web interface, the investigation began by exploring the ingested logs:
- The logs are organized under the
mainindex. - Two primary source types are ingested:
web_trafficandfirewall_logs.
- The web server is hosted at local IP
10.10.1.15.
Initial searches used queries like:
index=main sourcetype=web_trafficused to display all web traffic logs.
Visualizing and Identifying Anomalies
Using Splunk’s timechart command, I visualized event counts over time to detect spikes indicative of attack windows:
index=main sourcetype=web_traffic | timechart span=1d count
The above results are now showing the event logs captured per day. This could be interesting, as we can see some days getting a high volume of logs. We can also click on the Visualization tab to examine the graph for better representation, as shown below:
We can append the reverse function at the end to display the result in descending order, showing the day with the maximum number of events at the beginning.
Sorting and reversing results revealed the peak traffic day when King Malhare’s main attack took place.
Anomaly Detection
Now that we have examined the days with the abnormal logs, using the table and the graph, let’s use the same search query to examine various fields to hunt for suspicious values. We need to go back to the Events tab to continue.
User Agent
Let’s click on the user_agent field in the left panel, as shown below. It will show us the details about the user agents captured so far.
Upon closer examination, it becomes clear that, apart from legitimate user agents like Mozilla’s variants, we are receiving a large number of suspicious ones, which we will need to investigate further.
client_ip
The second field we will examine is the client_ip, which contains the IP addresses of the clients accessing the web server. We can immediately see one particular IP address standing out, which we will investigate further.
path
The third field we will examine is path, which contains the URI being requested and accessed by the client IPs. The results shown below clearly indicate some attacks worth investigating.
Filtering out Benign Values
We know King Malhare’s bunnies use scripts and tools, not standard browsers. Let’s filter out all standard traffic.
Let’s exclude common legitimate user agents. The following query will remove legitimate user agents from the results and only show the suspicious ones, which we will further investigate.
index=main sourcetype=web_traffic user_agent!=*Mozilla* user_agent!=*Chrome* user_agent!=*Safari* user_agent!=*Firefox*
The output reveals interesting results. By clicking on the client_ip field we can see a single IP address being responsible for all the suspicious user agents. Let's note that down for further investigation and fill in the <REDACTED> portions of the upcoming queries with that IP.
Narrowing Down Suspicious IPs
In real-world scenarios, we often encounter various IP addresses constantly attempting to attack our servers. To narrow down on the IP addresses that do not send requests from common desktop or mobile browsers, we can use the following query:
sourcetype=web_traffic user_agent!=*Mozilla* user_agent!=*Chrome* user_agent!=*Safari* user_agent!=*Firefox* | stats count by client_ip | sort -count | head 5
The result confirms the top IP used by the Bandit Bunnies. In the search query, the - in the sort -count part will sort the result by count in reverse order, it's the same as using the reverse function. Let's pick this IP address and filter out to see what the footprints of the activities captured.
Tracing the Attack Chain
We will now focus on the selected attacker IP to trace their steps chronologically, confirming the use of multiple tools and payloads. Don’t forget to replace <attacker_ip> with the IP we noted down previously.
Reconnaissance (Footprinting)
We will start searching for the initial probing of exposed configuration files using the query below:
sourcetype=web_traffic client_ip="<attacker_ip>" AND path IN ("/.env", "/*phpinfo*", "/.git*") | table _time, path, user_agent, status
The result confirms the attacker used low-level tools (curl, wget) and was met with 404/403/401 status codes.
Enumeration
Searching for path traversal and open redirect attack attempts:
sourcetype=web_traffic client_ip="<attacker_ip>" AND path="*..*" OR path="*redirect*"
The output shows the resources the attacker is trying to access. Let’s update the search query to get the count of the resources requested by the attacker. This search query is filtering on the paths that contain either ../../ or the term redirect in it, as shown below. This is done to look for footprints of path traversal attempts (../../). To, we need to update in the search query to escape the characters like ..\/..\/.
sourcetype=web_traffic client_ip="<attacker_ip>" AND path="*..\/..\/*" OR path="*redirect*" | stats count by path
Quite interesting results. Reveals attempts to read system files (../../*), showing the attacker moved beyond simple scanning to active vulnerability testing.
SQL Injection Attack
Identified usage of tools like sqlmap and Havij through user agents, with signature payloads such as SLEEP(5) confirming time-based SQL injection:
sourcetype=web_traffic client_ip="<attacker_ip>" AND user_agent IN ("*sqlmap*", "*Havij*") | table _time, path, status
Received 504 gateway timeout statuses typical of successful injection.
Exfiltration and Payload Execution
Attacker downloaded large backup and log files (backup.zip, logs.tar.gz) and deployed ransomware-like binaries (bunnylock.bin), evidenced by:
sourcetype=web_traffic client_ip="<attacker_ip>" AND path IN ("*backup.zip*", "*logs.tar.gz*", "*bunnylock.bin*", "*shell.php?cmd=*") | table _time, path, user_agent, status
The detection of successful Remote Code Execution (RCE) through webshell usage confirmed full system compromise.
Ransomware Staging & RCE
Requests for sensitive archives like /logs.tar.gz and /config indicate the attacker is gathering data for double-extortion. In the logs, we identified some requests related to bunnylock and shell.php. Let's use the following query to see what those search queries are about.
sourcetype=web_traffic client_ip="<attacker_ip>" AND path IN ("*bunnylock.bin*", "*shell.php?cmd=*") | table _time, path, user_agent, status
Above results clearly confirm a successful webshell. The attacker has gained full control over the web server and is also able to run commands. This type of attack is called Remote code Execution (RCE). The execution of /shell.php?cmd=./bunnylock.bin indicates a ransomware like program executed on the server.
Correlating Firewall Logs
Post-exploitation activity was validated by pivoting to firewall logs and searching for outbound connections from the compromised server (10.10.1.5) to the attacker IP:
sourcetype=firewall_logs src_ip="10.10.1.5" AND dest_ip="<attacker_ip>" AND action="ALLOWED" | table _time, action, protocol, src_ip, dest_ip, dest_port, reason
This query proves the server immediately established an outbound connection to the attacker’s C2 IP on the suspicious DEST_PORT. The ACTION=ALLOWED and REASON=C2_CONTACT fields confirm the malware communication channel was active.
Volume of Data Exfiltrated
Using stats aggregation, the volume of data exfiltrated to the attacker was quantified:
sourcetype=firewall_logs src_ip="10.10.1.5" AND dest_ip="<attacker_ip>" AND action="ALLOWED" | stats sum(bytes_transferred) by src_ip
A large amount of data was transferred, confirming significant data theft.
Lab Answers
What is the attacker IP found attacking and compromising the web server?
198.51.100.55.
— — — — — — — — — — — — — — —
Which day was the peak traffic in the logs? (Format: YYYY-MM-DD)
2025–10–12.
— — — — — — — — — — — — — — —
What is the count of Havij user_agent events found in the logs?
993.
— — — — — — — — — — — — — — —
How many path traversal attempts to access sensitive files on the server were observed?
658.
— — — — — — — — — — — — — — —
Examine the firewall logs. How many bytes were transferred to the C2 server IP from the compromised web server?
126167