Back to evidence

Sanitized live incident

Suspicious activity

Native source identity and targetable endpoints are private.

criticalopen
Confidence
99%
First seen
Aug 20, 1:52:34 PM PDT
Evidence through
Aug 20, 1:56:07 PM PDT
AI status
Complete
Likely true positive84% confidence

Verified process telemetry supports a real suspicious execution sequence in the protected processor workload: event-driven root dash shells repeatedly ran, and associated activity accessed and mutated an inventory-resolved shared resource. The observed processes were short-lived and exited successfully, but successful exit does not make the activity benign. The available evidence does not identify the initiating actor or action, and no cited HTTP or flow events are available to establish a remote exploit, request-to-process causality, or network consequences. This is therefore likely a true positive for unauthorized or anomalous workload execution and shared-resource modification, not proof of broader compromise.

Attack stage
Execution and shared-resource modification in workload; initial vector unknown
Model
gpt-5.6-sol · 9 evidence calls

Observed impact

  • Root shell execution occurred inside the processor workload.
  • An inventory-resolved shared resource was accessed and mutated, creating potential integrity risk for workloads attached to that resource.
  • Observed shell and child processes exited; no persistence, host escape, lateral movement, command-and-control, or data theft was established.

Deterministic signals

Process.observed shell spawn99%

An event-driven shell execution was observed in a protected workload without correlated HTTP evidence

26 observations · 12 process
Process.shared resource activity92%

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

48 observations · 11 process · 1 inventory
Process.correlated exit99%

A previously correlated process lifecycle exited

48 observations · 12 process

Explicit uncertainty

  • No HTTP evidence reference is cited by this incident, and HTTP evidence retrieval using process IDs was unavailable; the originating request or non-HTTP action cannot be determined.
  • No flow evidence reference is cited by this incident, and flow evidence retrieval using process IDs was unavailable; request-to-socket causality and network consequences cannot be assessed.
  • The source key represents a workload cluster, not a verified human or remote actor identity.
  • The bounded summaries do not expose exact commands, arguments, or mutated content, so intent and the precise shared-resource change are unknown.
  • Legitimate processor, deployment, maintenance, or administrative automation could produce short-lived root shells; authorization and expected-behavior context were not available.
  • The cited lifecycle evidence covers specific early processes and does not prove that every process counted by the detector exited or that no related process remained active.

Recommended actions

  1. Promptly validate whether the parent process and repeated root shell pattern were expected for this processor workload by comparing deployment, scheduler, and administrative change records for the incident window.
  2. If the activity is unauthorized or cannot be rapidly explained, contain the affected workload using established procedures while preserving process, workload, and shared-resource evidence.
  3. Snapshot or otherwise preserve the shared resource, determine exactly what changed, and compare it with a trusted version before restoring or redeploying.
  4. Identify every workload attached to the shared resource and assess them for execution of or dependency on the modified content; do not infer compromise solely from attachment.
  5. Review broader process and orchestration audit telemetry around 2026-08-20T20[redacted]34Z through [redacted]07Z to identify the initiator and full process lineage.
  6. Review relevant network telemetry independently for unexpected egress or service-to-service activity because no cited flow evidence was available here.
  7. Consider reducing workload privileges and removing unnecessary root execution or writable shared-resource access after operational requirements are confirmed.