Consolidated Lab Exercise: Complete Wintermute Assessment Simulation

Right. You've spent nine pages building tools, breaking concepts apart, and watching things fail in predictable ways. Now we tie it together. Not a CTF — I don't care if you pop a shell. I care whether you can look at a network, understand what an attacker sees, and write down what a defender must fix. That's the job.

Lab Wintermute again: Kali at 192.0.2.10, Metasploitable2 at 192.0.2.20, DVWA at 192.0.2.30. Air-gapped NAT network. Snapshots taken before we started, as covered in Page 4. Let's walk through the engagement flow I actually use when training juniors.

Pre-Engagement: The Boring Part That Saves Careers

Before touching a keyboard, I pull up the scope document. For Wintermute, this is a single-page authorization signed by the course instructor specifying IP ranges (192.0.2.20–192.0.2.30), permitted techniques (reconnaissance, vulnerability identification, conceptual exploitation review only — no persistent access), and time boundaries. No signature, no packets. I've seen students skip this in practice labs; in a real engagement, that's the difference between a paycheck and a prison sentence.

Snapshot confirmation comes next. I verify the rollback state in VirtualBox — the little arrow icon next to each VM showing a saved snapshot. If your lab has no snapshot, stop. Build one. The snapshot is your time machine; when you inevitably misconfigure a service during inspection, you restore rather than rebuild. I also confirm network isolation: the NAT network named "Wintermute-Isolated" with no external adapter attached to the Kali VM. Check this in VirtualBox's Network settings — Adapter 1 should show "NAT Network: Wintermute-Isolated," not "Bridged Adapter."

Why this matters: A bridged adapter would place your attacking VM on the same network as your host machine, potentially reaching the internet or your home devices. The "NAT Network" mode in VirtualBox creates an internal software network visible only to member VMs.

Phase 1: Python-Driven Reconnaissance

We built the recon scripts in Pages 5 and 6. Now we run them in sequence against both targets, collecting structured output for later analysis.

First, the host discovery script — the one that sweeps the /24 to confirm our two targets are alive. From Kali:

python3 wintermute_hostdiscover.py --subnet 192.0.2.0/24 --output hosts.json

This emits a JSON file with responsive hosts, their MAC addresses (useful for confirming you're talking to the right VM, not a rogue device), and round-trip times. I always glance at the MAC vendor prefix — Metasploitable2 typically shows a VirtualBox OUI (00:08:27 or similar), which confirms I'm in the lab and not accidentally probing my roommate's printer.

⚠️ Authorized, defensive use only.

Next, service enumeration against the confirmed targets. The script we built combines a TCP port sweep with banner grabbing:

python3 wintermute_services.py --target 192.0.2.20 --top-ports 1000 --output m2_services.json
python3 wintermute_services.py --target 192.0.2.30 --top-ports 1000 --output dvwa_services.json

The --top-ports 1000 flag restricts Nmap's port selection to the thousand most common ports, keeping scan duration manageable for lab work. For a full assessment you'd use -p- (all 65535 ports), but in training, speed matters more than completeness.

What I'm looking for here: on 192.0.2.20, I expect to see SSH (22), FTP (21), Telnet (23), and NFS-related services. The NFS service can be identified by probing port 2049 directly, or by querying the portmapper (port 111) for its registered services list [S2]. On 192.0.2.30, I expect HTTP (80) and possibly MySQL (3306) if DVWA's database is exposed.

The banner-grabbing component captures version strings. These are critical — they're how we map to vulnerabilities without exploiting anything yet. A banner like vsftpd 2.3.4 is a name and version number that we'll feed into the next phase.

Phase 2: Vulnerability Mapping with NVD

Here's where our Python fundamentals pay off. We built a script in earlier pages that queries the NIST National Vulnerability Database (NVD) API v2.0 [S1][S6]. The v1.0 API was sunsetted in December 2023 [S6], so if you copied old code from Stack Overflow, it broke. The current API lives at https://services.nvd.nist.gov [S3] and requires an API key for higher rate limits.

The script reads our service banners, constructs CPE (Common Platform Enumeration) strings, and queries the NVD:

python3 wintermute_nvd_mapper.py --services m2_services.json --api-key $NVD_KEY --output vuln_map.json

The NVD API v2.0 includes an apiKey parameter and a message field for debugging information [S6]. I set my key as an environment variable rather than hardcoding it — basic hygiene. The script sleeps between requests to stay polite; even in a lab, I train rate-limiting discipline.

What comes back: CVE identifiers, CVSS severity scores, and descriptions. For vsftpd 2.3.4, you'll likely see a backdoor vulnerability from 2011. This is where I pause and explain to students: the CVE doesn't mean the target is vulnerable. It means the software version might be, if unpatched. Confirmation requires either exploitation (out of scope for our defensive focus) or additional evidence like the specific backdoor behavior in the banner.

I correlate these findings manually in a simple Python script using the json module — loading both the service inventory and vulnerability map, then printing a table of "service → version → CVE list." No fancy framework needed; the learning is in understanding the mapping, not in tool polish.

Phase 3: Controlled Exploitation Understanding

Now we walk to the edge. Metasploit is installed on Kali; we use it for educational comprehension, not execution against production targets.

I launch msfconsole and demonstrate module selection for a discovered vulnerability. Metasploit module types include Exploit, Auxiliary, Payload, NOP, Post-exploitation, and Encoder [S4]. For our lab, I focus on Auxiliary modules — scanners and information gatherers that don't deliver payloads.

Suppose we found a potential template injection point. I show the module path structure: exploit/linux/http/skyvern_ssti_cve_2025_49619 [S5]. The path tells a story — it's an exploit against a Linux target, over HTTP, in the Skyvern application, using server-side template injection. The CVE number ties to NVD records. I explain that an exploit uses a payload to deliver code to run on another machine [S4], and that the payload opens a shell or Meterpreter session for post-exploitation [S4].

⚠️ Authorized, defensive use only.

But here's the critical teaching moment: I do not execute the exploit in this lab phase. Instead, I demonstrate module selection, option review (show options), and payload examination (show payloads). Then I ask: what would a defender see? What logs would this generate? What network indicators? The defensive equivalent is understanding the attack well enough to write detection rules, not to replicate harm.

For CVE-2025-33053, I note that the module drops a malicious .url file reaching to an attacker-controlled SMB server [S5]. A defender's response: monitor for .url file creation in user directories, block outbound SMB to untrusted hosts, and train users on the social engineering component that delivers such files.

Metasploit also now supports MITRE ATT&CK framework tagging in module references [S5] — I point students to these tags so they learn to map techniques to the common language defenders use.

Phase 4: Documentation and Report Generation

A penetration test without documentation is indistinguishable from an attack. We use Python to structure our findings into a defensible report.

I built a simple Jinja-based template engine in Page 3's exercises. Jinja templates use special placeholders allowing Python-like syntax for rendering documents with passed data [S8]. My script loads the vulnerability map and renders it:

python3 wintermute_report.py --findings vuln_map.json --template report_template.j2 --output wintermute_assessment.md

The template includes sections for: Executive Summary (risk in business terms), Technical Findings (each vulnerability with evidence), Affected Hosts, and Remediation. For each finding, I require students to include: the observed behavior (what we saw), the underlying weakness (why it's a problem), the defensive control (how to fix it), and the residual risk if unaddressed.

Risk ratings I keep simple: Critical (exploitable remotely, no authentication, high impact), High (exploitable with low complexity), Medium (requires conditions or user action), Low (information disclosure, minimal impact). I don't use CVSS directly for ratings — it's too granular for executive communication. I use it as an input, then apply judgment based on the target environment's actual exposure.

Post-Engagement: Clean Closure

The final hour of any engagement matters as much as the first. I verify snapshot restoration capability — not by restoring yet, but by confirming the snapshot tree in VirtualBox shows our pre-engagement state intact. Only after report delivery and instructor review do I actually roll back, preserving the lab for the next student.

Evidence retention: I keep the JSON outputs, rendered report, and scope document in a dated directory. I do not specify retention timeframes — organizational policy varies, and in training contexts the instructor sets these rules [Coverage Gap]. The principle is: retain enough to defend your work if questioned, not so much that you become a data breach risk yourself.

Lessons learned session — I write three defensive improvements that would have prevented each finding. For the vsftpd backdoor: patch management process, network segmentation preventing FTP exposure, and integrity monitoring on critical binaries. This transforms the exercise from "I found a hole" to "I understand how the hole got there and how to close it systematically."

Metacognitive Note: What This Exercise Actually Tests

I've watched students rush through Wintermute treating it as a game to win. The ones who become useful analysts slow down at each phase and ask: what would I need to explain to a system administrator who doesn't care about my tools? That administrator wants to know: is it real, is it urgent, and what do I do Monday morning?

If you can answer those three questions from your Python-collected data, you've passed. Not because you exploited anything. Because you understood it well enough to make someone else's system safer. That's the job.