Thousands of newsletter sign-up confirmations arriving in one inbox within an hour are rarely the attack itself: they are cover, or the set-up for a phone call from someone posing as your help desk. MITRE ATT&CK T1667 Email Bombing, in the Impact tactic (TA0040), covers adversaries flooding targeted addresses with an overwhelming volume of messages, which buries legitimate email and disrupts business. ATT&CK notes it may be a precursor to voice phishing, remote access software abuse, ransomware or financial theft (T1657), and lists Linux, macOS, Windows and Office Suite as platforms. This guide takes the ATT&CK technique view: what the flood looks like in mail logs, how ATT&CK's detection strategy works, which mail-flow settings limit damage, and how to treat a flood as an early warning. The follow-on help desk impersonation over Microsoft Teams is covered in depth in the Email Bombing and Help Desk Impersonation over Teams Guide, and the best-known actor in the Storm-1811 Threat Actor Profile Guide.
Key takeaways
- The flood uses legitimate mail. ATT&CK describes bots registering the target address with mailing lists that do not validate sign-ups; Rapid7 found many messages in 2024 cases were real newsletter confirmations, enough to overwhelm the email protection in place.
- Treat a flood as a security event. ATT&CK says it can bury security alerts, help desk tickets, client correspondence or ongoing scams, and can precede a fake support call.
- Detection is about volume per recipient. ATT&CK's DET0355 looks for spikes in inbound messages to one mailbox in a short window, with thresholds you tune per user.
- Authentication helps only partly. ATT&CK maps M1054 Software Configuration (SPF, DKIM, DMARC) and M1017 User Training, but subscription mail often comes from properly authenticated senders, so volume controls and user guidance carry most of the weight.
- The real damage is the follow-up. In Rapid7's cases, every intrusion came through AnyDesk or Quick Assist after a fake IT call; blocking unapproved remote tools and publishing one known help desk channel break the chain.
What the technique covers
ATT&CK v20's description points to three purposes for email bombing, and each changes the response:
| Purpose | What it looks like | What to do first |
|---|---|---|
| Pretext for social engineering | Flood, then a call, Teams message or chat from "IT support" offering to fix it | Warn the user directly, through a known channel, that IT will not call unprompted; watch for remote access tool launches on their device |
| Cover for another action | Flood arrives while a security alert, a password reset notice, a payment confirmation or a bank change notice is sent to the same mailbox | Search the flooded mailbox for non-bulk messages received during the window; check account security and payment notifications |
| Disruption or harassment | Sustained flood against a shared mailbox, help desk or individual | Apply mail-flow throttling or temporary rules; protect help desk ticket intake |
T1667 has no sub-techniques. It is distinct from network denial of service: the target is a mailbox and the people reading it, not mail server capacity.
Cases
- Storm-1811 (G1046): ATT&CK records the group deploying large volumes of non-malicious spam to prompt follow-on interactions, with the actor posing as IT support or help desk. Microsoft reported in May 2024 that the actor signs targets up to email subscription services, then calls them impersonating IT support, and had misused Quick Assist since mid-April 2024; by the end of May 2024 it was also using Microsoft Teams to message and call targets. Microsoft associates the group with Black Basta ransomware. See the Black Basta Threat Actor Profile.
- Rapid7 MDR cases (late April 2024 onward): users received spam volumes that overwhelmed existing email protection, mostly newsletter sign-up confirmations. Callers posing as internal IT moved on to the next user on the spam list if one refused. Access in every case came through AnyDesk or Quick Assist; scripts then captured the user's password at a fake update prompt and set up SSH reverse shells. Rapid7 linked the indicators to Black Basta and did not observe exfiltration or ransomware in its cases.
- Scale of the defence problem: Microsoft reported in June 2025 that its mail bombing detection blocks an average of 20,000 to 30,000 mail bombs a day across 200 to 300 users.
What to detect: ATT&CK DET0355 in practice
DET0355 Detection Strategy for Email Bombing has four analytics, built on DC0038 Application Log Content and DC0039 File Creation:
| Analytic | Platform | Signal ATT&CK describes | Tuning element |
|---|---|---|---|
| AN1008 | Windows | Spike of inbound messages to one recipient in the Microsoft 365 unified audit log; repetitive attachment file creation (Sysmon event 11) | TimeWindow, RecipientThreshold, AttachmentSizeThreshold |
| AN1009 | Linux | Excessive connections or inbound messages to one recipient in Postfix or Sendmail logs; file creation in /var/mail or /var/spool/mail above baseline | MailVolumeThreshold, AttachmentPatternList |
| AN1010 | Office Suite | High-frequency delivery of messages or attachments to a single recipient in Exchange logs | UserContext (VIP and sensitive recipients) |
| AN1011 | macOS | Repetitive inbound messages in unified logs; attachment creation under ~/Library/Mail | FileCountThreshold |
In Microsoft 365, the Defender for Office 365 mail bombing detection labels these messages: filter Threat Explorer by the detection technology "Mail bombing", or query the DetectionMethods column of the EmailEvents table in advanced hunting. Microsoft's own recommendation is to build a custom detection rule on that query so the SOC is alerted.
Detections NHI Mgmt Group recommends
- Per-recipient volume spike: inbound messages per mailbox per hour against that mailbox's own baseline, with a lower threshold for executives, finance, help desk and IT administrators.
- Sender diversity spike: a sudden jump in distinct sending domains to one recipient, which is the signature of subscription flooding.
- Flood plus contact: a flood followed within hours by an external Teams chat or call, or an inbound call from an unknown number to the same user. This is the high-priority alert.
- Flood plus remote tool: Quick Assist, AnyDesk, ScreenConnect or another remote access tool starting on the flooded user's device. See the MITRE ATT&CK T1219 Remote Access Tools page.
- Flood plus account change: password reset, MFA method registration or sign-in from a new device for the flooded user during or after the flood.
Limiting damage: mitigations and mail-flow settings
| Control | Source | Effect and limits |
|---|---|---|
| SPF, DKIM and DMARC enforcement | M1054 Software Configuration | Filters spoofed senders and lets recipients validate messages; does not stop authenticated newsletter mail, so treat it as a baseline, not the fix. See the DMARC, SPF and DKIM Guide. |
| User awareness | M1017 User Training | Users know that a flood plus an unexpected support call is an attack pattern, and know the one way to reach the real help desk |
| Bulk mail threshold | Microsoft Defender for Office 365 documentation | Bulk complaint level (BCL) threshold is 7 in the default policy, 6 in the Standard preset and 5 in the Strict preset; lowering it sends more bulk mail to Junk or quarantine, at the cost of some wanted newsletters |
| Mail bombing detection | Microsoft Defender for Office 365 documentation | On by default in Exchange Online Protection and Defender for Office 365; moves detected mail bombs to Junk and honours users' safe sender lists. For on-premises routing, Microsoft says Enhanced Filtering for Connectors must be enabled |
| Temporary throttling or rules | NHI Mgmt Group recommendation | During an active flood, apply a transport rule or gateway policy for the affected mailbox to route bulk and newly seen senders to quarantine, then remove it |
| Remote tool allowlisting | NHI Mgmt Group recommendation, consistent with Rapid7 and Microsoft guidance | Block unapproved remote access tools, including Quick Assist where it is not used, so the follow-up call cannot become a session |
| Restrict external chat | NHI Mgmt Group recommendation | Limit collaboration platform external access to known partner domains, as covered in the Teams guide linked above |
For other mail platforms, the same model applies: per-recipient rate limits on the gateway, bulk and newsletter classification, and a quick way for the SOC to quarantine by recipient and time window. Smaller organisations relying on a cloud mail provider should confirm the provider's bulk and flood protections are on and that users know how to report a flood; larger organisations should add the correlation alerts above and a runbook. See the M1054 Software Configuration and M1017 User Training pages.
Response runbook for an active flood
- Contact the user first, through a known channel: tell them IT will not call or message them about the flood unless they raised a ticket, and not to accept remote sessions.
- Contain the mail: apply temporary quarantine rules for the recipient; keep the messages for analysis rather than deleting them.
- Look for what the flood is hiding: search the window for non-bulk messages: security alerts, password reset or MFA notices, payment or bank detail notices, and client mail.
- Check the device and account: remote access tool executions, new MFA methods, password resets, sign-ins from new locations, inbox rules.
- Check colleagues: Rapid7 saw callers move from user to user, so search for floods to other recipients in the same period.
- Escalate if there was contact: if the user accepted a session or shared a code, treat it as a compromised endpoint and account. See the Help Desk Social Engineering Incident Playbook.
- Clean up: remove temporary rules once the flood stops; unsubscribing from hundreds of lists by hand is rarely worth it, so rely on Junk filtering as volumes fall.
Where identity fits
The flood itself does not touch credentials, but the steps it sets up do. A remote support session gives the adversary the signed-in user's context and any tokens cached on the device; the Rapid7 cases harvested the user's password at a fake prompt. Help desk staff are also targets: a flooded user who "needs" an MFA reset is a classic pretext. Require identity verification for any reset requested during or after a flood, using the Help Desk Identity Verification Policy Template.
How to test
- With approval, send a controlled burst of messages from many test senders to a test mailbox and confirm the volume alert fires within your target time.
- Check that Threat Explorer or your gateway labels flood messages and that the SOC can filter by recipient and window.
- Run a simulated "IT support" call after a test flood, with the user's manager informed, and check the user reports it through the published channel.
- Attempt to start an unapproved remote access tool on a test device and confirm it is blocked and alerted.
Metrics:
- Median time from flood start to SOC alert.
- Percentage of floods where the user was contacted by the SOC or IT before any external contact.
- Number of unapproved remote access tool executions blocked per month.
- Percentage of staff who correctly identify the flood-and-call pattern in awareness testing.
- Percentage of help desk resets during floods that passed identity verification.
Common failure patterns
- Treating it as a spam nuisance: the help desk deletes mail and closes the ticket without telling security.
- Relying on authentication alone: DMARC enforcement is in place, so the team assumes the flood will be filtered.
- No known help desk channel: users cannot tell a real IT call from a fake one.
- Remote tools left open: Quick Assist and free remote access tools run without allowlisting.
- Not looking for the hidden message: a password reset notice or payment confirmation in the middle of the flood goes unread.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | TA0040 Impact; T1667; DET0355; M1054, M1017; related T1566.004 Spearphishing Voice, T1219 Remote Access Tools, T1657 Financial Theft | Technique, detection, mitigations and the techniques it leads to |
| NIST CSF 2.0 | PR.AT-01, DE.CM-01, DE.AE-02 | Awareness, monitoring of network services, event analysis |
| NIST SP 800-53 Rev 5 | SI-8, SC-5, AT-2, SI-4 | Spam protection, denial-of-service protection, awareness training, monitoring |
| CIS Controls v8.1 | 9.5, 9.7, 14.2 | DMARC, email server anti-malware, social engineering training |
| ISO/IEC 27001:2022 Annex A | 6.3, 8.16, 5.26 | Awareness training, monitoring activities, response to information security incidents |
See the ATT&CK Impact Tactic Guide and the MITRE ATT&CK T1566 Phishing page.
Practitioner checklist
- Alert on per-recipient inbound volume spikes, with lower thresholds for high-risk roles.
- Turn on and alert from your mail platform's flood or mail bombing detection.
- Correlate floods with external chats, calls, remote tool launches and account changes.
- Publish one known way to contact the help desk and tell staff IT will not call unprompted.
- Block unapproved remote access tools, including Quick Assist where not needed.
- Restrict external collaboration chat to known partner domains.
- Keep a flood runbook: contact user, contain mail, look for hidden messages, check device and account.
- Require identity verification for resets requested during or after a flood.
Standards and references
- MITRE ATT&CK: T1667 Email Bombing
- MITRE ATT&CK: Storm-1811 (G1046)
- Microsoft Threat Intelligence: Threat actors misusing Quick Assist in social engineering attacks leading to ransomware
- Rapid7: Ongoing Social Engineering Campaign Linked to Black Basta Ransomware Operators
- Microsoft Tech Community: Protection against email bombs with Microsoft Defender for Office 365
- Microsoft Learn: Bulk complaint level (BCL) in EOP
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Email Bombing and Help Desk Impersonation over Teams Guide, Storm-1811 Threat Actor Profile Guide, Vishing and Help Desk Social Engineering Awareness Guide, MITRE ATT&CK T1219 Remote Access Tools.