Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 25, 5:04:00 AM PDT
Evidence through
Aug 25, 5:04:23 AM PDT
AI status
Complete
True positive98% confidence

This is a true-positive opportunistic reconnaissance event, not a confirmed compromise. The incident’s cited sequence records rapid GET enumeration of PHP/WordPress probe paths against target privatekind; inspected examples produced only HTTP 301 redirects or 404 responses (HTTP [redacted], [redacted], [redacted], [redacted]). The detector’s aggregate is 39 requests across 20 unique probe paths in about 4.2 seconds, with all 39 classified as redirects/rejections. No cited process or flow events were available to establish execution or egress, so successful exploitation is not demonstrated.

Attack stage
Reconnaissance—PHP/WordPress web-shell path enumeration
Model
gpt-5.6-sol · 5 evidence calls

Observed impact

  • No confirmed compromise or command execution; inspected HTTP events show only 301/404 outcomes [redacted].
  • Operational impact appears limited to a short burst of rejected probe traffic [redacted].

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

226 observations · 12 http

Explicit uncertainty

  • The source key is a traffic/workload cluster, not a proven human or agent identity; it may represent a proxy, NAT gateway, or multiple workers.
  • No process or flow events are cited by this incident. Required process/flow lookups therefore had no eligible cited IDs, so the available evidence cannot independently assess execution, persistence, or outbound connections.
  • HTTP status codes alone cannot prove exploit success or failure. The bounded summaries expose sizes and hashes but not raw response content; no cited server-generated command output is available.
  • Downstream workload affinity is inferred from configured target routing rather than an observed per-request trace edge.

Recommended actions

  1. Continue monitoring target privatekind for repeated PHP/WordPress path enumeration and escalate if later events show successful content retrieval, uploads, command output, or authenticated access.
  2. Consider proportionate rate limiting or temporary blocking for the source cluster, while accounting for the possibility that it represents shared proxy or NAT infrastructure.
  3. Have the service owner verify that unexpected PHP files and WordPress components are absent or fully patched, and review application logs around 2026-08-25T12[redacted]00Z–[redacted]05Z.
  4. Retain and correlate workload process, file-integrity, and egress telemetry for the incident window; absence of cited process/flow evidence here should not be treated as proof that no consequence occurred.