Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 21, 2:35:56 AM PDT
Evidence through
Aug 21, 2:36:09 AM PDT
AI status
Complete
True positive99% confidence

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.

Attack stage
Reconnaissance / web-shell path discovery
Model
gpt-5.6-sol · 6 evidence calls

Observed impact

  • Confirmed hostile or unauthorized-looking enumeration activity reached the HTTP service.
  • No workload compromise, command execution, persistence, or suspicious outbound connection is demonstrated by the cited evidence.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

118 observations · 12 http

Explicit uncertainty

  • The source_key is a derived traffic/workload cluster and may represent a proxy, NAT gateway, multiple workers, or another shared origin; it is not a proven human or agent identity.
  • The incident cites no process-plane or flow-plane event IDs. Consequently, the available evidence cannot determine whether any server-side process execution or outbound connection occurred around the requests.
  • Configured target routing does not provide an observed per-request trace edge to a specific downstream workload.
  • The bounded HTTP summaries provide response status, size, and hash but no semantic response-body content; therefore they cannot independently exclude command output or another server-side consequence.

Recommended actions

  1. Retain the HTTP evidence and monitor the source cluster for continued enumeration, authentication attempts, payload delivery, or shifts from GET probing to exploit requests.
  2. Review application and gateway logs for the full incident window and validate whether any probed paths actually exist or map to deployed PHP/WordPress components.
  3. If process and network telemetry is available outside this bounded incident, correlate it cautiously with the window for unusual web-server child processes, file changes, or outbound connections; do not infer unique request causality from timing alone.
  4. Consider proportionate rate limiting or temporary blocking for repeated probe behavior, while accounting for the possibility that the source cluster represents shared infrastructure.
  5. Verify that unnecessary PHP/WordPress components and known web shells are absent, and keep exposed applications and plugins patched.