Back to cases

Live public case

Confirmed compromise

Last activity Aug 28, 3:57:47 PM PDT

criticalImpact confirmed

Evidence-grounded assessment

Likely same operation

The three preserved incident threads are best explained as one likely operation, not as proven single-actor activity. Incident [redacted] records confirmed remote command execution as root beginning at [redacted]33Z. Incidents [redacted] and [redacted] then record overlapping root-shell, discovery, sensitive-file, and shared-resource activity. Deterministic links [redacted] and [redacted] connect each process-only thread to the confirmed-compromise thread by protected-workload attribution and temporal proximity. This is a coherent possible exploitation-to-post-compromise progression, but the links do not prove request-to-process causality, and the process-only threads lack correlated HTTP requests or known actors.

Protected workloads
Protected workload A · Protected workload B
Progression
Within-workload activity
Severity basis
Maximum incident posture

Observed impact

  • Confirmed root execution
  • Correlated process exited
  • Outbound client spawned
  • Remote command execution
  • Root execution
  • Sensitive file access command observed
  • Server identity disclosure
  • Shared resource access observed
  • Shared resource execution observed
  • Shared resource mutation observed
  • Shell spawned
  • State changing http activity after compromise
  • System discovery
  • System information disclosure
  • Workload discovery process spawned
  • Workload root shell
  • Remote command execution as root/UID 0 in the responding workload (HTTP [redacted]).
  • Process identity, kernel, and operating-system information were disclosed (HTTP [redacted]; HTTP [redacted]).
  • Root shell/discovery processes were observed in the correlated workload (process [redacted]; process [redacted]).
  • Root process activity targeting a sensitive resource included observed mutation, execution, and access operations; unique request causality is not proven (process [redacted]; process [redacted]; e
  • Root-run shell processes executed inside the processor workload.
  • Processes in the workload accessed an inventory-resolved shared resource.
  • Concrete downstream harm is not established by the available bounded evidence.
  • A root-run dash shell executed inside the protected workload [redacted].
  • Root-run discovery activity was observed through dash and env processes [redacted].
  • A root-run dash process was classified as a sensitive-file tool and had a sensitive target; actual file contents read or changed are not established [redacted].
  • A root-run shell and its child executed from shared resource [redacted].

Recommended actions

  1. Preserve the three incident boundaries and investigate them as one likely operation while retaining separate actor and causality hypotheses.
  2. Prioritize containment and forensic review of both protected workloads associated with incidents [redacted], [redacted], and [redacted] because confirmed root execution is present.
  3. Correlate application, authentication, orchestration, and process lineage records around 22:23–22:57Z to test the missing request-to-process edges represented by links [redacted] and [redacted].
  4. Review shared-resource mutations and sensitive-file access associated with incidents [redacted] and [redacted] for impact and persistence, without assuming they came from the same actor.
  5. Validate whether the post-compromise state-changing HTTP activity in incident [redacted] was authorized and rotate potentially exposed credentials if supported by the investigation.

Attack timeline

3 incident threads

Live progression remains visible; PII, native endpoints, hashes, and private identities do not.

  1. 1
    Confirmed compromiseconfirmed

    The immutable detector state is confirmed, and the evidence supports that conclusion. A command-injection request returned non-reflected root/UID 0 process output and kernel identification in the same captured HTTP transaction, proving command execution despite HTTP 400 (HTTP [redacted]). A separate injection request returned non-reflected OS-release and kernel data (HTTP [redacted]). Event-driven process telemetry also observed a root dash shell spawning id and later root processes targeting a sensitive resource and performing mutation, execution, and access operations. HTTP-to-process attribution remains temporal/workload-based rather than a unique causality edge. No cited flow event was available, so outbound communication, C2, or exfiltration is not established.

  2. 2
    Suspicious activityopen

    Real process activity is confirmed, but malicious intent or compromise is not. Event-driven telemetry directly observed root-run dash shells in the processor workload, including repeated shells from the same parent lineage. An exact lifecycle record shows one observed shell exited successfully. Separate root-run processes accessed a shared resource. However, no HTTP or flow evidence is cited, and the bounded summaries do not expose command arguments, resource contents, or an initiating actor. The short-lived, repeated shell pattern could be normal worker or administrative activity. Exploitation, persistence, host escape, lateral movement, command-and-control, and data theft are not established.

  3. 3
    Suspicious activityopen

    Likely true positive for suspicious workload-level execution, but not a proven externally initiated exploit. Event-driven telemetry directly observed repeated root-run dash shells, discovery activity, a sensitive-file-targeting shell, and execution from an inventory-resolved shared resource in the same workload context [redacted]. The repeated common parent PID may indicate an application service or administrative automation rather than a remote actor, and no HTTP or flow evidence was available to establish origin, request-to-process causality, or network consequences. At least one observed shell had an exact exit event with a zero outcome; that establishes process completion only, not benign intent or exploit causality [redacted].

Relationship reasoning

Shared workload time window90%

shared protected workload attribution and temporal proximity

Shared workload time window90%

shared protected workload attribution and temporal proximity