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:33 PM PDT
Evidence through
Aug 28, 1:34:17 PM PDT
AI status
Complete
Indeterminate84% confidence

The incident reflects real, high-risk process activity in the protected image-host workload: root-run dash shells, a root cat child classified as targeting a sensitive file, and a root shell associated with mutation of an inventory-resolved shared resource. Exact lifecycle evidence also shows sampled shells exited, with both zero and nonzero outcomes. However, the available evidence does not establish who initiated the activity, whether it was authorized workload/administrative behavior, or whether exploitation occurred. No HTTP request is cited as correlated, and no cited flow evidence is available to assess network consequences. Escalation and workload-owner validation are warranted, but compromise cannot be adjudicated from these process observations alone.

Attack stage
Execution and sensitive-resource interaction; initial access unestablished
Model
gpt-5.6-sol · 10 evidence calls

Observed impact

  • Root-privileged shell execution was observed inside the image-host workload.
  • A root-run cat process was classified as targeting a sensitive file.
  • A root shell was associated with mutation of a resource inventory-resolved as shared across workloads.
  • Sampled shell processes terminated with mixed zero and nonzero outcomes; their exit does not establish that downstream effects were reversed.

Deterministic signals

Process.observed shell spawn99%

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

34 observations · 12 process
Process.correlated exit99%

A previously correlated process lifecycle exited

44 observations · 12 process
Process.observed sensitive file command99%

An event-driven process targeted a sensitive file in a protected workload without correlated HTTP evidence

30 observations · 12 process
Process.shared resource activity92%

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

1 observations · 1 process · 1 inventory

Explicit uncertainty

  • No HTTP evidence reference is cited for these process events, so the originating action, request, and actor are unknown; a workload source key is not a human or remote-agent identity.
  • No flow evidence reference is cited, so outbound communication, command-and-control, lateral movement, or exfiltration cannot be assessed.
  • The bounded summaries identify a sensitive target classification but do not disclose the file path or prove what content, if any, was successfully read or exposed.
  • The shared-resource evidence establishes a mutation operation but does not show the resulting content, authorization context, or whether the change was malicious or expected for the image-host role.
  • The identity and expected behavior of the recurring parent process are not established by the cited evidence.
  • Process telemetry alone cannot distinguish compromise from legitimate workload automation or administrative activity; no evidence proves host escape, persistence, lateral movement, or data theft.

Recommended actions

  1. Escalate to the workload owner and verify whether the recurring root dash/cat activity and the shared-resource mutation match an approved image-host workflow at the cited times.
  2. Review trusted orchestration, deployment, scheduler, and administrative audit records for the recurring parent lineage and correlate them with workload changes; do not treat the workload source cluster as an actor identity.
  3. Preserve the workload state and relevant audit telemetry, then inspect the shared resource's version history or integrity metadata to determine exactly what changed and which attached workloads may be affected.
  4. If the activity is not immediately explainable, temporarily restrict writes to the shared resource and contain or replace the affected workload using established response procedures, balancing service impact.
  5. Determine which sensitive file was targeted and whether its contents were actually accessed or disclosed; rotate affected credentials only if exposure is confirmed or cannot be safely excluded.
  6. Review least-privilege controls: avoid root execution where possible, constrain shell invocation, and limit the image-host workload's access to sensitive files and cross-workload shared resources.