Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 28, 11:45:54 PM PDT
Evidence through
Aug 28, 11:46:24 PM PDT
AI status
Complete
True positive98% confidence

This is a true positive for rapid opportunistic reconnaissance, not confirmed exploitation. The detector recorded 39 requests across 20 PHP/WordPress probe paths in about 4.3 seconds, and the bounded HTTP summaries show representative GET probes receiving 301 redirects or 404 rejections. The derived detector outcome remains redirect_or_rejection_only. There is no cited process or flow evidence with which to establish command execution, outbound activity, or any request-to-consequence causal edge.

Attack stage
Reconnaissance: opportunistic discovery/enumeration of PHP and WordPress web-shell paths
Model
gpt-5.6-sol · 6 evidence calls

Observed impact

  • A short burst of probe traffic was handled by the target and produced redirect/rejection responses (HTTP refs [redacted] and [redacted]).
  • No post-request workload or network consequence is verified; the incident cites no process-plane or flow-plane event that can support such a conclusion.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

280 observations · 12 http

Explicit uncertainty

  • The source_key is a traffic/workload cluster, not a verified human or agent identity; it may represent a proxy, NAT gateway, or multiple workers.
  • Configured target routing does not establish an observed 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 return decision evidence. Command execution and outbound activity cannot be independently assessed.
  • HTTP status and the derived redirect/rejection outcome alone do not prove exploit failure. The bounded summaries show no server-generated command output, but they do not establish a complete workload-level absence of execution.
  • The 39-request and 20-path totals are detector-derived aggregate facts supported by 12 cited HTTP references; only bounded summaries of those references were available, not all raw requests.

Recommended actions

  1. Retain the cited HTTP telemetry and monitor the source cluster for retries, payload-bearing requests, authentication attempts, or a shift from enumeration to exploitation.
  2. Review the target's deployed PHP/WordPress files, plugins, and recent changes for unauthorized web-shell artifacts, prioritizing the probed application areas; do not infer compromise solely from this scan.
  3. Apply or confirm rate limiting and path-based filtering for known web-shell enumeration patterns. Treat source-cluster blocking cautiously because the cluster may represent shared proxy or NAT infrastructure.
  4. If workload process and conntrack telemetry exists outside this incident, correlate it over the incident window for unusual interpreter or shell execution and unexpected outbound connections; preserve uncertainty unless a causal edge is established.
  5. Confirm that public-to-private routing, redirect behavior, and 404 handling are intentional and that unsupported PHP/WordPress paths are not exposed.