Detection Engineering advanced T1621

Alert Fatigue Is an Offensive Technique, Not a Tuning Problem

MFA fatigue has a MITRE technique ID. SOC alert flooding doesn't — same deliberate tactic, different target, and why your defenses keep failing.

· 14 min read · Gowthamaraj Rajendran

Alert fatigue is treated as a tuning problem. Too many alerts, too many false positives, analysts who stop reading the queue because the queue is always wrong. The fix is always a variation of the same: suppress the noise, add filtering logic, adjust thresholds. The problem is framed as operational. The response is operational.

This framing hands adversaries a technique they never have to develop themselves.

Alert fatigue is a condition that can be deliberately induced. If it can be manufactured on demand against a target organization — and it can — it is an offensive technique. Treating it as a tuning problem is not just analytically wrong. It produces the worst possible response at exactly the moment the right one matters most.

MFA push bombing vs SOC alert flooding — same mechanism, different target

MFA Fatigue Is the Proof of Concept

Push bombing is alert fatigue in miniature — and the security industry has already accepted it as a deliberate attack technique.

The mechanism: generate authentication prompts faster than the target can evaluate them, until fatigue or confusion produces the wrong decision. Lapsus$ used it against an Uber contractor in 2022, flooding them with MFA requests for over an hour until approval came. Scattered Spider used it at MGM Resorts in 2023. Akira ransomware used it systematically across a wave of SonicWall intrusions in 2025. Scattered Spider used it again at Marks & Spencer in April 2025, contributing to a breach that hit 1,049 stores and dropped the share price by 7%.

MITRE ATT&CK catalogued this as T1621: Multi-Factor Authentication Request Generation. The definition: adversaries may abuse authentication mechanisms by sending repeated MFA prompts to overwhelm users and induce approval.

Push bombing succeeded in more than 20% of social engineering attacks against public sector organizations in 2025. Nobody argues that MFA fatigue is “just a UX problem” that authentication teams need to tune better. It is understood as a deliberate attack.

Now replace the push notification screen with the analyst alert queue. The mechanism is identical.

The SOC Analog

A SOC analyst has finite investigation bandwidth. At the average organization, that queue receives 2,992 alerts per day [1]. Of those, 40–42% are never investigated — not because the team is negligent, but because capacity runs out before the queue does [2]. I broke down how that attrition compounds across the full detection pipeline in The Detection Funnel. Alert fatigue is one stage of that funnel — but it is the one stage an adversary can reach in and widen on purpose.

The adversary does not need an analyst to approve anything. They need the real alert to reach position 847 in a 2,992-item queue, where it ages out, gets auto-closed by an overtaxed triage tool, or gets bundled into a suppression rule because the category is noisy.

If an adversary can generate enough volume to push real signals to the bottom, they have effectively disabled your detection without touching your SIEM, your EDR, or any of your tooling. The impairment is in the analyst’s attention, not in the technical stack.

That is the same mechanism as T1621. The target is a different human decision-maker. The outcome is the same.

How It Works in Practice

The obvious objection: most attackers aren’t this strategic. Deliberately engineering analyst fatigue sounds like a film-plot threat, not something the average ransomware crew plans on a Tuesday.

That objection misses the mechanism. This technique doesn’t require intent — it requires activity. In the most common case, the adversary isn’t trying to flood your queue at all; the flooding is a byproduct of doing what they were going to do anyway. There are two practical paths, and only one of them needs a plan.

Recon naturally generates noise. The first thing an adversary does after gaining initial access is enumerate: IAM permissions, resource inventories, service configurations. In AWS, that’s a burst of Describe, List, and Get API calls. In Entra ID, it’s directory reads and conditional access policy inspection. In a Windows environment, it’s LDAP queries and local group enumeration.

These are reconnaissance activities. They also fire a range of low-to-medium severity detection rules — cloud enumeration alerts, anomalous API activity, unusual credential usage. The adversary doesn’t need to know your rules to trigger them. They just need to do recon, which they’d do regardless. The fatigue is free.

By the time the adversary moves to lateral movement or data access, the alert queue has already absorbed a burst of real-looking, low-priority alerts sourced from the compromised identity. The early indicators are in the queue — buried under the noise that recon produced.

Deliberate generation with minimal effort. With AI-generated code and compromised credentials, deploying a red team simulation tool or a credential-based scanner is a low bar. Run it against your target infrastructure and it will trigger a broad spectrum of detections across multiple categories in minutes. No knowledge of the specific rule set required — just volume across the attack surface.

The Fragmentation Problem

Volume alone is not always sufficient. A skilled analyst reviewing 200 alerts from the same cloud account will notice the pattern. Alert flooding becomes more effective when the alerts don’t resolve to a shared entity.

Analyst queues are typically organized by data source or category. Cloud IAM events go to one analyst. Endpoint EDR alerts go to another. Network anomalies to a third. If an adversary generates activity that produces alerts across all three — a cloud enumeration burst, a suspicious process on a different endpoint, a DNS anomaly on the network — those alerts land in separate queues with separate analysts.

None of them see the full picture. The cloud analyst sees IAM enumeration from an account that looks like it might be a service credential behaving oddly. The endpoint analyst sees a low-confidence behavioral alert on a host that’s had five similar alerts this week. The network analyst closes the DNS query because it matches a suppression pattern.

Individually, each alert is ambiguous. Together, they form a picture. The queue structure prevents anyone from assembling it.

Fragmentation doesn’t even require knowing how your correlation works. It requires generating activity that doesn’t share an obvious identity string — not the same cloud account ID, not the same hostname, not the same username. If the alerts don’t share an entity, they won’t be grouped. If they’re not grouped, they won’t be investigated as a campaign.

Suppression Is the Attack Succeeding

Here is the specific failure mode.

An adversary generates a burst of 400 low-severity S3 enumeration alerts from a compromised cloud credential. The analyst team, already behind, opens a ticket to tune the rule. The tuning lead creates a suppression for that credential or IP range because the volume is unmanageable. The alert source goes quiet.

What just happened:

  1. The adversary now knows which credential triggered detections.
  2. They know the detection has been suppressed.
  3. They can operate from that credential without generating alerts.

The suppression — which felt like the correct operational response — was the attack succeeding. The adversary didn’t disable your detection. You disabled it for them, under time pressure, in response to a condition they manufactured.

The instinctive response to noise is to suppress and de-prioritize. That is the correct response to accidental noise and the worst possible response to intentional noise. In the moment, they look identical. That asymmetry is what makes this work.

What to Do Instead

If alert flooding can be deliberate, the defensive response has to account for that possibility. Tuning is not sufficient on its own.

Monitor your own alert volume as a security signal. Alert rate by source, by category, and by time window should be a dashboard metric. A sudden spike in S3 enumeration alerts is either a detection sensitivity problem or a reconnaissance problem. Those require different responses. Triage that question before creating a suppression rule.

Before suppressing, investigate the source entity. Any time a burst of low-severity alerts originates from a credential, service account, or host without a well-established baseline, treat the suppression request as a potential indicator. Ask: why is this entity generating this volume right now? The answer determines whether suppression is the right call or the wrong one.

Cross-queue correlation for multi-entity burst patterns. IAM alert, endpoint behavioral alert, and network anomaly all fired within the same 30-minute window — they should be linked for review regardless of which queue they landed in. This requires a shared timeline view across categories, not just within them. Most SOCs don’t have this wired up. It’s one of the highest-leverage gaps to close.

Invert alert priority during volume spikes. When overall alert volume spikes, the instinct is to focus on criticals and let the low-severity queue grow. For accidental noise, that’s right. For intentional flooding, the low-severity items that appeared just before the volume spike are the most important — they are the pre-positioning activity. The burst is the cover story. The interesting stuff came right before it.

Where AI Actually Helps (And When to Route to It)

The cross-queue correlation problem — finding the connection between a cloud IAM alert, an endpoint behavioral alert, and a network anomaly that don’t share an obvious entity — is exactly the problem AI is well-suited to solve. The question is not whether AI helps here. It does. The question is when you route to it and what you ask it to do.

Running every alert through AI analysis individually is not the answer. Individual alert triage with AI is a cost problem disguised as a capability problem — you’re paying for LLM inference on 2,992 daily alerts, most of which are false positives, and the AI’s per-alert accuracy on isolated low-context signals won’t be materially better than a well-tuned rule. The value of AI in this context is correlation, not classification.

The architecture that actually scales:

Layer 1 — Always-on entity correlation (rules, no AI). Every alert gets tagged with whatever entity identifiers it carries: cloud account ID, IAM role ARN, hostname, username, device ID, source IP. Standard SIEM correlation. Fast, cheap, deterministic. Alerts that share a common entity get grouped automatically. This handles the easy cases.

Layer 2 — AI correlation, triggered by anomaly conditions. When alert volume from a source spikes beyond a defined threshold, or when a time window produces a burst of alerts that share no common entity (the fragmentation case), that cluster gets fed to an AI correlation layer. The AI’s job: entity resolution across non-obvious relationships. Same IAM role accessed through different services. Same source IP appearing across different accounts. Same attack pattern expressed through different tooling. The AI looks for structural similarity across alerts that rule-based correlation can’t group because the surface-level entity strings don’t match.

Layer 3 — Automated correlation engine outputs a unified investigation ticket. The AI findings — “these seven alerts from three different queues share a temporal pattern and a behavioral fingerprint consistent with credential-based enumeration” — feed an automated engine that creates a single grouped ticket for analyst review. The analyst reviews one investigation, not seven separate alerts.

The decision point for when to trigger Layer 2 is not “is this alert important?” It is “does this alert belong to a pattern I cannot see from entity strings alone?” Two triggers work in practice:

  • Volume spike from an unknown or low-baseline entity. A service account generating 200 API calls in 10 minutes when its baseline is 12 calls per hour. Route the cluster to AI.
  • Time-windowed burst with no common entity across categories. If your cloud, endpoint, and network queues all spike within the same 30-minute window and none of the alerts share an entity identifier, that cluster is the exact fragmentation pattern an adversary exploits. Route it to AI before anyone writes a suppression rule.

The critical guardrail: AI findings in Layer 2 should produce grouped investigation tickets, not auto-closures. The whole point of this architecture is to catch the cases where automated rules fail. An AI that auto-closes a cluster it couldn’t correlate has reproduced the original problem — real signals disappearing without a human ever seeing them — with a more convincing paper trail.

What you want is: AI surfaces the pattern → analyst confirms or refutes → suppression only happens after a human has reviewed the grouped context, not the individual alert.

Detection: The Recon Burst Pattern

The most reliable signal for this technique is the reconnaissance burst itself — not the analyst fatigue it induces downstream.

title: Anomalous Cloud Enumeration Burst — Potential Alert Flooding Prelude
status: experimental
description: >
  Detects high-volume read-only enumeration API calls from a single identity in a short
  window. Consistent with reconnaissance that floods detection queues as a side effect,
  or deliberate pre-exploitation setup to induce analyst fatigue before real action.
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName|startswith:
      - 'Describe'
      - 'List'
      - 'Get'
  condition: selection | count(eventName) by userIdentity.arn > 200
  timeframe: 10m
falsepositives:
  - Automated infrastructure tooling (allowlist known service account ARNs)
  - Initial account provisioning scripts
level: medium
tags:
  - attack.defense_evasion
  - attack.t1562
  - attack.t1621

This detects the input, not the output. Detecting alert fatigue after it has occurred — after suppression rules are written, after the queue has been cleared — is too late. The recon burst is detectable before the analyst ever sees the resulting alerts.

The MFA push bombing analog operates the same way: detect bursts of push denials followed by success from the same user within a 30-minute window, not the breach that follows the approved request.

The Bigger Ask: This Belongs in ATT&CK

Everything above is what an individual team can do. There’s a structural fix the field hasn’t made yet, and it’s why this keeps working.

T1621 covers MFA fatigue. T1562.011 covers spoofed security alerting — injecting fake alerts to confuse defenders. Neither covers the technique described in this post: generating high volumes of legitimate-looking alerts to exhaust analyst attention and create blind spots through suppression.

This is a gap. The technique has documented effect, reproducible execution paths, and no technique ID. The absence of a technique ID means no ATT&CK-aligned detection baseline, no organizational awareness framework, and no language for post-incident attribution.

Where it belongs: Defense Evasion, under Impair Defenses (T1562). A sub-technique scoped to deliberate analyst attention exhaustion via alert volume — distinct from T1562.011 (which requires fake alert injection) and distinct from T1621 (which is scoped to authentication mechanisms, not detection operations).

The counterargument is that this is a procedure under existing techniques rather than a distinct technique in its own right. That’s a reasonable position for the MFA case — T1621 could be stretched. But T1621 is explicitly scoped to authentication mechanisms. The analyst queue is not an authentication mechanism. The technique is the same; the target system is different. That warrants its own entry.

Until it gets one, there’s no shared vocabulary for organizations to detect, attribute, or brief leadership on what happened. “We got noisy alerts and tuned them out” and “an adversary manufactured alert fatigue to create a blind spot before their main action” are the same incident described at two completely different levels of accountability.

Closing

The reason alert fatigue persists despite years of SOC investment is not that organizations are bad at tuning. It is that the threat model is wrong.

When you treat alert fatigue as an operational problem, the fix is always operational: more suppression, better filtering, faster triage. Each of those responses assumes the noise is accidental. None of them accounts for noise that is manufactured.

The right question is not “how do we reduce alert volume?” It is: if an adversary wanted to create a blind spot in this SOC by flooding the queue, what would that look like — and would we know the difference between that and a legitimate tuning problem?

Most teams don’t have a process for answering that question. That is the gap this technique exploits. And until SOC-level alert flooding gets the same treatment MFA fatigue did — a technique ID, an attribution pattern, a detection baseline — it will keep working exactly as designed.

Resources

  1. 2026 State of Threat Detection and Response — Vectra AI (SOC teams receive an average of 2,992 alerts per day).
  2. SANS 2025 SOC Survey — SANS Institute (roughly 40% of alerts are never fully investigated as capacity runs out).