Back to evidence

Sanitized live incident

Attempted exploitation

Native source identity and targetable endpoints are private.

highopen
Confidence
99%
First seen
Aug 20, 11:34:33 PM PDT
Evidence through
Aug 20, 11:48:44 PM PDT
AI status
Complete
True positive98% confidence

This is successful server-side command execution, not merely an unsuccessful injection attempt. Verified HTTP summaries show an injection-pattern request and multiple captured 400 responses containing non-reflected root/UID 0 process identity or kernel output; the 400 status therefore does not negate execution. Event-driven process telemetry independently observed root dash shells with discovery children in the correlated workload, followed later by execution, access, and mutation involving a shared resource. The incident's derived classification remains `attempted_exploitation`, but the server-generated output supports upgrading the analyst verdict to a true positive with observed execution. Exact request-to-process causality, source identity, and any network consequence remain unresolved.

Attack stage
Exploitation with command execution; discovery and shared-resource activity observed
Model
gpt-5.6-sol · 12 evidence calls

Observed impact

  • Server-side command execution occurred in a root/UID 0 workload context.
  • Process and kernel identity information was returned to the traffic source.
  • Root shell and discovery processes executed in the correlated workload.
  • Execution, access, and mutation involving a shared resource were observed; attack causation and downstream scope are not uniquely established.
  • No host escape, persistence, lateral movement, command-and-control, or data theft is established by the available evidence.

Deterministic signals

Http.server command output85%

Response contains non-reflected process identity output

5 observations · 5 http
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

50 observations · 12 process
Process.correlated discovery command80%

A discovery process appeared in the correlated workload and request window

37 observations · 12 process
Process.correlated exit99%

A previously correlated process lifecycle exited

64 observations · 12 process
Http.server kernel output84%

Response contains non-reflected kernel identification

2 observations · 2 http
Http.command injection attempt88%

Request contains shell metacharacters and command tokens

1 observations · 1 http
Process.shared resource activity80%

A process executed or interpreted content from an inventory-resolved resource attached to multiple workloads

16 observations · 11 process · 1 inventory

Explicit uncertainty

  • The source key is a traffic/workload cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • Downstream workload affinity is inferred from configured routing; there is no observed per-request trace edge.
  • Process correlation is based on workload and temporal proximity. Even exact exec/exit joins do not prove which HTTP request created a process.
  • No flow event is cited by this incident, and the attempted flow-evidence lookup could not substantiate outbound connections or request-to-socket causality.
  • The shared resource activity is observed, but available evidence does not establish that a particular HTTP request caused it, what content changed, or the downstream effect on other attached workloads.
  • The available evidence does not establish authorization context; an approved test is possible but not indicated.
  • There is no cited proof of host escape, persistence, lateral movement, command-and-control, or data exfiltration.

Recommended actions

  1. Treat the affected workloads as potentially compromised: restrict exposure and consider isolating or replacing them using approved incident-response procedures while preserving evidence.
  2. Preserve application, gateway, process, orchestration, and shared-resource audit records for the full incident interval; snapshot shared resource [redacted] before remediation.
  3. Identify and remediate the API command-injection path through strict allowlisting, safe process APIs, removal of shell interpretation, and regression tests for metacharacter payloads.
  4. Compare the shared resource with a known-good version, review every workload attached to it, and restore or redeploy from trusted immutable artifacts if unauthorized changes are confirmed.
  5. Review secrets and credentials exposed to the affected root-running workloads; rotate those that may have been accessible after scoping the exposure.
  6. Reduce workload privilege: run the service as a non-root identity, use a read-only root filesystem where feasible, and limit write/execute permissions on shared resources.
  7. Hunt for the cited request pattern, source cluster, root dash/discovery chains, and shared-resource identifier across retained telemetry. Apply source blocking only with care because the source key may aggregate proxies or multiple workers.