Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 21, 6:37:54 PM PDT
Evidence through
Aug 21, 6:38:07 PM PDT
AI status
Complete
True positive98% confidence

This is a true-positive opportunistic web-shell/path-enumeration scan against target privatekind. The detector recorded 39 requests over roughly six seconds, spanning 20 PHP/WordPress probe paths; the inspected bounded HTTP summaries show bodyless GET probes receiving redirects or 404 responses. The available evidence establishes reconnaissance/probing, but not successful exploitation or compromise. No process or flow evidence references are available in this incident, and HTTP status codes alone cannot prove exploit failure.

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

Observed impact

  • The target received rapid automated probing of PHP and WordPress paths.
  • No confirmed command execution, outbound connection, persistence, data access, or other compromise consequence is established by the available cited evidence.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

92 observations · 12 http

Explicit uncertainty

  • No process-plane or flow-plane event references are cited by this incident; the evidence tools therefore could not return process or conntrack summaries. Command execution and outbound network consequences cannot be independently assessed.
  • HTTP 301/404 status codes do not by themselves prove that exploitation failed. Raw response bodies are not exposed, so the content of non-empty rejection responses cannot be independently inspected here.
  • The source_key identifies a derived traffic cluster, not a guaranteed single human or agent; it may represent a proxy, NAT gateway, or multiple workers.
  • Downstream workload affinity is inferred from configured target routing and is not an observed per-request trace edge.

Recommended actions

  1. Retain the cited gateway evidence and correlate the six-second window with application, web-server, endpoint, and container telemetry if available.
  2. Inspect the target for unexpected PHP files, recently modified web content, or known web-shell artifacts, especially if PHP or WordPress is intentionally deployed.
  3. Review process creation and outbound connection telemetry around the incident window; escalate only if anomalous execution or egress is found.
  4. Consider proportionate rate limiting or blocking for repeated probe clusters, while accounting for the possibility that the source cluster represents shared NAT or proxy infrastructure.
  5. Confirm that unused PHP/WordPress routes are not exposed and keep any deployed CMS, plugins, themes, and web server components patched.