PwnageBox
A Docker lab that simulates an attack chain against a deliberately vulnerable target and logs it to Splunk.
What it is
A Dockerized simulation of recon, vulnerability analysis, simulated exploitation and post-exploitation against an intentionally vulnerable FTP target, with a Flask web UI and Splunk Enterprise logging. Metasploit steps are simulated, and README marks it for authorized testing and education only.
What it does
- One lab network with attacker, victim (vsftpd 2.3.4, CVE-2011-2523), Splunk and a background traffic generator.
- Real-time logging into Splunk through the HTTP Event Collector.
- Web UI with authentication and rate limiting; ports 80, 8000 and 8088 published on the host.
The problem
Security teams and students need to see an attack and the telemetry it leaves, but real attacks against real systems are not an option. PwnageBox is a simulated offensive-security lab in Docker where an attack chain runs against an intentionally vulnerable container and every stage is logged to Splunk.
Design decisions
- Run everything inside a Docker Compose lab with one intentionally vulnerable FTP container. The tradeoff is that nothing can touch outside systems, but it also is not a real intrusion.
- Simulate the exploit stage, with a simulated Metasploit module step and a fallback simulated banner if the scan cannot connect. The tradeoff is less realism, in return for safe, repeatable runs.
- Send every stage as an event to Splunk through the HTTP event collector, so the kill chain can be seen on a dashboard.
- Require an access code to start an attack and a cooldown between attacks. The tradeoff is a slower demo.
How it works
- Web UIA Flask page takes the access code and starts the attack chain, with a cooldown between runs.
- Attack containerA Python script runs the stages: recon with Nmap, vulnerability match, simulated exploit, simulated root shell.
- Victim containerAn intentionally vulnerable FTP service is the only target.
- Traffic generatorBackground Cisco-style syslog traffic gives the dashboard normal noise.
- SplunkReceives events over the HTTP event collector and shows an alert, a kill-chain timeline and CVE detections.
Security: enforced, simulated and known gaps
- Enforced in code: an access code for starting an attack, a 45-second global cooldown by default, CPU and memory limits on every container, and no built-in secrets: the lab will not start until the owner sets the Splunk password, the event-collector token and the access code.
- Simulated: the exploit and root shell are simulations against a victim container in the lab. This is a simulation and not a real intrusion, and the README says to use it only for authorized testing and education.
- Known gap: the containers share one bridge network that is not marked internal, and ports 80, 8000 and 8088 are published on the host, so a shared server needs a firewall in front of it.
What broke and how it was fixed
- What broke
- The lab shipped with known default values for the Splunk admin password, the event-collector token and the web access code, and the README and the lab's own web page printed the Splunk password.
- How it was found
- A review of the project for this site compared the README with the compose file and the code.
- The fix
- The defaults are gone. Docker Compose stops with a clear message if a value is missing, the start script refuses placeholder values, and each service exits if its value is unset. The README now describes the network as it really is.
- What guards it now
- docker compose config fails without the three values and passes with them; the start script rejects the placeholder file.
- Reference
caa9de4
Where it runs
Docker Compose on one machine, started with a script. A separate VPS deployment guide is in the repository.
Who did what
The owner conceived the lab, architecture and spec and directed the work. Coding agents did much of the implementation: the history shows a scaffold from a Codex agent and a project generated from the spec.
Limits and honest status
- A portfolio lab built around intentionally vulnerable components; the exploitation steps are simulated.
- For authorized testing and education only, per the README disclaimer.
Next: CareOps — A healthcare-operations AI assistant where the software, not the model, decides what it can see and do.