Confirmed compromise

True positive. HTTP events [redacted] and [redacted] contained command-injection indicators and returned non-reflected uid=0/root process-identity output, proving root-level command execution in the responding workload even though the responses were HTTP 400. Process events [redacted] and [redacted] independently show a root dash shell followed by root id execution. Root processes also performed shared-resource mutation/access and sensitive-file-targeting activity. A processor-attributed outbound TCP flow to a private, remote-shell-class destination was observed, but it is not a proven request-to-socket or process-to-socket edge. The evidence does not establish host escape, persistence, lateral movement, command-and-control, or data theft.

Verified process telemetry establishes repeated security-relevant execution inside the protected processor workload: root-run dash shells, processes classified as outbound-capable clients, discovery execution, sensitive-targeting shells, and access/mutation of the same shared resource. This warrants urgent investigation. However, the available evidence does not identify the initiating actor or action, establish that the behavior was unauthorized, or distinguish compromise from expected processor/administrative activity. No incident-cited HTTP or flow event was available to the corresponding evidence tools, so there is no supported HTTP-to-process or process-to-network causality claim. The incident therefore remains indeterminate rather than a confirmed compromise or a false positive.

Verified process telemetry establishes real root-level shell execution and repeated root `cat` executions classified as targeting sensitive files in the protected image-host workload [redacted]. It also records a root shell executing from an inventory-resolved shared resource [redacted]. These are material workload consequences, but the bounded evidence does not identify the initiating actor or action, expose arguments or exact file targets, or correlate any HTTP request. No incident-cited HTTP or flow event IDs were available for verification. The same stable parent and short-lived, zero-exit shells are compatible with either automated workload/administrative behavior or unauthorized execution. Maliciousness therefore cannot be adjudicated from the available evidence.

Likely unauthorized execution and discovery inside the protected processor workload. Event-driven telemetry directly observed multiple dash shell executions as root, including activity recurring from 02:15 through at least 02:40 (process evidence [redacted], [redacted], and [redacted]). A root dash process also spawned root id and uname discovery processes ([redacted], [redacted], and [redacted]). This pattern is suspicious enough for a likely true positive, but process summaries omit arguments and do not establish whether the activity was authorized or how it originated. No HTTP or flow references are available in the incident, so exploitation, request causality, and network consequences remain unproven.

Verified process telemetry shows three short-lived root executions of the dash shell in the same workload, all sharing the same parent PID and each followed by a zero-outcome exit. This establishes shell execution but not malicious exploitation. The incident contains no correlated HTTP evidence, and no incident-cited flow evidence was available; command arguments, parent identity, initiating actor/action, and authorization context are therefore unresolved. The detector's critical suspicious-activity output is preserved, but the available evidence cannot distinguish compromise from legitimate workload or administrative behavior.

Successful command execution is observed, not merely attempted. Multiple HTTP responses contained non-reflected process-identity output identifying uid 0/root, including in HTTP 400 responses; status therefore does not negate execution. Event-driven process telemetry independently shows root dash shells spawning identity and host-discovery utilities in temporally correlated workloads. The incident is a true positive for command injection leading to root-context command execution and discovery. However, workload/time correlation is not a unique request-to-process edge, and no incident-cited flow evidence was available to establish an outbound connection or request-to-socket causality.

Likely true positive for unauthorized or otherwise security-relevant execution inside the workload. Event-driven telemetry shows repeated root-run dash shells, including shells classified as targeting sensitive files, plus execution/access involving an inventory-resolved shared resource and subsequent discovery activity [redacted]. Exact lifecycle evidence shows sampled processes exited, mostly successfully; this does not negate the observed executions [redacted]. No cited HTTP or flow event is available to establish an originating request, actor, or outbound consequence, so exploitation causality and broader compromise remain unproven.

Indeterminate. Verified event-driven telemetry shows root-run dash executions in one protected workload, including a discovery-class shell [redacted] and a sensitive-target shell [redacted], plus access to an inventory-resolved shared resource [redacted]. Exact sampled exec/exit joins show short-lived processes terminating, including zero and nonzero outcomes [redacted]. The evidence establishes suspicious execution and resource access, but not malicious causation or intent. No HTTP or flow event is cited, while the argument-free process summaries do not reveal exact commands or authorization context; legitimate image-host or administrative activity remains plausible.