Modern Web Stacks

During a time-boxed engagement, the first tester to identify Apache/2.4.49 in a Server: header already knows the exact CVE before their teammate has finished running a port scan. The second tester, waiting on scanner output, is still in recon. Stack fingerprinting is not a nice-to-have skill. It is a direct multiplier on exploitation speed.

Every web stack leaks its identity. Headers, cookie names, error messages, URL structure, and HTML source patterns each tell you something specific about what is running. Once you know the stack and the version, you know the attack surface. Generic vulnerability scanners miss authentication bypasses that live in a single middleware function. They miss the RCE that requires understanding a deserialisation protocol. Manual fingerprinting, followed by targeted CVE research, is how experienced red teamers work.

The workflow for every task in this room is the same: identify the stack from observable signals, confirm the version, understand why the vulnerable code pattern exists, and then execute the exploit chain.

The three-step workflow is applied to every task:

1. Fingerprint the stack from HTTP response signals (no exploit payloads yet)
2. Confirm the version and identify the applicable CVE
3. Execute the exploit chain and understand the root cause

Learning Objectives

You should have an understanding of the following rooms before starting:

• Identify a web stack from passive HTTP signals (headers, cookie names, error pages, URL structure) without sending exploit payloads
• Exploit CVE-2025-29927 to bypass Next.js middleware authentication
• Exploit CVE-2021-35042 to extract database contents from a Django application 
• Exploit CVE-2021-41773 to read arbitrary files and execute system commands via mod_cgi on Apache 2.4.49

Prerequisites

You should have an understanding of the following rooms before starting:

• HTTP in Detail
• Linux Shells
• Networking Essentials

Machine Access

The target machine is an Ubuntu 22.04 VM running four services: port 3000 (MERN/Express), port 3001 (Next.js/RSC), port 8000 (Django), and port 8080 (Apache 2.4.49 in a Docker container). All four ports are reachable from the AttackBox via the split-view connection.

Set up your virtual environment

To successfully complete this room, you'll need to set up your virtual environment. This involves starting both your AttackBox (if you're not using your VPN) and Target Machines, ensuring you're equipped with the necessary tools and access to tackle the challenges ahead.

Attacker machine

Status:Off

Target machine

Status:Off

Start Machine

Start the lab by clicking the Start Machine button below. The VM takes approximately 2 minutes to boot, then all four services will be accessible from the AttackBox.