Back to evidence

Sanitized live incident

Attempted exploitation

Native source identity and targetable endpoints are private.

highopen
Confidence
99%
First seen
Aug 28, 2:32:44 AM PDT
Evidence through
Aug 28, 2:39:14 AM PDT
AI status
Complete
Likely true positive95% confidence

Three repeated command-injection-shaped GET requests to the same API endpoint were followed within the request windows by recurring root shell/discovery process chains. The final sequence shows the same shared resource being mutated in one workload and then executed in another, followed by a root cat process targeting sensitive material and exiting zero. This strongly supports successful command execution rather than a request-only attempt. The verdict remains “likely” rather than definitive because workload/time correlation does not provide a unique request-to-process trace edge, response content is unavailable, and no cited flow evidence establishes outbound communication.

Attack stage
Exploitation with workload command execution, discovery, sensitive-file access, and shared-resource activity
Model
gpt-5.6-sol · 13 evidence calls

Observed impact

  • Root-level shell and discovery processes were observed in processor and image-host workloads.
  • A common inventory-resolved resource was marked mutated from both workload contexts and executed in the image-host context.
  • A root cat process targeted sensitive material and exited zero; the material’s contents and any disclosure are not shown.
  • Outbound-capable process telemetry exists, but no verified network flow establishes an outbound connection or exfiltration.

Deterministic signals

Http.command injection attempt88%

Request contains shell metacharacters and command tokens

3 observations · 3 http
Process.correlated sensitive file command80%

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

3 observations · 3 process
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

8 observations · 8 process
Process.correlated network client80%

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

3 observations · 3 process
Process.correlated discovery command80%

A discovery process appeared in the correlated workload and request window

3 observations · 3 process
Process.correlated exit99%

A previously correlated process lifecycle exited

10 observations · 10 process
Process.shared resource activity80%

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

5 observations · 5 process · 1 inventory

Explicit uncertainty

  • Process correlation is based on workload identity and time proximity; no unique per-request trace proves that a specific HTTP request created a specific process.
  • The source key is a derived traffic/workload cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • Bounded HTTP evidence excludes exact paths, query strings, headers, bodies, and response content, so the precise injected commands and whether command output appeared in the response cannot be verified.
  • No flow event is cited by this incident. The required flow-evidence query therefore could not retrieve a verified connection; outbound communication, destination novelty, command-and-control, and exfiltration remain unproven.
  • A zero exit proves the lifecycle-matched process exited successfully; it does not by itself prove sensitive contents were read into an attacker-visible channel.
  • Shared-resource mutation and execution are observed across workload contexts, but the evidence does not prove host escape, persistence, or lateral movement.

Recommended actions

  1. Immediately preserve HTTP, process, workload, and shared-resource telemetry for the full incident window and surrounding baseline.
  2. Contain or temporarily isolate the affected processor and image-host workloads if operationally feasible; inspect and replace the shared resource before returning them to service.
  3. Patch or disable the implicated API behavior and validate that all request-derived values are passed without shell interpretation; add strict allow-list validation and avoid shell invocation.
  4. Identify the sensitive target and rotate any credentials or secrets it may contain if exposure is plausible; verify access logs and downstream use before concluding disclosure.
  5. Review the parent services associated with the observed shell PPIDs, compare deployed artifacts and the shared resource against known-good versions, and redeploy affected workloads from trusted images where warranted.
  6. Restrict workload root privileges, shared writable mounts, and unnecessary inter-workload resource access; enforce least privilege and read-only mounts where possible.
  7. Review independent network telemetry for the incident window because no cited conntrack flow is available; do not infer exfiltration solely from an outbound-capable process class.
  8. Treat source-cluster blocking cautiously because it may represent shared infrastructure; prefer endpoint remediation and validated indicators over identity assumptions.