Back to evidence

Sanitized live incident

Suspicious activity

Native source identity and targetable endpoints are private.

criticalopen
Confidence
99%
First seen
Aug 18, 10:46:54 PM PDT
Evidence through
Aug 18, 11:09:58 PM PDT
AI status
Complete
Likely true positive78% confidence

Likely true positive for suspicious workload execution: event-driven telemetry directly observed multiple root-context dash shells, a root-context bash child shell, and root-context discovery executables (`id` and `hostname`) in one workload (process evidence [redacted], [redacted], [redacted], [redacted], [redacted]). This supports execution and discovery inside the workload, but not exploitation, remote-request causality, persistence, host escape, or data theft. The origin and authorization remain unresolved because no incident-cited HTTP or flow evidence was available.

Attack stage
Execution and discovery within workload; initial access unconfirmed
Model
gpt-5.6-sol · 6 evidence calls

Observed impact

  • Root-context shell processes executed inside the workload [redacted].
  • Root-context discovery processes executed inside the workload [redacted].
  • At least one observed root dash lifecycle ended with a nonzero exit; this does not negate that execution occurred [redacted].

Deterministic signals

Process.observed shell spawn99%

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

409 observations · 12 process
Process.observed discovery command88%

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

3 observations · 3 process
Process.correlated exit99%

A previously correlated process lifecycle exited

411 observations · 12 process

Explicit uncertainty

  • No incident-cited HTTP event IDs were available. An HTTP lookup using a cited process ID was rejected because that ID is not cited on the HTTP plane, so the initiating request, if any, cannot be determined.
  • No incident-cited flow event IDs were available. A flow lookup using a cited process ID was rejected because that ID is not cited on the flow plane, so network consequences and request-to-socket causality cannot be assessed.
  • The process summaries expose executable names and lineage but not command arguments or operator intent; authorization and purpose are therefore unknown.
  • The recurring parent PID is visible, but its executable, service role, and authorization context are not established by the inspected evidence.
  • The source key denotes a workload cluster, not a specific person or remote actor.
  • There is no cited evidence proving exploitation, persistence, host escape, lateral movement, command-and-control, or data theft.

Recommended actions

  1. Immediately identify the owner and executable associated with recurring parent PID 3076121 and compare the activity with deployment, CI/CD, health-check, and administrative change records.
  2. If the shell and discovery activity is not explicitly authorized, contain the affected workload according to policy, preserve telemetry, and redeploy it from a known-good immutable image.
  3. Review workload, application, orchestration, and identity-provider logs around 05:46–06:10 UTC to determine the initiating action and principal; preserve relevant records before retention expires.
  4. Audit the workload image and runtime configuration for unexpected scripts, cron or scheduled tasks, writable executable paths, injected environment configuration, and unauthorized package or file changes.
  5. Reduce exposure by running the workload as a non-root user where feasible and applying least-privilege capabilities, filesystem, exec, and egress controls.
  6. Investigate only evidence-supported scope first; do not infer host escape or lateral movement without additional telemetry.