Back to cases

Live public case

Observed workload execution

Last activity Aug 30, 6:38:50 PM PDT

criticalComplete

Evidence-grounded assessment

Likely same operation

The two immutable incident threads are best explained as parts of one likely operation: an HTTP-side sequence of broad unauthenticated enumeration followed by confirmed root-context command execution and system discovery, then a closely timed process-only sequence of additional root shells, discovery, and a sensitive-file access command in the same protected workload [redacted]. This is not assessed as definitively the same operation because the deterministic link establishes only workload attribution and temporal proximity, not a unique request-to-process causal edge or common actor [redacted]. Incident boundaries and detector conclusions remain unchanged.

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

Observed impact

  • Correlated process exited
  • Sensitive file access command observed
  • Server identity disclosure
  • Shell spawned
  • System information disclosure
  • Workload discovery process spawned
  • Workload root shell
  • Server-side shell and identity-discovery processes executed as root in the affected workload.
  • HTTP responses disclosed root/UID 0 identity information and kernel identification.
  • The exposed service was subjected to broad route and HTTP-method enumeration.
  • Root-run shell processes executed inside the protected workload ([redacted]; [redacted]).
  • A root-run cat process classified as a sensitive-file tool with a sensitive target was spawned as a child of a shell ([redacted]; [redacted]).
  • Observed cited shell lifecycles were short-lived and exited zero; no persistence is established ([redacted]; [redacted]).

Recommended actions

  1. Preserve both incident boundaries and seek request, application, and process trace identifiers that could establish or refute a unique HTTP-to-process edge.
  2. Review workload and orchestrator audit records for the full case window to identify the initiator of the process-only executions and any related administrative activity.
  3. Confirm whether the enumeration and command execution were part of an authorized test; if not, treat the workload as potentially compromised and consider isolation and clean redeployment under the response plan.
  4. Review access to sensitive files, secrets, workload changes, and outbound network telemetry around the window; absence of current evidence should not be treated as proof that these effects did not occur.
  5. Address the root-context command-execution path and reduce workload privilege after preserving relevant evidence.

Attack timeline

2 incident threads

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

  1. 1
    Reconnaissanceopen

    Verified HTTP evidence shows non-reflected root identity output and kernel identification returned by the server, despite HTTP 400 responses. Event-driven process telemetry independently observed root-run dash shells and an id child in the correlated workload during those response windows, followed by zero-result lifecycle exits. Together, this establishes real server-side command execution and discovery, not reconnaissance alone. The HTTP-to-process edge remains temporal/workload correlation rather than unique request causality, and no incident-cited flow evidence was available to assess network follow-on activity.

  2. 2
    Suspicious activityopen

    Likely true positive for suspicious in-workload command execution, but not proof of remote exploitation or compromise. Event-driven process telemetry shows repeated root-run dash shells in one workload, including discovery activity and a root-run cat process classified as targeting a sensitive file (process evidence [redacted], [redacted], [redacted], [redacted], [redacted], and [redacted]). The first and latest cited shells exited successfully, indicating short-lived execution rather than persistence ([redacted] and [redacted]). No HTTP or flow evidence reference is available in this incident, so the trigger, actor, authorization, and any network consequence remain unknown.

Relationship reasoning

Shared workload time window90%

shared protected workload attribution and temporal proximity