Back to cases

Live public case

Confirmed compromise

Last activity Aug 30, 11:09:33 AM PDT

criticalImpact confirmed

Evidence-grounded assessment

Likely same operation

The four preserved incident threads are best explained as a likely single operation against the same protected workload, but the evidence does not prove one actor or unique HTTP-to-process causality. Incident [redacted] establishes confirmed root-level command execution during an initial exploitation window; incident [redacted] contains overlapping process-only root shell activity linked by [redacted]. Later, incident [redacted] records enumeration and attempted exploitation from the same source cluster as [redacted] under link [redacted], followed by process-only root shells in [redacted] linked through [redacted]. This connected sequence supports resumed or continued activity more strongly than unrelated operations, while the source-cluster ambiguity, approximately 69-minute gap, and absent unique request-to-process edges prevent a definitive same-operation finding.

Protected workloads
Protected workload A
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
  • 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 in the responding workload, with process identity and system information exposed [[redacted]; [redacted]].
  • Root shell and discovery processes executed in the correlated workload [redacted].
  • A root shell classified as targeting a sensitive resource was observed; actual file content access or disclosure is not established [redacted].
  • A root shell classified as network-client capable and a root bash process were observed, but no outbound connection is established [redacted].
  • A PATCH request received HTTP 200 after compromise, but authorization and an actual state mutation are not established [[redacted]].
  • Root-context shell execution occurred three times inside the workload [redacted].
  • All three observed shell lifecycles terminated with zero exit outcomes; no continuing shell process is established by these records [process:[redacted]; process:[redacted]; process:fcdbd9b04200f6a
  • Root-context shell execution and child discovery utilities were observed in the correlated processor workload.
  • Outbound-capable shell processes were observed, but no cited network flow proves that they established an outbound connection.
  • The cited shell and discovery processes were short-lived; the available evidence does not establish persistence, host escape, lateral movement, or data theft.
  • Root-level shell processes executed inside the workload [redacted].
  • A root id discovery process was spawned by a root dash parent [redacted].
  • Sampled shell processes were transient and exited, with exact PID-matched examples returning zero [redacted].

Recommended actions

  1. Preserve all four incident boundaries and retain the complete telemetry around [redacted], [redacted], [redacted], and [redacted] for request, process-parentage, and lifecycle reconstruction.
  2. Review workload and application audit records around both activity windows to determine whether processes in [redacted], [redacted], and [redacted] can be tied to specific requests without assuming causality from proximity.
  3. Validate whether the sensitive-target command and PATCH request in [redacted] produced file access, disclosure, or an authorized or unauthorized durable state change.
  4. Investigate the protected workload for persistence, modified artifacts, credential exposure, and unexpected outbound activity, while treating those outcomes as unproven by the current incidents.
  5. Determine whether the source-cluster activity connecting [redacted] and [redacted] corresponds to authorized testing, a shared intermediary, or a consistent external engagement.

Attack timeline

4 incident threads

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

  1. 1
    Confirmed compromiseconfirmed

    True positive confirmed compromise: captured exploit/response evidence shows command-oriented input followed by non-reflected root identity and kernel output in the responding workload, despite HTTP 400 [[redacted]; [redacted]]. Event-driven telemetry independently observed root shells and discovery processes in the correlated workload [redacted]. The detector's immutable state is confirmed, and the inspected evidence supports that result. Later sensitive-target and network-client-class processes increase concern, but request-to-process and request-to-socket causality remain unproven [redacted].

  2. 2
    Suspicious activityopen

    Three event-driven process records confirm root-context `dash` shell executions in the same workload, all with parent PID 2212455 [redacted]. Matching lifecycle records show all three PIDs subsequently exited with outcome zero [redacted]. This proves shell execution inside the workload, but the available argument-free summaries do not identify the commands or actor. No HTTP or flow evidence IDs are cited by the incident, so exploitation and network consequences cannot be established. The behavior could represent malicious execution or legitimate processor/administrative activity.

  3. 3
    Attempted exploitationopen

    Likely true positive command-injection exploitation with workload-level execution. Multiple HTTP requests were classified as containing shell metacharacters and command tokens, and root-context dash processes appeared tens of milliseconds later in the correlated processor workload. The strongest examples include dash spawning the discovery utilities id and uname as direct children. This repeated request/exec pattern strongly supports successful command execution, although routing affinity and temporal correlation do not provide a unique per-request causality edge. No cited flow evidence was available, so outbound communication, command-and-control, and exfiltration are not established.

  4. 4
    Suspicious activityopen

    Process telemetry conclusively shows repeated root-level dash execution in the processor workload, including discovery-classified shells and a final root dash→id parent-child chain [redacted]. Exact PID-matched lifecycle evidence also shows sampled shells exiting, generally successfully [redacted]. These are real execution consequences, but the bounded evidence does not establish whether they were authorized processor behavior or malicious activity. No usable HTTP or flow evidence was cited, so initial access, actor, request causality, network consequences, and compromise cannot be determined.

Relationship reasoning

Shared workload time window90%

shared protected workload attribution and temporal proximity

Same source cluster80%

same privacy-preserving traffic source cluster and target within a bounded time window

Shared workload time window90%

shared protected workload attribution and temporal proximity