Back to evidence

Sanitized live incident

Reconnaissance

Native source identity and targetable endpoints are private.

mediumopen
Confidence
92%
First seen
Aug 18, 4:10:56 PM PDT
Evidence through
Aug 18, 4:11:33 PM PDT
AI status
Complete
Likely true positive88% confidence

The reviewed HTTP evidence supports the detector's finding of automated surface enumeration against target privatekind: one traffic cluster issued GET and HEAD requests across distinct hashed paths and categories, receiving a mixture of 200, 401, 404, and 405 responses (for example, [redacted], [redacted], [redacted], [redacted], and [redacted]). This is likely genuine reconnaissance, but whether it was unauthorized or malicious cannot be determined from network evidence. No process or flow event identities are cited by the incident, so downstream execution or network consequences cannot be assessed.

Attack stage
Reconnaissance: HTTP route and method enumeration
Model
gpt-5.6-sol · 7 evidence calls

Observed impact

  • The activity mapped application surface behavior, including which sampled routes returned success, authentication-required, not-found, or method-not-allowed responses.
  • No exploit execution, persistence, lateral movement, command-and-control, or data theft is established by the available cited evidence.

Deterministic signals

Http.surface enumeration92%

Broad unauthenticated route and HTTP method enumeration observed

33 observations · 12 http

Explicit uncertainty

  • The source key is a traffic/workload cluster, not a verified person or agent identity; it may represent a proxy, NAT gateway, or multiple workers.
  • Authorization and intent are unknown. The pattern may be hostile reconnaissance, an approved security test, or benign inventory automation.
  • The incident cites no process-plane or flow-plane event identities. Queries using the HTTP identities could not return process or flow evidence, so absence of execution or outbound-flow consequences is not proven.
  • Only bounded HTTP summaries are available; exact routes, headers, and response contents are intentionally excluded, preventing assessment of what information the HTTP 200 responses exposed.
  • HTTP status codes alone do not establish exploit success or failure.

Recommended actions

  1. Confirm whether the source cluster and timing correspond to an approved scanner, inventory job, health check, or penetration test.
  2. Review application and gateway logs for the full 33-request sequence, focusing on the routes that returned HTTP 200 and whether any sensitive metadata was disclosed.
  3. Validate that administrative, diagnostic, and API discovery routes require appropriate authentication and expose only necessary response detail.
  4. If the activity is unauthorized, apply proportionate gateway rate limits or temporary source controls and continue monitoring for follow-on exploitation attempts.
  5. Preserve the cited HTTP evidence and correlate with independently retained workload/process and network telemetry for the same interval, if available.