Setting Up Your Command Injection Lab Without Breaking Anything

You cannot learn command injection by reading about it. You need a target that talks back, a proxy that lets you mangle requests, and a shell where you can test payloads before firing them at a live app. This lesson gets all three running in under twenty minutes.

What you actually need installed

Three things. A Linux VM (Kali, Parrot, or Ubuntu with pentest tools), Burp Suite Community Edition, and a vulnerable target. The target can be a local PHP app, a Docker container running a deliberately broken web service, or an HTB/THM machine. Pick one. Do not install all three targets and then get confused about which one you are testing.

Spinning up a vulnerable PHP target locally

The fastest path is a single PHP file that passes user input straight into a system call. No framework, no database, no authentication. Just raw vulnerability. You will build this properly in Module 2, but for now, confirm your PHP server responds.

Configuring Burp as your interception proxy

Open Burp, go to Proxy > Intercept, and make sure interception is on. In Firefox, set your network proxy to 127.0.0.1 port 8080. Install the Burp CA certificate in Firefox under about:preferences#privacy so HTTPS traffic does not throw certificate errors. Test it by browsing to your PHP app and confirming the request shows up in Burp's HTTP history tab.

Quick sanity check

If you see ping output, your lab is live. If you see a connection refused error, your PHP server is not running or is bound to a different interface. Fix that before moving on. Everything in this course assumes you can intercept, modify, and replay HTTP requests through Burp.

Lab is up. Proxy is intercepting. Target responds. In the next module we tear apart exactly why passing user input into system() is the fastest way to hand an attacker a root shell.