Back to evidence

Sanitized live incident

Attempted exploitation

Native source identity and targetable endpoints are private.

highopen
Confidence
99%
First seen
Aug 24, 9:25:18 AM PDT
Evidence through
Aug 24, 9:44:16 AM PDT
AI status
Complete
True positive99% confidence

Successful command injection is established, not merely attempted. Repeated requests contained shell metacharacters and command tokens, and separate HTTP responses returned non-reflected root/UID 0 identity and kernel identification even though the responses were HTTP 400. Event-driven telemetry concurrently observed root-run dash shells with discovery children, sensitive-file targeting, and execution/access/mutation involving an inventory-resolved shared resource. The detector labels the incident as attempted_exploitation, but the server-generated output and observed workload consequences support upgrading the investigator verdict to successful exploitation. No flow-plane evidence was cited, so outbound communication, command-and-control, or exfiltration is not established.

Attack stage
Successful command injection: execution, discovery, sensitive-file targeting, and shared-resource modification
Model
gpt-5.6-sol · 9 evidence calls

Observed impact

  • Root-level command execution occurred in affected workloads.
  • Server responses disclosed process identity (root/UID 0) and kernel information.
  • Discovery processes including whoami and id executed as root.
  • Root-run commands targeted sensitive files; successful disclosure of their contents is not established.
  • A shared resource attached to multiple workloads was accessed, interpreted/executed, and mutated.
  • No proven outbound connection, command-and-control, persistence, host escape, lateral movement, or data theft.

Deterministic signals

Http.command injection attempt88%

Request contains shell metacharacters and command tokens

9 observations · 9 http
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

71 observations · 12 process
Process.correlated discovery command80%

A discovery process appeared in the correlated workload and request window

44 observations · 12 process
Process.correlated network client80%

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

4 observations · 4 process
Process.correlated exit99%

A previously correlated process lifecycle exited

85 observations · 12 process
Http.server command output85%

Response contains non-reflected process identity output

4 observations · 4 http
Http.server kernel output84%

Response contains non-reflected kernel identification

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

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

5 observations · 5 process
Process.shared resource activity80%

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

6 observations · 6 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 identity and temporal proximity. It does not prove which individual HTTP request created each process.
  • The incident cites no flow-plane event IDs. A flow-evidence query therefore could not establish socket activity, destination novelty, command-and-control, or exfiltration.
  • Sensitive-file commands were observed, but available evidence does not show the file contents or prove that contents were successfully read or disclosed.
  • Shared-resource mutation is observed, but the resulting content, durability, and effect on other attached workloads are unknown.
  • No cited evidence proves persistence, host escape, lateral movement, or data theft.

Recommended actions

  1. Immediately isolate or replace the affected processor and image-host workload instances while preserving volatile and process telemetry for analysis.
  2. Disable or restrict the vulnerable API route until the command-injection flaw is fixed; validate and safely encode all untrusted parameters and avoid invoking a shell.
  3. Inspect the inventory-resolved shared resource [redacted], compare it with a known-good version, determine the mutation, and prevent execution from shared writable locations.
  4. Review sensitive files and environment data available to the affected workloads. Rotate credentials, tokens, or keys that could have been exposed.
  5. Review network telemetry for the incident window from affected workload identities and enforce least-privilege egress; the current incident contains no cited flow evidence.
  6. Redeploy from trusted immutable images, run workloads as non-root, minimize shell and discovery utilities, and apply read-only filesystems or narrowly scoped mounts where feasible.
  7. Search retained telemetry for the same request pattern, source cluster, process lineage, and shared-resource identifier across other workloads and adjacent time windows.