Introduction
It’s time for more SOC Simulator challenges!
Today I’ll be doing the Upload & Conquer scenario. You can find this on the scenarios page. This one is not another phishing-based scenario like my previous SOC simulator writeup. Phishing emails have a lot of red-flags that you can look out for. Once you know what to look for it can be fairly easy to spot. I don’t know if there will be any other phishing-based scenarios, but I’m always happy to see more content!
Scenario overview
An old, forgotten upload page on an e-commerce website becomes every hacker’s dream when it pops up during a routine recon scan. Exploiting this weak spot, the attacker uploads a simple web shell and begins their journey through the server, hunting for privilege escalation opportunities with one goal in mind: exfiltration.
Can you follow the attack chain and uncover the overlooked misconfigurations that made this breach possible?
I sure hope I can! This looks like we’ll be investigating network logs. WAF logs and the like can be useful for identifying malicious file uploads or common web-based attacks. OWASP.org have a top ten list that has some of the most commonly seen web-attacks:
- Broken Access Control
- Cryptographic Failures
- Injection
- Insecure Design
- Security Misconfigurations
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery
This is an easy room so I don’t think we’ll be seeing anything crazy like Cryptographic Failures or Software and Data Integrity Failures. I’m expecting that we’ll be seeing some Injection based attacks, Maybe a SSRF (Server-Side Request Forgery) if we’re lucky.
Here’s the objectives of the scenario:
- Recognise and analyse malicious activity in web logs.
- Practice analysing logs to trace file upload attempts and command execution.
- Uncover how attackers leverage system misconfigurations to escalate privileges and execute malicious scripts.
Sounds fun! This should be a pretty quick room. It’s estimated to take 1 hour.
The Simulator
I launched the simulator using a Splunk instance. As soon as I checked the Alert Queue I can see that there are 13 alerts incoming. So, let’s get to it!
Alert one
The first alert has come through. The severity is Low, which is nice. Here’s the alert details:
Description: An attempt at SQL code injection has been detected in the web request. Investigate further to determine if it was successful.
datasource: web_log
host: store.tryhatme.thm
client_ip: 17.196.218.65
ident: -
user: -
timestamp: 10/04/2025 14:55:05.273
method: GET
uri: /products/search.php?q=vip+selection
protocol: HTTP/1.1
status: 200
bytes: 17946
referer: -
user_agent:
Mozilla/5.0 (Linux; Android 14; SM-M136B Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/130.0.6723.106 Mobile Safari/537.36 WebView MetaMaskMobile
The main thing to look out for these web logs are the uri. We can see that the search query was ‘vip selection’. This log doesn’t show any sort of malicious or suspicious activity.
I didn’t post any answers for the previous SOC simulator. However I think it’s important to show what I entered for this, being a false positive. It’s important to cover the 5 Ws. Who, What, When, Where, and Why. Here’s the case-report I wrote:
Time of Activity:
Oct 4th 2025 at 14:57
List of Related Entities:
External:
client_ip: 17.196.218.65
Internal:
datasource: web_log
host: store.tryhatme.thm
Reason for Classifying as False Positive:
The web_log shows that this is a GET request from the client_ip 17.196.218.65. The URI for this request is /products/search.php?q=vip+selection. This appears to be a legitimate request. The response code is 200, showing that this was successful. No further action is needed as this appears legitimate.
And that’s this incident done! Onto number two!
Alert two
Once again another Low severity alert. Let’s take a look at the alert details:
datasource: web_log
host: store.tryhatme.thm
client_ip: 109.70.100.1
ident: -
user: -
timestamp: 10/04/2025 14:57:54.273
method: GET
uri: /products/search.php?q=test%20UNION%20SELECT%20NULL%2CNULL%2CNULL--
protocol: HTTP/1.1
status: 500
bytes: 35902
referer: -
user_agent: sqlmap/1.7-dev-59e8f7c (https://sqlmap.org)
We now have our first True Positive. Looking at the uri once again we see the string: test%20UNION%20SELECT%20NULL%2CNULL%2CNULL--. The user_agent field here is also showing the tool used for the attack - sqlmap. From the Sqlmap site: is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. It comes with a powerful detection engine, many niche features for the ultimate penetration tester and a broad range of switches lasting from database fingerprinting, over data fetching from the database, to accessing the underlying file system and executing commands on the operating system via out-of-band connections.
Sounds pretty suspicious to me!
Like in the previous incident I’ll show the case-report for this to show the template I’ll be using for this scenario for true-positives:
Time of activity:
Oct 4th 2025 at 15:00
List of Affected Entities:
Internal:
datasource: web_log
host: store.tryhatme.thm
External:
client_ip: 109.70.100.1
Reason for Classifying as True Positive:
The uri in this alert suggests an SQL Injection attempt: /products/search.php?q=test%20UNION%20SELECT%20NULL%2CNULL%2CNULL--
The user-agent is also indicative of sqlmap being used to automate finding potential vectors of attack: sqlmap/1.7-dev-59e8f7c (https://sqlmap.org)
Reason for Escalating the Alert:
No escalation is needed. The status shows that this request returned a 500 status code - Internal Server Error.
Recommended Remediation Actions:
Block the client IP and the user-agent.
List of Attack Indicators:
client_ip: 109.70.100.1
user_agent: sqlmap/1.7-dev-59e8f7c (https://sqlmap.org)
Onto the next one!
Alert three
By the time I had written up my notes on the above incident, a few more had come in to the alert queue. There was one high severity incident which I’ll tackle immediately. It should be obvious; but you should always go for alerts in order from High, to Medium, then Low.
So let’s look at the alert details for this high severity alert:
datasource: web_log
host: store.tryhatme.thm
client_ip: 109.70.100.67
ident: -
user: -
timestamp: 10/04/2025 15:17:10.273
method: GET
uri: /_old/uploads/shell.php?cmd=chmod%20+x%20/tmp/test-hat-script.sh
protocol: HTTP/1.1
status: 200
bytes: 28
referer: -
user_agent: Mozilla/5.0 (X11; Linux x86_64; rv:115.0) Gecko/20100101 Firefox/115.0
Once again we can look at the uri here. This alert was categorized as a RCE (Remote code execution). If you’re familiar with web-shells then the uri should look familiar to you. Based on the scenario description we know that there is an unused file upload page present somewhere in the environment. A web-shell has been uploaded: shell.php, and the command chmod +x /tmp/test-hat-script.sh has been run through it.
The status of this was a 200, so it was successful. That’s not good! We definitely need to escalate this.
I won’t post my case-report here, but I followed a similar template to the true-positive one I posted above.
Alert four
The Medium alert that came through was a Web-Attack. Let’s take a look at the details:
datasource: web_log
host: store.tryhatme.thm
client_ip: 109.70.100.67
ident: -
user: -
timestamp: 10/04/2025 15:10:46.273
method: GET
uri: /_old/uploads/shell.php?cmd=cat%20/etc/passwd
protocol: HTTP/1.1
status: 200
bytes: 48
referer: -
user_agent: Mozilla/5.0 (X11; Linux x86_64; rv:115.0) Gecko/20100101 Firefox/115.0
Like in the third alert we can see the uri suggests that a command was executed through the web-shell uploaded at /_old/uploads/shell.php. The command run looks very suspicious. Trying to read the /etc/passwd/ file is a pretty important part of enumerating possible usernames or services running on a web-server. This is bad to see and definitely needs to be escalated so we can eradicate the shell.
We can confidently mark this as a True Positive. I’ll write up the case-report on this and suggest that this is escalated.
Alert five (And the rest)
There are nine more alerts. They are all low severity and classified as Web Attacks. I won’t post the alert details for every single one of these alerts, you’ll just have to do it yourself!
This alert though, looks a lot like a an SQL Injection attempt. The response code is 200 as well, meaning that this was successful. Uh oh!
We’ll escalate this as it was successful.
One of the other alerts we get has the uri: /products/view.php?id=1%20AND%20SLEEP(5). This is another common way of determining if an input field is vulnerable to SQL Injections. Timing how long the server waits to respond (in this case 5 seconds) can be used to see if the encoded commands are being executed.
Another incident that came through had the uri of /products/search.php?q=sleep+bonnet. While this may look suspicious, it ultimately isn’t. It’s just a simple search query for ‘sleep bonnet’. At first I misread this as ‘botnet, but even so this wouldn’t actually do anything.
For all the other incidents I filled out if they were True/False positives. There was nothing I haven’t mentioned before, but to experienec it yourself I suggest just jumping in and doing it yourself.
Conclusion
After closing all of the alerts I get a nice little completion page showing that we’ve identified all of the alerts correctly. The AI driven analysis goes as follows:
Your reports provide a good level of detail regarding the technical aspects of the incidents, particularly in identifying the nature of the attacks and the entities involved. However, there is room for improvement in consistently addressing the ‘Why’ aspect, specifically the rationale behind classifying incidents as true positives and the implications of these findings. Additionally, while the ‘When’ and ‘Where’ are generally well-covered, ensuring that each report consistently includes these details will enhance clarity and completeness. Focus on maintaining a balanced coverage of all aspects to improve the overall structure and effectiveness of your reports.
It’s nice to get some immediate feedback on the reports. The ‘Why’ aspect can be a little hard to tackle though given what we have to work with. There aren’t many IOCs that we can correlate with known APT groups to further expand the ‘Why’ section. I know later scenarios are specifically tailored around APT groups, so that will be fun to cover!
This was another fun scenario to cover. I liked how different it is to the phishing scenario. Again, I would love for some community-made scenarios, but we’ll see if that’s ever released!
I’ll try tackle the more APT focused ones soon. That should be fun, so stay tuned!