Back to evidence

Sanitized live incident

Suspicious activity

Native source identity and targetable endpoints are private.

criticalopen
Confidence
99%
First seen
Aug 20, 11:33:27 PM PDT
Evidence through
Aug 21, 12:06:11 AM PDT
AI status
Complete
Likely true positive91% confidence

Likely true positive for suspicious execution within the protected processor workload. Event-driven telemetry directly observed repeated root-run dash shells, a child discovery command, outbound-capable client-class processes, and access/mutation/execution involving an inventory-resolved shared resource (process evidence [redacted], [redacted], [redacted], [redacted], [redacted], [redacted]; inventory evidence [redacted]). This establishes concerning workload-level execution and shared-resource activity, but not an exploitation vector, actor, network connection, persistence, host escape, lateral movement, command-and-control, or data theft. No cited HTTP or flow event was available for bounded inspection, so the origin and network consequences remain unresolved.

Attack stage
Execution and discovery, with shared-resource access, mutation, and execution
Model
gpt-5.6-sol · 13 evidence calls

Observed impact

  • Root-run shell and discovery processes were observed in the processor workload [redacted].
  • A shared resource was observed being mutated, executed from, and accessed [redacted].
  • Outbound-capable client-class processes were spawned, but no socket consequence was established [redacted].

Deterministic signals

Process.observed shell spawn99%

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

58 observations · 12 process
Process.observed discovery command88%

An event-driven discovery command was observed in a protected workload without correlated HTTP evidence

21 observations · 12 process
Process.correlated exit99%

A previously correlated process lifecycle exited

70 observations · 12 process
Process.observed network client87%

An event-driven outbound-capable client was observed in a protected workload without correlated HTTP evidence

6 observations · 6 process
Process.shared resource activity92%

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

18 observations · 11 process · 1 inventory

Explicit uncertainty

  • No HTTP evidence reference is cited by the incident, so the originating action, request, and actor cannot be determined or uniquely linked to any process.
  • No flow evidence reference is cited by the incident. Network-client process classification does not establish a connection, destination, command-and-control, or data transfer.
  • The bounded summaries do not expose exact command arguments or shared-resource contents, so intent and the precise changes cannot be determined.
  • The workload cluster is not a guaranteed human or agent identity.
  • Legitimate processor or administrative automation remains possible; no allowlist, deployment history, maintenance context, or expected process baseline was available.
  • Exact exec/exit lifecycle joins prove process termination and outcomes, not causality from any particular external request.
  • There is no cited evidence proving persistence, host escape, lateral movement, command-and-control, or data theft.

Recommended actions

  1. Temporarily isolate or restrict the affected processor workload if operationally safe, prioritizing preservation of volatile and process telemetry.
  2. Validate whether root-run dash, id, network-client tooling, and the observed shared-resource operations are expected for this processor and time window.
  3. Preserve and compare the shared resource against a known-good version; review its change history and determine which other workloads mount or consume it.
  4. Review available application, orchestrator, job-queue, administrative, and audit logs around 06:33–06:55Z to identify the initiating action and principal.
  5. Inspect egress telemetry for the affected workload during the incident window; do not infer network compromise solely from network-client process classes.
  6. If the activity is unauthorized, rotate credentials accessible to the workload, replace the workload and affected shared material from trusted sources, and assess other consumers of the shared resource.
  7. Reduce workload privileges where feasible: avoid running the processor as root, constrain shell/tool availability, apply least-privilege mounts, and restrict egress.