Confirmed compromise

The immutable detector output remains state=confirmed/classification=confirmed_compromise for incident [redacted], and the evidence supports that verdict. HTTP requests containing command-injection behavior received non-reflected root identity and kernel output, directly proving command execution in the responding workload even though the responses were HTTP 400 (HTTP [redacted] and [redacted]). Event-driven process telemetry independently observed root shell and discovery processes in the correlated workload window (process [redacted] and [redacted]). Additional correlated activity included a network-client-class shell, a sensitive-targeting shell, and execution/access involving a shared resource. These process observations strengthen the compromise assessment but do not establish a unique HTTP-request-to-process causal edge.

The incident is behaviorally substantiated but maliciousness is not established. Event-driven telemetry shows repeated root-run dash shell executions in the processor workload, including execution/access/mutation classifications involving shared resource [redacted]. A later root-run uname discovery process adds suspicion [redacted]. Exact lifecycle evidence shows sampled shells exited, with both zero and nonzero outcomes; this proves process termination but not benign intent or request causality [redacted]. No cited HTTP or flow events were available through the bounded evidence tools, and process summaries exclude arguments, so the originating action, actor, exact commands, authorization, and network consequences remain unresolved. These could represent compromise or expected processor/administrative automation.

Likely true positive for suspicious runtime activity in the protected workload, but not proof of a specific exploit or full compromise. Verified process telemetry shows repeated root dash shells, two root shell processes classified as network clients, root shell commands targeting sensitive files, and root discovery commands [redacted]. These behaviors are materially suspicious in combination. No incident-cited HTTP or flow event was available to establish an initiating request or actual outbound connection, and legitimate automation remains possible.

Verified process telemetry shows repeated event-driven `dash` shell executions as root in one protected workload, with a common observed parent PID; representative events span [redacted]38Z to [redacted]06Z ([redacted], [redacted]). Matching lifecycle evidence shows sampled shells exited with outcome zero ([redacted], [redacted], [redacted]). This validates the detector's critical shell-execution observation, but not malicious causation. No cited HTTP or flow event was available to inspect, and the bounded process summaries do not expose command arguments or enough parent context to distinguish exploitation from expected processor or administrative behavior. Verdict: indeterminate pending workload-owner validation and richer lineage/command evidence.

Verified process telemetry establishes repeated event-driven, root-context shell execution in the protected workload and one root process classified as both a shell and network client. This is materially suspicious, but the bounded evidence does not establish whether the activity was authorized workload/administrative automation or malicious execution. No cited HTTP or flow-plane event was available for inspection, so there is no supported request-to-process origin or observed network connection. The incident's critical detector output is therefore not dismissed, but exploitation or compromise cannot be adjudicated from the available evidence.

Two HTTP command-injection detections were followed in the correlated processor workload by event-driven root dash executions, including a sensitive-file-targeting command. The repeated timing pattern strongly supports successful command execution, even though both HTTP responses were 400; status alone does not determine exploit success (HTTP [redacted], [redacted]; process [redacted], [redacted], [redacted]). The verdict remains “likely” rather than definitive because routing/workload and process correlation do not establish a unique request-to-process causality edge. The detector’s immutable classification is attempted_exploitation; this assessment finds likely observed execution consequences beyond the request attempts.