Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 26, 1:58:08 PM PDT
Evidence through
Aug 26, 1:58:15 PM PDT
AI status
Complete
True positive98% confidence

This is a true positive for opportunistic reconnaissance: a single derived traffic cluster rapidly enumerated PHP and WordPress web-shell-style paths on target privatekind. The incident records 64 requests across 32 unique probe paths in roughly seven seconds. Verified HTTP samples are GET requests categorized as PHP/WordPress probes and show only redirects or 404 responses. The available evidence establishes scanning, but it does not establish successful exploitation or any downstream workload consequence.

Attack stage
Reconnaissance — PHP/WordPress web-shell path enumeration
Model
gpt-5.6-sol · 7 evidence calls

Observed impact

  • Automated reconnaissance reached the application-facing HTTP service; observed outcomes were redirects or rejection responses, with no demonstrated post-request consequence.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

64 observations · 12 http

Explicit uncertainty

  • The source key identifies a traffic or workload cluster, not a guaranteed individual actor; it may represent a proxy, NAT gateway, or multiple workers.
  • Target-to-workload affinity is inferred from configured routing and is not an observed per-request trace edge.
  • No process or flow evidence identities are cited by this incident, so command execution and outbound network consequences cannot be independently evaluated from those planes.
  • The bounded HTTP summaries exclude raw response content; 404/301 outcomes support rejection or redirection but cannot by themselves rule out all server-side effects.
  • Whether this scanning was authorized security testing is not established by the available evidence.

Recommended actions

  1. Continue monitoring the source cluster for follow-on exploit attempts, authentication activity, uploads, or successful responses.
  2. Apply rate limiting or temporary blocking to the source cluster if consistent with policy and operational context.
  3. Verify that probed PHP/WordPress paths are absent or inaccessible and review application logs around the incident window for unexpected handler execution.
  4. Keep WordPress, PHP applications, plugins, themes, and the fronting web stack patched; remove unused components and exposed administrative endpoints.
  5. If the target is not intended to serve PHP or WordPress, consider explicit deny rules for these probe patterns while avoiding disruption to legitimate routes.