How T1667 email bombing hides attacks and disrupts users
A sudden surge of mail that fills an inbox should be treated as a security event until proven otherwise. Under the Impact tactic (TA0040), T1667 Email bombing lets an adversary flood a mailbox with a large volume of messages so the user cannot find or act on legitimate alerts. In intrusions, the flood is often used as cover: it buries the password reset notices, MFA prompts, sign-in alerts and vendor messages that would otherwise reveal a phishing campaign or account takeover running in parallel. The MITRE ATT&CK tactic page for Impact describes the goal as manipulating, interrupting or destroying systems and data, and a drowned mailbox interrupts the user's ability to respond.
For the SOC lead, the decision is whether the surge is a nuisance, a mail-based attack, or a diversion for an intrusion. Treat it as a two-track investigation from the first hour. One track checks the volume itself: sender patterns, message sizes, and whether the gateway or mail platform throttled or quarantined the traffic. The other track checks the targeted accounts for the activity that the flood may be hiding, including new sign-in locations, mailbox forwarding or rule changes, and recent credential resets. Confirm which of these logs your mail platform and identity provider actually retain, and for how long, before an incident begins, because the evidence you need is often in sources that roll over quickly.
This page targets ATT&CK version 20.0, and the technique mapping should be checked against that version before any rule is written or tuned. MITRE can rename, deprecate or revoke techniques and change their detection guidance between releases, so the detection strategies, analytics and data components cited here must be confirmed against the attack-stix-data repository for the version your team uses. Record the ATT&CK version in every detection's metadata so that a later release does not silently change what your alerts claim to cover.
Which telemetry reveals email bombing on each platform
This table maps the telemetry that exposes T1667 Email Bombing on Linux, Office Suite, Windows and macOS, with the signal to look for and the open-source collector that gathers it. Read each row as a starting point: confirm the data component mapping against the ATT&CK version your detections target, because mappings can change between releases. The main takeaway is that mail server logs and SMTP traffic reveal the flood on every platform, while endpoint telemetry mainly shows the local process that drives it.
| Platform | Telemetry and signal to look for | Open-source collector |
|---|---|---|
| Linux | Application Log Content (DC0038) from mail transfer agent logs: sudden spikes in accepted messages per recipient or per sender, and bursts of queued mail | Wazuh agent log collection, with Zeek or Suricata watching SMTP sessions at the network edge |
| Linux | Process Creation (DC0032) for local mail clients or scripts launched in bulk, and File Creation (DC0039) for spool or queue files growing quickly | Wazuh agent with process and file integrity monitoring, or Velociraptor artifacts for on-demand collection |
| Office Suite | Application Log Content (DC0038) from mail gateway and tenant audit logs: high message volume to one mailbox, repeated sends from a single account | Wazuh ingestion of exported audit logs, paired with Zeek SMTP metadata where mail transits your network |
| Office Suite | File Creation (DC0039) for locally cached or exported mailbox files that grow abnormally, which can indicate mass rule or client activity | Velociraptor artifacts for endpoint mail data stores, where your policy allows collection |
| Windows | Process Creation (DC0032) for mail client or PowerShell-driven send activity launched at unusual rates, from non-standard parent processes | Wazuh agent Windows event collection, with Velociraptor for process and artifact review |
| Windows | Application Log Content (DC0038) from Exchange or SMTP relay logs: recipient count per minute and repeated identical subjects | Wazuh log collection from the mail server, with Zeek SMTP logs for corroboration |
| macOS | Process Creation (DC0032) for mail client processes or scripts sending in bulk, and File Creation (DC0039) for outbox or spool files growing quickly | Wazuh agent for macOS where supported, with Velociraptor for on-demand endpoint artifacts |
| macOS | Application Log Content (DC0038) from the mail relay the endpoint uses, showing repeated submissions from one client | Wazuh log collection from the relay, with Zeek for SMTP session metadata |
Detection logic for email bombing spikes
Email bombing floods a mailbox with high volumes of messages so that real alerts get buried or the recipient is pushed into a response. The detection ideas below share one principle: compare current mail behavior against a baseline for the same recipient, sender, host or account, then check whether a spike is followed by an authentication or phishing event.
Per-recipient rate threshold
Count inbound messages to each recipient over a rolling window and alert when the count exceeds that mailbox's own historical range. Set thresholds per recipient group, since executives, shared service desks and on-call aliases receive very different volumes. Start with a short window and a high multiplier, then tighten it after reviewing a few weeks of alerts. Expected false positives come from mailing list fan-outs, newsletters, ticket systems that echo every update, and bulk HR or payroll notices sent on a fixed schedule. Maintain an allowlist of known bulk senders and document each exception with an owner.
Repeated sends from one account
Look for a single sending account, or a mail client or script process on one host, generating many outbound messages in a short period. Correlate the sending process with the mail gateway logs so that a legitimate desktop client and an unexpected automation tool are easy to tell apart. A sudden change in the process that submits mail, or a new scheduled job on the host, is a stronger signal than volume alone. Confirm with the owner whether the account was used for a planned campaign before treating the activity as hostile.
Bursts of new mail files
On endpoints and mail servers, watch for bursts of newly created message, queue or spool files in a short interval, and for spool growth that does not match the user's normal sending pattern. File creation telemetry from the mail client profile and the local mail spool directory provides this signal. Filter out backup, indexing and sync tools that write many files at once, and record their normal behavior so that analysts can compare against it quickly. Treat a burst on a host that also shows unexplained process activity as a higher priority.
Correlate with authentication and phishing alerts
Email bombing is often followed by a request to a victim to call a help desk, approve a multifactor prompt, or click a link that appears legitimate. Join mail volume alerts with authentication logs for the same mailbox and with phishing or suspicious link alerts from the gateway. A spike followed by a new sign-in, a failed MFA challenge sequence or a help desk ticket within a defined window raises the case priority. Agree the correlation window and escalation path with the identity and service desk teams before go-live, and test it during the exercise.
How to validate the detection before relying on it
This sequence proves that the T1667 Email Bombing detections fire on controlled, agreed volumes in a test mailbox, and it produces a record of latency, false positives and tuning changes that a reviewer can check before the rule goes into production.
Agree scope and rollback with the mail owner
The detection lead and the owner of the mail platform agree in writing which test mailbox, sending sources and time window will be used, who can stop the test, and how the mailbox and any mail flow rules are restored afterward. Security operations confirms which log sources feed the detection, such as application logs from the mail platform and the file creation telemetry from the endpoints that open mail clients. The step is done when both parties sign off on the plan and the rollback path has been written down and tested on a non-production mailbox.
Confirm telemetry reaches the platform
Before any volume is generated, the team checks that Application Log Content from the mail platform and File Creation events from the test endpoints arrive in the SIEM with the expected fields, timestamps and host identifiers. Gaps in ingestion, parsing errors or delayed forwarding are recorded as findings to fix first, since they would make later results misleading. The step is complete when a benign test message produces the expected log records in the search interface within the agreed window.
Set the message rate in advance
The test lead writes down the message volume, rate, sending pattern and recipient count before the run, using the test mailbox only and a rate that the mail owner has approved for the lab. Each planned step is labeled so that results can later be matched to a specific tier of volume. The step is done when the plan is approved, the rate is documented in the test record, and the exercise owner confirms that no production recipients are in scope.
Run the controlled volume and observe
The team generates the agreed message volume to the test mailbox, watches mail platform health and queue behavior, and stops the run if the rollback conditions are met. Analysts watch the relevant dashboards and alert queues live so that they can see whether the rule fires as the volume rises. The step is done when the planned volume has been sent or the run has been halted under the agreed conditions, and the stop or completion time is recorded.
Measure which detections fire and when
For each detection, the team compares the alert timestamps with the first message in the run to calculate detection latency, and checks which dashboards and case queues show the alert. Detections that never fire, fire late or fire only at a different volume tier are marked for investigation. The step is complete when every detection in scope has a recorded outcome, including the ones that did not fire.
Record evidence and false positives
The team records alert timestamps, event counts per detection, the volume sent, any false positives from normal mail traffic during the window, and the analyst notes on each alert. Results are stored with the ATT&CK version and detection rule version the test targeted, so the record stays meaningful after later ATT&CK releases. The step is done when the evidence package is complete and a second reviewer has checked that it matches the raw logs.
Tune the rule and rerun the test
Changes to thresholds, exclusions or the rule logic are made under change control, each linked to the specific false positive or missed detection it addresses. The same controlled sequence is then rerun against the updated rule, and the new results are compared with the baseline run. The step is done when the rerun shows the intended improvement without new false positives, and the change record links both runs.
Preventive controls that reduce email bombing impact
Email bombing works by burying a mailbox under volume until a real message is missed or a user acts on a lure hidden in the noise. The two mitigations named for T1667 address different layers: people who recognize and report floods, and the mail platform settings that limit how much traffic reaches a mailbox in the first place.
User training for floods and lures
Users should know that a sudden burst of unsolicited sign-up or subscription emails can be a deliberate pattern, not a fault. User Training (M1017) covers how to recognize that pattern, avoid clicking links or calling phone numbers that appear inside floods, and report the activity to the security team quickly. Ask your awareness provider whether the course includes scenarios where the flood is followed by a fake helpdesk message, and whether reporting goes to a monitored queue rather than a general inbox.
Sender rate limits at the gateway
Rate limits at the mail gateway cap how many messages a sending host or domain can deliver within a window, so a single source cannot fill a mailbox unchecked. Confirm with your mail platform vendor whether limits apply per sender IP, per domain, per recipient, or per authenticated account, and whether the thresholds can be tuned without disabling delivery for legitimate bulk senders. Record the chosen values as configuration evidence.
Sender throttling and reputation checks
Throttling slows delivery from senders that exceed normal volume, and reputation checks weigh a sender's history before messages reach the inbox. Together they reduce the speed of a flood while giving analysts time to act. Ask the vendor how throttling responses are logged, whether deferred messages are retried or dropped, and how you would exempt known transactional senders so that password reset and invoice emails still arrive.
Quarantine and hold settings
Quarantine policies hold suspicious or high-volume messages for review instead of delivering or deleting them. This keeps evidence for investigation and lets administrators release legitimate mail. Confirm the retention period for quarantined messages, who can release them, whether users receive notifications about held mail, and whether quarantine actions appear in the logs that feed your SIEM.
Validate settings in the cyber range
Thresholds only protect a mailbox if they fire on the right traffic. Replay a controlled burst of test messages in the cyber range against the same gateway configuration used in production, then confirm that throttling, quarantine and alerting behave as documented. Record the mitigation ID and the ATT&CK version the test targets, and retest after any gateway upgrade or policy change.
Triage and response when an email bombing alert fires
The first decision is whether the alert describes a flood or a legitimate bulk send. Before anyone blocks a sender, confirm the volume, timing and content pattern against what the business expected that day. A marketing campaign, a payroll notice or a system migration can produce a sharp spike in one mailbox or one distribution list without any attack. Check whether the messages share a sender address, a sending IP, a subject pattern or a template, and whether the recipients are a single target or many. Next, identify the affected mailboxes and the sender sources, and record the time window. Then look for the usual companion activity: a mailbox that suddenly shows successful sign-ins from unfamiliar locations, new forwarding or inbox rules, or outbound messages that were not sent by a person. Email bombing is often used to bury a password reset or a fraud alert, so a flood paired with phishing or account takeover needs to be handled as an incident, not as a nuisance.
Contain the source at the gateway before cleaning up the mailbox. If the flood is confirmed, throttle or block the sending addresses, domains or IP ranges at the mail gateway, and apply rate limits to the affected recipient so that further messages are held or deferred rather than delivered. Force a password reset and revoke active sessions for any account showing compromise, and review whether a second factor method was changed during the window. Inform users and mail administrators at the same time, using a short, pre-approved message that says what happened, what to ignore, and whom to contact. Do not ask users to forward suspicious messages to an open address or to reply to them. Confirm with your own gateway and mail platform what throttling and quarantine options they actually provide, since capabilities differ by product and configuration.
Preserve evidence before you remove anything. Export the message headers, the gateway and mail server logs, and the authentication logs for the window, and store them in a case folder with a hash and a clear chain of custody. Use the platform's legal hold or preservation feature where one exists, rather than moving or deleting messages by hand. Clean-up can then proceed by quarantining or purging the flood messages only after the export is verified, and by reviewing the mailbox for forwarding rules and delegated access that the attacker may have added. Record each step in the incident ticket so that the response can be reviewed later and aligned with your own retention policy and any applicable disclosure duties.
Rehearsing email bombing detection in a private cyber range
The range should mirror the mail path the client operates, but on isolated infrastructure with synthetic accounts that nobody outside the exercise can reach. Collection must be working before the first inject, so that application log content from the mail stack and file creation events on the mail hosts are captured and searchable.
- Isolated mail server: Deploy the mail platform the client runs, or a close equivalent, on a network segment with no route to production mail services or the internet.
- Test mailboxes: Create synthetic mailboxes with naming that makes every generated message traceable to a test identity.
- Wazuh collection: Confirm agents on the mail hosts forward application logs and file creation events to the manager, and validate parsing before the exercise begins.
- Security Onion collection: Verify that mail-related network traffic reaches the sensor so host-side events can be correlated with network context.
- Baseline capture: Record normal message volume for the test mailboxes so analysts have a reference point during the run.
Before scheduling any inject, check that a known test message appears in both Wazuh and Security Onion with the fields the Sigma-style rule expects.
Injects describe what happens in the scenario, not how the traffic is produced. The facilitator schedules events that change the volume and shape of mail activity, then records the time of each one so the review can compare what the team observed with what actually occurred.
- Gradual onset: An inject that raises message volume to a test mailbox over time, testing whether analysts notice a trend before any threshold is crossed.
- Sudden burst: A short, high-volume event that tests alert timing and first-line triage.
- Mixed traffic: A scenario in which ordinary test mail continues alongside the anomaly, testing whether analysts separate noise from signal.
- Administrator call: A scripted report from a test user about a full or unresponsive inbox, testing the handoff between the SOC and mail administrators.
- Timeline log: A facilitator log with timestamps for every inject, kept separately from the team's own notes.
Write each inject as an observable outcome so the team has to determine the cause from telemetry, not from the facilitator's description.
SOC analysts should be judged on whether they reached the detection logic defined earlier on this page, correlated application log content with file creation events, and escalated with enough context for mail administrators to act. Documented reasoning matters more than speed alone.
- Alert fidelity: Confirm the rule fired on the expected application log content and on the intended test mailbox, and note any alerts that fired on unrelated test activity.
- Context gathering: Analysts should pivot from the alert to the affected mailbox and to the host where file creation events were recorded.
- Triage notes: Record what was ruled out, such as scheduled jobs or bulk mail from known test senders.
- Escalation: Hand off to mail administrators using the field set in the response playbook.
- Tuning proposals: List false positives and missed signals so the rule can be tuned after the exercise.
Check that every alert has a documented disposition and that the analyst timeline matches the facilitator's inject log.
Mail administrators rehearse containment and recovery: keeping mailbox service available, applying the configuration changes the playbook specifies, and confirming that user guidance reaches affected test users. Success depends on restoring service without losing evidence that the SOC needs for review.
- Containment steps: Apply the rate or access change defined in the playbook, and record it before execution so the change is traceable.
- Configuration review: Compare the mail platform's sending and receiving settings with the documented baseline, and confirm that any deviation is intentional.
- Evidence preservation: Export mail logs and snapshot configuration before making changes, so the analysts can reconstruct the timeline.
- User communication: Send the scripted notice to test users, then verify they follow the guidance on suspicious mail from the user training material.
- Service restoration: Return mailboxes to normal operation and record when each step was completed.
Check that each configuration change can be reversed and that the recovery record names who approved each step.
Questions SOC leads ask about detecting email bombing
How do we separate legitimate bulk mail from an email bombing flood?
Separate them by behavior rather than by volume alone, since a newsletter and a flood can both produce thousands of messages. Legitimate bulk mail usually comes from known senders, follows a predictable schedule, carries consistent authentication results and generates few complaints or bounces per recipient. A flood tends to target one or a small set of mailboxes, arrives from many unrelated sources in a short window, and shows repeated sign-up or verification messages from unfamiliar services. Build your baseline from several weeks of mailbox telemetry, then alert on deviation per recipient. Confirm how your mail platform exposes these fields before writing any rule.
Which MITRE ATT&CK version should our email bombing detections map to?
Map detections to the ATT&CK version you are actively using, and record that version in every rule and in the coverage matrix. Releases can rename, deprecate or revoke techniques, so a mapping that is correct today may need review after the next update. The MITRE ATT&CK updates page lists each release, and the Enterprise STIX bundles in the attack-stix-data repository let you diff technique and data component changes between versions. Pin the version in your detection-as-code repository, and schedule a review when MITRE publishes a new release.
Are Office Suite audit logs enough to detect email bombing?
Audit logs are a necessary source, but they are rarely enough on their own. Application Log Content from the mail and collaboration platform shows message delivery, mailbox rule changes and authentication events, which covers most of the signal. Endpoint telemetry adds context when a user is flooded by a process or client, and network telemetry helps when mail is relayed through unusual paths. Check three things: whether your retention covers the baseline window, whether message-level metadata is logged or only summaries, and whether the logs reach your SIEM without parsing gaps.
How do we tune email bombing thresholds without blinding the SOC?
Tune thresholds in stages, and measure alert volume and false positives for each change before promoting it. Start with per-recipient rates that exceed your baseline by a wide margin, then add conditions such as sender diversity and time window. Suppress known bulk senders through an allowlist that is reviewed on a fixed schedule, not one that grows silently. Keep a record of every threshold change, the reason for it and the analyst who approved it. Avoid raising a threshold simply because one shift was noisy, because a quiet queue can hide a real campaign.
How often should we rerun validation after detection rule changes?
Rerun validation after every change to a rule, a threshold, a log source or the mail platform itself, and on a fixed schedule even when nothing has changed. A log source upgrade can rename fields and quietly break a rule without any error. Use a cyber range or a non-production tenant to replay representative benign and flood-like traffic, then confirm the expected alerts fire and the benign traffic stays quiet. Record the results against the ATT&CK version and rule version tested. The schedule for routine reruns should be set in your own change process, and DeployOpen can help define it within a fixed-scope engagement.
Which user training and configuration controls reduce email bombing impact?
Two ATT&CK mitigations apply most directly: User Training (M1017) and Software Configuration. User training helps people recognize sudden floods of verification or sign-up messages, know not to click unsolicited support links and report the activity promptly. Software configuration covers mail platform settings such as rate limits, sender filtering, verification controls and mailbox rules that can be tuned to limit abuse. Confirm the exact settings your platform offers and test each change in a non-production environment before rollout, since some controls can also block legitimate mail.
Can our own team build and rehearse these detections without outside help?
Many teams can build the core detections internally if they have a mail platform administrator, a SIEM engineer and an analyst who understands the normal mail pattern. The harder parts are the baseline, the validation and the response playbook, which need time and a safe place to test. Ask yourself whether you have a non-production mail environment, a way to generate benign and flood-like test traffic, and a process for recording test results against the ATT&CK version you target. If any of these is missing, a fixed-scope engagement that covers detection, validation and a cyber range exercise can close the gap, and DeployOpen scopes that work in writing before it starts.
How DeployOpen builds email bombing detections and range drills
DeployOpen approaches T1667 Email bombing as a fixed-scope engagement that starts with the mail platforms and log sources your organization actually runs. The detection work is built inside your own infrastructure, then rehearsed in a private cyber range before it is handed over.
How we scope
- Confirm which mail, collaboration and identity platforms in your estate produce application logs relevant to T1667 Email bombing.
- Record which Linux, Windows, macOS and Office Suite log sources are in scope, and which ones are not yet collected.
- Agree the ATT&CK version the detection mapping targets, such as v20, in the written scope before work starts.
How we build
- Map candidate detections to the Application Log Content and File Creation data components referenced for this technique.
- Write detection logic in open-source formats such as Sigma rules and deploy it to Wazuh or Security Onion in your environment.
- Document alert thresholds, tuning notes and known false positives from mailing lists, bulk notifications and legitimate newsletters.
How we hand over
- Deliver the detection catalog with each rule's data source requirements, logic in plain language and the ATT&CK mapping.
- Run a rehearsal in a private cyber range and record which simulated bombing patterns triggered alerts and which did not.
- Provide runbooks for triage and response, plus a list of user training and software configuration actions for your owners to confirm.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
- Ongoing support, upgrades and continuous testing of these detections are available as a retainer.
- Revisit the mapping when ATT&CK releases rename, deprecate or revoke techniques, so detections stay tied to a named version.
