Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 21, 4:34:40 AM PDT
Evidence through
Aug 21, 4:35:02 AM PDT
AI status
Complete
Likely true positive98% confidence

The incident is strongly consistent with genuine opportunistic reconnaissance for exposed PHP/WordPress web shells. Verified HTTP summaries show rapid GET probes categorized as php_or_wordpress_probe against target privatekind, with 301 redirects or 404 rejections. The derived detector reports 39 requests covering 20 unique probe paths in about 11 seconds. Available evidence establishes the scan attempt, but not web-shell presence, command execution, or compromise; no process or flow evidence references are cited by this incident.

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

Observed impact

  • The target was exposed to rapid opportunistic enumeration of suspected PHP and WordPress web-shell locations.
  • No confirmed execution, persistence, outbound activity, or other workload compromise 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

  • The source_key is a traffic/workload cluster, not a guaranteed identity; it may represent a proxy, NAT gateway, or multiple workers.
  • Downstream workload affinity is inferred from configured target routing rather than an observed per-request trace edge.
  • The incident cites no process or conntrack event IDs. Process and flow evidence therefore could not be retrieved for consequence assessment, so execution or outbound effects cannot be confirmed or excluded from those planes.
  • Exact probe paths are intentionally excluded from bounded summaries; only their hashes, categories, and segment counts are available.
  • HTTP status alone cannot prove exploit failure. The available summaries do not describe the content of non-empty 404 response bodies, so they cannot independently exclude server-generated output.

Recommended actions

  1. Retain the HTTP evidence and review adjacent gateway activity from the same source cluster for follow-up POST requests, command parameters, uploads, authentication attempts, or successful responses.
  2. Validate that the probed PHP/WordPress paths do not map to deployed files; review application file-integrity and deployment records for unexpected PHP artifacts.
  3. Review workload process and outbound-network telemetry for the incident window and a reasonable period afterward, because those planes are not cited in this incident.
  4. Apply proportionate rate limiting or blocking to the source cluster if consistent with policy, while accounting for possible NAT or proxy aggregation.
  5. Confirm WordPress core, plugins, themes, and PHP components are patched and remove unused internet-exposed endpoints.