How should web-attack evidence be reported?¶
Report web attacks in stages: reconnaissance, malicious request, application processing, server-side effect, data or account impact, persistence and attribution. A payload and a compromised application are not the same conclusion.
Identify the evidence beneath alerts¶
State the endpoint, request, authentication and session, response, process or database effect, affected files or records and later changes. Explain proxies, gateways, CDNs, cloud services and shared infrastructure in the route.
Several gateway, application and incident alerts may derive from one request. Do not present them as independent corroboration; identify the underlying event and each product's interpretation.
Use precise outcome language¶
A traversal request is not a returned file; an upload is not execution; SQL-like input is not extracted records. State whether a conclusion rests on request pattern, returned content, server process, database action or later account use.
Where sources are incomplete, mark the stage confirmed, supported or uncertain. IP addresses, domains and accounts provide technical identifiers, not automatic personal attribution.
Key takeaway
Report each web-attack stage and its underlying evidence separately, avoiding duplicated alerts and keeping technical effect distinct from offender attribution.