Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 30, 1:36:21 PM PDT
Evidence through
Aug 30, 1:36:54 PM PDT
AI status
Complete
Likely true positive97% confidence

The incident is strongly consistent with real opportunistic PHP/WordPress web-shell path enumeration against target privatekind. Verified HTTP summaries show rapid GET requests categorized as PHP/WordPress probes from the same source cluster, with distinct path hashes and rejection/redirect outcomes. The available responses include 404s and a 301; these support unsuccessful discovery attempts but, by themselves, do not prove that every request failed to trigger application behavior. No process or flow evidence is cited by this incident, so there is no evidence-grounded basis to claim command execution, outbound activity, persistence, or compromise. The verdict therefore affirms the scanning activity, not successful exploitation.

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

Observed impact

  • Observed impact is limited to a short burst of inbound probe traffic; no confirmed execution, outbound activity, persistence, or compromise is established.
  • The probes tested whether PHP/WordPress web-shell-like paths were exposed, creating discovery risk even though the observed HTTP outcomes were redirects or rejections.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

314 observations · 12 http

Explicit uncertainty

  • The source_key identifies a traffic/workload cluster, not a guaranteed individual, host, or agent; it may represent NAT, a proxy, or multiple workers.
  • No process-plane or flow-plane evidence references are cited by this incident, so command execution and outbound network consequences cannot be assessed from the available bounded evidence.
  • The bounded HTTP summaries expose status, size, and hashes rather than raw response content. HTTP status alone cannot conclusively exclude server-side behavior or command output.
  • Whether the traffic was an authorized vulnerability scanner is not established by the available evidence.
  • Target routing affinity is configured/inferred rather than an observed per-request downstream trace edge.

Recommended actions

  1. Review gateway and application logs around 2026-08-30T20[redacted]21Z–[redacted]26Z for the full probe set and any subsequent non-rejected requests from the same source cluster.
  2. Verify that no unexpected PHP files, WordPress plugins/themes, upload artifacts, or web-shell endpoints are deployed on the target; compare against approved release manifests where available.
  3. Apply or confirm rate limiting and path-based rejection for recurring PHP/WordPress probe patterns, while accounting for approved scanners.
  4. Monitor the source cluster and equivalent probe patterns for escalation, but do not isolate the workload solely on this evidence because no compromise consequence is established.