Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 25, 12:18:24 PM PDT
Evidence through
Aug 25, 12:30:30 PM PDT
AI status
Complete
True positive98% confidence

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.

Attack stage
Reconnaissance / discovery of exposed PHP or WordPress web-shell paths
Model
gpt-5.6-sol · 6 evidence calls

Observed impact

  • Attempted enumeration of potentially exposed PHP or WordPress web-shell endpoints.
  • No confirmed command execution, persistence, outbound connection, or other workload consequence in the available evidence.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

384 observations · 12 http

Explicit uncertainty

  • The source key identifies a traffic/workload cluster, not a verified person or single agent; 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 incident cites no process-plane or flow-plane event IDs. Queries against those planes therefore could not retrieve correlated execution or conntrack evidence, leaving workload execution and outbound-network consequences unverified.
  • The bounded HTTP summaries exclude exact paths and raw response bodies, so they cannot independently identify which named files were probed or inspect the 404 response content beyond verified metadata and hashes.

Recommended actions

  1. Continue monitoring this source cluster for follow-on requests, while avoiding attribution of the cluster to a unique actor.
  2. Review gateway/WAF controls for rate limiting or temporary blocking if the scan continues or expands.
  3. Verify that the probed PHP/WordPress paths are not deployed and review application files for unauthorized PHP artifacts using approved operational procedures.
  4. Review available workload process, file-integrity, application, and network telemetry around the incident window for any follow-on execution or outbound activity.
  5. Retain the cited HTTP evidence and correlate any subsequent signals with the same target and source cluster.