Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 25, 9:33:59 PM PDT
Evidence through
Aug 25, 9:34:17 PM PDT
AI status
Complete
True positive98% confidence

The incident is a true positive for opportunistic PHP/WordPress web-shell path enumeration, not for confirmed compromise. The deterministic detector remains open with a medium-severity scan classification. Verified HTTP summaries show rapid GET probes categorized as PHP/WordPress probes, while the incident aggregates 39 requests across 20 unique probe paths in about 5.4 seconds. The observed responses were redirects or rejections; the available record does not establish command execution or any follow-on host/network consequence.

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

Observed impact

  • Observed impact is limited to unsolicited web-path reconnaissance against the target.
  • No exploit execution, persistence, lateral movement, command-and-control, or data theft is established by the cited evidence.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

138 observations · 12 http

Explicit uncertainty

  • No process-plane or flow-plane evidence references are cited by this incident. Queries using the cited HTTP event IDs were rejected as not being process/flow events, so workload execution and outbound-flow consequences cannot be independently evaluated from those planes.
  • HTTP status alone cannot conclusively prove exploit failure. The bounded HTTP summaries expose response sizes and hashes but not raw response content, so the 404 bodies cannot be independently inspected for server-generated output.
  • The source key is a traffic/workload cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • Target workload affinity is inferred from configured routing and is not an observed request-to-workload trace edge.

Recommended actions

  1. Retain the cited gateway records and continue monitoring the source cluster for retries, changed methods, payload-bearing requests, authentication attempts, or probes that receive materially different responses.
  2. Verify that the probed PHP/WordPress and web-shell-like paths are not deployed and that unnecessary PHP/WordPress components, plugins, upload directories, and script execution permissions are removed or hardened.
  3. Keep gateway/WAF rejection and rate-limit controls enabled; consider a temporary source-cluster block only if repeated activity warrants it and operational policy permits.
  4. Review workload process and egress telemetry around the incident window if available outside this bounded record; escalate containment only if execution, file changes, credential access, or suspicious outbound connections are found.