Live operation queue
Cases
Potential operations correlated across HTTP, process, network, and workload evidence.
Suspicious activity
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.
Suspicious activity
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.
Suspicious activity
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.
Suspicious activity
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.
Confirmed compromise
The five preserved incident threads are most plausibly phases or repeated actions within one operation against the same target: broad reconnaissance, command-injection attempts, confirmed workload compromise, additional command/discovery activity, and a later injection attempt with a temporally correlated root shell. The incidents form an unbroken deterministic same-source-cluster chain across about 2.4 hours. This supports likely—not definitive—common operation because the source cluster may conceal a proxy, NAT, shared account, or multiple workers, and workload/time correlation does not establish unique request-to-process causality. Incident boundaries and detector classifications remain unchanged.
Suspicious activity
The two preserved incident threads are best treated as a likely single operational sequence, not a proven one. Both record closely spaced, root-context shell/discovery behavior in the same protected workload, and deterministic link [redacted] associates incidents [redacted] and [redacted] with 0.93 confidence. Incident [redacted] contains initial dash/id sequences at 18:22, while incident [redacted] begins about 25 minutes later with recurring dash/discovery activity, including env discovery and sensitive-file targeting. This behavioral continuity supports likely continuation, but the same-workload link does not establish one actor or causal chain; neither incident supplies correlated HTTP or flow evidence identifying the initiating action.
Suspicious activity
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.
Attempted exploitation
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.
Confirmed compromise
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.
Opportunistic scan
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.
Opportunistic scan
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.
Reconnaissance
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.
Opportunistic scan
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.
Reconnaissance
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.
Reconnaissance
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.
Confirmed compromise
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.
Confirmed compromise
The strongest defensible assessment is that the four preserved incident threads are likely parts of one operation against the same protected target, not proven to be one actor or one causal chain. Two recurring source-cluster tracks—[redacted] with [redacted], and [redacted] with [redacted]—are joined by shared-workload and temporal correlation between [redacted] and [redacted] (links [redacted], [redacted], [redacted]). The tightly interleaved exploitation activity and confirmed workload compromise support operational continuity, but the distinct source clusters and absence of unique request-to-process edges prevent a definitive same-operation conclusion (incidents [redacted], [redacted], [redacted], [redacted]).
Confirmed compromise
The strongest defensible assessment is that these are likely two stages of one operation: an initial command-injection attempt thread ([redacted]) followed about 25 minutes later by a confirmed command-execution/root-shell thread ([redacted]). Both targeted the same target and are joined by the deterministic same-source-cluster link ([redacted]). This supports continuity, but not certainty: the privacy-preserving source cluster could multiplex actors or workers, and no evidence establishes that a request from the earlier thread caused execution in the later thread.
Confirmed compromise
The five preserved incident threads are best explained as one sustained exploitation operation against the same target, progressing from command-injection attempts to high-volume exploitation activity and then confirmed root command execution ([redacted], [redacted], [redacted], [redacted], [redacted]; links [redacted], [redacted], [redacted], [redacted]). This is likely, not definitive: the shared privacy-preserving source cluster may represent multiple workers, and temporal/workload correlation does not establish unique request-to-process causality. Incident boundaries and classifications remain unchanged.
Confirmed compromise
Exploit request received non-reflected process identity output
Attempted exploitation
The two preserved incident threads are best explained as likely parts of one operation because they concern the same target and are joined by a deterministic same-source-cluster link within an approximately 31-minute case window [redacted]. The earlier thread is high-severity attempted exploitation, while the later thread is medium-severity suspicious activity with additional system-information disclosure recorded [redacted]. This is a plausible follow-on sequence, but neither common actor identity nor request-to-process causality is established, so a definitive same-operation finding is not warranted [redacted].
Attempted exploitation
The two preserved incident threads are best explained as likely parts of the same operation: they affected the same target, carried the same attempted-exploitation classification and server-identity-disclosure consequence, and were tied by a confidence-0.86 same-source-cluster link within a bounded window (incidents [redacted] and [redacted]; link [redacted]). This is not strong enough for a definitive same-operation conclusion because the shared source cluster may represent a proxy, NAT gateway, shared account, or multiple workers (link [redacted]).
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
Rapid enumeration of PHP and WordPress web-shell paths
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
The two incident threads are best assessed as likely parts of the same operation, while preserving them as separate incidents. They affected the same target, were linked by the same privacy-preserving source cluster within the bounded case window, and both showed non-reflected root process-identity output [redacted]. The later thread added command-injection attempts and workload-proximate root shell/discovery process observations [redacted]. This supports a possible progression from initial execution validation to repeated exploitation activity, but does not prove a common actor or a unique request-to-process causal chain [redacted].
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
Response contains non-reflected process identity output
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
The two preserved incident threads are best explained as successive phases of one likely operation against the same target. They share a deterministic same-source-cluster link, closely aligned command-injection behavior, workload shell/discovery effects, and a short temporal separation. The earlier thread ran from [redacted]27Z to [redacted]03Z and the later thread began at [redacted]16Z, leaving about 25 minutes between them. This supports continuity but does not prove a single actor, worker, request chain, or causal request-to-process/flow path.
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
Request contains shell metacharacters and command tokens
Attempted exploitation
Request contains shell metacharacters and command tokens
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths
Opportunistic scan
Rapid enumeration of PHP and WordPress web-shell paths