Back to evidence

Sanitized live incident

Attempted exploitation

Native source identity and targetable endpoints are private.

highopen
Confidence
99%
First seen
Aug 25, 12:15:54 PM PDT
Evidence through
Aug 25, 12:36:31 PM PDT
AI status
Complete
True positive98% confidence

True positive. Although the deterministic incident remains classified as attempted exploitation, the available evidence goes beyond an attempt: three HTTP responses contained non-reflected server process-identity output identifying root/UID 0 [[redacted], [redacted], [redacted]]. The first did so in an HTTP 400 response, which does not negate execution [[redacted]]. Correlated event-driven process telemetry independently observed root dash shells spawning root discovery commands, including id and hostname [redacted]. A later root shell was classified as targeting a sensitive file and had an exact zero-exit lifecycle [redacted]. Exact HTTP-request-to-process causality remains unproven, and no host escape, persistence, lateral movement, external command-and-control, or data theft is established.

Attack stage
Initial access—command injection with root execution; discovery and sensitive-file targeting ([redacted]; [redacted]
Model
gpt-5.6-sol · 14 evidence calls

Observed impact

  • Observed server-side command execution under root/UID 0, with process identity disclosed in HTTP responses [[redacted], [redacted], [redacted]].
  • Root-level workload discovery occurred through dash children including id and hostname [redacted].
  • A root shell command targeting a sensitive file was observed and exited zero; the summaries do not prove that file contents were obtained or returned [redacted].

Deterministic signals

Http.server command output85%

Response contains non-reflected process identity output

3 observations · 3 http
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

15 observations · 12 process
Process.correlated discovery command80%

A discovery process appeared in the correlated workload and request window

12 observations · 12 process
Process.correlated exit99%

A previously correlated process lifecycle exited

20 observations · 12 process
Process.correlated sensitive file command80%

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

1 observations · 1 process
Http.command injection attempt88%

Request contains shell metacharacters and command tokens

3 observations · 3 http

Explicit uncertainty

  • The available evidence does not provide a unique per-request trace or parentage edge from an HTTP request to a specific process; process correlation is based on workload and time proximity.
  • Downstream workload affinity is inferred from configured target routing rather than observed per-request tracing.
  • No flow evidence reference is cited by this incident, so external connectivity, destination novelty, command-and-control, and exfiltration cannot be assessed from the bounded evidence.
  • The zero exit of the sensitive-target shell does not prove that sensitive file contents were read, returned to the requester, or exfiltrated.
  • The evidence does not establish host escape, persistence, lateral movement, or data theft.
  • The source key is a traffic cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • The available evidence does not establish whether the activity was authorized security testing.

Recommended actions

  1. Immediately contain or replace the affected processor workload after preserving volatile and process evidence; prioritize this because root command execution is evidenced [redacted].
  2. Identify and patch the API command-injection path; remove shell invocation where possible and enforce strict argument allowlisting and parameterization [[redacted], [redacted], [redacted]].
  3. Scope filesystem and secret exposure around 2026-08-25T19[redacted]49Z–[redacted]31Z, especially resources reachable by the root workload and the observed sensitive-target command [redacted]. Rotate potentially exposed workload credentials based on that scoping rather than assuming theft.
  4. Review retained network telemetry for the affected workload and interval because this incident provides no cited flow evidence; look for unexpected egress without treating destination novelty alone as proof of compromise.
  5. Preserve gateway and process telemetry and use application/request tracing, if available, to establish request-to-process causality for each execution wave [redacted].
  6. Consider temporary rate limiting or blocking for the source cluster while accounting for possible proxy/NAT aggregation; do not treat the source key as a guaranteed individual identity.