Command Injection Attempts

A Debian-first guide to detecting input designed to trigger shell execution, reviewing targeted application behavior, and reducing command execution risk.

What this is

Command injection is an attack that tries to make an application execute unintended operating system commands. It usually happens when user-controlled input is passed unsafely into shell commands, scripts, or system utilities.

Attackers often try separators, shell syntax, or encoded payloads to break out of intended input handling and run their own commands.

What it looks like

Requests containing shell separators such as ;, &&, |, or backticks
Payloads containing commands like id, whoami, cat, uname, or curl
Repeated testing of the same parameter with different shell-style input
Unexpected child processes or outbound connections after a request

Detect

Review recent web service logs

sudo journalctl -u caddy --since "1 hour ago"

Search for common command injection indicators in logs

sudo grep -Ei ";|&&|\||`|whoami|id|uname|cat /etc/passwd|curl |wget |bash -c|sh -c" /var/log/caddy/*.log 2>/dev/null | tail -n 100

Review targeted parameters

sudo grep -Ei "\?|cmd=|exec=|ping=|host=|target=|query=" /var/log/caddy/*.log 2>/dev/null | tail -n 100

Check for suspicious processes and connections

ps auxf
sudo ss -tpn

Review recent journal activity for errors or child processes

sudo journalctl --since "1 hour ago"

Contain

Block a clearly abusive source IP

sudo ufw deny from <IP_ADDRESS>

Temporarily disable the affected endpoint if needed

# Limit or disable the vulnerable application function while investigating

Stop suspicious child processes if they appeared

sudo kill -TERM <PID>
sudo kill -KILL <PID>

Recover

Review the affected application logic

# Inspect how user input reaches shell commands, scripts, or utilities

Check for follow-on activity after suspicious requests

ps auxf
sudo ss -tpn
sudo journalctl --since "24 hours ago"

Review temporary paths and web content for dropped files

sudo find /tmp /var/tmp /dev/shm /var/www -type f -mtime -2 2>/dev/null

Recovery means confirming whether the payload stayed a failed probe or whether it caused command execution, child processes, or persistence.

Prevent

Option 1 — Avoid passing raw input into shell commands

# Do not build shell commands directly from untrusted input

Option 2 — Reduce exposed application features

sudo ss -tulnp
sudo ufw status numbered

Option 3 — Review logs for shell-like payloads regularly

sudo journalctl -u caddy --since "24 hours ago"

Option 4 — Monitor processes and outbound connections

ps auxf
sudo ss -tpn

Option 5 — Keep software updated

sudo apt update
sudo apt upgrade

Optional Tools & Hosting

Manual review of logs, processes, and application behavior should come first. Future recommendations may include tooling that improves visibility, but the most important control is avoiding unsafe command execution paths in the first place.

Notes

Command injection attempts may quickly turn into reverse shells or dropped persistence.
This is both an application-layer and host-level risk.
If a suspicious request is followed by new processes or outbound traffic, treat it seriously.

Environment Note

All commands shown are based on Debian-based systems unless otherwise noted.