Mon, 01 Jan 0001 00:00:00 +0000

Risk Analysis and Exploitation: Case “Traverse” (TryHackMe)

Author: Alexander Roca
Date: April 24, 2026
Risk Level: High (Critical for Data Integrity)
Category: Web Vulnerabilities / Secret Management / Command Injection

1. Business Context & Scenario

Imagine a digital tourism company (“Tourism MHT”) that manages reservations, customer data, and payments. Its web infrastructure is its most critical asset. A security failure in this platform is not merely a “bug”; it represents a breach of trust that could result in:

Direct Financial Loss: Theft of credit card data or fraud.
Reputational Damage: Loss of customer confidence following a data leak.
Regulatory Fines: Penalties for non-compliance with GDPR due to exposed personal data.

In this scenario, an attacker has compromised the web server. Our objective is to analyze how this occurred, assess the business impact, and define the mitigation strategy.

2. Technical Execution: The Attack Chain (Tactics)

The attack followed a classic methodology: Reconnaissance → Exploitation → Persistence. Below is the technical breakdown of the findings:

Phase 1: Reconnaissance & Vector Discovery

The attacker began with passive inspection of the HTML source code.

Finding: Hidden comments in the code revealed critical paths: ./logs and custom.min.js.
Technique: Browser inspection (F12) and network analysis.
Obfuscation: The custom.min.js file was encoded in Hexadecimal.
- Action: Used CyberChef to decode the payload.
- Result: The decrypted message was DIRECTORY LISTING IS THE ONLY WAY, indicating that directory listing was enabled on the Apache server.

Phase 2: Exploitation of Misconfiguration

The enabled directory listing allowed the attacker to navigate to /logs.

Vulnerability: Exposure of sensitive files (email_dump.txt) due to poor web server configuration.
Intel Extraction: The file contained internal emails where a developer (“Bob”) shared credentials and API paths in plaintext.
- Credentials Found: THM{100100111} (Password for /planning).
- Business Logic: The developer named the API folder based on the first phase of the SSDLC (Secure Software Development Life Cycle): Planning.

Phase 3: Lateral Movement & Privilege Escalation

Accessing /planning with the obtained password revealed an insecure API endpoint: /api/?customer_id=X.

Vulnerability: IDOR (Insecure Direct Object Reference). The system failed to validate if the user had permission to view data for any customer_id.
Exploitation: Manual iteration of IDs (1, 2, 3…) until finding the admin user (ID: 3).
Result: Obtained administrator credentials (realadmin@traverse.com / admin_key!!!) and the hidden endpoint /realadmin.

Phase 4: Remote Code Execution (RCE)

The /realadmin administration panel allowed system command execution under the www-data user context.

Attack Vector: Command Injection via the commands parameter in the POST request.
Payload: ls -lsa to enumerate the filesystem.
Critical Finding: Existence of a Web Shell (thm_shell.php) and a renamed file manager (renamed_file_manager.php).
Final Action: Used the file manager (authenticated with THM{10101}) to edit index.php and restore the site, demonstrating full control over content integrity.

3. Risk Analysis & Business Impact (Strategy - CISM)

From a management perspective, this incident is not an isolated event but the result of multiple failures in Security Governance.

Risk Assessment Matrix (Impact vs. Probability)

Vulnerability	Business Impact	Probability	Calculated Risk	Justification
Log Exposure	High	High	Critical	Allows credential theft with minimal effort. Violates Confidentiality.
IDOR in API	High	Medium	High	Allows access to all customer data. GDPR risk.
Command Injection	Critical	High	Critical	Full server compromise (RCE). Loss of Integrity & Availability.

Violated Security Principles

Confidentiality: Credentials and customer data exposed in plaintext.
Integrity: Attacker ability to modify the website (index.php).
Principle of Least Privilege: The www-data user had sufficient permissions to list system files and execute arbitrary commands.
Secure by Design: Failure in the SDLC. Credentials shared via email; secrets left in comments.

Financial Risk Calculation (Hypothetical Example)

Assuming the company handles 10,000 customers:

SLE (Single Loss Expectancy): Cost of breach = $150/record x 10,000 = $1.5M.
ARO (Annual Rate of Occurrence): Given the public nature of the vulnerabilities and ease of exploitation, estimated at 1 time/year if unpatched.
ALE (Annual Loss Expectancy): $1.5M x 1 = $1.5M annually.
Conclusion for Leadership: Investing in a vulnerability scanner ($10k/year) and developer training ($5k) yields a clear ROI against a potential loss of $1.5M.

4. Mitigation Plan & Recommendations

To reduce Residual Risk below the organization’s Risk Appetite, the following actions are proposed based on the NIST CSF framework:

A. Preventive Controls (Protect)

Server Hardening:
- Disable directory listing (Options -Indexes in Apache/Nginx).
- Remove debug files and sensitive logs from web-accessible directories.
Secrets Management:
- Prohibit storing credentials in source code, comments, or text files.
- Implement a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) to inject credentials at runtime.
Input Validation & Authorization:
- Implement Role-Based Access Control (RBAC) to ensure users only access their own data (mitigate IDOR).
- Sanitize all user inputs to prevent command injection.

B. Detective Controls (Detect)

Log Monitoring (SIEM):
- Configure alerts for anomalous patterns in access logs (e.g., multiple requests to /api/?customer_id= with different IDs).
- Detect command execution attempts in administration endpoints.
WAF (Web Application Firewall):
- Deploy rules to block command injection patterns and access to sensitive paths.

C. Corrective Controls (Respond/Recover)

Incident Response Plan (IRP):
- Update playbooks for immediate rotation of all exposed credentials.
- Establish a procedure for “cleaning” malicious files (Web Shells).
Security Culture:
- Mandatory training for developers on OWASP Top 10 and Secure Coding practices.
- Integrate code reviews and SAST scans into the CI/CD pipeline.

5. Conclusion & Lessons Learned

The “Traverse” case demonstrates that security is a continuous process, not a product. The combination of insecure configurations (directory listing), poor data management (plaintext credentials), and lack of validation (IDOR) created a trivial attack chain.

For Leadership: Security investment must be viewed as a business enabler, not a cost. A failure of this magnitude could have cost millions in fines and reputation loss. Implementing a robust Application Security (AppSec) program is the only way to ensure business continuity in a hostile digital environment.

For Technical Teams: Defense in depth is mandatory. Do not rely on “security through obscurity” (hidden comments, obscure filenames). Validate, sanitize, and monitor every layer of the application.

📎 Technical References

OWASP Top 10: A01:2021-Broken Access Control, A03:2021-Injection, A05:2021-Security Misconfiguration.
NIST SP 800-53: Security Controls for Information Systems.
TryHackMe Room: Traverse

Alexander Roca | Security Manager & Pentester