Sanitized live incident
Opportunistic scan
Native source identity and targetable endpoints are private.
mediumopen
- Confidence
- 96%
- First seen
- Aug 20, 5:54:58 AM PDT
- Evidence through
- Aug 20, 5:55:33 AM PDT
- AI status
- Complete
True positive99% confidence
The cited HTTP evidence confirms a rapid, automated-looking PHP/WordPress path-enumeration scan against target privatekind. Representative requests were bodyless GETs categorized as php_or_wordpress_probe and produced only 301 redirects or 404 responses. This establishes reconnaissance/probing, not successful exploitation. No process or flow evidence references are present in the incident, so command execution, outbound activity, persistence, or other compromise consequences are not established.
- Attack stage
- Reconnaissance / web-shell path discovery
- Model
- gpt-5.6-sol · 6 evidence calls
Observed impact
- Unauthorized reconnaissance reached the HTTP service and enumerated suspected PHP/WordPress web-shell locations.
- No successful exploitation or downstream workload impact is demonstrated by the cited evidence.
Deterministic signals
Rapid enumeration of PHP and WordPress web-shell paths
304 observations · 12 httpExplicit uncertainty
- No process-plane event references are cited by this incident; therefore the available evidence cannot determine whether any workload process activity occurred during or after the scan.
- No flow-plane event references are cited by this incident; therefore the available evidence cannot assess correlated outbound connections or destination novelty.
- The source key is a 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.
- The bounded HTTP summaries exclude exact paths and raw response bodies; they confirm probe categorization and response metadata but do not independently reveal the specific filenames tested or body content.
Recommended actions
- Keep the incident open briefly for correlation with later HTTP, process, and flow telemetry from the same target and time window; escalate only if execution or other compromise evidence appears.
- Review the target for exposed or unexpected PHP/WordPress files and web shells, prioritizing recently modified files and publicly reachable upload/plugin directories.
- Confirm that redirects and 404 handling are expected and that no alternate virtual host or redirect destination exposes the probed resources.
- Apply proportional rate limiting or temporary source-cluster blocking if the scanning continues, while accounting for possible NAT or proxy aggregation.
- Preserve the cited HTTP evidence and search application/access logs for subsequent requests from the same traffic cluster that returned unusual content or accessed valid administrative/upload endpoints.