How to detect incidents in an avalanche of alerts: a real case

TL;DR

• Most real attacks don't look like a single critical alert. They look like a handful of low or medium ones, scattered across email, identity, endpoint, network, and cloud.
• Qevlar AI automatically correlates malicious alerts from any source into a single incident, and prioritizes each incident with a contextual severity score based on threat, spread, asset criticality, and your environment.
• The result: one incident per attack, prioritized for your environment.

‍

Attacks hide in the noise

Cyber attacks rarely announce themselves as one obvious critical alert. They show up as isolated events spread across different tools and queues: a failed login here, an odd PowerShell execution there, a quiet beacon to an unfamiliar domain. On their own, none of these signals describe the full intent or scope of the attack, so security responders miss real threats that are disguised as multiple low-priority alerts.

Qevlar’s investigations across 1,500 companies show that 34% of alerts in the "low" and "informational" buckets actually turn out to be malicious once investigated end-to-end.

Modern campaigns are amorphous: same actor, same goal, but constantly varying subject lines, sender names, URLs, file names, and infrastructure. To the detection tool, each variant looks like a new, low-severity event. The SOC team ends up hunting for all the variants belonging to the same attack by hand, usually after the fact.

Why existing correlation falls short

Alert correlation isn't new. Most SOCs already rely on something:

• SIEM and SOAR correlation is rules-based. It only catches what someone wrote a rule for, and those rules need constant tuning every time a detection, tool, or attacker behavior changes.
• XDR correlation works inside one vendor's telemetry, and is helpful in spotting some attack chains, but falls short when it comes to evasive campaigns.
• Most AI SOC platforms investigate one alert at a time. They enrich it, give a verdict on it, and move on. So multi-stage attacks and campaigns still get fragmented across separate tickets. See how Qevlar compares to most AI SOC platforms in this free guide.

How Qevlar Incidents work

Qevlar investigates at both the alert and the incident level.

First, Qevlar investigates each alert end-to-end and dynamically expands the scope. Qevlar AI doesn’t stop at triage. By the time Qevlar finishes investigating a single alert, it knows the full set of observables tied to that confirmed threat, quite often expanding beyond the ones the detection tool happened to fire on.

This matters for correlation. That gives the correlation engine a much richer surface to match against, so connections get made that a tool comparing raw alert payloads would miss.

Second, Qevlar asks: does this connect to anything else we've recently seen?

Qevlar cross-references this full set of observables against all other recent investigations. When activity points back to the same attack pattern, Qevlar groups the alerts into a single Incident, builds the attack narrative, and assigns a severity score that reflects the full threat picture.

• No predefined patterns to maintain. The AI reasons across observables and adapts to novel attacks without rules. It picks up campaigns even when attackers deliberately vary IOCs to evade detection.
• Vendor-agnostic. Email, identity, network, endpoint, cloud: if Qevlar can investigate the source, it can correlate it. SOC teams get more value out of the security tools they already pay for.
• Real-time and dynamic. The incident's scope, narrative and severity update as new alerts come in. There is no "final" report frozen at first detection.
• Contextual severity scoring. Severity is calculated from the underlying alert verdicts, the threat's mitigation status, the spread across users and devices, the engagement of each user/device with the threat, asset and user context (VIP, privileged, critical systems), and the timing between alerts.

The end result is one incident per attack, prioritized for your environment, instead of one ticket per alert.

Example: Cross-tool correlation, from TOR sign-ins to an infostealer on a VIP's laptop

You open Qevlar in the morning, and the first thing at the top of the queue is a Critical incident. That's where the analyst starts.

What was correlated, and why

Qevlar grouped 5 identity alerts and 2 endpoint alerts, coming from three different detection sources across identity and endpoint, into a single incident. None of the seven source alerts on its own scored Critical.

‍

The correlation happened because:

• Same two compromised users
• Same confirmed TOR exit nodes (IPs)
• All malicious activity was happening within a close time window (5 days)

In other words, Qevlar saw the same users, the same time window, and a clean handoff from identity compromise to endpoint compromise.

What this attack is about and why it scored Critical

Qevlar summarizes an attack narrative up-front (and updates it every time a new alert is correlated into the incident).

In this case, between April 6 and April 11, 2026, five login attempts to four distinct accounts originated from TOR exit nodes (MITRE T1078, T1090.003), indicating a coordinated credential-stuffing campaign using anonymized infrastructure to evade detection.

‍

The incident severity is Critical, and Qevlar shows exactly why.

Four of five factors are raising the score, with User and Device Context the one that tips it over the line: one of the compromised accounts is a VIP (Regional Director), and the infostealer is live on his laptop.

None of the seven source alerts on its own would have scored Critical. The incident did, because the score factored in the full picture.

Top affected users and devices

The analyst doesn't have to dig for the blast radius. Qevlar surfaces it directly on the incident page:

• Users: a.holm@metrix-retail.com (VIP, compromised), i.petrov@metrix-retail.com (compromised), f.kessler@metrix-retail.com (targeted, blocked), r.schubert@metrix-retail.com (targeted).
• Devices: LPT-FINANCE-042 (Anders Holm), WKS-IP-008 (Ilia Petrov).

For more comprehensive details, SOC analysts go to the Observables & Impact tab. It's the full IOC inventory for the incident, filterable by type and ready to feed into containment, blocking, or threat-hunting. All 12 observables sit in one view (4 IPs, 4 mailboxes, 2 devices, 2 files), each tagged with both threat context and business context.

‍

‍

Drilling into each alert investigation

If the analyst wants to verify, the seven alert investigations are all one click away from the incident view. Each keeps its own full investigation: which observables were analyzed, which tools and threat intel sources were used, which log queries were executed, and which context items were applied.

How Qevlar Incidents help SOC teams

• Prioritize the work that matters. A live, dynamic severity score per incident, tuned to your environment: VIP status, asset criticality, spread, engagement, timing, and the threat itself.
• Catch campaigns and multi-stage attacks. Correlation works across email, identity, network, endpoint and cloud. The AI doesn't need a pre-written rule to recognize an attack shape.
• Skip the narrative-writing. Qevlar reconstructs the scope, sequence and connections between alerts as a readable narrative, refreshed as the incident evolves.
• Respond to the full threat blast radius. Incidents are available through the public API, so your existing automated workflows, e.g. in a SOAR, can act on a single incident object instead of stitching together raw alerts.

See it in your environment

Already a Qevlar AI customer? Log in to the platform. Incidents are live in your tenant.

Not yet? Book a demo and we'll show you Incidents on a real attack chain in under 30 minutes.

FAQ

Does Qevlar correlate any alerts into incidents?

Qevlar correlates alerts it has investigated and concluded as malicious. Benign and informational findings don't make it into an incident. That's the point: incidents are meant to be the prioritized, real things, not another inbox.

Qevlar Incidents is also vendor-agnostic. It works with any Qevlar-supported alert source, and correlation runs on commonalities between observables, so it doesn't matter which tool generated the alert.

My SIEM / XDR / SOAR already correlates signals. How is Qevlar's Incidents different?

Three differences worth knowing:

1. No rules to write or maintain. SIEM and SOAR correlation is rules-based, which means it only catches what's been defined and needs ongoing tuning. Qevlar's AI reasons across observables and adapts to new attack patterns without rule changes.
2. Vendor-agnostic. Native XDR correlation is strongest inside its own telemetry. Qevlar correlates across whatever you've integrated (EDR, identity, email, network, cloud), without forcing you into one vendor's ecosystem.
3. Investigation-driven correlation. Qevlar runs a full end-to-end investigation on every alert before deciding whether to group it into an incident, and expands the scope of each investigation to uncover all related malicious observables. The correlation is built on verdicts and a complete set of observables, not just on raw IOC overlap.

I already have custom correlation logic. What does Qevlar add?

Two options:

• Augment. Run Qevlar alongside your existing logic. It will pick up activity your rules don't define, especially novel or amorphous attacks.
• Replace. Use Qevlar as your primary correlation engine. It works out of the box with zero ongoing tuning.

Either way, you're not locked in.

Does Qevlar deduplicate alerts?

Yes. When Qevlar receives multiple identical alerts for the same entity and alert type within a 12-hour window, it automatically groups them together as repeated alerts. This reduces noise in your investigations queue while preserving full visibility of every alert.

‍