Back to evidence

Sanitized live incident

Confirmed compromise

Native source identity and targetable endpoints are private.

criticalconfirmed
Confidence
100%
First seen
Aug 27, 7:47:21 PM PDT
Evidence through
Aug 27, 8:05:09 PM PDT
AI status
Complete
True positive100% confidence

The immutable detector state is confirmed, and the evidence independently supports a true compromise: exploit-shaped HTTP requests received non-reflected command output identifying UID 0/root, with repeated identity output and later kernel/OS-release output. A 400 response does not negate execution because the response itself contained server-generated command results. Event-driven process telemetry also observed root shell and discovery lineages in correlated workload windows, plus sensitive-target and shared-resource activity. Request-to-process causality is not uniquely traced, so those process consequences are corroborative rather than attributed to a specific request. No cited flow evidence was available to prove an outbound connection, command-and-control, or exfiltration.

Attack stage
Exploitation leading to root command execution and system discovery
Model
gpt-5.6-sol · 11 evidence calls

Observed impact

  • Remote command execution as UID 0/root was proven on the responding workload.
  • Process identity, kernel, and operating-system release information were disclosed through command output.
  • Root shell and discovery processes were observed in correlated workload windows.
  • Root process telemetry recorded sensitive-target activity and operations involving an inventory-resolved shared resource.
  • No host escape, persistence, lateral movement, command-and-control, or data theft was proven.

Deterministic signals

Http.command injection attempt88%

Request contains shell metacharacters and command tokens

23 observations · 12 http
Process.correlated discovery command80%

A discovery process appeared in the correlated workload and request window

31 observations · 12 process
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

42 observations · 12 process
Process.correlated exit99%

A previously correlated process lifecycle exited

58 observations · 12 process
Http.server command output100%

Exploit request received non-reflected process identity output

5 observations · 5 http
Http.server kernel output97%

Response contains non-reflected kernel identification

4 observations · 4 http
Process.shared resource activity80%

A process modified an inventory-resolved resource attached to multiple workloads

3 observations · 3 process · 1 inventory
Process.correlated sensitive file command80%

A process command targeted a sensitive file in the correlated workload and request window

16 observations · 12 process
Process.correlated network client80%

An outbound-capable client process appeared in the correlated workload and request window

3 observations · 3 process
Http.server os release output96%

Response contains non-reflected operating-system release data

1 observations · 1 http

Explicit uncertainty

  • The source key is a traffic/workload cluster, not a guaranteed human or agent identity; it may represent a proxy, NAT gateway, or multiple workers.
  • Downstream workload affinity is inferred from configured routing rather than an observed per-request trace edge.
  • Process events are correlated by workload and time. Even where process parent lineage is observed, no unique HTTP-request-to-process causality edge is available.
  • No incident-cited conntrack event was available to the flow evidence tool. Network-client process classification therefore does not establish an outbound connection, destination, command-and-control, or exfiltration.
  • The evidence proves compromise of the responding workload, not host escape or compromise of the underlying host.
  • Persistence, lateral movement, the final contents of sensitive files or the shared resource, and any data theft remain unproven.

Recommended actions

  1. Immediately remove the affected responding workload instances from service or isolate them according to incident-response policy while preserving volatile telemetry and forensic snapshots.
  2. Disable or tightly restrict the vulnerable API path, identify and remediate the command-injection flaw, and validate the fix before restoring service.
  3. Rebuild affected workloads from a known-good image rather than trusting in-place cleanup; run the service as a non-root identity and reduce filesystem and shared-resource permissions.
  4. Preserve and review application, gateway, process, orchestrator, and storage audit records covering the full incident window; map the two observed workload keys to concrete workload instances.
  5. Diff and validate the inventory-resolved shared resource and sensitive files against trusted baselines; restore affected material if unauthorized changes are confirmed.
  6. Review exposure of environment variables, service credentials, tokens, and mounted secrets to the compromised root context, and rotate credentials that may have been accessible.
  7. Review independent network telemetry for the affected workloads to determine whether the network-capable processes established connections; apply least-privilege egress controls.
  8. Treat the source key as a cluster rather than an identity when applying temporary rate limits or access controls, to avoid over-attribution.