Back to evidence

Sanitized live incident

Reconnaissance

Native source identity and targetable endpoints are private.

mediumopen
Confidence
92%
First seen
Aug 27, 8:58:02 PM PDT
Evidence through
Aug 27, 10:13:55 PM PDT
AI status
Complete
Likely true positive84% confidence

Likely true positive for automated HTTP reconnaissance against target privatekind, not for compromise. The detector aggregated 335 requests spanning 128 unique paths, three methods, and eight path categories from one traffic cluster; sampled evidence includes repeated POSTs to one API-route hash receiving 429 responses and later GETs across distinct API-route hashes receiving 401 responses (HTTP refs [redacted], [redacted], [redacted], [redacted], [redacted], [redacted]). This strongly supports route/method enumeration. Authorization and intent remain unknown, however, and the detector facts report that 293 of 335 requests were authenticated, so the signal summary's “unauthenticated” wording is not uniformly applicable. No process or flow evidence is cited by this incident, so consequences beyond HTTP probing are not established.

Attack stage
Reconnaissance / Discovery — HTTP surface enumeration
Model
gpt-5.6-sol · 8 evidence calls

Observed impact

  • Broad probing of the target's HTTP route and method surface was observed.
  • Available evidence does not establish command execution, outbound network consequences, persistence, lateral movement, or data loss.

Deterministic signals

Http.surface enumeration92%

Broad unauthenticated route and HTTP method enumeration observed

747 observations · 10 http

Explicit uncertainty

  • Authorization and intent are not established. The pattern could represent hostile reconnaissance, authorized security testing, or inventory/monitoring automation.
  • The source key is a derived traffic/workload cluster and may represent a proxy, NAT gateway, or multiple workers rather than one actor.
  • The incident cites only HTTP-plane events. Process and flow evidence tools had no incident-cited process or flow event IDs to retrieve, so host execution and outbound-network consequences cannot be adjudicated from this update.
  • The bounded summaries exclude exact paths, headers, query strings, and bodies, preventing assessment of which named routes were tested, what authentication principal was used, or whether request bodies contained exploit payloads.
  • HTTP status codes show sampled requests were rate-limited or unauthorized, but status alone does not establish the result of every request in the 335-request campaign.

Recommended actions

  1. Confirm with the service owner whether this source cluster and time window correspond to an authorized scanner, integration test, inventory job, or monitoring system.
  2. Review full gateway and application logs for the 335-request window, prioritizing non-rejected responses, sensitive route categories, authentication principal(s), and any unusual response-size or latency patterns.
  3. Because most requests were reported as authenticated, validate the associated credential or service account, its expected route scope, and whether rotation or revocation is warranted if the activity is unauthorized.
  4. Maintain or tune rate limiting and authentication controls for enumeration-prone endpoints; consider source throttling only after accounting for possible shared proxies or NAT.
  5. If the activity is unauthorized, search adjacent telemetry for the same source cluster and authentication context before and after the incident window, and escalate only if concrete post-reconnaissance behavior is found.