Slingshot
TryHackMe Challenge Walkthrough
Challenge Overview
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?
Threat Analysis Summary
Analyst Summary Report
Incident Title
Web Shell Exploitation and Database Breach via Directory Enumeration
Category
Web Server Compromise, Credential Access, Data Exfiltration
Detection Source
Elastic Stack (Kibana) – HTTP logs
Impact
The attacker exploited exposed paths, brute-forced admin credentials, uploaded a web shell, and extracted sensitive database contents including credit card records.
Investigation Workflow
- Set the timeline
- 2. Identified the attacker IP based on request volume.
- Traced the attack chain via user-agents (Nmap, Gobuster, Hydra).
- Uncovered compromised login and successful credential-based access.
- Detected file upload of a web shell and command execution.
- Followed LFI abuse leading to phpMyAdmin credential discovery.
- Tracked database access, data export, and tampering.
Recommendations
- Restrict access to admin panels using IP allowlists or VPN.
- Implement rate-limiting and CAPTCHA to prevent brute-force attacks.
- Regularly audit exposed directories and web files.
- Harden file upload mechanisms.
- Monitor web logs for automated scanners and alert on excessive 401/404s.
- Patch vulnerable web components and isolate DB management tools
Tools Used
- Kibana
- CyberChef
Chain Attack Overview
Initial Access
Nmap and Gobuster used to enumerate and find exposed admin-login.php
Execution
Brute-force with Hydra, successful login using stolen credentials
Persistence
PHP web shell uploaded via admin panel
Privilege Escalation
Not explicitly present; attacker already had web admin access
Defense Evasion
Standard headers and user-agents used to appear normal
Discovery
LFI and phpMyAdmin exploration via path traversal
Credential Access
Admin credentials brute-forced and DB creds extracted via LFI
Exfiltration
Downloaded customer credit card database
Impact
Database tampering and flag insertion (cardholder name overwrite)
MITRE ATT&CK Mapping
Phase
ID
Technique
Description
Initial Access
T1190
Exploit Public-Facing Application
Brute-forced login via admin-login.php
Discovery
T1087.002
File and Directory Discovery (Web)
Directory enumeration with Gobuster
Execution
T1059.003
Web Shell
Executed commands via uploaded PHP shell
Credential Access
T1003.003
Credential Dumping via LFI
Extracted DB credentials from phpMyAdmin config file
Collection
T1119
Automated Collection
Exported customer_credit_cards database
Exfiltration
T1041
Exfiltration Over Web Service
Downloaded DB dump over HTTP
Impact
T1491.001
Defacement: Database Content Injection
Overwrote credit card names with injected flag
Reference: [MITRE ATT&CK Navigator] ( https://attack.mitre.org/ )
Q & A
Q1: What was the attacker's IP?
To kick off, I set the timeline to July 26, 2023 as mentioned in the brief.
Next, I inspected the transaction.remote_address field to identify suspicious request volume.
Out of 3028 total requests, 2565 came from the same internal IP — clearly the main source of activity.
Answer
10.0.2.15
Q2: What was the first scanner that the attacker ran against the web server?
After filtering for the attacker’s IP and sorting the logs by @timestamp from oldest to newest, I checked the early entries.
Right after the first few requests, the logs show the Nmap Scripting Engine as the User-Agent — a common signature for reconnaissance.
Answer
Nmap Scripting Engine
Q3: What was the User Agent of the directory enumeration tool that the attacker used on the web server?
I looked through the logs for suspicious User-Agent values, especially during high volumes of 404 responses — typical of directory brute forcing.
The User-Agent string clearly identifies Gobuster, a well-known directory enumeration tool.
Answer
Mozilla/5.0 (Gobuster)
Q4: In total, how many requested resources on the web server did the attacker fail to find?
Since failed resource lookups return status code 404, I filtered by response.status:404 and counted the results.
The total came out to 1867 — consistent with aggressive directory scanning.
Answer
1867
Q5: What is the flag under the interesting directory the attacker found?
I filtered for successful hits (response.status: 200) made with the Gobuster User-Agent.
Among the discovered directories, one revealed a flag stored as a plain string.
Answer
a76637b62ea99acda12f5859313f539a
Q6: What login page did the attacker discover using the directory enumeration tool?
We don’t have any login page in the response status 200
To find login-related pages, I searched for URLs containing the word “login”, while excluding 404 responses to focus only on valid hits.
The result: admin-login.php — discovered during enumeration.
Answer
admin-login.php
Q7: What was the user agent of the brute-force tool that the attacker used on the admin panel?
We already noticed before that under Gobuster there was Hydra, clearly used to brute force it, but lets look for it.
A spike in “401” Unauthorized responses hinted at a brute-force attempt. Filtering for response.status: 401 and checking request.headers.User-Agent confirmed it:
The tool used was Hydra, a classic for login brute-forcing.
Answer
Mozilla/4.0 (Hydra)
Q8: What username:password combination did the attacker use to gain access to the admin page?
To isolate the successful login, I filtered for response.status: 200 along with User-Agent: Hydra, since failed attempts earlier returned 401.
Among those few successful hits, I inspected the request.headers.Authorization field.
The base64-encoded value decodes cleanly to the valid credential pair:
Answer
admin:thx1138
Q9: What flag was included in the file that the attacker uploaded from the admin directory?
I filtered for requests under /admin/* with http.request.method: POST, since file uploads are typically POST requests.
Out of all admin subdirectory actions, only one stood out — a POST to upload.php. Inspecting the request body revealed the flag.
Answer
THM{ecb012e53a58818cbd17a924769ec447}
Q10: What was the first command the attacker ran on the web shell?
From Q9, we know the uploaded web shell was named easy-simple-php-webshell.php.
I filtered for requests to that file and sorted by @timestamp (oldest first) to reconstruct the sequence.
The first command sent through the shell was a classic — to confirm access:
Answer
whom
Q11: What file location on the web server did the attacker extract database credentials from using Local File Inclusion?
While reviewing /admin/* paths, I noticed suspicious path traversal attempts using ../../ — typical of Local File Inclusion (LFI).
One of these LFI requests successfully accessed a sensitive config file related to phpMyAdmin.
Answer
etc/phpmyadmin/config-db.php
Q12: What directory did the attacker use to access the database manager?
From the LFI activity in the previous step, we already know the attacker targeted phpMyAdmin. The path used appears repeatedly in logs related to database interaction.
Answer
/phpmyadmin
Q13: What was the name of the database that the attacker exported?
I filtered for requests under /phpmyadmin/* and looked for signs of export activity.
Scrolling through the logs revealed a clear export request pointing to a specific database.
Answer
customer_credit_cards
Q14: What flag does the attacker insert into the database?
After spotting the export request, I filtered by http.method: POST to catch follow-up write actions. Two relevant requests stood out:
– import.php
– tbl_replace.php
Looking into the body of import.php, I found a nearly readable payload that appeared to insert a value into the cardholder_name field across multiple entries.
I decoded the content manually (or with CyberChef) and confirmed that the attacker inserted a single string repeatedly — likely as a planted flag.
Answer
c6aa3215a7d519eeb40a660f3b76e64c
Conclusion
The attacker performed a full web exploitation chain — starting with recon and directory brute-force, followed by admin panel access via Hydra, web shell upload, and database manipulation.
They exfiltrated sensitive data and inserted a flag into the database, highlighting the critical impact of weak authentication and misconfigured web services.