Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 28, 8:29:48 AM PDT
Evidence through
Aug 28, 8:30:20 AM PDT
AI status
Complete
True positive98% confidence

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.

Attack stage
Reconnaissance / web-shell path enumeration; exploit success not established
Model
gpt-5.6-sol · 6 evidence calls

Observed impact

  • No confirmed compromise impact can be established from the available HTTP-only evidence; observed consequences are limited to probe traffic and redirect/rejection responses.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

302 observations · 12 http

Explicit uncertainty

  • The incident cites only HTTP evidence. Process and flow retrieval using the cited event IDs was unavailable because those IDs are not cited in those evidence planes, so execution and outbound-network consequences cannot be assessed from this incident.
  • HTTP status codes alone cannot prove exploit failure, and bounded summaries exclude exact paths, query strings, headers, and response-body content.
  • The source_key is a traffic/workload cluster, not a guaranteed human or agent identity; 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.
  • The available evidence does not establish whether the scanning was unauthorized or originated from an approved security scanner.

Recommended actions

  1. Review application and gateway logs for the full request set around 2026-08-28T15[redacted]48Z–[redacted]53Z and verify that all probes received expected redirect/rejection handling.
  2. Inspect the target's web root and deployment history for unexpected PHP files or recently modified WordPress components; prioritize the hashed probe-path set if internal mapping is available.
  3. Collect and correlate workload process and conntrack telemetry for the incident window, since no process or flow references were cited here.
  4. If the source cluster is not an approved scanner, apply proportionate rate limiting or temporary blocking and monitor for recurrence across related targets.
  5. Confirm ownership and authorization for the source cluster before attributing intent or taking durable enforcement action.