Back to evidence

Sanitized live incident

Confirmed compromise

Native source identity and targetable endpoints are private.

criticalconfirmed
Confidence
99%
First seen
Aug 21, 4:13:46 PM PDT
Evidence through
Aug 21, 5:18:52 PM PDT
AI status
Complete
True positive99% confidence

The detector’s immutable output is confirmed/confirmed_compromise, and the evidence supports that result. Command-injection-shaped HTTP requests were followed by responses containing non-reflected root identity and kernel output; notably, command output was present even in HTTP 400 responses, which proves execution in the responding workload rather than failure based on status alone [[redacted], [redacted], [redacted]]. Event-driven telemetry independently observed root dash shells, discovery utilities, sensitive-file tools, and shared-resource mutation in correlated workload windows [redacted]. This establishes successful remote command execution and post-exploitation activity within responding workloads. It does not establish host escape, persistence, exfiltration, lateral movement, or command-and-control.

Attack stage
Exploitation and post-exploitation discovery in responding workloads
Model
gpt-5.6-sol · 8 evidence calls

Observed impact

  • Root-level command execution was disclosed in server responses [[redacted], [redacted]].
  • Kernel/system discovery output was returned by the responding workload [[redacted]].
  • Root process telemetry observed discovery and sensitive-file tooling [redacted].
  • Execution and mutation of an inventory-resolved resource shared by multiple workloads were observed [redacted].

Deterministic signals

Http.surface enumeration92%

Broad unauthenticated route and HTTP method enumeration observed

574 observations · 12 http
Http.command injection attempt88%

Request contains shell metacharacters and command tokens

20 observations · 12 http
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

89 observations · 12 process
Process.correlated network client80%

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

5 observations · 5 process
Process.correlated exit99%

A previously correlated process lifecycle exited

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

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

10 observations · 10 process
Process.correlated discovery command80%

A discovery process appeared in the correlated workload and request window

30 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

2 observations · 2 http
Process.shared resource activity80%

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

38 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; it is not a confirmed human or agent identity.
  • Authorization is not established. The route enumeration and exploitation could be part of sanctioned testing, although actual root command execution is still proven.
  • Configured workload affinity and temporal process correlation do not provide a unique HTTP-request-to-process causality edge.
  • No incident-cited conntrack event was available to the flow-evidence tool; process evidence only establishes that outbound-capable clients appeared, not that any outbound connection succeeded or was caused by a request.
  • Sensitive-file commands were observed, but the bounded evidence does not prove what content was read, retained, or exfiltrated.
  • Shared-resource execution and mutation are observed, but the evidence does not prove propagation into another workload or lateral movement.
  • Host escape, persistence, command-and-control, and data theft are not established by the available evidence.

Recommended actions

  1. Immediately contain the affected processor and image-host workloads according to incident-response policy while preserving volatile and immutable evidence.
  2. Remove or disable the vulnerable command-execution path, validate input handling, and patch or redeploy the application from a known-good image.
  3. Preserve gateway, workload, process, orchestration, and available network telemetry for the full incident window; build request-to-workload traces if possible.
  4. Inspect the shared resource identified as [redacted] for unauthorized changes, restore it from a trusted version if integrity is not assured, and review every attached workload.
  5. Rotate credentials, tokens, and application secrets accessible to the affected workloads, prioritizing values that may have been present in environment files or process environments.
  6. Review sensitive system and application files for access and modification, and assess whether returned response bodies exposed additional system information.
  7. Hunt for related root shells, discovery tools, sensitive-file access, shared-resource mutations, and outbound connections across workloads sharing the same deployment or resource.
  8. Treat source-cluster-based blocking as a temporary containment option only; validate ownership and authorization because the source key may aggregate multiple entities.