Sanitized live incident
Confirmed compromise
Native source identity and targetable endpoints are private.
- Confidence
- 100%
- First seen
- Aug 28, 7:08:24 PM PDT
- Evidence through
- Aug 28, 9:15:03 PM PDT
- AI status
- Complete
True positive: HTTP evidence proves successful command injection and root-level command execution in the responding workload, even though the responses were HTTP 400. The strongest event contains shell-command input and non-reflected process-identity output identifying UID 0 ([redacted]); another response disclosed non-reflected kernel information ([redacted]). Event-driven process telemetry independently shows root shells and discovery commands in the correlated workload, followed by sensitive-target and shared-resource activity. The detector's confirmed state and confirmed-compromise classification are therefore supported. Process timing does not establish a unique request-to-process edge, and no cited flow evidence was available to assess outbound consequences.
- Attack stage
- Exploitation with root command execution and post-exploitation discovery/resource access
- Model
- gpt-5.6-sol · 13 evidence calls
Observed impact
- Remote command execution as root was proven in the responding workload.
- Root shell and system-discovery processes were observed in the correlated workload.
- A root shell targeted a sensitive file and mutated a shared resource; child processes accessed the shared resource and sensitive target.
- Non-reflected process identity and kernel information were disclosed in HTTP responses.
Deterministic signals
Broad unauthenticated route and HTTP method enumeration observed
271 observations · 12 httpA shell process appeared in the correlated workload and request window
83 observations · 12 processA previously correlated process lifecycle exited
99 observations · 12 processExploit request received non-reflected process identity output
5 observations · 5 httpA discovery process appeared in the correlated workload and request window
34 observations · 12 processResponse contains non-reflected kernel identification
1 observations · 1 httpRequest contains shell metacharacters and command tokens
42 observations · 12 httpA process modified an inventory-resolved resource attached to multiple workloads
4 observations · 4 process · 1 inventoryA process command targeted a sensitive file in the correlated workload and request window
16 observations · 12 processA state-changing HTTP method was observed after confirmed workload compromise
1 observations · 1 httpExplicit uncertainty
- The source key is a traffic/workload cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
- Configured routing provides workload affinity but not an observed per-request trace edge; process timing and workload identity do not prove unique request-to-process causality.
- No flow-plane event was cited by this incident for bounded retrieval, so outbound connectivity, command-and-control, exfiltration, and destination novelty cannot be assessed.
- The evidence proves compromise of the responding workload, not host escape, persistence, lateral movement, credential theft, or data theft.
- The contents and operational effect of the sensitive-file and shared-resource activity are not exposed by the bounded summaries; access or mutation does not by itself prove exfiltration or persistence.
- Authorization for the scanning and exploitation traffic is not established by network evidence; broad enumeration alone could be testing, but the proven root command execution remains a real security impact.
Recommended actions
- Immediately isolate the affected responding workloads and preserve volatile telemetry, container/runtime metadata, and immutable images before redeployment.
- Disable or restrict the vulnerable API route, correct the command-injection flaw, and add temporary gateway filtering for the observed exploit pattern until the fix is verified.
- Inspect and diff shared resource [redacted], identify every attached workload, validate integrity, and restore known-good content where necessary.
- Review all sensitive files and secrets reachable by the compromised root workload; rotate exposed credentials or tokens according to verified access and organizational policy.
- Rebuild affected workloads from trusted images, run them as non-root where feasible, remove unnecessary shell/discovery utilities, and apply least-privilege filesystem and shared-resource permissions.
- Review retained HTTP, process, audit, and network telemetry across the incident window for persistence, outbound sessions, lateral access, and data exposure; do not infer these impacts without evidence.
- Determine whether the source cluster was authorized security testing; retain the source key as a cluster identifier rather than treating it as a unique person or agent.