Attack Surge Detection - Am I Under Attack?
Attack Surge Detection watches the alert rate of your Security Engines and flags periods of unusual activity - a surge. When one starts, you are notified by email and in-app, and a dedicated dashboard gathers the contributing alerts so you can answer the only question that matters: is this one dangerous?
Turn it on
The toggle lives right in the Alert Explorer header, and on the Attack Surge dashboard itself:
When a surge is detected
Two notifications go out at the same time:
- an email to the organization owner, summarizing the surge with a direct link to the dashboard;
- an in-app notification, one click away from the same place.
A surge is a period of unusual activity, uninterrupted for at least 15 minutes - so when the notification arrives, the surge may well still be going on.
Read the dashboard
You'll find Attack Surges in the side menu of the Security Stack section.
Everything on this dashboard is scoped to the selected time period. Set the period first (date picker, top-right), optionally pick a Security Engine, and every number you see is already scoped to what you want to investigate.
The four KPI cards count, for the selected period: detected surges, contributing alerts, affected engines, and the date of the latest surge. The Attack Surge History chart shows the alert volume of each surge over time - click and drag across bars to zoom into a sub-period.
Inspect a surge
The details table lists each surge with its start/end, alert count, variation, and affected engines. Expand a row to get the breakdown:
- Top attacking IPs - the most active sources and the reputation CrowdSec observed during the surge. The three-dot menu on each IP jumps to its CTI page, or creates an immediate ban decision (1 week / 1 month, Editors and above).
- Top behaviors - the attack patterns behind the surge.
- Affected Security Engines - who received what.
Drill into the alerts
Click View alerts on an expanded surge: the Alert Explorer opens with the surge's time period and engines already applied as filters - you land directly on the contributing alerts. Clicking an individual IP, behavior, or engine in the breakdown adds it as an extra filter.
From there it's a regular investigation: break the surge down by reputation or behavior, isolate the sources that matter, check their context.
Qualify the surge
Three questions separate a scary-looking blip from a real problem:
Is it new? Compare with what this engine usually receives. A surge of the bruteforce you see every day needs less attention than a scenario that has never fired here before, or familiar activity suddenly hitting a rarely-attacked service. A change in attack type often matters more than the raw volume.
What are they after? Look at the scenarios and the context of the contributing alerts: one scenario generating most of the activity, several related scenarios (stages of the same attack), repeated targeting of one path or service, a recognizable username in a bruteforce. This decides where the rest of your investigation goes.
Is remediation covering it? Check that the involved IPs have active decisions and that your remediation components are connected and applying them. Watch for engines without a remediation component, decisions that expired while activity continues, and sources with no decision at all.
CrowdSec detects the behavior but cannot see whether an attempt succeeded - that evidence is in your own logs:
| Activity in the surge | Where to look for success |
|---|---|
| Brute force / credential stuffing | Successful logins from attacking IPs, new accounts, password or MFA changes |
| Web crawling / reconnaissance | Sensitive paths returning HTTP 200, admin endpoints, config or backup files |
| Vulnerability exploitation | Is the targeted product/version in your stack? Unusual processes, file changes |
| Scanning / probing | Exposed services or ports that should not be public |
| API abuse | Unusual tokens, object enumeration, unexpected data access |
| Bot activity / scraping | High-value endpoints scraped, auth or rate-limit bypass |
After acting, keep an eye on the affected systems: the signal rate should return to normal, and the same sources should not come back the moment a decision expires. If the surge persists, changes technique, or you find evidence of successful access, escalate through your normal incident-response process.