Does a traffic spike prove an attack?¶
The practical answer¶
No. A traffic spike does not by itself prove an attack.
The key evidential caution¶
The dangerous assumption is that abnormal volume must be malicious.
Legitimate causes may include:
Key points¶
- media coverage
- marketing campaigns
- software updates
- customer demand
- backup or replication
- monitoring changes
- automated clients
- misconfigured systems
Investigators should compare:
- the volume
- source distribution
- request type
- targeted service
- timing
- user-agent or application details
- success and error rates
- resource impact
- normal historical patterns
A malicious traffic spike may involve repeated identical requests, unusual protocols, spoofing, automated timing or known attack infrastructure.
But none of those indicators should be interpreted in isolation.
A well-known source can be compromised.
An unfamiliar source can be legitimate.
Evidential limits¶
Do not rely only on a graph or summary alert.
Obtain the underlying traffic and application events.
The baseline used for comparison should match the same service, time of day, season and business context where possible. A traffic level that is abnormal on an ordinary day may be expected during a major public event, release or emergency. Context is part of the evidential assessment.
Also identify whether the spike preceded the outage or followed it. Retries from legitimate users can create a secondary surge after a service begins failing, which should not automatically be mistaken for the original cause.
A spike may also be amplified by monitoring changes, duplicated telemetry or a switch in measurement point. Preserve how the figures were produced and avoid comparing unlike metrics, such as requests, packets, connections and bytes, as though they describe the same event.
Operational takeaway¶
Use traffic spikes as a trigger for investigation, then assess source, request pattern, system impact and legitimate explanations before concluding attack.