Evidence

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

Request contains shell metacharacters and command tokens

Broad unauthenticated route and HTTP method enumeration observed

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

This is a true positive for opportunistic reconnaissance/web-shell path enumeration against target privatekind, not a confirmed compromise. Verified HTTP summaries show rapid, bodyless GET requests categorized as PHP or WordPress probes from the same source traffic cluster. The sampled responses were redirects or not-found responses with no server-generated command output. The incident cites no process- or flow-plane event IDs, so the available evidence does not establish command execution, outbound communication, persistence, or other post-exploitation impact.

The incident is most consistent with automated reconnaissance followed by a genuine command-injection attempt against target privatekind. The injection-marked PUT carried shell metacharacters and command tokens and received HTTP 200, but its response body was empty; status alone does not establish execution (HTTP [redacted]). Representative later probes used POST against API-category paths and received 404 responses (HTTP [redacted] and [redacted]). No cited process or flow evidence was available to establish command execution or follow-on network activity. The verdict remains “likely” rather than definitive because authorization is unknown and the source key is a traffic cluster rather than a verified actor identity.

The detector's critical suspicious-activity output is supported at the consequence level: event-driven telemetry observed a root-context dash shell in the processor workload and a root-context child id discovery process, followed by zero-result exits. However, the available evidence does not establish whether this execution was malicious, authorized workload behavior, or administrative/testing activity. No incident-cited HTTP or flow evidence was available to establish an originating request, actor, request-to-process causal edge, or network consequence. Therefore, execution and discovery are confirmed, while exploitation or compromise remains indeterminate.

This is a true-positive opportunistic reconnaissance event: the source traffic cluster rapidly issued repeated GET requests categorized as PHP/WordPress probes against target privatekind. The detector aggregate records 37 requests across 20 unique probe paths in about 4.4 seconds. Available HTTP evidence shows redirect/rejection outcomes (301 and 404), with no server-generated command output in the inspected summaries. The evidence supports web-shell path enumeration, but not successful exploitation or compromise.

The incident is a true positive for opportunistic PHP/WordPress web-shell path enumeration against target privatekind. The detector recorded 39 requests across 20 probe paths in roughly 4.3 seconds, and the inspected HTTP evidence confirms repeated GET requests categorized as php_or_wordpress_probe from one derived source cluster [http:[redacted]; http:[redacted]; http:[redacted]; http:[redacted]]. Inspected responses were redirects or 404 rejections; this supports detection of scanning but, because HTTP status alone is not dispositive, does not prove exploit failure. No cited process or flow evidence was available to establish execution or network consequences.

This is a true positive for opportunistic PHP/WordPress web-shell path enumeration, not for successful exploitation. The deterministic detector recorded 41 requests against 20 probe paths in roughly 4.7 seconds. The retained HTTP summaries consistently classify the requests as PHP/WordPress probes from one traffic cluster to target privatekind and show only 301 redirects or 404 responses. No cited process or flow evidence is available to establish command execution, persistence, outbound activity, or other compromise consequences.

A captured POST request triggered the immutable high-confidence command-injection-attempt detector for shell metacharacters with command tokens. The request received HTTP 301 with an empty response body, which neither proves nor disproves execution. No process or flow evidence is cited by this incident, so observed command execution or downstream network activity cannot be established. Evidence: HTTP event [redacted] (SHA-256 [redacted]).

The incident is best assessed as likely true-positive application-surface reconnaissance. The detector aggregated 64 requests from one traffic/workload cluster across 51 unique paths, five HTTP methods, and six path categories, with 53 rejected responses. The verified samples show rapid requests to distinct route hashes, mixed GET/POST usage, and repeated 401/422 responses, consistent with automated route and method enumeration. Two sampled requests returned HTTP 200, but status alone does not establish exploitation or compromise. Authorization is unknown, so sanctioned security testing or inventory remains a plausible alternative. No process or flow evidence is cited by this incident, so no execution, outbound consequence, persistence, lateral movement, or data loss is established.

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.

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.

The alert accurately identifies a rapid, opportunistic enumeration campaign against PHP/WordPress web-shell-style paths. The verified HTTP samples are bodyless GET probes assigned to the php_or_wordpress_probe category, use multiple distinct path hashes, and span roughly 5.34 seconds. Sampled outcomes are redirects or not-found responses; they establish reconnaissance but not exploitation or compromise. No process- or flow-plane event references are available in this incident to assess downstream execution or network consequences.

The incident is strongly consistent with real opportunistic PHP/WordPress web-shell path enumeration against target privatekind. Verified HTTP summaries show rapid GET requests categorized as PHP/WordPress probes from the same source cluster, with distinct path hashes and rejection/redirect outcomes. The available responses include 404s and a 301; these support unsuccessful discovery attempts but, by themselves, do not prove that every request failed to trigger application behavior. No process or flow evidence is cited by this incident, so there is no evidence-grounded basis to claim command execution, outbound activity, persistence, or compromise. The verdict therefore affirms the scanning activity, not successful exploitation.

Likely true positive for automated HTTP reconnaissance against target privatekind. The cited HTTP sequence supports rapid, broad, unauthenticated surface enumeration: the detector aggregated 64 requests to 64 unique paths across two methods and seven path categories in roughly 2.74 seconds, with 52 rejected responses. Verified examples have distinct path hashes, complete captures, empty request bodies, and mostly uniform 404 responses; the root request returned 200. This establishes probing behavior, not exploit success. Authorization is unknown, and no process or flow evidence is cited by the incident, so no workload compromise or follow-on network consequence is established.

Likely true positive command-injection exploitation with workload-level execution. Multiple HTTP requests were classified as containing shell metacharacters and command tokens, and root-context dash processes appeared tens of milliseconds later in the correlated processor workload. The strongest examples include dash spawning the discovery utilities id and uname as direct children. This repeated request/exec pattern strongly supports successful command execution, although routing affinity and temporal correlation do not provide a unique per-request causality edge. No cited flow evidence was available, so outbound communication, command-and-control, and exfiltration are not established.

Process telemetry conclusively shows repeated root-level dash execution in the processor workload, including discovery-classified shells and a final root dash→id parent-child chain [redacted]. Exact PID-matched lifecycle evidence also shows sampled shells exiting, generally successfully [redacted]. These are real execution consequences, but the bounded evidence does not establish whether they were authorized processor behavior or malicious activity. No usable HTTP or flow evidence was cited, so initial access, actor, request causality, network consequences, and compromise cannot be determined.

True positive confirmed compromise: captured exploit/response evidence shows command-oriented input followed by non-reflected root identity and kernel output in the responding workload, despite HTTP 400 [[redacted]; [redacted]]. Event-driven telemetry independently observed root shells and discovery processes in the correlated workload [redacted]. The detector's immutable state is confirmed, and the inspected evidence supports that result. Later sensitive-target and network-client-class processes increase concern, but request-to-process and request-to-socket causality remain unproven [redacted].

Three event-driven process records confirm root-context `dash` shell executions in the same workload, all with parent PID 2212455 [redacted]. Matching lifecycle records show all three PIDs subsequently exited with outcome zero [redacted]. This proves shell execution inside the workload, but the available argument-free summaries do not identify the commands or actor. No HTTP or flow evidence IDs are cited by the incident, so exploitation and network consequences cannot be established. The behavior could represent malicious execution or legitimate processor/administrative activity.

The incident is a true positive for opportunistic PHP/WordPress web-shell path enumeration, not for successful exploitation. The detector aggregated 39 requests across 20 probe paths in roughly 4.3 seconds. Verified HTTP summaries identify sampled requests as GETs in the php_or_wordpress_probe category; the first returned a 301 with an empty response body and the next returned a 404. The incident's cited HTTP evidence records only redirects or rejections, with no observed exploit consequence. No process or flow evidence references were available in this incident, so execution, outbound activity, and compromise cannot be determined from those planes.

The evidence supports a real, sustained web-surface enumeration pattern against target privatekind: the detector-derived facts report 1,205 requests over 512 connections, 128 unique paths, four methods, and eight path categories. Verified HTTP samples from the cited cluster show requests to multiple path hashes/categories with mixed 200, 400, 403, and 404 responses, consistent with route probing. This is best assessed as likely true-positive reconnaissance, not confirmed compromise. Authorization and intent remain unresolved, and the incident contains a material semantic inconsistency: its summary calls the activity unauthenticated while its own facts count 1,057 authenticated requests. No process- or flow-plane evidence is cited, so execution, persistence, outbound activity, or other post-reconnaissance consequences are not established.

The incident is a true positive for opportunistic reconnaissance: one derived source cluster rapidly issued 39 GET requests covering 20 distinct PHP/WordPress probe paths against target privatekind between [redacted].030Z and [redacted].351Z. Representative complete captures returned redirects or rejections, including 301 and 404 responses (HTTP evidence [redacted], [redacted], and [redacted]). This establishes scanning/enumeration, but the available evidence does not establish web-shell access, command execution, persistence, or outbound activity.

This is a true positive for opportunistic reconnaissance: the detector aggregated 39 rapid GET requests across 20 PHP/WordPress probe paths from one derived traffic cluster. The verified HTTP summaries show capture-complete probe requests receiving redirects or rejections, including 301 and 404 responses. The evidence supports web-shell path enumeration, but not successful exploitation or compromise. No process or flow evidence is cited by this incident, and HTTP status alone cannot establish exploit failure, so execution and network consequences remain unproven rather than ruled out.

This is a true positive for rapid opportunistic reconnaissance, not confirmed exploitation. The detector recorded 39 requests across 20 PHP/WordPress probe paths in about 4.3 seconds, and the bounded HTTP summaries show representative GET probes receiving 301 redirects or 404 rejections. The derived detector outcome remains redirect_or_rejection_only. There is no cited process or flow evidence with which to establish command execution, outbound activity, or any request-to-consequence causal edge.

The incident is strongly supported as web-surface reconnaissance. The detector aggregated 58 unauthenticated requests across 32 unique paths, two methods, and eight path categories from one derived source cluster, with 32 rejected responses (HTTP evidence set [redacted] through [redacted]). Verified samples corroborate a rapid sequence of empty-body GET probes against distinct path hashes: the root returned 200, while several subsequent routes returned 404. This supports route enumeration but does not establish exploit execution or compromise. Authorization and the real actor behind the source cluster remain unknown.

True positive: HTTP evidence proves successful command injection and root-level command execution in the responding workload, even though the responses were HTTP 400. The strongest event contains shell-command input and non-reflected process-identity output identifying UID 0 ([redacted]); another response disclosed non-reflected kernel information ([redacted]). Event-driven process telemetry independently shows root shells and discovery commands in the correlated workload, followed by sensitive-target and shared-resource activity. The detector's confirmed state and confirmed-compromise classification are therefore supported. Process timing does not establish a unique request-to-process edge, and no cited flow evidence was available to assess outbound consequences.

Verified process telemetry shows a repeated pattern of root-run dash executions in one processor workload, including a discovery-classified shell and a two-process parent/child chain classified as both shell and network client. The first verified shell has a matching exit event moments later. This substantiates the detector's suspicious execution findings (process refs [redacted], [redacted], [redacted], and [redacted]). However, the bounded evidence does not establish malicious intent, an originating HTTP request, or any actual outbound connection. The verdict is therefore likely true positive for suspicious workload execution, not confirmed exploitation or compromise.

Confirmed remote command injection with successful root-level execution in the responding application workload. Non-reflected process-identity and kernel output in HTTP responses proves execution even though the responses were HTTP 400. Event-driven process telemetry independently shows root-run dash shells spawning id, uname, and hostname in matching windows. A public-web outbound flow was also observed from an inventory-attributed media-edge workload, but it is not causally linked to the requests or processor command execution. The detector's immutable state is confirmed and is consistent with the evidence.

This is likely a true positive for repeated attempted exploitation, not proof of successful command execution. Two captured PUT requests to target privatekind, five minutes apart and associated with the same derived source cluster, each triggered the high-severity command-injection-attempt detector for shell metacharacters with command tokens [[redacted]; [redacted]]. The incident further attributes the second request to targeting an application environment file [[redacted]]. Both requests received HTTP 200 with empty response bodies, but status alone does not establish execution. No cited process or flow events were available to validate a workload consequence or outbound activity.

Real process activity is confirmed, but malicious intent or compromise is not. Event-driven telemetry directly observed root-run dash shells in the processor workload, including repeated shells from the same parent lineage. An exact lifecycle record shows one observed shell exited successfully. Separate root-run processes accessed a shared resource. However, no HTTP or flow evidence is cited, and the bounded summaries do not expose command arguments, resource contents, or an initiating actor. The short-lived, repeated shell pattern could be normal worker or administrative activity. Exploitation, persistence, host escape, lateral movement, command-and-control, and data theft are not established.

Likely true positive for suspicious workload-level execution, but not a proven externally initiated exploit. Event-driven telemetry directly observed repeated root-run dash shells, discovery activity, a sensitive-file-targeting shell, and execution from an inventory-resolved shared resource in the same workload context [redacted]. The repeated common parent PID may indicate an application service or administrative automation rather than a remote actor, and no HTTP or flow evidence was available to establish origin, request-to-process causality, or network consequences. At least one observed shell had an exact exit event with a zero outcome; that establishes process completion only, not benign intent or exploit causality [redacted].

The immutable detector state is confirmed, and the evidence supports that conclusion. A command-injection request returned non-reflected root/UID 0 process output and kernel identification in the same captured HTTP transaction, proving command execution despite HTTP 400 (HTTP [redacted]). A separate injection request returned non-reflected OS-release and kernel data (HTTP [redacted]). Event-driven process telemetry also observed a root dash shell spawning id and later root processes targeting a sensitive resource and performing mutation, execution, and access operations. HTTP-to-process attribution remains temporal/workload-based rather than a unique causality edge. No cited flow event was available, so outbound communication, C2, or exfiltration is not established.

The incident is a true positive for attempted command injection, not confirmed compromise. The verified HTTP event records a POST whose request content triggered the command-injection detector for shell metacharacters with command tokens and identified the targeted resource as the system account database [redacted]. The transaction returned HTTP 200 with a 1,389-byte response, but status and response size do not establish command execution or disclosure [redacted]. No cited process or flow event is available to verify downstream consequences.

Likely true positive for suspicious root-level workload activity, but not proof of remote exploitation. Event-driven process telemetry recorded a root dash shell and child shell, repeated root discovery-class env executions, and a root process associated with mutation of an inventory-resolved shared resource [redacted]. The first two shells exited successfully within milliseconds [redacted]. Attribution and intent remain unresolved because no correlated HTTP evidence or cited flow evidence is available and exact arguments are excluded from the summaries.

The incident reflects real, high-risk process activity in the protected image-host workload: root-run dash shells, a root cat child classified as targeting a sensitive file, and a root shell associated with mutation of an inventory-resolved shared resource. Exact lifecycle evidence also shows sampled shells exited, with both zero and nonzero outcomes. However, the available evidence does not establish who initiated the activity, whether it was authorized workload/administrative behavior, or whether exploitation occurred. No HTTP request is cited as correlated, and no cited flow evidence is available to assess network consequences. Escalation and workload-owner validation are warranted, but compromise cannot be adjudicated from these process observations alone.

The detector's immutable state is confirmed, and this assessment agrees. Repeated injection-shaped requests produced non-reflected server identity and kernel output showing UID 0/root execution on the responding workload, including in HTTP 400 responses; the status codes do not negate execution [redacted]. Event-driven telemetry also observed root shells, discovery commands, sensitive-file targeting, and operations on an inventory-resolved shared resource [redacted]. HTTP-to-process causality remains temporal/workload-based rather than a unique trace edge, so the verdict proves RCE in the responding workload but not host escape, persistence, lateral movement, C2, or exfiltration.

Likely true positive for suspicious root-context execution inside the protected processor workload. Verified process telemetry shows a root dash shell spawning root discovery activity, followed later by repeated root shells classified as targeting sensitive files and additional discovery execution. Exact lifecycle evidence shows several processes exited, including zero exits, but that proves only process completion—not successful sensitive-data access or malicious intent. No HTTP- or flow-plane evidence reference was available to establish the originating action, actor, request causality, or network consequence.

The incident is likely a true positive for suspicious command execution inside the protected workload. Event-driven telemetry independently observed repeated root-run dash shells, discovery-classified shell executions, and root-run cat processes targeting sensitive files. This is materially stronger than a payload-only alert, although maliciousness and initial access are not proven: no usable HTTP or flow evidence is cited, command arguments and file identities are unavailable, and legitimate administrative or workload activity remains possible.

The detector's immutable state is confirmed with classification confirmed_compromise, and the evidence supports that result: an exploit request/response exchange returned non-reflected process identity output showing root/UID 0, proving command execution in the responding workload despite HTTP 400. Root shell and discovery executions, sensitive-file-targeting commands, and outbound-capable process activity were also observed in correlated workload/time windows. The evidence does not establish host escape, persistence, data theft, or actual outbound socket activity.

The detector's critical suspicious-activity output is supported at the process-observation level: event-driven root `dash` executions occurred repeatedly, one was classified as both a shell and network client, and later root processes executed/accessed inventory-resolved shared resource [redacted] (process evidence [redacted], [redacted], [redacted], [redacted], [redacted], [redacted]; inventory evidence [redacted]). However, the bounded evidence exposes neither command arguments/content nor a causal originating action. No incident-cited HTTP or flow event was available to establish exploitation or an outbound connection. The same observations could reflect unauthorized execution or legitimate processor/administrative behavior, so compromise cannot be adjudicated from the available evidence.

The bounded HTTP evidence supports the detector's reconnaissance classification: one source cluster sent varied HEAD, GET, and POST requests across root, API, and other route categories on target privatekind during the cited interval [redacted]. Responses varied among 200, 401, 404, 422, and 500, and several GETs returned sizable bodies, indicating that some probed resources responded with content [redacted]. This is strong evidence of surface enumeration, but authorization and operator identity are unknown. No cited process or flow events were available to assess consequences beyond HTTP reconnaissance.

The incident is a true positive for rapid automated PHP/WordPress web-shell path enumeration, not for confirmed compromise. The detector grouped 39 requests across 20 unique probe paths in approximately 4.27 seconds. Retrieved representative requests are categorized as php_or_wordpress_probe and returned only 301 or 404 responses. Those status codes do not by themselves prove exploit failure, but the available evidence contains no process or flow references with which to establish execution, outbound activity, persistence, or data access.

The incident is a true positive for opportunistic reconnaissance: the traffic cluster rapidly issued GET requests categorized as PHP or WordPress probes against target privatekind, and the detector aggregated 38 requests spanning 20 unique probe paths. The cited HTTP outcomes were redirects or rejections, so this establishes web-shell path enumeration but not successful exploitation. No process or flow evidence is cited by the incident, leaving execution and downstream network consequences unproven.

The incident is a true positive for rapid opportunistic enumeration of PHP/WordPress web-shell paths against target privatekind. The detector reports 38 requests over roughly 7.7 seconds and 20 unique probe paths; the verified cited samples are bodyless GET requests categorized as PHP/WordPress probes and received only 301 or 404 responses. This establishes hostile or unauthorized reconnaissance behavior, but not successful exploitation or compromise. No process or flow evidence is cited by the incident, so execution, outbound communication, persistence, or other post-request consequences cannot be determined from the available evidence.

The incident is strongly supported as broad, unauthenticated HTTP surface enumeration against target privatekind. The detector aggregated 75 requests across 48 unique paths, two methods, six path categories, and 46 connections from one derived source cluster; the verified samples show rapid HEAD/GET probing of distinct path hashes with mixed 200, 404, and 500 responses. Multiple 200 responses indicate that some probed routes returned content, but status codes and response sizes do not establish exploitation or sensitive-data exposure. No process- or flow-plane evidence is cited by this incident, so consequences beyond reconnaissance cannot be assessed. Because authorization and source identity are unknown, sanctioned scanning remains a material alternative.

Repeated command-injection HTTP activity was followed within the correlated windows by event-driven root shell, discovery, sensitive-target, and shared-resource process activity. The strongest sequences are: a suspicious PUT targeting the system account database followed about 2.4 seconds later by root dash and env execution [redacted], and later suspicious GETs followed within hundreds of milliseconds by root shell mutation/execution of the same shared resource and, in the final sequence, a parent-linked dash→dash→cat sensitive-target chain [redacted]. This strongly supports successful workload-level command execution, but request-to-process causality remains inferential rather than a unique trace edge. No flow-plane event was available, so no network consequence is assessed.

Three repeated command-injection-shaped GET requests to the same API endpoint were followed within the request windows by recurring root shell/discovery process chains. The final sequence shows the same shared resource being mutated in one workload and then executed in another, followed by a root cat process targeting sensitive material and exiting zero. This strongly supports successful command execution rather than a request-only attempt. The verdict remains “likely” rather than definitive because workload/time correlation does not provide a unique request-to-process trace edge, response content is unavailable, and no cited flow evidence establishes outbound communication.

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.

The incident is a true positive for successful command injection, not merely an attempt. Repeated malicious HTTP inputs were observed, including one targeting the system account database [[redacted]]. A captured HTTP response contained non-reflected server-generated identity output identifying UID 0/root even though the response status was 400 [[redacted]]; status therefore does not negate execution. Independent process telemetry recorded root shells, discovery, a sensitive-file command, and mutation/execution of the same shared resource in correlated workload contexts [redacted]. The HTTP-to-process relationship remains temporal/workload correlation rather than a unique per-request parentage edge, but the server-generated output directly establishes server-side root execution.

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.

Verified process telemetry establishes two short-lived parent/child pairs of root-run dash shell executions in the same workload, approximately 63 seconds apart ([redacted], [redacted], [redacted], [redacted]). The second pair was associated with execution from inventory-resolved shared resource [redacted]. Exact lifecycle evidence shows all four processes exited quickly: the first pair nonzero and the second pair zero. This is security-relevant execution, but the bounded evidence contains no correlated HTTP event, cited network-flow event, command arguments, or actor attribution. It therefore cannot distinguish exploitation from expected image-host, automation, or administrative activity. The incident's critical suspicious-activity detector output remains intact, but malicious compromise is not established.

The incident is best assessed as a likely true-positive command-injection attempt. Verified HTTP evidence [redacted] carries the detector signal that the request contained shell metacharacters with command tokens. The request reached an API endpoint and received HTTP 500, but that status neither proves nor disproves command execution. No cited process or flow event was available to establish a downstream consequence.

The available verified HTTP evidence supports a likely command-injection exploitation attempt against target privatekind: a PUT request was flagged for shell metacharacters combined with command tokens. The request received HTTP 200 with an empty response body, but that does not establish command execution or exploit success. The incident cites no process or flow event IDs, so no execution or outbound-network consequence can be adjudicated from the available bounded evidence.

The incident is a true positive for an attempted command-injection request, not for confirmed command execution. The verified HTTP summary shows a PUT request with a 106-byte body that triggered the command-injection rule for shell metacharacters combined with command tokens. The request received HTTP 200 with an empty response, but status alone cannot establish exploit success. No incident-cited process or flow event was available to evaluate execution or network consequences.

The incident is best assessed as a likely genuine command-injection attempt, not a proven compromise. The verified, capture-complete HTTP event records a PUT request whose detector signal identified shell metacharacters with command tokens (HTTP evidence [redacted]). The request received HTTP 200 with an empty response body, but status alone does not establish command execution. No incident-cited process or flow evidence was available to demonstrate downstream consequences.

Server-side command execution is directly evidenced: a captured GET response contained non-reflected process identity output identifying root/UID 0, despite returning HTTP 400 (HTTP evidence [redacted]). Process telemetry independently recorded two root `dash` executions classified as shell and discovery activity in the same workload and parent lineage (process evidence [redacted] and [redacted]). The second execution occurred during the HTTP transaction and exited successfully just before response completion (process evidence [redacted]), providing strong corroboration without establishing a unique request-to-process edge. The observed scope is workload-level root command execution and identity disclosure; host escape, persistence, lateral movement, outbound communication, and data theft are not established.

Verified process telemetry shows a root-run dash execution classified as both shell and discovery in the protected workload [redacted]. Its exact lifecycle subsequently exited with outcome zero about 23 ms later [redacted]. This validates the detector's process observations, but the bounded evidence does not reveal the command or establish malicious intent, exploitation, or an originating HTTP request. No HTTP or flow evidence references are available in this incident for causality or network-impact analysis. The incident therefore remains suspicious but indeterminate rather than a demonstrated compromise.

Likely true positive for automated HTTP reconnaissance against target privatekind, not for compromise. The detector aggregated 335 requests spanning 128 unique paths, three methods, and eight path categories from one traffic cluster; sampled evidence includes repeated POSTs to one API-route hash receiving 429 responses and later GETs across distinct API-route hashes receiving 401 responses (HTTP refs [redacted], [redacted], [redacted], [redacted], [redacted], [redacted]). This strongly supports route/method enumeration. Authorization and intent remain unknown, however, and the detector facts report that 293 of 335 requests were authenticated, so the signal summary's “unauthenticated” wording is not uniformly applicable. No process or flow evidence is cited by this incident, so consequences beyond HTTP probing are not established.

Likely true positive for unauthorized or otherwise security-relevant workload execution, but not proof of an HTTP exploit. Event-driven telemetry shows root-context shell and discovery execution, an outbound-capable process class, a root shell/child command targeting a sensitive file, and mutation plus access of an inventory-resolved shared resource in the same processor workload [redacted]. This combination is substantially more suspicious than a shell spawn alone. However, no cited HTTP or flow event was available to establish an originating request, remote actor, or actual outbound connection, and the bounded evidence does not establish persistence, lateral movement, host escape, command-and-control, or exfiltration.

Verified event-driven process telemetry confirms repeated root-context dash shell execution in the protected image-host workload, including discovery-class activity and two network-client-class shell executions. Matching lifecycle evidence shows sampled shells exited quickly, with both zero and nonzero outcomes. However, the incident provides no retrievable HTTP or flow evidence to establish an originating request, actor, actual outbound connection, exploitation, or compromise. This is materially suspicious and warrants urgent validation, but process execution alone cannot distinguish unauthorized activity from legitimate workload or administrative automation.

Confirmed remote command execution in the responding workload. A command-injection request received non-reflected process-identity output showing UID 0/root, which proves execution despite the HTTP 400 response (HTTP evidence [redacted]). Event-driven process telemetry immediately afterward recorded root shell and identity-discovery processes, and later recorded a root cat process targeting a sensitive file; those process events corroborate workload activity but are correlated by workload/time rather than uniquely attributable to the HTTP request.

The immutable detector state is confirmed, and the evidence independently supports a true compromise: exploit-shaped HTTP requests received non-reflected command output identifying UID 0/root, with repeated identity output and later kernel/OS-release output. A 400 response does not negate execution because the response itself contained server-generated command results. Event-driven process telemetry also observed root shell and discovery lineages in correlated workload windows, plus sensitive-target and shared-resource activity. Request-to-process causality is not uniquely traced, so those process consequences are corroborative rather than attributed to a specific request. No cited flow evidence was available to prove an outbound connection, command-and-control, or exfiltration.

Verified process telemetry shows repeated root-context dash execution in one processor workload, including five dash-to-env parent/child pairs, followed by zero-status exits. The stable parent, repeated pattern, short lifetimes, and clean exits are compatible with an intentional workload task, health/diagnostic routine, or administrative automation; they do not by themselves prove exploitation. Conversely, root shell execution and environment discovery could be unauthorized. No request origin, actor attribution, command arguments, authorization context, or decision-relevant network consequence is available, so compromise cannot be confirmed or ruled out. The detector's critical suspicious-activity output is therefore preserved, but the investigative verdict is indeterminate.

Process telemetry confirms repeated, short-lived root shell execution in the protected image-host workload, including nested dash/bash chains. Exact lifecycle evidence shows the cited processes exited with zero outcomes. However, the incident contains no correlated HTTP or flow evidence, and the available argument-free process summaries do not reveal commands, initiating action, or actor. The detector's critical suspicious-activity result is therefore supported as an observation of root shell spawning, but the evidence is insufficient to determine whether this was exploitation or expected workload/administrative automation.

True positive for opportunistic PHP/WordPress web-shell path enumeration, not for confirmed compromise. The incident records 236 requests spanning 119 probe paths in about 29 seconds. The inspected complete HTTP summaries show bodyless GET requests categorized as PHP/WordPress probes and responses of 301 or 404. No process or flow evidence is cited by the incident, so command execution and downstream network consequences are not established.

The incident is a true positive for opportunistic PHP/WordPress web-shell path enumeration, not a confirmed compromise. The detector aggregated 39 requests across 20 probe paths in roughly 4.3 seconds, and the reviewed immutable HTTP records consistently classify the requests as php_or_wordpress_probe traffic from the same source cluster to target privatekind [http:[redacted], http:[redacted], http:[redacted]]. Sampled responses were redirects or rejections (301/404), with no request bodies [same references]. This supports a reconnaissance/enumeration verdict. It does not establish exploitation, command execution, persistence, or outbound activity; no process or flow evidence was cited by the incident and therefore those evidence tools could not provide corroboration.

This is a true positive for opportunistic reconnaissance/web-shell enumeration, not a confirmed compromise. The detector derived 39 requests across 20 PHP/WordPress probe paths in about 4.8 seconds, and verified HTTP examples are GETs categorized as php_or_wordpress_probe with distinct path hashes [redacted]. The incident records redirect/rejection-only outcomes for all 39 requests. That supports an attempted discovery scan but does not, by HTTP status alone, prove exploit failure. No process or flow evidence references were cited by this incident, so execution, outbound activity, persistence, or other compromise consequences cannot be assessed from the available evidence.

The incident is a true positive for opportunistic reconnaissance: a single derived traffic cluster rapidly issued GET requests categorized as PHP/WordPress probes across differing path hashes. The cited HTTP samples received only 301 redirects or 404 responses. This establishes hostile-style web-shell path enumeration, but not successful exploitation or compromise. No process or flow evidence was cited by the incident, so workload-side execution, outbound activity, persistence, or other consequences cannot be determined from the available evidence.

This is a true positive for opportunistic reconnaissance: a rapid burst enumerated PHP and WordPress web-shell-style paths. The available HTTP evidence shows redirects and rejections, so the observed incident is scanning rather than a demonstrated compromise. No cited process or flow evidence was available to establish execution or outbound network consequences.

Observed exploitation progressed beyond probing to server-side command execution. A captured HTTP response contained non-reflected process-identity output identifying uid 0/root, which is execution evidence despite the HTTP 400 status [redacted]. Independently, event-driven process telemetry recorded a root-run `id` process in the correlated workload shortly afterward [redacted]. A later request contained shell metacharacters and command tokens [redacted], followed closely by a root-run `dash` process in that workload [redacted]. The HTTP-to-process relationships remain temporal/workload correlations rather than unique causal trace edges, but the non-reflected server output directly supports successful execution.

Process telemetry verifies that an event-driven `dash` shell was executed as root in the protected workload, then exited successfully about 11.6 ms later (process evidence [redacted] and [redacted]). This supports the detector's shell-spawn consequence, but it does not establish malicious exploitation. No cited HTTP or flow evidence was available to identify an originating request, actor, network consequence, or external destination. The very short, zero-exit lifecycle is compatible with both a successful one-shot command and legitimate workload activity; command arguments and parent identity are not exposed in the bounded evidence. Therefore maliciousness cannot be determined from the available evidence.

Likely true positive for unauthorized or at least security-relevant execution inside the processor workload. Verified event-driven telemetry shows root-level discovery and shell execution, followed by root processes classified as targeting sensitive files and access to an inventory-resolved shared resource. The behavior is materially suspicious, but the available evidence does not identify an initiating actor or action and does not establish exploitation: no correlated HTTP evidence or cited flow evidence is available, and the processor role could legitimately launch shell-based jobs. Treat the workload as potentially compromised pending owner validation.

The incident reflects genuine, repeated root-context dash executions in the protected workload, including one execution classified as a sensitive-file tool targeting a sensitive object. Representative exec/exit pairs share the same parent and terminate with zero exit outcomes within milliseconds. This strongly supports short-lived shell activity, but not malicious causation: the bounded evidence provides no command arguments, initiating actor/action, HTTP correlation, or retrievable flow evidence. The highly repetitive same-parent pattern could represent either automated legitimate workload behavior or unauthorized execution. Exploitation, persistence, data disclosure, and network follow-on are therefore not established.

This is highly likely to be a real command-injection exploitation campaign. Verified HTTP events contain shell metacharacters and command tokens, and repeated root-owned dash shells with discovery children appeared in the correlated workload within milliseconds of those requests. Later telemetry also shows root processes classified as targeting sensitive files. The evidence strongly supports exploitation and workload-level command execution, but the verdict remains “likely” rather than definitive because routing and time correlation do not establish a unique request-to-process causality edge, and no incident-cited flow evidence was available.

The incident is a true positive for opportunistic reconnaissance/web-shell path enumeration, not for successful compromise. The traffic cluster generated a rapid burst that the detector aggregated as 39 requests across 20 PHP/WordPress probe paths from [redacted].438Z through [redacted].271Z. Verified HTTP examples are GET requests categorized as php_or_wordpress_probe and received 301 redirects or 404 rejections; no bounded process or flow evidence is cited to establish execution or follow-on activity. [HTTP: [redacted], [redacted], [redacted], [redacted], [redacted]]

This is a true positive for opportunistic reconnaissance: a single derived traffic cluster rapidly enumerated PHP and WordPress web-shell-style paths on target privatekind. The incident records 64 requests across 32 unique probe paths in roughly seven seconds. Verified HTTP samples are GET requests categorized as PHP/WordPress probes and show only redirects or 404 responses. The available evidence establishes scanning, but it does not establish successful exploitation or any downstream workload consequence.

High-confidence true positive for rapid opportunistic PHP/WordPress web-shell path enumeration against target privatekind. Verified HTTP summaries show repeated GET requests categorized as php_or_wordpress_probe, with distinct path hashes, from one derived source cluster over roughly 4.4 seconds. The incident detector reports 38 requests across 20 unique probe paths. Observed HTTP outcomes were redirects or rejections, but status codes alone do not prove exploit failure. No process or flow evidence is cited by this incident, so successful execution or follow-on network activity is neither demonstrated nor conclusively excluded.

The process evidence supports genuine, sustained high-risk execution behavior inside one protected workload: root-context dash shells spawned discovery children, including an exact shell-to-id parent/child sequence (process evidence [redacted] and [redacted]); a root dash shell spawned cat against a telemetry-classified sensitive target ([redacted] and [redacted]); and root dash executions were classified as outbound-capable network clients ([redacted], [redacted], and [redacted]). This is likely a true positive for unauthorized or otherwise suspicious workload execution, discovery, and possible credential/configuration access. The verdict stops short of confirmed compromise because authorization and initiating action are unknown, and no cited HTTP or flow evidence was available to establish initial access, request-to-process causality, a resulting socket, command-and-control, or exfiltration.

The evidence strongly supports a real command-injection campaign and likely successful command execution in the correlated processor workload. A command-injection-pattern HTTP request was followed within the same request window by a root-run dash execution, and additional root-run discovery commands (uname and hostname) appeared in that workload. Repetition and tight timing make coincidence unlikely. However, the evidence provides workload/time correlation rather than a unique request-to-process trace edge, so the verdict remains likely true positive rather than definitive. HTTP response status is not treated as proof of success or failure.

The immutable detector state is confirmed, and the evidence supports that conclusion. A command-injection request received non-reflected process-identity output identifying uid 0/root, proving remote command execution in the responding workload even though the HTTP response was 400 (HTTP evidence [redacted]). Event-driven process telemetry independently observed root-run dash discovery/shell activity in the correlated workload, followed later by root process activity labeled as shared-resource mutation/access and sensitive-file targeting. The latter process observations are correlated by workload and time, not by unique per-request causality, so they are treated as observed post-exploitation activity with attribution uncertainty rather than definitive consequences of a specific request. No incident-cited flow event was available for retrieval, so outbound networking, command-and-control, and exfiltration are not established.

Likely unauthorized in-workload execution: event-driven telemetry shows a root dash process spawning root `id`, followed minutes later by a separate root dash/cat chain targeting a sensitive file and another root dash classified as a network client. These behaviors are directly observed in process evidence ([redacted], [redacted], [redacted], [redacted], [redacted]). The initial dash and `id` processes exited with zero outcomes ([redacted], [redacted]). However, authorization and origin cannot be established because the incident cites no retrievable HTTP or flow event, so exploitation, sensitive-data acquisition, and successful outbound communication remain unproven.

Likely successful command-injection exploitation, not merely scanning. A captured GET containing shell metacharacters and command tokens was followed 69 ms later in the correlated workload by a root-run dash process classified as shell/discovery/network-client; that process exited nonzero [redacted]. Later, another captured injection-pattern GET was followed 35 ms later by a root dash execution that exited zero [redacted]. A separate observed root dash spawned root uname, and both exited zero [redacted]. This strongly supports workload-level command execution and discovery, but correlation is by workload and time rather than a unique request trace; authorization and network consequences remain unverified.

This is a true positive for opportunistic PHP/WordPress web-shell path enumeration, not a confirmed compromise. The cited HTTP sequence contains repeated GET requests classified as PHP/WordPress probes from one traffic cluster over approximately 50 seconds (HTTP refs [redacted] through [redacted]). Retrieved examples were capture-complete, had empty request bodies, and returned consistent 404 responses. Those responses support rejection/non-discovery but, by themselves, do not prove that every possible exploit consequence was absent. No process- or flow-plane event references are cited by this incident, so execution and outbound-network consequences cannot be independently evaluated.

The alert accurately identifies a rapid, opportunistic PHP/WordPress web-shell path-enumeration campaign against target privatekind. The cited HTTP evidence supports real probing activity, while the incident aggregate records 38 requests across 20 probe paths. Observed HTTP outcomes were redirects or rejections, but status codes alone cannot prove that every probe failed. No process or flow evidence was cited by this incident, so there is no verified command execution, persistence, outbound connection, or other compromise consequence.

The incident is likely a true positive for reconnaissance followed by attempted command injection, not for confirmed compromise. Two PUT requests matched the command-injection detector; the later request was classified as targeting the system account database [redacted]. Both received HTTP 200 with empty response bodies, which establishes request handling but does not establish command execution [same refs]. The source cluster also conducted broad route/method enumeration, represented by the cited enumeration evidence [redacted]. No cited process or flow evidence was available to confirm downstream execution or network consequences.

The incident is most consistent with automated, unauthenticated HTTP surface enumeration against target privatekind. The detector reports 47 requests spanning 42 unique paths, two methods, and eight path categories, with no authenticated requests; the retained HTTP event independently confirms an unauthenticated GET that received a 404. This supports reconnaissance, but not exploit success or compromise. Authorization cannot be determined from the available network evidence, and no process or flow evidence is cited by the incident.

The incident is a true positive for opportunistic PHP/WordPress web-shell path enumeration, not for confirmed compromise. The deterministic detector remains open with a medium-severity scan classification. Verified HTTP summaries show rapid GET probes categorized as PHP/WordPress probes, while the incident aggregates 39 requests across 20 unique probe paths in about 5.4 seconds. The observed responses were redirects or rejections; the available record does not establish command execution or any follow-on host/network consequence.

A complete-capture POST request to target privatekind triggered the high-confidence command-injection-attempt rule for shell metacharacters combined with command tokens (HTTP evidence [redacted]). This supports a likely genuine exploitation attempt. The request received HTTP 200, but status alone does not prove command execution. No incident-cited process or flow evidence was available to establish downstream execution, outbound activity, or other compromise consequences.

The incident is strongly supported as broad HTTP surface reconnaissance against target privatekind. Detector-derived aggregation reports 77 unauthenticated requests spanning 48 paths, two methods, and seven path categories; reviewed samples from the same traffic cluster show rapid probing of distinct root, other, and API-path hashes with mixed 200 and 404 responses. This is consistent with automated route discovery, but authorization and operator intent are not established, so the verdict is likely rather than definitive true positive. The available evidence does not establish exploitation or a downstream workload/network consequence.

The evidence strongly supports real HTTP reconnaissance against target privatekind: the detector aggregated 64 unauthenticated requests across 56 unique paths, two methods, and six path categories from one derived source cluster. Representative verified events show GET and POST probing with differentiated 200, 401, 404, and 422 responses. This is consistent with automated surface enumeration, but authorization and operator identity are not established. No cited process or flow evidence was available to assess execution, outbound activity, or other post-reconnaissance consequences.

Verified process telemetry establishes two event-driven root executions of the dash shell in the same workload, both from the same observed parent PID. Exact lifecycle evidence shows each process later exited successfully. This confirms shell execution but does not establish malicious exploitation: the incident cites no HTTP or flow event that can be inspected, and the bounded summaries do not expose command arguments, parent executable identity, or an initiating actor. The detector's critical suspicious-activity output is therefore supported as an execution anomaly, while compromise remains indeterminate.

True positive. Although the deterministic incident remains classified as attempted exploitation, the available evidence goes beyond an attempt: three HTTP responses contained non-reflected server process-identity output identifying root/UID 0 [[redacted], [redacted], [redacted]]. The first did so in an HTTP 400 response, which does not negate execution [[redacted]]. Correlated event-driven process telemetry independently observed root dash shells spawning root discovery commands, including id and hostname [redacted]. A later root shell was classified as targeting a sensitive file and had an exact zero-exit lifecycle [redacted]. Exact HTTP-request-to-process causality remains unproven, and no host escape, persistence, lateral movement, external command-and-control, or data theft is established.

The incident is a true positive for opportunistic reconnaissance: one derived traffic cluster rapidly issued GET requests categorized as PHP/WordPress probes against target privatekind. The detector reports 39 requests spanning 20 unique probe paths in about 4.5 seconds. The cited HTTP outcomes are redirects or rejections, with no evidence establishing web-shell access or command execution. This verdict confirms the scan activity, not a compromise.

This is a true-positive opportunistic reconnaissance event, not a confirmed compromise. The incident’s cited sequence records rapid GET enumeration of PHP/WordPress probe paths against target privatekind; inspected examples produced only HTTP 301 redirects or 404 responses (HTTP [redacted], [redacted], [redacted], [redacted]). The detector’s aggregate is 39 requests across 20 unique probe paths in about 4.2 seconds, with all 39 classified as redirects/rejections. No cited process or flow events were available to establish execution or egress, so successful exploitation is not demonstrated.

The evidence supports a likely genuine exploitation attempt against target privatekind. After a detector-aggregated period of broad route/method enumeration, the same derived source cluster sent a PUT request whose captured 267-byte body triggered the command-injection rule for shell metacharacters with command tokens [http:[redacted]]. The request received HTTP 200 with an empty response body, but status alone neither proves nor disproves execution. No cited process or flow event was available to establish a workload consequence or a unique request-to-process/socket edge. The incident's immutable detector classification remains attempted_exploitation; this assessment agrees at the attempt level, not at the level of successful command execution.

The incident is a true positive for opportunistic reconnaissance/web-shell path enumeration, not for confirmed compromise. The cited HTTP series records a rapid burst against PHP/WordPress probe-path categories, and the detector-derived aggregate reports 41 requests across 20 unique probe paths. Available outcomes are redirects or rejections, including 301 and 404 responses. HTTP status alone cannot prove exploit failure, but the available evidence contains no demonstrated execution or other downstream consequence. Process and flow evidence could not be retrieved because this incident cites no events from those planes.

High-confidence true positive for opportunistic web-shell/path reconnaissance against target privatekind. The incident aggregates 39 requests across 20 PHP/WordPress probe paths in under five seconds, and verified HTTP summaries confirm rapid GET probes from one source cluster with redirect/rejection outcomes (HTTP evidence [redacted] through [redacted]). This establishes the scan, but not compromise: no process or flow evidence is cited by the incident, and HTTP status by itself cannot prove exploit failure.

The incident is a true positive for opportunistic reconnaissance: a single derived traffic cluster rapidly issued GET requests categorized as PHP or WordPress probes, and the detector derived 39 requests across 20 unique probe paths in roughly 4.5 seconds. The available HTTP evidence shows only redirects or rejection responses and does not establish successful web-shell access or code execution. This verdict confirms the scan/enumeration activity, not host compromise. No process- or flow-plane evidence is cited by the incident, so downstream execution and network consequences remain unverified.

The incident is likely a true positive for unauthorized command execution inside the processor workload. Event-driven telemetry shows multiple distinct root-run dash shells over the incident window, followed by root discovery activity, a root dash-to-find chain marked as targeting a sensitive file, and additional shells classified as outbound-capable network clients (process evidence [redacted], [redacted], [redacted], [redacted], [redacted], [redacted], and [redacted]). This combination is substantially more suspicious than an isolated shell, but it does not establish the originating actor, an HTTP exploit, a successful outbound connection, persistence, host escape, lateral movement, command-and-control, or data theft. The initial cited shell exited successfully almost immediately; that lifecycle fact does not identify what launched it (process evidence [redacted] and [redacted]).

The incident is likely a true detection of materially suspicious in-workload execution, but not proof of a specific remote exploit or actor. Event-driven telemetry shows multiple root-run dash shells, shell-classified outbound-capable clients, later root discovery and sensitive-target tooling, and access to an inventory-resolved shared resource. The progression and repeated activity across roughly 14 minutes are unlikely to be explained by one isolated shell launch. However, no HTTP event or conntrack event is cited by the incident, so the initiating action, authorization status, remote-request causality, and whether the outbound-capable processes actually opened connections remain unresolved. Exact exit joins show some processes terminated, but do not negate the observed execution or prove request causality.

Successful command injection is established, not merely attempted. Repeated requests contained shell metacharacters and command tokens, and separate HTTP responses returned non-reflected root/UID 0 identity and kernel identification even though the responses were HTTP 400. Event-driven telemetry concurrently observed root-run dash shells with discovery children, sensitive-file targeting, and execution/access/mutation involving an inventory-resolved shared resource. The detector labels the incident as attempted_exploitation, but the server-generated output and observed workload consequences support upgrading the investigator verdict to successful exploitation. No flow-plane evidence was cited, so outbound communication, command-and-control, or exfiltration is not established.

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.

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 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.

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.

The incident is a likely true positive for attempted command injection, not for confirmed execution. Six fully captured POST requests to the root path reached target privatekind in a rapid burst; every request independently triggered the high-confidence command-injection rule for shell metacharacters with command tokens, and the six request bodies had distinct hashes (HTTP evidence [redacted], [redacted], [redacted], [redacted], [redacted], [redacted]). All received HTTP 404 responses with the same short response hash, but status alone cannot prove that command execution failed. No cited process or flow event was available to establish execution or post-exploitation consequences.

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.

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.

This is a true positive for automated reconnaissance/web-shell path enumeration, not a confirmed compromise. The detector aggregated 232 requests across 118 PHP/WordPress probe paths in about 28 seconds, while the cited HTTP outcomes were redirects or rejections (for example, HTTP [redacted], [redacted], [redacted], and [redacted]). HTTP status does not independently prove exploit failure, and the incident provides no cited process or flow identities with which to determine workload execution or outbound network consequences.

The incident is a true positive for opportunistic reconnaissance/web-shell path enumeration, not for successful compromise. The detector recorded 218 requests spanning 110 probe paths in about 23 seconds from one derived source cluster. Verified representative requests were GETs categorized as PHP/WordPress probes and received 301 or 404 outcomes. No cited process or flow evidence was available to establish command execution, outbound activity, persistence, or any other post-request consequence, so impact remains unproven.

The incident is best assessed as a likely true-positive command-injection attempt against target privatekind. The verified HTTP event records a POST whose request content triggered the high-confidence command-injection rule for shell metacharacters combined with command tokens. The request received a 301 response with an empty body in about 1 ms, but status and response shape do not establish whether execution succeeded or failed. No process or flow event is cited by the incident, so no execution, outbound connection, persistence, lateral movement, or data loss is established. This agrees with the detector's immutable output: the incident remains open and is classified as attempted exploitation, not confirmed compromise.

True positive for opportunistic PHP/WordPress web-shell path enumeration, not for successful exploitation. The HTTP evidence shows rapid GET probes from one derived source cluster, categorized as PHP/WordPress probes, including the first and last cited events [http:[redacted]; http:[redacted]]. The detector aggregated 38 requests over 20 unique probe paths and recorded only redirects or rejections across the cited set. No process or flow evidence is cited by this incident, so execution, outbound connectivity, persistence, or other compromise consequences are not established.

The incident is best assessed as a likely genuine command-injection attempt, not a demonstrated compromise. The verified HTTP event reports a POST request whose captured body triggered the command-injection rule for shell metacharacters plus command tokens [redacted]. The server returned 301 with an empty response body, but status and response shape do not establish whether execution occurred. No cited process or flow event was available to substantiate command execution or downstream network activity.

The incident is highly consistent with automated hostile reconnaissance followed by command-injection attempts. The detector recorded 566 unauthenticated requests spanning 505 unique paths, and five closely timed GET requests matched shell-metacharacter/command-token behavior; cited facts also identify application environment files as targets. This supports a likely true positive for attempted exploitation. Exploit success is not established: inspected HTTP summaries returned 404 responses, but status alone cannot prove failure, and the incident cites no process or flow event IDs with which to assess workload execution or outbound consequences. Authorization and the real identity behind the source traffic cluster remain unknown.

The evidence strongly supports the detector's medium-severity reconnaissance classification: a single derived traffic cluster generated broad, unauthenticated HTTP route/method enumeration against target privatekind. The incident aggregate reports 65 requests across 48 unique paths, four methods, and seven path categories, while representative HTTP records show rapid probing of API endpoints with both 200 and 401 responses (for example, [redacted] and [redacted]). Authorization and actor identity remain unknown, so this could still be sanctioned testing or inventory activity. No process- or flow-plane references are cited by the incident, and the HTTP evidence does not establish exploitation or downstream compromise.

This is a true positive for opportunistic reconnaissance: the cited traffic cluster rapidly enumerated PHP/WordPress probe paths on target privatekind. The aggregate signal records 38 requests across 20 unique probe paths, with all 38 receiving redirect or rejection outcomes, supported by HTTP evidence [redacted] through [redacted]. Representative capture-complete summaries show GET probes returning either an empty 301 or a 404 ([redacted]; [redacted]). This verifies the scan attempt, but does not establish successful exploitation or workload compromise. No process or flow references were cited by the incident, so consequence telemetry could not be evaluated.

This is a true-positive opportunistic web-shell/path-enumeration scan against target privatekind. The detector recorded 39 requests over roughly six seconds, spanning 20 PHP/WordPress probe paths; the inspected bounded HTTP summaries show bodyless GET probes receiving redirects or 404 responses. The available evidence establishes reconnaissance/probing, but not successful exploitation or compromise. No process or flow evidence references are available in this incident, and HTTP status codes alone cannot prove exploit failure.

The process activity is genuine and security-relevant: event-driven root dash executions occurred in the processor workload, an id discovery child was spawned, a later root shell targeted a sensitive file, and root processes executed and accessed a shared resource. However, the bounded evidence does not establish whether these actions were unauthorized or expected processor/administrative behavior. No usable HTTP or flow evidence was available to identify an originating action, actor, or network consequence. Accordingly, this is an indeterminate suspicious-execution incident rather than proven exploitation or compromise.

Likely true positive for suspicious privileged process activity inside the image-host workload, but not proof of an external exploit. Event-driven telemetry directly observed a root dash shell spawning a root cat process classified as targeting a sensitive file; both had exact, zero-outcome exits [redacted]. Additional root dash shells recurred from the same parent, and a later root dash execution was classified as discovery [redacted]. The available summaries do not expose command arguments, the sensitive target, authorization context, HTTP causality, or network consequences, so compromise scope and origin remain unresolved.

The detector’s immutable output is confirmed/confirmed_compromise, and the evidence supports that result. Command-injection-shaped HTTP requests were followed by responses containing non-reflected root identity and kernel output; notably, command output was present even in HTTP 400 responses, which proves execution in the responding workload rather than failure based on status alone [[redacted], [redacted], [redacted]]. Event-driven telemetry independently observed root dash shells, discovery utilities, sensitive-file tools, and shared-resource mutation in correlated workload windows [redacted]. This establishes successful remote command execution and post-exploitation activity within responding workloads. It does not establish host escape, persistence, exfiltration, lateral movement, or command-and-control.

Confirmed command-injection compromise of the responding workload. HTTP responses contained non-reflected root identity output despite HTTP 400 responses ([redacted]; [redacted]), and another injected request returned non-reflected kernel and OS-release data ([redacted]). Event-driven telemetry independently observed root dash processes and discovery children in the correlated workload ([redacted]; [redacted]; [redacted]; [redacted]). This validates the detector's immutable confirmed state for workload-level root execution, while not proving host escape, persistence, or request-to-process causality.

Verified process telemetry establishes repeated root-level shell and discovery execution in the protected workload, including dash spawning id and dash spawning env, with exact zero-exit lifecycle evidence for sampled sequences [redacted]. This confirms execution and discovery consequences, but not unauthorized exploitation. No incident-cited HTTP or flow events were available for bounded inspection, and the process summaries do not establish the initiating action, actor, or authorization. The behavior could represent malicious post-exploitation or legitimate processor/administrative activity; the available evidence cannot distinguish them.

Two distinct event-driven executions of the dash shell as root were directly observed in the same protected workload within about 159 ms [redacted]. This validates the detector's shell-spawn observation, but the available summaries expose neither command arguments nor sufficient parent context to determine purpose. The incident cites no HTTP or flow events that can be inspected, so exploitation, an originating actor/action, and network consequences cannot be established. The activity is therefore security-relevant but of indeterminate maliciousness.

A root-run dash process was directly observed in the protected processor workload and classified as both a shell and a sensitive-file tool with a sensitive target [redacted]. The same PID then exited with a zero outcome [redacted]. This validates the detector's suspicious process observations, but the bounded evidence does not expose the command, target, actor, or initiating action, and there is no cited HTTP or flow event available to establish exploitation, network consequence, or malicious intent. Legitimate workload or administrative execution therefore remains plausible.

High-integrity process telemetry confirms that a root-run `dash` execution occurred and was classified both as a shell and a sensitive-file tool with a sensitive target. The same PID then exited with outcome zero. This establishes suspicious execution and a sensitive-file command, but not malicious intent, exploitation, or successful access to file contents. No HTTP or flow evidence references are available in the incident to establish an originating request, actor, network consequence, or request-to-process/socket causality. The activity could therefore be unauthorized execution or legitimate workload/administrative behavior.

Two event-driven process records prove that separate dash shell processes executed as root in the same protected workload within about 177 ms (process evidence [redacted] and [redacted]). This validates the detector's observed shell-spawn consequence, but the available summaries do not expose commands, parent identities, initiating action, or a causal HTTP/flow chain. Root dash execution can represent either malicious command execution or legitimate workload/administrative automation, so exploitation or compromise cannot be adjudicated from the cited evidence.

Highly likely successful command injection into the processor workload, not merely scanning. Repeated requests containing shell metacharacters and command tokens aligned within milliseconds with root-run shell, discovery, and sensitive-file-tool executions. The strongest sequences are HTTP [redacted] followed by dash→id, and HTTP [redacted] followed by dash→cat against a sensitive target; similar activity recurred around HTTP [redacted]. Later process telemetry recorded access and mutation operations against a shared resource. The evidence lacks a unique per-request process-parentage edge, so the verdict is “likely” rather than causally proven. A separate public outbound flow is contextual only.

Likely true positive for unauthorized or malicious workload execution. Event-driven telemetry shows a root dash shell classified for discovery spawning root id ([redacted]; [redacted]), a later root shell classified as an outbound-capable client ([redacted]), and root dash/head processes targeting sensitive files ([redacted]; [redacted]). This strongly supports real shell execution, discovery, and sensitive-file targeting inside the processor workload, but not a specific exploitation path. No incident-cited HTTP or flow evidence was available to identify an originating request, actor, or actual network connection.

The incident is strongly consistent with genuine opportunistic reconnaissance for exposed PHP/WordPress web shells. Verified HTTP summaries show rapid GET probes categorized as php_or_wordpress_probe against target privatekind, with 301 redirects or 404 rejections. The derived detector reports 39 requests covering 20 unique probe paths in about 11 seconds. Available evidence establishes the scan attempt, but not web-shell presence, command execution, or compromise; no process or flow evidence references are cited by this incident.

The incident is a true positive for opportunistic reconnaissance: one derived source cluster rapidly issued GET requests to numerous distinct paths categorized as PHP or WordPress probes against target privatekind. The verified HTTP samples returned 404 responses with the same response-body hash and contained no request bodies. This supports web-shell/path enumeration, but not successful exploitation. HTTP status alone cannot establish exploit failure, and the incident cites no process or flow evidence with which to assess command execution or network consequences.

Likely true positive for suspicious execution within the protected processor workload. Event-driven telemetry directly observed repeated root-run dash shells, a child discovery command, outbound-capable client-class processes, and access/mutation/execution involving an inventory-resolved shared resource (process evidence [redacted], [redacted], [redacted], [redacted], [redacted], [redacted]; inventory evidence [redacted]). This establishes concerning workload-level execution and shared-resource activity, but not an exploitation vector, actor, network connection, persistence, host escape, lateral movement, command-and-control, or data theft. No cited HTTP or flow event was available for bounded inspection, so the origin and network consequences remain unresolved.

The detector’s critical suspicious-activity finding is supported at the process-effect level: repeated event-driven root `dash` executions occurred in one workload, including a `dash` process classified as discovery/shell that parented a root `env` discovery process [redacted]. Exact lifecycle evidence shows sampled shells exited, including a zero exit for the first observed shell and a nonzero exit for the latest [redacted]. However, the bounded evidence exposes neither command arguments nor cited HTTP/flow events, so it cannot determine whether this was exploitation, authorized application behavior, or administration. Verdict: indeterminate rather than confirmed compromise or false positive.

This is successful server-side command execution, not merely an unsuccessful injection attempt. Verified HTTP summaries show an injection-pattern request and multiple captured 400 responses containing non-reflected root/UID 0 process identity or kernel output; the 400 status therefore does not negate execution. Event-driven process telemetry independently observed root dash shells with discovery children in the correlated workload, followed later by execution, access, and mutation involving a shared resource. The incident's derived classification remains `attempted_exploitation`, but the server-generated output supports upgrading the analyst verdict to a true positive with observed execution. Exact request-to-process causality, source identity, and any network consequence remain unresolved.

The evidence strongly supports the detector's reconnaissance finding: one derived source cluster generated a concentrated, unauthenticated pattern that the incident aggregates as 64 requests spanning 57 unique paths, three methods, and seven path categories in about 97 seconds. Bounded HTTP examples corroborate probing across root, other, and API categories, with mixed 200, 401, and 404 responses. This is consistent with automated application-surface enumeration. The verdict is “likely” rather than definitive because network evidence does not establish whether the activity was authorized security testing or benign inventory work. HTTP status codes do not establish exploitation, and the incident cites no process or flow evidence with which to assess execution or outbound consequences.

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.

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.

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.

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.

The cited HTTP evidence confirms a rapid, automated-looking PHP/WordPress path-enumeration scan against target privatekind. Representative requests were bodyless GETs categorized as php_or_wordpress_probe and produced only 301 redirects or 404 responses. This establishes reconnaissance/probing, not successful exploitation. No process or flow evidence references are present in the incident, so command execution, outbound activity, persistence, or other compromise consequences are not established.

True positive for opportunistic PHP/WordPress web-shell path enumeration, based on a rapid sequence of categorized probe requests from one traffic cluster against target privatekind (for example [redacted], [redacted], [redacted], and [redacted]). The cited HTTP outcomes are redirects or rejections, including 301 and 404 responses; this supports detection of scanning but does not by itself prove exploit failure. No process or flow evidence was cited by the incident, so execution, compromise, or follow-on network activity is not established.

High-confidence true positive for opportunistic PHP/WordPress web-shell path enumeration, not for successful exploitation. The incident’s immutable detector output reports 39 requests across 20 probe paths in about 4.4 seconds; the verified HTTP samples are GET requests categorized as PHP/WordPress probes and show only 301 redirects or 404 rejections. No process or flow evidence is cited by this incident, so execution, outbound activity, or compromise cannot be determined from those planes.

This is a true positive for opportunistic reconnaissance: the detector recorded a rapid cluster of 39 GET requests spanning 20 PHP/WordPress probe paths against target privatekind. Verified HTTP samples at the beginning and end of the burst are categorized as php_or_wordpress_probe and received 301 or 404 responses [[redacted], [redacted], [redacted], [redacted]]. The evidence establishes enumeration activity, but not successful exploitation. HTTP status is not dispositive, response-content semantics were not exposed, and the incident cites no process or flow events with which to evaluate execution or outbound consequences.

Verified event-driven process telemetry shows repeated root-run dash shells in the protected workload, including child discovery utilities and a root-run cat process classified as targeting a sensitive file. This strongly supports unauthorized or attack-like command execution with discovery and sensitive-file access activity. However, no HTTP or flow evidence references are available to establish the initiating action, actor, exploit vector, request-to-process causality, network consequence, or whether the activity was authorized administration or lab automation.

The evidence establishes successful server-side command execution, not merely an attempt. Three captured HTTP responses contained non-reflected process-identity output identifying root/UID 0 despite HTTP 400 statuses ([redacted], [redacted], [redacted]). Event-driven telemetry in the correlated workload also recorded root dash shells and child discovery/sensitive-file processes ([redacted], [redacted], [redacted], [redacted]). HTTP requests with shell metacharacters and command tokens occurred in the same time windows ([redacted], [redacted]). The evidence does not provide a unique request-to-process trace edge, prove sensitive-file contents were returned, or prove an outbound connection.

Likely true positive for suspicious in-workload execution, but not proof of a remote exploit. Event-driven telemetry shows repeated root-run dash executions, including discovery-classified activity, plus a root-run cat child targeting a sensitive file [redacted]. Exact lifecycle evidence shows the sensitive-targeting shell and cat exited nonzero, while other discovery/shell instances exited zero [redacted]. No cited HTTP or flow events were available to establish origin, request causality, actor identity, egress, or exploitation.

This is a true positive for rapid, opportunistic PHP/WordPress web-shell path enumeration, not a demonstrated compromise. The incident aggregates 331 requests across 167 unique probe paths from one derived source cluster over approximately 12 seconds, and the bounded HTTP evidence confirms GET requests categorized as PHP/WordPress probes [[redacted], [redacted], [redacted], [redacted]]. The incident reports redirect/rejection-only outcomes for all 331 requests, with cited summaries showing 301 or 404 responses [[redacted], [redacted], [redacted], [redacted]]. No process- or flow-plane evidence is cited, so the available evidence does not establish command execution, outbound activity, persistence, or other post-exploitation impact.

Likely true positive for automated, unauthenticated web-surface reconnaissance against target privatekind. The aggregate volume, near one-to-one request/path ratio, rapid timing, varied route categories, and representative PHP/WordPress probing strongly support route enumeration rather than ordinary browsing. Authorization cannot be established, so the activity could still be an approved scanner. The incident cites no process or flow evidence establishing exploitation or downstream workload consequences.

The detector's immutable state is confirmed/confirmed_compromise, and the available evidence supports that conclusion. A command-injection-marked request received a response containing non-reflected kernel identification, proving command execution in the responding workload even though the HTTP status was 400 (HTTP [redacted]). Separate responses contained non-reflected root/UID 0 identity output (HTTP [redacted] and [redacted]). Correlated process telemetry independently observed root dash shells and root discovery commands in the workload window, but it does not provide a unique request-to-process causality edge (process [redacted], [redacted], [redacted]). No cited flow-plane evidence was available, so outbound communication, command-and-control, and exfiltration are not established.

Likely true positive for suspicious workload execution: event-driven telemetry directly observed multiple root-context dash shells, a root-context bash child shell, and root-context discovery executables (`id` and `hostname`) in one workload (process evidence [redacted], [redacted], [redacted], [redacted], [redacted]). This supports execution and discovery inside the workload, but not exploitation, remote-request causality, persistence, host escape, or data theft. The origin and authorization remain unresolved because no incident-cited HTTP or flow evidence was available.

Verified process telemetry supports a likely true positive for suspicious execution and discovery inside the workload: event-driven root-context dash shells ran, and root-context id and hostname discovery processes were observed beneath shell lineage [redacted]. Exact matching exit telemetry shows sampled shell/discovery processes exited with zero outcomes, but that does not determine whether the activity was authorized or tie it to any HTTP request [redacted]. No incident-cited HTTP or flow events were available through the respective evidence tools, so exploitation origin, actor, and network consequences remain unproven.

The incident is a true positive for opportunistic PHP/WordPress web-shell path enumeration, not for confirmed compromise. The source traffic cluster generated a rapid series of GET probes across many PHP/WordPress-associated paths. The incident aggregate records 214 requests against 109 unique probe paths in about 40 seconds, with all 214 classified as rejected responses. Verified representative requests returned only 301 redirects or 404 responses. No process- or flow-plane event references are cited by this incident, so execution, persistence, or outbound activity cannot be adjudicated from those planes and is not claimed.

The evidence strongly supports real automated HTTP surface enumeration against target privatekind from one derived traffic cluster. The detector aggregated 356 requests spanning 173 unique paths, six methods, and eight path categories; verified samples show rapid POST, PATCH, PUT, and GET activity against distinct path hashes, with a mixture of 200, 404, 405, and 422 responses. This is highly consistent with reconnaissance, but maliciousness is not conclusive because authorization and source ownership are unknown and the incident also reports substantial authenticated traffic. Some requests returned 200, but status codes and body hashes alone do not prove state change, exploitation, or compromise. No cited process or flow events were available to assess downstream consequences.

The reviewed HTTP evidence supports the detector's finding of automated surface enumeration against target privatekind: one traffic cluster issued GET and HEAD requests across distinct hashed paths and categories, receiving a mixture of 200, 401, 404, and 405 responses (for example, [redacted], [redacted], [redacted], [redacted], and [redacted]). This is likely genuine reconnaissance, but whether it was unauthorized or malicious cannot be determined from network evidence. No process or flow event identities are cited by the incident, so downstream execution or network consequences cannot be assessed.

The evidence strongly supports a genuine command-injection attempt against target privatekind: the verified HTTP event was flagged for shell metacharacters with command tokens [redacted]. About four seconds later, event-driven process telemetry recorded a root-run dash shell in the detector-correlated workload [redacted], and the same observed PID later exited with a zero outcome [redacted]. This materially strengthens the incident, but does not prove that this particular request created the shell because workload routing and temporal correlation are not a unique request-to-process edge. The HTTP 400 status does not itself establish success or failure. The immutable detector classification remains attempted_exploitation; the appropriate adjudication is likely true positive, with possible execution rather than conclusively request-attributed execution.

Direct event-driven process telemetry supports real suspicious activity inside the workload: a root-run dash process classified as both shell and discovery spawned a root-run env child [redacted], similar root shell/discovery executions recurred later [redacted], and a root-run dash process classified as a shell and sensitive-file tool targeted a sensitive resource [redacted]. This makes the behavioral detection likely valid, but available evidence does not identify the initiating actor or distinguish malicious execution from authorized administrative/lab automation. No HTTP or flow evidence references were available to establish an ingress vector or network consequence.

Likely true positive for suspicious root-level command execution inside the workload, but not proof of external exploitation. Event-driven process evidence shows a root dash shell spawning discovery command id [redacted], later followed by a root dash/head chain classified as targeting a sensitive file [redacted]. Additional root dash executions continued through [redacted]36Z [redacted]. The repeated shell, discovery, and sensitive-file pattern strongly supports genuine suspicious activity. However, no HTTP or flow references are available to identify an initiating request or network consequence, and authorization or lab activity cannot be excluded.

Verified HTTP evidence shows server-generated, non-reflected root/UID 0 identity output, which establishes server-side execution even though that response was HTTP 400 ([redacted]). Two additional requests contained shell metacharacters with command tokens ([redacted]; [redacted]). Workload telemetry independently recorded root-context dash/id execution and, immediately after the later request, a root dash-to-cat lineage targeting a sensitive file ([redacted]; [redacted]; [redacted]; [redacted]). This supports successful command injection with root-context command execution and discovery, beyond the detector's attempted-exploitation classification. Request-to-process attribution remains temporal/workload-based rather than a unique trace edge.

Incident [redacted] retains the detector's immutable confirmed/confirmed_compromise state. The verdict is independently supported by a command-injection request whose response contained non-reflected process-identity output and explicit command-input/process-output correlation showing UID 0/root (HTTP [redacted]). Root shell and discovery processes, plus a root sensitive-file tool, were also observed in the correlated workload (process [redacted], [redacted], [redacted]). The HTTP 400 responses do not negate execution because server-generated command output is present. Process timing/lineage corroborates workload activity but is not treated as a unique request-to-process causality edge.

Verified process telemetry establishes three root-context dash shell executions, each followed by a root-context id discovery process in the same workload (process evidence [redacted], [redacted], [redacted], [redacted], [redacted], [redacted]). Exact lifecycle evidence shows all six processes exited; the first pair had nonzero outcomes and the later four had zero outcomes (process evidence [redacted], [redacted], [redacted], [redacted], [redacted], [redacted]). This supports execution and discovery inside the workload, but not a malicious origin: the incident cites no HTTP or flow events, and the available summaries omit command arguments and authorization context. The detector's critical suspicious-activity output remains intact, while the available evidence is insufficient to distinguish exploitation from legitimate administrative or workload behavior.

The captured HTTP transaction is consistent with an attempted command-injection attack: the complete 115-byte PUT request triggered the verified high-severity rule for shell metacharacters combined with command tokens. The request received HTTP 200 with an empty response, but status alone does not establish command execution. No cited process or flow evidence is available to demonstrate execution, outbound activity, persistence, or other post-exploitation consequences. Evidence: HTTP event [redacted] (SHA-256 [redacted]).

The evidence supports the detector's reconnaissance finding: one derived source cluster sent a broad, rapid sequence of requests to target privatekind using multiple HTTP methods and distinct route hashes. Representative requests include GET, POST, and OPTIONS against API and other route categories, with varied 200/401/404/405/422 responses. This is consistent with automated surface and method enumeration. Authorization and source identity are unresolved, so the activity could be sanctioned testing or inventory rather than hostile reconnaissance. No process or flow evidence is cited by this incident, so no execution, persistence, lateral movement, outbound callback, or other post-reconnaissance consequence is established.

Response contains non-reflected process identity output

Response contains non-reflected process identity output

Rapid enumeration of PHP and WordPress web-shell paths

Rapid enumeration of PHP and WordPress web-shell paths

Rapid enumeration of PHP and WordPress web-shell paths

Response contains non-reflected process identity output

Response contains non-reflected process identity output

Request contains shell metacharacters and command tokens

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

Response contains non-reflected process identity output

Response contains non-reflected process identity output

True positive: successful command injection produced non-reflected process identity output showing root/UID 0 in the same captured HTTP transaction (HTTP [redacted]). The 400 response does not negate execution because the server response contained command output. Additional HTTP transactions also returned root identity output, and four root-owned dash shells were observed in correlated workload/time windows. Two new public-web TCP flows were also observed from an inventory-attributed workload, but they cannot be causally linked to a request or shell and their purpose is unknown. The detector's confirmed/confirmed_compromise state is therefore supported for compromise of the responding workload; evidence does not establish host escape, persistence, lateral movement, command-and-control, or data theft.

Request contains shell metacharacters and command tokens

Request contains shell metacharacters and command tokens

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

Request contains shell metacharacters and command tokens

Rapid enumeration of PHP and WordPress web-shell paths

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

Response contains non-reflected process identity output

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

Rapid enumeration of PHP and WordPress web-shell paths

Rapid enumeration of PHP and WordPress web-shell paths

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

Rapid enumeration of PHP and WordPress web-shell paths

Rapid enumeration of PHP and WordPress web-shell paths

Rapid enumeration of PHP and WordPress web-shell paths

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

Request contains shell metacharacters and command tokens

Request contains shell metacharacters and command tokens

Request contains shell metacharacters and command tokens

Request contains shell metacharacters and command tokens

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens

Rapid enumeration of PHP and WordPress web-shell paths

Exploit request received non-reflected process identity output

Request contains shell metacharacters and command tokens

Response contains non-reflected process identity output

Request contains shell metacharacters and command tokens

Request contains shell metacharacters and command tokens

Request contains shell metacharacters and command tokens

Rapid enumeration of PHP and WordPress web-shell paths

Request contains shell metacharacters and command tokens