Back to cases

Live public case

Observed workload execution

Last activity Aug 20, 1:56:07 PM PDT

criticalComplete

Evidence-grounded assessment

Likely same operation

The strongest defensible explanation is a likely single operation spanning HTTP reconnaissance/exploit attempts and subsequent or overlapping process activity, while preserving all four incident boundaries. Incident [redacted] records sustained surface enumeration and injection-associated requests; incidents [redacted], [redacted], and [redacted] record temporally proximate shell and related workload activity. Deterministic links [redacted] and [redacted] connect the HTTP thread to process threads by protected-workload attribution and time, while [redacted] strongly connects two process threads to the same workload. This is coherent with one progression, but not conclusive: no incident provides a unique HTTP-request-to-process trace edge, one process thread belongs to a distinct workload cluster, and actor identity and authorization remain unresolved.

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

Observed impact

  • Correlated process exited
  • Outbound client spawned
  • Sensitive file access command observed
  • Shared resource access observed
  • Shared resource execution observed
  • Shared resource mutation observed
  • Shell spawned
  • Workload discovery process spawned
  • Workload root shell
  • Root-run shell execution was observed in the processor workload ([redacted]).
  • A root-run whoami discovery process executed and exited successfully ([redacted]; [redacted]).
  • Root shell/head process chains targeted sensitive files; successful data access or disclosure was not established ([redacted]; [redacted]).
  • Network-client-class shell processes were spawned, but no socket connection or egress consequence was established ([redacted]).
  • Root-context shell execution occurred inside the protected processor workload.
  • A root-context shell command was classified as targeting a sensitive file; the specific access outcome is not established.
  • Processes executed, accessed, and mutated the same shared resource, creating potential integrity impact; the resulting content change and dependent-workload effects are unknown.
  • Outbound-capable shell processes were spawned, but no actual connection, command-and-control, or exfiltration was established.
  • At least one observed shell lifecycle exited successfully; this proves process completion, not request causality or overall attack success.
  • Root dash shells and root id discovery executed in the protected workload ([redacted]; [redacted]).
  • Mutation, access, and execution involved shared resource [redacted] ([redacted]; [redacted]).
  • The first observed shell exited with a zero outcome; this establishes termination only, not benign intent ([redacted]).
  • No downstream impact to other attached workloads, persistence, host escape, lateral movement, command-and-control, or data theft is established by the cited evidence.
  • Root shell execution occurred inside the processor workload.
  • An inventory-resolved shared resource was accessed and mutated, creating potential integrity risk for workloads attached to that resource.
  • Observed shell and child processes exited; no persistence, host escape, lateral movement, command-and-control, or data theft was established.

Recommended actions

  1. Preserve the four incident boundaries and seek workload audit, deployment, and authorization records covering the observed interval to distinguish expected activity from unauthorized execution [redacted].
  2. Prioritize obtaining an application or distributed-tracing correlation edge between the injection-associated HTTP events and process executions; do not infer that edge solely from links [redacted] or [redacted].
  3. Review the shared resource identified in the process incidents for authorized mutation, access, and execution, and compare activity across both workload clusters [redacted].
  4. Validate whether repeated shell invocation, root-shell context, sensitive-file-access commands, and outbound-client spawning are expected for the affected workload before taking containment action [redacted].

Attack timeline

4 incident threads

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

  1. 1
    Attempted exploitationopen

    Likely genuine command-injection exploitation activity. Multiple HTTP requests carried shell metacharacters and command tokens, while root-run dash shells and child discovery commands were observed in the routed workload during the same narrow windows (HTTP [redacted]; process [redacted] and [redacted]). A whoami child completed successfully, and later root shell/head chains targeted sensitive files. This strongly supports execution in the workload, but the evidence supplies only workload/time correlation—not a unique request-to-process trace edge. Authorization is unknown, and no cited flow evidence establishes actual outbound communication.

  2. 2
    Suspicious activityopen

    Likely true positive for suspicious post-start execution inside the processor workload, but not proof of an external exploit or actor identity. Verified telemetry shows repeated event-driven, root-context dash execution, a shell classified as targeting a sensitive file, execution/access/mutation involving the same shared resource, and outbound-capable shell processes [redacted]. This combination is materially suspicious, although the evidence cannot determine whether it was authorized processor behavior. No incident-cited HTTP or flow event was available to establish an initiating request or an actual network connection.

  3. 3
    Suspicious activityopen

    Verified event-driven process telemetry substantiates the detector’s core observations: root-run dash shells spawned, root-run id discovery occurred as a shell child, and later root-run activity mutated, accessed, and executed an inventory-resolved shared resource (process evidence [redacted], [redacted], [redacted], [redacted], [redacted]; inventory evidence [redacted]). This is materially suspicious and has potential cross-workload relevance. However, the incident cites no HTTP or flow-plane events, and the bounded process summaries do not provide command arguments, authorization context, or a malicious causality edge. Because an image-host may legitimately use root shells and shared resources, the evidence cannot currently distinguish compromise from expected automation or administration.

  4. 4
    Suspicious activityopen

    Verified process telemetry supports a real suspicious execution sequence in the protected processor workload: event-driven root dash shells repeatedly ran, and associated activity accessed and mutated an inventory-resolved shared resource. The observed processes were short-lived and exited successfully, but successful exit does not make the activity benign. The available evidence does not identify the initiating actor or action, and no cited HTTP or flow events are available to establish a remote exploit, request-to-process causality, or network consequences. This is therefore likely a true positive for unauthorized or anomalous workload execution and shared-resource modification, not proof of broader compromise.

Relationship reasoning

Shared workload time window90%

shared protected workload attribution and temporal proximity

Shared workload time window90%

shared protected workload attribution and temporal proximity

Same workload97%

same protected workload identity within a short bounded continuity window