Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 27, 7:55:44 PM PDT
Evidence through
Aug 27, 7:56:13 PM PDT
AI status
Complete
True positive99% confidence

True positive for opportunistic PHP/WordPress web-shell path enumeration, not for confirmed compromise. The incident records 236 requests spanning 119 probe paths in about 29 seconds. The inspected complete HTTP summaries show bodyless GET requests categorized as PHP/WordPress probes and responses of 301 or 404. No process or flow evidence is cited by the incident, so command execution and downstream network consequences are not established.

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

Observed impact

  • Observed impact is limited to rapid application-path probing; the supplied evidence does not establish command execution, persistence, data access, exfiltration, or an attacker-induced outbound connection.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

236 observations · 12 http

Explicit uncertainty

  • The source_key is a derived traffic/workload cluster and may represent a proxy, NAT gateway, multiple workers, or another shared origin; it is not a proven actor identity.
  • Downstream workload affinity is inferred from configured target routing rather than an observed per-request trace edge.
  • The incident cites no process or flow event IDs available to the bounded process and conntrack evidence tools. Consequently, the available evidence cannot determine whether any workload process execution or outbound connection occurred during the window.
  • HTTP status codes and body hashes alone cannot prove exploit success or failure. The bounded summaries expose no server-generated command output, and exact response contents are unavailable.
  • Exact request paths are intentionally excluded from the bounded summaries, so individual filenames and whether any probed path actually exists cannot be verified here.

Recommended actions

  1. Retain or strengthen rate limiting and blocking for rapid PHP/WordPress probe enumeration at the gateway.
  2. Review application and origin logs around 2026-08-28T02[redacted]44Z–[redacted]14Z to confirm whether redirected requests were followed and whether any matching paths were served by the downstream workload.
  3. Verify that unexpected PHP files, WordPress components, and common web-shell filenames are absent from the deployed artifact and writable web roots.
  4. If broader telemetry is available, check process and outbound-flow activity in the same window, while avoiding assumptions of request-to-process or request-to-socket causality.
  5. Continue monitoring the source cluster and equivalent probe patterns; treat source-based blocking cautiously because the cluster may represent shared infrastructure.