Sanitized live incident
Opportunistic scan
Native source identity and targetable endpoints are private.
- Confidence
- 96%
- First seen
- Aug 28, 6:11:06 AM PDT
- Evidence through
- Aug 28, 6:12:43 AM PDT
- AI status
- Complete
The incident is a true positive for rapid opportunistic enumeration of PHP/WordPress web-shell paths against target privatekind. The detector reports 38 requests over roughly 7.7 seconds and 20 unique probe paths; the verified cited samples are bodyless GET requests categorized as PHP/WordPress probes and received only 301 or 404 responses. This establishes hostile or unauthorized reconnaissance behavior, but not successful exploitation or compromise. No process or flow evidence is cited by the incident, so execution, outbound communication, persistence, or other post-request consequences cannot be determined from the available evidence.
- Attack stage
- Reconnaissance / web-shell path enumeration
- Model
- gpt-5.6-sol · 16 evidence calls
Observed impact
- Observed impact is limited to rapid HTTP probing of suspected PHP/WordPress web-shell locations.
- No successful command execution, persistence, outbound callback, lateral movement, or data loss is established by the available evidence.
Deterministic signals
Rapid enumeration of PHP and WordPress web-shell paths
522 observations · 12 httpExplicit uncertainty
- No process or flow evidence references are cited by this incident. Queries to the process and flow evidence tools therefore could not retrieve decision-relevant telemetry, leaving execution and network consequences unassessed.
- HTTP status alone cannot establish exploit success or failure, and the bounded summaries do not expose response contents needed to determine whether the 404 response body contained any server-generated output.
- The source_key is a derived traffic/workload cluster and may represent a proxy, NAT gateway, multiple workers, or another shared source rather than one human or agent.
- Downstream workload affinity is inferred from configured target routing rather than an observed per-request trace edge.
- Exact request paths are intentionally withheld; path categories and hashes establish probe type and diversity but not the literal names requested.
Recommended actions
- Retain the cited gateway events and review application/origin logs for the same time window to confirm whether any requests reached a workload and whether the 404 response body was a standard error page.
- Verify that none of the probed PHP or WordPress web-shell locations exist on the target, and review recent file-integrity or deployment records for unexpected PHP files.
- Search workload process telemetry around the incident window for web-server child processes or shell/interpreter execution; search network telemetry for unusual outbound connections, while avoiding claims of causality without trace-level linkage.
- Continue rejecting or redirecting these paths; consider rate limiting or a narrowly scoped gateway rule for repeated PHP/WordPress shell enumeration if operationally appropriate.
- Do not attribute the activity to a specific person or automatically block a broad shared source solely from source_key clustering; correlate with independently verified network identity first.