Live operation queue
Cases
Potential operations correlated across HTTP, process, network, and workload evidence.
Confirmed compromise
The four preserved incident threads are best explained as a likely single operation against the same protected workload, but the evidence does not prove one actor or unique HTTP-to-process causality. Incident [redacted] establishes confirmed root-level command execution during an initial exploitation window; incident [redacted] contains overlapping process-only root shell activity linked by [redacted]. Later, incident [redacted] records enumeration and attempted exploitation from the same source cluster as [redacted] under link [redacted], followed by process-only root shells in [redacted] linked through [redacted]. This connected sequence supports resumed or continued activity more strongly than unrelated operations, while the source-cluster ambiguity, approximately 69-minute gap, and absent unique request-to-process edges prevent a definitive same-operation finding.
Confirmed compromise
The strongest defensible explanation is a likely single operation, while preserving all four incident boundaries. The HTTP activity shows repeated suspected command injection, later confirmed application-workload compromise, and subsequent route/method enumeration against the same target from the same derived source cluster [redacted]. Overlapping shell and discovery activity on the protected workload is also temporally and operationally consistent with the confirmed-compromise thread [redacted]. This is not proof of one actor or a unique request-to-process chain: the source is only a cluster, the process-only incident lacks HTTP parentage, and the later enumeration could be separate or authorized activity.
Confirmed compromise
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.
Confirmed compromise
The three preserved incident threads are best explained as one likely operation, not as proven single-actor activity. Incident [redacted] records confirmed remote command execution as root beginning at [redacted]33Z. Incidents [redacted] and [redacted] then record overlapping root-shell, discovery, sensitive-file, and shared-resource activity. Deterministic links [redacted] and [redacted] connect each process-only thread to the confirmed-compromise thread by protected-workload attribution and temporal proximity. This is a coherent possible exploitation-to-post-compromise progression, but the links do not prove request-to-process causality, and the process-only threads lack correlated HTTP requests or known actors.
Confirmed compromise
The five distinct incident threads are best explained as a likely single operation affecting two protected workload clusters: sustained HTTP command-injection/confirmed remote root execution overlaps two waves of shell, discovery, and sensitive-file-access process activity [redacted]. Repeated activity in each of the two derived workload clusters and the closely synchronized late shell wave strengthen continuity [redacted]. This is not assessed as definitively the same operation because process executions lack correlated HTTP evidence, the earliest process activity predates the HTTP thread, and all deterministic links establish only shared-workload attribution plus temporal proximity—not unique request-to-process causality [redacted]. Incident boundaries remain intact.
Confirmed compromise
The two immutable incident threads are best explained as related parts of one operational episode, but not conclusively one actor or one causal chain. Incident [redacted] records broad HTTP enumeration followed by confirmed command/root execution and related process behavior, while incident [redacted] records overlapping event-driven shell, outbound-client, and shared-resource activity. Deterministic link [redacted] ties them by protected-workload attribution and temporal proximity at 0.9 confidence. The overlap and compatible behaviors support likely_same_operation; the absence of a unique request-to-process edge and the workload-derived identity of the process-only thread prevent a definitive same_operation finding.
Confirmed compromise
The strongest defensible explanation is one likely operation with two activity windows against the same target, while preserving all five incident boundaries. Incident [redacted] records enumeration followed by proven root command execution and post-execution activity; incidents [redacted] and [redacted] contain overlapping workload process activity linked by [redacted] and [redacted]. Roughly two hours later, incidents [redacted] and [redacted] show another closely timed workload/request cluster linked by [redacted]; [redacted] also shares a source cluster and target with [redacted] through [redacted]. These links support recurrence within one operation, but they do not prove one actor or unique request-to-process causality, so a definitive same-operation finding is not warranted.
Confirmed compromise
The three immutable incident threads are best explained as one likely operation, while remaining separate incidents. The primary thread records sustained HTTP command-injection activity and confirmed root-level execution across the case window ([redacted]). Two process-only threads then record repeated shell and discovery execution in protected workloads during the same interval ([redacted], [redacted]). Each process thread has a high-confidence shared-workload/time-window link to the primary thread ([redacted], [redacted]). This supports a coherent possible progression from attempted web command injection to root shell and discovery activity across two workload contexts, but no unique HTTP-request-to-process edge or common actor identity is established.
Confirmed compromise
The two immutable incident threads are best explained as a likely single operation against the same protected workload: incident [redacted] records enumeration, proven command-injection-based root execution, and correlated root post-exploitation activity; incident [redacted] then records closely timed, sustained root shell/discovery, sensitive-target, and network-client process activity. Deterministic link [redacted] supports shared-workload attribution and temporal proximity. The timing and behavioral continuity are strong, but they do not establish one actor or unique HTTP-request-to-process causality, so the incident boundaries remain intact and “same operation” is not asserted as certain.
Confirmed compromise
The strongest defensible hypothesis is one continuing operation with two temporally separated activity waves, not proof of one actor or a unique request-to-process chain. The early wave combines confirmed HTTP-driven root execution in incident [redacted] with contemporaneous shell/process activity in incidents [redacted], [redacted], [redacted], and [redacted]. A later HTTP exploitation wave in [redacted] is tied to the early confirmed incident by same-source-cluster link [redacted] and overlaps later process activity in [redacted] and [redacted] through links [redacted] and [redacted]. Because the source cluster may be shared and workload/time links are non-causal, “likely same” is stronger than either definitive same-operation or multiple-operation conclusions.
Confirmed compromise
The six threads are best explained as two waves of one likely operation against the same target and two recurring workload clusters. The earlier wave includes confirmed-compromise HTTP incident [redacted] and overlapping process activity. The later wave includes command-injection incident [redacted] from the same source cluster and renewed process activity. This does not prove one actor or request-to-process causality; incident boundaries remain intact.
Confirmed compromise
The strongest defensible explanation is one likely operation conducted in two waves against the same target. Both confirmed HTTP incidents show enumeration followed by proven root command execution and share a privacy-preserving source cluster [redacted]. Root-shell, discovery, sensitive-file, and shared-resource process incidents fall within the corresponding workload windows. This supports a likely common operation, but the deterministic links do not establish one actor or unique HTTP-request-to-process causality.
Observed workload execution
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.
Observed workload execution
The two immutable incident threads are best explained as parts of one likely operation: an HTTP-side sequence of broad unauthenticated enumeration followed by confirmed root-context command execution and system discovery, then a closely timed process-only sequence of additional root shells, discovery, and a sensitive-file access command in the same protected workload [redacted]. This is not assessed as definitively the same operation because the deterministic link establishes only workload attribution and temporal proximity, not a unique request-to-process causal edge or common actor [redacted]. Incident boundaries and detector conclusions remain unchanged.
Observed workload execution
The three preserved incident threads are best explained as a likely single operation, but not conclusively one actor or one request-to-process chain. The early request-only command-injection attempts in [redacted] and the later exploitation sequence in [redacted] share a target and privacy-preserving source cluster under link [redacted]. The workload-only shell activity in [redacted] overlaps the later sequence on a protected workload under link [redacted]. Similar shell and shared-resource behavior strengthens continuity, while the approximately one-hour gap before the later traffic, absent HTTP evidence for [redacted], and lack of unique trace edges prevent a definitive same-operation finding. Incident boundaries remain intact.
Observed workload execution
The two immutable incident threads are best explained as parts of one likely operation, while preserving their separate detector boundaries. The attempted-exploitation thread records repeated command-injection requests followed by root shell/discovery execution and shared-resource effects [redacted]. The process-only thread records closely preceding root shell/discovery activity in the protected workload [redacted]. Their shared protected-workload attribution and temporal proximity are explicitly represented by the deterministic relationship link [redacted]. Similar execution behavior within the same short period supports a common operational sequence, but the evidence does not establish one actor or a unique request-to-process causal edge [redacted].
Observed workload execution
The two immutable threads are best explained as a likely shared operation, while remaining short of proof. During the sustained HTTP enumeration and exploitation activity in incident [redacted], incident [redacted] recorded two brief root-level `dash` shell executions in the same protected workload; the HTTP incident later recorded root identity disclosure and a root-run `id` process. The deterministic link [redacted] establishes shared-workload attribution and temporal proximity, and the compatible execution/discovery behavior strengthens the one-operation hypothesis. However, no unique HTTP-request-to-shell edge exists, and the process-only incident's completed verdict is indeterminate, so a separate legitimate or unrelated source of the shells remains plausible. Incident boundaries are preserved.
Observed workload execution
The strongest defensible explanation is a likely single exploitation operation expressed across three preserved incident threads: sustained HTTP enumeration and exploit-like request activity in [redacted] overlaps discovery, root-shell, sensitive-file-access, and shared-resource process activity in [redacted], followed by another concentrated root-shell and sensitive-file-access process burst in [redacted]. Deterministic links [redacted] and [redacted] connect the HTTP incident to each process incident through protected-workload attribution and temporal proximity. The behavioral compatibility and timing support one operation, but do not prove one actor or a request-to-process causal chain; separate activity, shared infrastructure, or authorized workload behavior remain possible.
Observed workload execution
The three preserved incident threads are best explained as a likely single, sustained exploitation operation against the same protected target, rather than unrelated activity. The two HTTP-led threads share the same derived traffic-cluster source and repeat broad enumeration plus command-injection behavior, while each is connected to the intervening/overlapping process thread by a high-confidence shared-workload/time-window link [redacted]. The observed pattern is coherent: enumeration and injection-pattern requests, recurring root shells and discovery, a sensitive-file access command, and later outbound-capable shell executions [redacted]. “Likely” is required because the traffic source is only a cluster, the process incident has no incident-cited HTTP origin, and workload/time proximity does not prove that any request created any process.
Observed workload execution
The strongest defensible assessment is that the two immutable incident threads likely represent one continuing operation, not proven identity or causality. Incident [redacted] records attempted exploitation with HTTP command indicators/output and closely timed root shell, discovery, and sensitive-file-targeting process activity; incident [redacted] then records additional root dash shells and their exits in the same protected workload. Deterministic link [redacted] establishes shared-workload attribution and temporal proximity, and the later process-only activity begins about 68 seconds after the first incident's last observation. This behavioral and temporal continuity favors a continuation, but the absence of a unique request-to-process edge and the lack of correlated HTTP evidence for the second thread prevent a definitive same-operation finding.
Observed workload execution
The three preserved incident threads are best explained as a likely single exploitation operation, but not conclusively. Incident [redacted] records sustained HTTP command-injection activity, server-generated root identity output, and correlated root shell/discovery execution. Process-only incidents [redacted] and [redacted] then show closely overlapping root-shell, discovery, and outbound-capable-client activity on the protected workloads. Deterministic links [redacted] and [redacted] connect those threads to [redacted] by shared workload attribution and temporal proximity at 0.9 confidence. The behavioral similarity and tight timing support coordinated continuation, while the absence of unique HTTP-to-process trace edges and unresolved source identity prevent a definitive same-operation finding.
Observed workload execution
The two immutable incident threads are best explained as complementary views of one likely exploitation and post-exploitation operation against the same protected workload. Incident [redacted] records sustained HTTP reconnaissance/exploitation activity and repeated same-window suspicious request/process patterns; incident [redacted] records overlapping root shell, discovery, outbound-capable process, and sensitive-file activity. Deterministic link [redacted] confirms shared-workload attribution and temporal proximity. This supports likely—not proven—common operation because neither the link nor incident evidence provides a unique HTTP-request-to-process edge or a unique actor identity. Incident boundaries remain intact.
Observed workload execution
The four preserved incident threads are best explained as a likely single operation, while falling short of proof. Earlier HTTP reconnaissance in incident [redacted] is connected to the later attempted-exploitation thread [redacted] by the same-source-cluster link [redacted]. The later HTTP/execution activity in [redacted] is temporally and workload-associated with the process-only threads [redacted] and [redacted] through links [redacted] and [redacted]. Together these form a coherent possible progression from enumeration to attempted exploitation and workload execution. The assessment remains “likely” because the source cluster is not an actor identity, the earlier reconnaissance has a substantial timing gap, and no unique request-to-process causality edge connects the HTTP and process events [redacted].
Observed workload execution
The strongest defensible explanation is a likely single operation spanning HTTP reconnaissance/exploit attempts and subsequent or overlapping process activity, while preserving all four incident boundaries. Incident [redacted] records sustained surface enumeration and injection-associated requests; incidents [redacted], [redacted], and [redacted] record temporally proximate shell and related workload activity. Deterministic links [redacted] and [redacted] connect the HTTP thread to process threads by protected-workload attribution and time, while [redacted] strongly connects two process threads to the same workload. This is coherent with one progression, but not conclusive: no incident provides a unique HTTP-request-to-process trace edge, one process thread belongs to a distinct workload cluster, and actor identity and authorization remain unresolved.
Observed workload 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.
Observed workload execution
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.
Observed workload execution
The two preserved incident threads are best explained as likely phases of the same operation: an initial command-injection probe in incident [redacted], followed about 43 minutes later by repeated command-injection activity and observed root-level workload consequences in incident [redacted]. The strongest cross-incident support is deterministic link [redacted], which places both incidents in the same privacy-preserving source cluster against the same target within the bounded period. This does not prove one actor or a causal continuation because that cluster can represent shared infrastructure or multiple workers, and no unique request-to-process edge connects the threads.
Observed workload execution
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.
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
Broad unauthenticated route and HTTP method enumeration observed
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
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.
Attempted exploitation
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]).
Attempted exploitation
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.
Attempted exploitation
The two preserved incident threads are most defensibly assessed as likely parts of the same operation, not proven to be one operation. Both concern attempted exploitation of the same target, and the deterministic same-source-cluster link places them within a roughly 55-minute window (incidents [redacted] and [redacted]; link [redacted]). The later incident has an incident-level likely-true-positive command-injection verdict, but no completed verdict was returned for the earlier incident, so a shared exploit technique, actor, or causal progression is not established (incidents [redacted] and [redacted]).
Attempted exploitation
The two preserved incident threads are best explained as separate bursts or phases of one automated probing operation against the same target, but not as proof of one actor. Incident [redacted] records broad unauthenticated HTTP surface enumeration; after an approximately 21-minute gap, incident [redacted] records renewed broad enumeration plus repeated POST/payload probing and carries the higher attempted-exploitation classification. The deterministic same-source-cluster link [redacted] strongly supports continuity. Confidence remains below definitive because that cluster can represent a proxy, NAT gateway, shared account, or multiple workers, and neither temporal proximity nor shared targeting supplies a unique causal or actor-identity edge. No exploit success or post-exploitation consequence is established.
Attempted exploitation
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.
Attempted exploitation
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.
Attempted exploitation
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.
Attempted exploitation
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.
Attempted exploitation
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.
Attempted exploitation
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.
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Reconnaissance
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.
Opportunistic scan
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.
Opportunistic scan
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.
Reconnaissance
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.
Opportunistic scan
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.
Reconnaissance
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Reconnaissance
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Reconnaissance
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.
Reconnaissance
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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]]
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Reconnaissance
The two preserved incident threads are best explained as repeated phases of one reconnaissance operation against the same target: both recorded broad unauthenticated HTTP route/method enumeration from the same privacy-preserving source cluster, and the deterministic same-source link connects them within the case window [redacted]. This remains “likely,” not definitive, because the first thread ended at [redacted]32Z and the second began at [redacted]04Z, and a source cluster can represent shared infrastructure or multiple workers [redacted]. No exploitation or post-reconnaissance consequence is established in either thread [redacted].
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Reconnaissance
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.
Opportunistic scan
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.