Back to evidence

Sanitized live incident

Confirmed compromise

Native source identity and targetable endpoints are private.

criticalconfirmed
Confidence
100%
First seen
Aug 17, 3:22:10 PM PDT
Evidence through
Aug 17, 3:52:18 PM PDT
AI status
Complete
True positive100% confidence

True positive: successful command injection produced non-reflected process identity output showing root/UID 0 in the same captured HTTP transaction (HTTP [redacted]). The 400 response does not negate execution because the server response contained command output. Additional HTTP transactions also returned root identity output, and four root-owned dash shells were observed in correlated workload/time windows. Two new public-web TCP flows were also observed from an inventory-attributed workload, but they cannot be causally linked to a request or shell and their purpose is unknown. The detector's confirmed/confirmed_compromise state is therefore supported for compromise of the responding workload; evidence does not establish host escape, persistence, lateral movement, command-and-control, or data theft.

Attack stage
Exploitation and command execution in the responding application workload
Model
gpt-5.6-sol · 9 evidence calls

Observed impact

  • Remote command execution occurred in the responding workload with root/UID 0 privileges.
  • The server disclosed process identity output identifying root execution.
  • Four root-owned dash shell processes were observed in correlated workload/time windows; unique request-to-process causality is not established.
  • Two new outbound TCP flows to public web destinations were observed from an inventory-attributed workload; their purpose and causal relationship to exploitation are unknown.

Deterministic signals

Http.server command output100%

Exploit request received non-reflected process identity output

4 observations · 4 http
Http.command injection attempt88%

Request contains shell metacharacters and command tokens

16 observations · 12 http
Flow.correlated new outbound destination70%

The correlated workload opened a flow to a destination not previously observed in the captured baseline

2 observations · 2 flow · 1 inventory
Process.correlated shell spawn72%

A shell process appeared in the correlated workload and request window

4 observations · 4 process

Explicit uncertainty

  • The source key is a traffic cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • Configured routing supplies workload affinity; there is no observed per-request trace edge to a unique downstream workload instance.
  • Process correlation is based on workload identity and timing, not unique HTTP-request parentage; polling at 100 ms may also miss shorter executions.
  • Conntrack and inventory attribution do not prove which request or process opened either outbound socket, and destination novelty is relative only to the retained baseline.
  • The exact injected commands are not exposed by the bounded evidence summaries.
  • The update referenced environment-file targeting evidence, but the bounded HTTP evidence service did not accept those event IDs as currently cited, so that detail was not relied upon.
  • No cited evidence establishes host escape, persistence, lateral movement, command-and-control, credential theft, or data exfiltration.

Recommended actions

  1. Immediately isolate the affected workload from untrusted ingress and unnecessary egress while preserving container, application, gateway, process, and network evidence.
  2. Redeploy the workload from a known-good image after fixing or disabling the vulnerable endpoint; validate strict input handling and avoid invoking shells with request-derived data.
  3. Rotate application, infrastructure, and service credentials or tokens accessible to the root-running workload, and review their use from the incident start onward.
  4. Investigate the four shell observations and surrounding process telemetry for child processes, file changes, downloads, and credential access; expand host-level review to determine whether container boundaries were crossed.
  5. Resolve and assess the two public web destinations using approved internal tooling, review transferred-byte and application logs if available, and block them temporarily if not business-approved.
  6. Review other requests associated with the source traffic cluster, but do not treat the cluster as a guaranteed single actor identity.
  7. Hunt peer workloads for the same vulnerable endpoint behavior and command-output pattern, and add detection coverage for recurrence after remediation.