Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Sep 1, 10:20:50 AM PDT
Evidence through
Sep 1, 10:21:03 AM PDT
AI status
Complete
True positive98% confidence

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.

Attack stage
Reconnaissance / discovery: PHP and WordPress web-shell path enumeration
Model
gpt-5.6-sol · 6 evidence calls

Observed impact

  • Observed impact is limited to hostile scanning traffic and associated request handling; no verified workload execution, outbound connection, persistence, lateral movement, or data loss is established.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

112 observations · 12 http

Explicit uncertainty

  • HTTP status and response size alone cannot conclusively prove that no vulnerable resource was reached; the available summaries contain no server-generated command output or other success indicator.
  • No process or flow evidence events are cited by this incident. Queries using the cited HTTP event IDs were rejected by those evidence planes, so workload execution and network consequences cannot be independently assessed rather than assumed absent.
  • The source key identifies a traffic cluster, not a guaranteed individual actor; it may represent a proxy, NAT gateway, or multiple workers.
  • Downstream workload affinity is inferred from configured target routing and is not an observed per-request trace edge.

Recommended actions

  1. Retain and monitor the source cluster and associated indicators for recurrence; apply proportionate rate limiting or blocking if consistent with policy and operational context.
  2. Verify that the probed PHP/WordPress or web-shell-like paths are not intentionally deployed and review application file integrity and recent administrative changes on the routed workload.
  3. Review surrounding application and gateway telemetry for successful responses, uploads, authentication anomalies, or command-like output beyond this incident window.
  4. Keep unnecessary PHP/WordPress endpoints disabled, patch exposed components, and ensure gateway rejection and redirect controls remain effective.