Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 29, 7:21:54 PM PDT
Evidence through
Aug 29, 7:22:19 PM PDT
AI status
Complete
True positive98% confidence

This is a true positive for opportunistic reconnaissance: the detector aggregated 39 rapid GET requests across 20 PHP/WordPress probe paths from one derived traffic cluster. The verified HTTP summaries show capture-complete probe requests receiving redirects or rejections, including 301 and 404 responses. The evidence supports web-shell path enumeration, but not successful exploitation or compromise. No process or flow evidence is cited by this incident, and HTTP status alone cannot establish exploit failure, so execution and network consequences remain unproven rather than ruled out.

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

Observed impact

  • Observed impact is limited to rapid inbound PHP/WordPress path probing and associated gateway/application request handling; no execution or outbound-network consequence is demonstrated.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

218 observations · 12 http

Explicit uncertainty

  • No process or flow event is cited by this incident; attempts to retrieve those planes using the cited IDs were rejected as uncited. Consequently, host execution and outbound-network consequences cannot be assessed from process or flow evidence.
  • HTTP status alone cannot conclusively prove exploit failure. The bounded HTTP summaries exclude exact response bodies, so the 404 body content cannot be independently inspected for server-generated command output.
  • The source_key is a derived traffic/workload cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • Downstream workload affinity is inferred from configured target routing and is not an observed per-request trace edge.

Recommended actions

  1. Retain the HTTP evidence and monitor the same source cluster and target for follow-on requests, successful responses, authentication activity, uploads, or command parameters.
  2. Review the target's deployed PHP/WordPress files and routing configuration to confirm that none of the probed web-shell paths exists and that redirects do not expose an alternate reachable endpoint.
  3. Where operationally appropriate, apply rate limiting or temporary source-cluster blocking for repeated web-shell enumeration while accounting for possible proxy/NAT aggregation.
  4. Correlate with workload process, file-integrity, and egress telemetry over the incident window if those data are available outside this bounded incident evidence.