Back to evidence

Sanitized live incident

Confirmed compromise

Native source identity and targetable endpoints are private.

highconfirmed
Confidence
99%
First seen
Aug 18, 10:23:26 PM PDT
Evidence through
Aug 18, 11:18:15 PM PDT
AI status
Complete
True positive99% confidence

The detector's immutable state is confirmed/confirmed_compromise, and the available evidence supports that conclusion. A command-injection-marked request received a response containing non-reflected kernel identification, proving command execution in the responding workload even though the HTTP status was 400 (HTTP [redacted]). Separate responses contained non-reflected root/UID 0 identity output (HTTP [redacted] and [redacted]). Correlated process telemetry independently observed root dash shells and root discovery commands in the workload window, but it does not provide a unique request-to-process causality edge (process [redacted], [redacted], [redacted]). No cited flow-plane evidence was available, so outbound communication, command-and-control, and exfiltration are not established.

Attack stage
Initial access/exploitation: remote command execution followed by workload discovery
Model
gpt-5.6-sol · 7 evidence calls

Observed impact

  • Remote command execution was proven in the responding workload, with root/UID 0 execution identity disclosed (HTTP [redacted] and [redacted]).
  • Kernel and operating-system information was disclosed in server responses (HTTP [redacted] and [redacted]).
  • Root shell and discovery executables were observed in the correlated workload window; unique causality to a particular request remains unproven (process [redacted], [redacted], 39b5dd0d3cfde30bc2e

Deterministic signals

Http.surface enumeration92%

Broad unauthenticated route and HTTP method enumeration observed

569 observations · 12 http
Http.command injection attempt88%

Request contains shell metacharacters and command tokens

4 observations · 4 http
Process.correlated discovery command80%

A discovery process appeared in the correlated workload and request window

8 observations · 8 process
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

10 observations · 10 process
Process.correlated network client80%

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

3 observations · 3 process
Process.correlated exit99%

A previously correlated process lifecycle exited

14 observations · 12 process
Http.server command output85%

Response contains non-reflected process identity output

2 observations · 2 http
Http.server kernel output97%

Response contains non-reflected kernel identification

1 observations · 1 http
Http.server os release output84%

Response contains non-reflected operating-system release data

1 observations · 1 http

Explicit uncertainty

  • The source key is a traffic/workload cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • Configured target routing and temporal workload correlation do not provide a unique per-request trace edge to the observed processes.
  • No flow-plane evidence reference was cited by the incident; actual outbound connections, destinations, command-and-control, or exfiltration cannot be determined.
  • The proven scope is the responding workload. Host escape, persistence, lateral movement, and compromise of other workloads are not established.
  • The evidence does not establish whether this activity was authorized security testing.

Recommended actions

  1. Immediately contain the affected workload according to operational policy; preserve relevant workload, gateway, process, and orchestration telemetry before redeployment.
  2. Identify and patch the vulnerable API code path. Remove shell invocation where possible and apply strict allow-list validation and safe argument handling.
  3. Rotate credentials, tokens, and other secrets accessible to the root-running workload, prioritizing credentials present during the incident window.
  4. Review adjacent workload and control-plane telemetry for persistence, unauthorized changes, credential use, lateral movement, and follow-on execution; do not infer these outcomes without evidence.
  5. Review egress telemetry and network logs for the incident window because no cited flow evidence was available here; validate any destinations before classifying them as malicious.
  6. Apply proportionate rate limiting or temporary source-cluster controls while accounting for possible proxy/NAT aggregation, and verify whether the activity was authorized testing.