Back to evidence

Sanitized live incident

Suspicious activity

Native source identity and targetable endpoints are private.

criticalopen
Confidence
99%
First seen
Aug 28, 1:20:10 PM PDT
Evidence through
Aug 28, 1:34:17 PM PDT
AI status
Complete
Likely true positive84% confidence

Likely true positive for suspicious root-level workload activity, but not proof of remote exploitation. Event-driven process telemetry recorded a root dash shell and child shell, repeated root discovery-class env executions, and a root process associated with mutation of an inventory-resolved shared resource [redacted]. The first two shells exited successfully within milliseconds [redacted]. Attribution and intent remain unresolved because no correlated HTTP evidence or cited flow evidence is available and exact arguments are excluded from the summaries.

Attack stage
Execution and discovery with shared-resource impact
Model
gpt-5.6-sol · 9 evidence calls

Observed impact

  • Root dash shell execution occurred in the protected workload, including a root child shell [redacted].
  • Multiple root discovery-class env processes executed over several minutes [[redacted]; [redacted]; [redacted]; [redacted]; [redacted]

Deterministic signals

Process.observed shell spawn99%

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

91 observations · 12 process
Process.correlated exit99%

A previously correlated process lifecycle exited

92 observations · 12 process
Process.observed discovery command88%

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

9 observations · 9 process
Process.shared resource activity92%

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

2 observations · 2 process · 1 inventory

Explicit uncertainty

  • No HTTP request was correlated with the event-driven process executions; the originating action and actor are unknown. The attempted HTTP-evidence lookup found no incident-cited HTTP event for the selected process IDs.
  • No incident-cited flow event was available for the selected process activity, so outbound communication, destination novelty, and request-to-socket causality cannot be assessed.
  • Bounded process summaries exclude exact arguments and command content, preventing determination of the discovery targets and the precise shared-resource change.
  • The source key is a workload cluster, not a guaranteed person or agent identity.
  • Legitimate workload automation or administrative activity remains possible; authorization context and a behavioral baseline were not available.
  • No evidence here proves host escape, persistence, lateral movement, command-and-control, or data theft.

Recommended actions

  1. Immediately validate whether the root shell, discovery executions, and shared-resource mutation were authorized by deployment, maintenance, or administrative activity.
  2. Preserve the affected workload and shared resource for forensic review; collect orchestrator audit logs, deployment history, job/task records, and full process ancestry for the incident window.
  3. Compare the shared resource against a known-good version and identify every attached workload before deciding whether to restore or rotate it.
  4. If the activity is unauthorized, isolate or replace the workload using established response procedures and restrict its access to the shared resource.
  5. Review least-privilege controls: avoid running the processor as root where feasible, limit shell availability, and narrow write permissions on resources shared across workloads.
  6. Search retained telemetry for the same workload lineage and source cluster before and after the incident window, while avoiding attribution of the cluster to a specific actor without corroboration.