Back to evidence

Sanitized live incident

Suspicious activity

Native source identity and targetable endpoints are private.

criticalopen
Confidence
99%
First seen
Aug 23, 2:39:38 PM PDT
Evidence through
Aug 23, 2:53:36 PM PDT
AI status
Complete
Indeterminate92% confidence

Verified process telemetry shows repeated event-driven `dash` shell executions as root in one protected workload, with a common observed parent PID; representative events span [redacted]38Z to [redacted]06Z ([redacted], [redacted]). Matching lifecycle evidence shows sampled shells exited with outcome zero ([redacted], [redacted], [redacted]). This validates the detector's critical shell-execution observation, but not malicious causation. No cited HTTP or flow event was available to inspect, and the bounded process summaries do not expose command arguments or enough parent context to distinguish exploitation from expected processor or administrative behavior. Verdict: indeterminate pending workload-owner validation and richer lineage/command evidence.

Attack stage
Execution — workload-local root shell launches observed; cause and intent undetermined
Model
gpt-5.6-sol · 6 evidence calls

Observed impact

  • Repeated root-context shell processes executed inside the protected workload.
  • Several exact matched shell lifecycles exited with outcome zero shortly after execution.
  • No evidence available here proves host escape, persistence, lateral movement, command-and-control, data theft, or a request-triggered exploit.

Deterministic signals

Process.observed shell spawn99%

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

13 observations · 12 process
Process.correlated exit99%

A previously correlated process lifecycle exited

13 observations · 12 process

Explicit uncertainty

  • No HTTP evidence event is cited by this incident; attempted HTTP retrieval using cited process IDs was rejected because those IDs are not HTTP events. The originating action and any remote actor remain unknown.
  • No flow evidence event is cited by this incident; attempted flow retrieval using cited process IDs was rejected because those IDs are not flow events. Network consequences cannot be assessed from this evidence set.
  • The bounded process summaries do not expose command arguments, shell input, parent executable identity, or parent command line, so the actions performed by `dash` cannot be determined.
  • It is unknown whether parent PID 1322209 is an expected component of the processor workload or an unauthorized process.
  • The detector signal reports a count of 13 shell executions, while the incident update exposes 12 immutable exec evidence references; the unexposed occurrence could not be independently inspected.
  • A zero exit outcome establishes process completion, not benign intent or exploit causality.
  • The source key is a workload cluster, not a guaranteed human or agent identity.

Recommended actions

  1. Ask the workload owner to validate whether the processor is expected to invoke `dash` repeatedly as root during the cited interval and whether parent PID 1322209 belongs to the approved application lineage.
  2. Preserve and review richer process/audit telemetry for the cited PIDs and parent, especially command arguments, environment provenance, executable hashes, descendants, file activity, and initiating scheduler or job metadata.
  3. Correlate the interval with application, orchestration, authentication, deployment, and administrative audit logs to identify the triggering action without assuming HTTP causality.
  4. Review network telemetry for the workload during and shortly after the interval for independently attributable unusual connections; do not infer request-to-socket causality from timing alone.
  5. If the launches are not expected, contain or restart the affected workload according to policy, preserve forensic artifacts first, and rotate workload-accessible credentials based on exposure review.
  6. Reduce future ambiguity by running the processor as non-root where feasible and by adding approved shell-execution baselines or explicit command allowlists rather than suppressing the detector broadly.