Back to cases

Live public case

Confirmed compromise

Last activity Aug 27, 8:05:09 PM PDT

criticalImpact confirmed

Evidence-grounded assessment

Likely same operation

The three immutable incident threads are best explained as one likely operation, while remaining separate incidents. The primary thread records sustained HTTP command-injection activity and confirmed root-level execution across the case window ([redacted]). Two process-only threads then record repeated shell and discovery execution in protected workloads during the same interval ([redacted], [redacted]). Each process thread has a high-confidence shared-workload/time-window link to the primary thread ([redacted], [redacted]). This supports a coherent possible progression from attempted web command injection to root shell and discovery activity across two workload contexts, but no unique HTTP-request-to-process edge or common actor identity is established.

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
  • System discovery
  • System information disclosure
  • Workload discovery process spawned
  • Workload root shell
  • Remote command execution as UID 0/root was proven on the responding workload.
  • Process identity, kernel, and operating-system release information were disclosed through command output.
  • Root shell and discovery processes were observed in correlated workload windows.
  • Root process telemetry recorded sensitive-target activity and operations involving an inventory-resolved shared resource.
  • No host escape, persistence, lateral movement, command-and-control, or data theft was proven.
  • Eight root-context dash shell processes were observed in the protected workload.
  • Five root-context env processes classified as discovery were observed as direct children of corresponding shells.
  • The eight correlated shell lifecycles exited with zero status; no additional security impact is established by the bounded evidence.
  • Ten shell processes were observed executing with root privileges inside the workload.
  • The cited shell processes subsequently exited with zero outcomes; no enduring process impact is demonstrated.
  • No evidence provided establishes persistence, host escape, lateral movement, command-and-control, or data theft.

Recommended actions

  1. Preserve and review application, reverse-proxy, and distributed-trace records for the 02:47-03:05Z interval to test request-to-process causality for incident [redacted] and links [redacted] and [redacted].
  2. Validate the executable, image role, authorization context, and expected behavior of the stable parent processes associated with incidents [redacted] and [redacted].
  3. Contain or isolate the affected workload instances represented by incidents [redacted], [redacted], and [redacted] if operationally safe, while preserving volatile evidence.
  4. Review network telemetry for the affected workloads during the incident window to determine whether network-client execution in incident [redacted] produced actual connections or data transfer.
  5. Identify the sensitive files and shared resources touched in incident [redacted]; rotate potentially exposed credentials or secrets based on confirmed access rather than capability classification alone.
  6. Hunt for the same parent-child process patterns and timing sequence outside incidents [redacted] and [redacted] to determine whether the episode affected additional workloads.

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 independently supports a true compromise: exploit-shaped HTTP requests received non-reflected command output identifying UID 0/root, with repeated identity output and later kernel/OS-release output. A 400 response does not negate execution because the response itself contained server-generated command results. Event-driven process telemetry also observed root shell and discovery lineages in correlated workload windows, plus sensitive-target and shared-resource activity. Request-to-process causality is not uniquely traced, so those process consequences are corroborative rather than attributed to a specific request. No cited flow evidence was available to prove an outbound connection, command-and-control, or exfiltration.

  2. 2
    Suspicious activityopen

    Verified process telemetry shows repeated root-context dash execution in one processor workload, including five dash-to-env parent/child pairs, followed by zero-status exits. The stable parent, repeated pattern, short lifetimes, and clean exits are compatible with an intentional workload task, health/diagnostic routine, or administrative automation; they do not by themselves prove exploitation. Conversely, root shell execution and environment discovery could be unauthorized. No request origin, actor attribution, command arguments, authorization context, or decision-relevant network consequence is available, so compromise cannot be confirmed or ruled out. The detector's critical suspicious-activity output is therefore preserved, but the investigative verdict is indeterminate.

  3. 3
    Suspicious activityopen

    Process telemetry confirms repeated, short-lived root shell execution in the protected image-host workload, including nested dash/bash chains. Exact lifecycle evidence shows the cited processes exited with zero outcomes. However, the incident contains no correlated HTTP or flow evidence, and the available argument-free process summaries do not reveal commands, initiating action, or actor. The detector's critical suspicious-activity result is therefore supported as an observation of root shell spawning, but the evidence is insufficient to determine whether this was exploitation or expected workload/administrative automation.

Relationship reasoning

Shared workload time window90%

shared protected workload attribution and temporal proximity

Shared workload time window90%

shared protected workload attribution and temporal proximity