Back to evidence

Sanitized live incident

Attempted exploitation

Native source identity and targetable endpoints are private.

highopen
Confidence
99%
First seen
Aug 28, 2:27:37 AM PDT
Evidence through
Aug 28, 2:38:42 AM PDT
AI status
Complete
Likely true positive94% confidence

Likely successful command-injection exploitation, not merely an attempt. Three HTTP events from the same derived source cluster contained shell metacharacters and command tokens; the last was followed about 281 ms later by an event-driven root dash exec in the correlated processor workload, with a root discovery child. The processor-side lineage mutated shared resource [redacted]; shortly afterward, root dash processes in a different workload mutated and executed that same resource. This sequence is highly suspicious and supports actual workload command execution and shared-resource impact. However, correlation is based on routing/workload affinity and time proximity rather than a unique request-to-process trace, so the initiating HTTP request cannot be proven as the sole cause. The incident remains detector-classified as attempted_exploitation/open; this assessment elevates the likely observed consequence while preserving that causality limitation. No flow evidence is cited by the incident, so outbound network consequences are not established.

Attack stage
Initial access via command injection; workload execution and shared-resource activity observed
Model
gpt-5.6-sol · 13 evidence calls

Observed impact

  • Root shell and discovery processes were observed in the processor workload ([redacted], [redacted]).
  • Shared resource [redacted] was observed mutated in one workload and executed by a root shell in another ([redacted], [redacted]).
  • The correlated processor processes later exited with zero outcomes; this does not undo or disprove the preceding activity ([redacted], [redacted]).

Deterministic signals

Http.command injection attempt88%

Request contains shell metacharacters and command tokens

3 observations · 3 http
Process.correlated shell spawn80%

A shell process appeared in the correlated workload and request window

3 observations · 3 process
Process.shared resource activity80%

A process modified an inventory-resolved resource attached to multiple workloads

5 observations · 5 process · 1 inventory
Process.correlated discovery command80%

A discovery process appeared in the correlated workload and request window

1 observations · 1 process
Process.correlated exit99%

A previously correlated process lifecycle exited

4 observations · 4 process

Explicit uncertainty

  • There is no unique per-request trace or parentage edge proving that the final HTTP request created the observed processor shell; routing affinity and close timing provide correlation only.
  • The source key is a derived traffic cluster and may represent a proxy, NAT gateway, multiple workers, or another aggregation rather than one actor.
  • HTTP status codes (200 and 500) do not determine exploit success. The bounded HTTP summaries do not expose response content, so they cannot establish whether command output was returned.
  • No flow evidence reference is cited by this incident. Outbound connectivity, command-and-control, lateral movement, or data exfiltration cannot be assessed from the available evidence.
  • The evidence establishes shared-resource mutation and execution but does not reveal the exact mutated content or prove persistence, host escape, credential theft, or data theft.
  • The legitimate operational context for the root dash/env processes and shared-resource workflow is not available, leaving a smaller possibility of coincidental or expected automation.

Recommended actions

  1. Temporarily isolate or restrict the affected processor and image-host workloads and prevent further execution from shared resource [redacted] while preserving forensic state.
  2. Preserve the cited HTTP, process, workload, and shared-resource artifacts; collect the resource contents and metadata before restoration or redeployment.
  3. Review and remediate the affected API handler for unsafe shell invocation, validate/allowlist input, and avoid passing remote input to a shell.
  4. Rebuild or redeploy affected workloads from known-good immutable images after evidence preservation, and verify the shared resource against a trusted baseline.
  5. Review access to the system account database and any secrets available to the root processes; rotate credentials if evidence shows possible disclosure or modification.
  6. Add end-to-end request tracing or request-to-process attribution so future investigations can establish a unique causality edge.
  7. Review network telemetry around the incident window separately; no cited flow evidence was available in this incident.