Test for Command Injection with Burp Suite (2026)

Burp Suite can’t detect command injection vulnerabilities in the same way it can detect SQL injection or XSS. It’s a tool for manual testing and assisted discovery, not an automated scanner for this specific threat.

Here’s how you’d actually test for command injection using Burp Suite, focusing on how you’d think about it and what you’d do:

The Core Problem: Trusting User Input for System Commands

Command injection happens when an application takes user-supplied input and directly incorporates it into a system command that the server then executes. The vulnerability arises because the attacker can inject special characters that the operating system interprets as command separators or control operators, allowing them to execute arbitrary commands on the server.

Burp Suite’s Role: Interception and Manipulation

Burp Suite’s primary function here is to intercept HTTP requests and responses, allowing you to modify the requests before they reach the server. This is crucial for injecting malicious payloads.

Step 1: Identify Potential Endpoints

You need to find places where user input might influence backend commands. Think about:

• File Uploads: Filenames, descriptions, or even image metadata.
• Form Parameters: Search fields, login fields, any text input.
• URL Parameters: Values in the query string.
• HTTP Headers: User-Agent, Referer, custom headers.
• AJAX/JavaScript Calls: Any dynamic data sent to the server.

Use Burp’s Proxy tab to capture traffic as you interact with the application. Browse around, submit forms, click links, and observe what requests are being sent.

Step 2: Crafting Basic Injection Payloads

Once you’ve identified a parameter that seems promising, you’ll start injecting characters that have special meaning to the operating system’s shell. The most common ones are:

• ; (semicolon): Command separator. Executes the injected command after the original command.
• | (pipe): Redirects the output of the original command to the input of the injected command.
• && (double ampersand): Executes the injected command only if the original command succeeds.
• || (double pipe): Executes the injected command only if the original command fails.
• ` (backtick) or $(...): Command substitution. Executes the command inside and substitutes its output.

Example Scenario: A "ping" function

Imagine a web application with a feature to "ping" a host. The backend might construct a command like:

ping -c 4 example.com

If you can control example.com, you can try to inject commands.

1. Intercept the request in Burp Proxy when you ping example.com.
2. Send the request to Intruder (Right-click -> "Send to Intruder").
3. Select the target parameter (example.com in this case) and click "Add §" to mark it as the injection point.
4. Go to the "Payloads" tab.
5. In "Payload type", select "Simple list".
6. Add your test payloads:
   • example.com; ls
   • example.com | id
   • example.com && whoami
   • example.com || cat /etc/passwd
   • example.com; $(uname -a)

Step 3: Analyzing the Responses

This is where Burp’s "Intruder" tab is invaluable. It will send all your payloads and display the responses. You’re looking for:

• Unexpected Output: Did the response suddenly contain output from ls, id, whoami, or uname -a? This is a strong indicator.
• Error Message Changes: Sometimes, a failed command injection might still alter the error message in a way that suggests the shell tried to interpret it.
• Timing Differences: For out-of-band vulnerabilities (where the command execution causes the server to make a network request to your server), you’d use Burp Collaborator.

Step 4: Using Burp Collaborator for Out-of-Band Detection

Many command injection vulnerabilities can’t be directly observed in the HTTP response because the injected command’s output isn’t reflected back. This is where Burp Collaborator shines.

1. Enable Collaborator Client: Go to "Project options" -> "Misc" -> "Collaborator client" and ensure it’s enabled.
2. Craft Payloads for Collaborator: Instead of just ls, you’d use payloads that force the server to make an outbound connection to a Collaborator-provided domain:
   • example.com; ping your_collaborator_id.burpcollaborator.net
   • example.com | curl http://your_collaborator_id.burpcollaborator.net
   • example.com && wget http://your_collaborator_id.burpcollaborator.net
3. Monitor Collaborator Interactions: In Burp’s "Collaborator client" tab, you’ll see incoming network interactions (DNS lookups, HTTP requests) from the target server. If you see an interaction triggered by your injected payload, you’ve confirmed command injection.

Step 5: Escalation and Bypasses

If basic payloads don’t work, the application might be sanitizing input. You’ll need to try:

• Encoding: URL encoding (%3b for ;), double URL encoding, or other character encodings.
• Different Shells: Some systems might use sh vs. bash vs. cmd.exe. Payloads might differ.
• Whitespace Bypass: If spaces are filtered, try using tabs (%09), backticks, or other characters that can represent spaces in certain contexts.
• Command Chaining: Using operators like &&, ||, ; in different combinations.
• Using Built-ins: Instead of ls, try echo "content" > /tmp/test.txt and then see if you can make another request that fetches /tmp/test.txt to confirm.

The Next Step After Finding Command Injection

Once you’ve confirmed command injection and can execute commands, the next logical step is to see if you can leverage it to read sensitive files (like configuration files, password hashes) or even gain a reverse shell for interactive command execution.