Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 29, 8:17:04 PM PDT
Evidence through
Aug 29, 8:17:36 PM PDT
AI status
Complete
True positive99% confidence

The incident is a true positive for opportunistic reconnaissance: one derived source cluster rapidly issued 39 GET requests covering 20 distinct PHP/WordPress probe paths against target privatekind between [redacted].030Z and [redacted].351Z. Representative complete captures returned redirects or rejections, including 301 and 404 responses (HTTP evidence [redacted], [redacted], and [redacted]). This establishes scanning/enumeration, but the available evidence does not establish web-shell access, command execution, persistence, or outbound activity.

Attack stage
Reconnaissance: PHP and WordPress web-shell path enumeration
Model
gpt-5.6-sol · 6 evidence calls

Observed impact

  • Reconnaissance traffic reached the target HTTP service; the cited HTTP evidence shows redirect/rejection outcomes rather than a verified exploit consequence.
  • No verified workload execution, persistence, lateral movement, outbound connection, or data loss is established by the evidence available for this incident.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

312 observations · 12 http

Explicit uncertainty

  • The source key is a traffic/workload cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • Target routing provides inferred workload affinity, not a per-request trace edge to a specific downstream workload.
  • The incident cites no process-plane or flow-plane event IDs; process and flow evidence queries therefore could not establish whether any temporally related execution or outbound connection occurred.
  • Bounded HTTP summaries exclude raw response bodies, so the 404 response body cannot be independently inspected here; HTTP status alone is not proof of exploit failure.

Recommended actions

  1. Retain and correlate the source cluster and probe-path hashes with subsequent authentication, upload, write, or command-execution alerts.
  2. Apply proportionate gateway rate limiting or blocking to repeated probe clusters if consistent with operational policy.
  3. Verify that the probed PHP/WordPress or web-shell paths are not deployed on the target and review recent file-integrity or deployment changes for unexpected PHP artifacts.
  4. Continue monitoring the routed workload for unusual child processes and novel outbound flows; escalate only if independently cited process or flow evidence appears.