## https://sploitus.com/exploit?id=5A172967-3E3B-53F6-86B9-2E940488A6A3
# Log4Shell Exploitation Lab (CVE-2021-44228)
Reproduced the Log4Shell vulnerability end to end in an isolated lab environment, from initial exploitation through to a full remediation report. Done as a paired piece of MSc coursework with Aditya Chaudhari, written up together as a joint report.
## What I did
- Set up a vulnerable Log4j based Tomcat web application in a Docker container
- Wrote a Python script to generate the exploit payload, then stood up a malicious LDAP server and an HTTP server to serve it
- Triggered the JNDI injection chain by sending a crafted lookup string, then caught the resulting reverse shell with netcat and confirmed root access
- Rebuilt the same container with a hardened Dockerfile (JNDI lookups disabled via `JAVA_OPTS`) and confirmed the exploit no longer worked
- Wrote a structured vulnerability report covering root cause, patch history, and network level mitigations, the kind you'd actually hand to a client or dev team
## Why I did it this way
I wanted to understand the full exploit chain myself rather than just read about it. Log4Shell is a good vulnerability to learn from because it touches Java class loading, LDAP, and JNDI all at once, and the patching story afterward teaches you what remediation actually looks like beyond just applying an update.
## Screenshots

*Project structure for the vulnerable app, exploit code, and PoC script.*

*The vulnerable Tomcat application starting inside its Docker container.*

*Sending the JNDI payload through a login field, then confirming root access with `whoami` on the netcat listener.*

*The hardened Dockerfile that disables JNDI lookups and blocks the exploit.*

*The Python PoC script standing up the LDAP and HTTP servers, and netcat listening for the callback.*
## Tools
Docker, Java, Python, netcat, Kali Linux
## Disclaimer
All work conducted in an isolated lab environment for educational purposes.