Back to evidence

Sanitized live incident

Opportunistic scan

Native source identity and targetable endpoints are private.

mediumopen
Confidence
96%
First seen
Aug 20, 1:50:23 AM PDT
Evidence through
Aug 20, 1:51:17 AM PDT
AI status
Complete
True positive98% confidence

True positive for opportunistic PHP/WordPress web-shell path enumeration, based on a rapid sequence of categorized probe requests from one traffic cluster against target privatekind (for example [redacted], [redacted], [redacted], and [redacted]). The cited HTTP outcomes are redirects or rejections, including 301 and 404 responses; this supports detection of scanning but does not by itself prove exploit failure. No process or flow evidence was cited by the incident, so execution, compromise, or follow-on network activity is not established.

Attack stage
Reconnaissance: attempted web-shell discovery/path enumeration; no established execution
Model
gpt-5.6-sol · 7 evidence calls

Observed impact

  • Observed impact is limited to repeated HTTP probing of target privatekind; representative cited requests received 301 or 404 outcomes ([redacted], [redacted], ad3f508e-3a2d-4863-953b-9be3c
  • No command execution, persistence, lateral movement, data theft, or request-linked egress is established by the incident's cited evidence; the incident provides HTTP references only.

Deterministic signals

Http.php webshell enumeration96%

Rapid enumeration of PHP and WordPress web-shell paths

266 observations · 12 http

Explicit uncertainty

  • The incident cites only HTTP event IDs. Process and flow evidence queries could not return summaries because those HTTP IDs are not cited process/flow events; therefore command execution and follow-on egress cannot be affirmatively assessed from those planes.
  • HTTP status codes and empty redirect bodies do not alone prove that every probe failed or that the workload was uncompromised before this scan.
  • Source_key [redacted] may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • Downstream workload affinity is inferred from configured routing and is not an observed per-request trace edge.

Recommended actions

  1. Keep the alert as a confirmed scan/reconnaissance event and correlate this source cluster with nearby gateway activity for additional probe families or later requests receiving materially different responses.
  2. Apply proportionate rate limiting or temporary blocking to the source cluster if consistent with policy, while accounting for possible proxy/NAT sharing.
  3. Verify that the probed PHP/WordPress or web-shell paths are not deployed and review application/file-integrity telemetry around the incident window before concluding there was no compromise.
  4. Improve or validate process and conntrack telemetry correlation for target privatekind so future HTTP probes can be assessed for execution and egress consequences.
  5. Continue monitoring rather than initiating high-impact containment solely from these rejected/redirected probes, unless independent workload evidence indicates compromise.