Back to cases

Live public case

Observed workload execution

Last activity Aug 28, 2:38:42 AM PDT

criticalComplete

Evidence-grounded assessment

Likely same operation

The two immutable incident threads are best explained as parts of one likely operation, while preserving their separate detector boundaries. The attempted-exploitation thread records repeated command-injection requests followed by root shell/discovery execution and shared-resource effects [redacted]. The process-only thread records closely preceding root shell/discovery activity in the protected workload [redacted]. Their shared protected-workload attribution and temporal proximity are explicitly represented by the deterministic relationship link [redacted]. Similar execution behavior within the same short period supports a common operational sequence, but the evidence does not establish one actor or a unique request-to-process causal edge [redacted].

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

Observed impact

  • Correlated process exited
  • Shared resource access observed
  • Shared resource execution observed
  • Shared resource mutation observed
  • Shell spawned
  • Workload discovery process spawned
  • Workload root shell
  • Root shell and discovery processes were observed in the processor workload ([redacted], [redacted]).
  • Shared resource [redacted] was observed mutated in one workload and executed by a root shell in another ([redacted], [redacted]).
  • The correlated processor processes later exited with zero outcomes; this does not undo or disprove the preceding activity ([redacted], [redacted]).
  • Two root shell executions and root discovery-process executions occurred in the workload [redacted].
  • The second process chain recorded mutation and access involving shared resource [redacted], which inventory attributed as shared across workloads [[redacted], [redacted], 668
  • Observed shell/discovery lifecycles ended: the first shell had a nonzero outcome, while the second shell and its child had zero outcomes [redacted].

Recommended actions

  1. Preserve both incident boundaries and investigate them as a likely related sequence, prioritizing the 09:27–09:39 window across the linked workloads [redacted].
  2. Validate the stable process parent, scheduler or service context, and authorization of the repeated root dash/discovery executions [redacted].
  3. Review available application, orchestration, and workload audit records for a traceable link between the three suspicious requests and the observed processor executions [redacted].
  4. Determine the shared resource's contents, expected owners, mutation history, and execution purpose across both workload contexts [redacted].
  5. If the root shells or shared-resource changes are unauthorized, contain the affected workloads and rotate credentials accessible to them according to established response procedures [redacted].

Attack timeline

2 incident threads

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

  1. 1
    Attempted exploitationopen

    Likely successful command-injection exploitation, not merely an attempt. Three HTTP events from the same derived source cluster contained shell metacharacters and command tokens; the last was followed about 281 ms later by an event-driven root dash exec in the correlated processor workload, with a root discovery child. The processor-side lineage mutated shared resource [redacted]; shortly afterward, root dash processes in a different workload mutated and executed that same resource. This sequence is highly suspicious and supports actual workload command execution and shared-resource impact. However, correlation is based on routing/workload affinity and time proximity rather than a unique request-to-process trace, so the initiating HTTP request cannot be proven as the sole cause. The incident remains detector-classified as attempted_exploitation/open; this assessment elevates the likely observed consequence while preserving that causality limitation. No flow evidence is cited by the incident, so outbound network consequences are not established.

  2. 2
    Suspicious activityopen

    The underlying process activity is verified: two event-driven root dash executions from the same parent occurred about 63 seconds apart in the same workload, each followed by a root env-classified discovery child [redacted]. The second chain recorded mutation/access against inventory-resolved shared resource [redacted]. However, no cited HTTP or flow evidence is available, process summaries expose no arguments, and the stable parent plus repeated pattern can fit either unauthorized execution or a legitimate recurring workload task. Therefore the observed execution and resource activity are real, but malicious exploitation or compromise cannot be adjudicated from the available evidence.

Relationship reasoning

Shared workload time window90%

shared protected workload attribution and temporal proximity