Microsoft 365 Email Bombing: When an Inbox Flood Is a Fake IT Support Attack

Microsoft 365 Email Bombing: When an Inbox Flood Is a Fake IT Support Attack
An employee's Microsoft 365 inbox suddenly fills with hundreds of messages.
Newsletter confirmations arrive every few seconds. Password-reset notices, shopping promotions, foreign-language subscriptions, and account-registration emails bury normal customer and coworker messages. The employee cannot keep up.
Then someone offers to help.
The contact may come through a Microsoft Teams chat, a Teams call, a phone call, or a message from someone named "Help Desk" or "IT Support." The person sounds informed because they already know about the email flood. They say the account has a spam problem, the mailbox needs an urgent filter update, or the device must be checked before the situation gets worse.
The timing makes the support contact feel legitimate. In reality, the person offering help may be the same attacker who created the inbox flood.
This is email bombing, also called subscription bombing, mail bombing, or an inbox flood attack. It can be used as a distraction, a way to hide an important security alert, or the opening act in a fake IT support attack that leads to remote access, credential theft, malware, or ransomware.
For small and midsize businesses, the practical lesson is important: a sudden flood of email is not only a spam problem. It may be an active security incident.
Why This Topic Matters Now
The buyer-relevant keyword cluster behind this post is Microsoft 365 email bombing, subscription bombing attack, inbox flood attack, Microsoft Teams fake IT support, Quick Assist scam, mail bombing detection, Microsoft 365 spam flood, fake help desk attack, and email bombing incident response.
This is a useful search topic because it connects a visible employee problem to identity, endpoint, email, collaboration, and ransomware risk.
Microsoft's Q2 2026 email threat landscape report showed that malicious Teams activity was rising during the first half of 2026. The average number of detected Teams-based phishing attacks increased 19% from March to April and another 10% into June. Microsoft also showed weekly malicious Teams call attempts climbing from roughly 2,000 in early January to nearly 10,000 by the end of June. The dominant lure was technical-support impersonation, often warning employees about an impending account lockout.
Microsoft separately documented a 2026 incident in which an attacker used persistent Teams voice phishing, impersonated IT support, and eventually convinced an employee to provide remote access through Quick Assist. After gaining interactive access, the attacker directed the employee to a malicious website and deployed additional tooling.
The email flood is what makes this attack especially convincing. Microsoft has described attackers signing a target up for many legitimate mailing lists, then contacting the target as fake support and claiming they can fix the problem. The attacker creates the emergency and then arrives as the apparent solution.
The attack does not depend on one obviously malicious email. Many of the flood messages may be genuine confirmations from real services. Traditional sender blocking alone is not enough.
What Is an Email Bombing Attack?
An email bombing attack sends a very large number of messages to one mailbox or a small group of mailboxes in a short period.
One common method is automated subscription abuse. The attacker submits the victim's address to newsletters, product registrations, mailing lists, trial accounts, event sites, and other online forms. Each legitimate service sends its own confirmation or welcome message.
The result can be hundreds or thousands of unrelated messages from many legitimate domains.
This creates several problems:
- important customer and employee messages become difficult to find
- security alerts may be buried in the noise
- password-reset or purchase notifications may be missed
- the employee becomes anxious and distracted
- the help desk may treat the issue as ordinary spam cleanup
- a fake support contact can appear unusually credible
- employees may approve remote access just to make the flood stop
Email bombing is different from ordinary spam. A normal spam campaign usually tries to deliver a lure, advertisement, or malicious link. A subscription bomb uses volume itself as a weapon.
The inbox flood may be the objective, but often it is a means to another objective.
Why Attackers Flood an Inbox
Attackers use email bombing for several reasons. The response should account for all of them.
1. To Create a Fake Support Emergency
The attacker floods the inbox and then contacts the employee through another channel.
They may say:
- "We detected the spam attack on your mailbox."
- "Your Microsoft 365 account is generating errors."
- "IT needs to install an updated spam filter."
- "Your device is at risk of being locked."
- "Open Quick Assist so we can remove the messages."
- "Accept this Teams request so the help desk can repair Outlook."
The employee sees a real problem, so the explanation feels plausible. The attacker does not need to convince the employee that something is wrong. The employee can see the problem happening.
2. To Hide a Real Security or Financial Alert
An inbox flood can bury a message the attacker does not want the employee to notice.
That message might be:
- a password-reset notification
- a new sign-in alert
- an MFA or authentication-method change
- a bank transfer or card-purchase notice
- an e-commerce order confirmation
- a payroll or direct-deposit change
- a new mailbox rule notification
- an OAuth application approval
- a vendor payment message
- a cloud file-sharing alert
This means the business should not only stop the flood. It should search for the event the flood may be hiding.
3. To Overwhelm the Employee's Judgment
An inbox flood creates urgency and frustration. Employees may stop checking sender details, click "unsubscribe" links without thinking, or accept help from the first person who offers it.
The attacker benefits from decision fatigue.
This is why "be more careful" is not an adequate control. The business needs a documented response that employees can follow while the mailbox is noisy.
4. To Distract IT During a Larger Attack
If several employees are affected, the help desk may spend time creating filters and deleting mail while a separate compromise continues.
The flood can pull attention away from:
- a compromised Microsoft 365 account
- remote access on an endpoint
- unusual Teams communication
- suspicious sign-ins
- data access in SharePoint or OneDrive
- changes to mailbox rules or forwarding
- fraudulent finance activity
- malware execution or lateral movement
The visible symptom is not always the main incident.
How the Email Bombing and Fake IT Attack Works
A common attack sequence looks like this.
Step 1: The Attacker Selects a Target
The attacker may target an employee with access to money, customer data, administration, files, or other business systems.
Likely targets include:
- executives and executive assistants
- accounting and finance employees
- HR and payroll staff
- IT administrators
- office managers
- legal or compliance employees
- employees with broad SharePoint or OneDrive access
- employees who can approve remote access or install software
Public websites, social media, prior breaches, vendor lists, and address-format guessing can provide enough information to begin.
Step 2: The Inbox Flood Begins
Automated systems submit the employee's email address to many online forms. Messages begin arriving from unrelated, often legitimate services.
The employee may receive hundreds of messages over minutes or hours. Some services may require confirmation, while others send welcome or registration emails immediately.
Because the senders are diverse and legitimate, a simple block on one sender or domain does not solve the problem.
Step 3: Fake Support Arrives Through Teams or Phone
The attacker contacts the employee while the flood is active.
Microsoft Teams is attractive because employees associate it with coworkers and business communication. An external chat or call can still appear professional, especially when the attacker's display name is "IT Support," "Help Desk," or a variation of the company's MSP name.
The contact may also arrive by phone. Caller ID is not proof of identity because numbers and display names can be spoofed.
Step 4: The Attacker Requests Access
The attacker may ask the employee to:
- open Microsoft Quick Assist
- enter a remote-support code
- allow screen sharing or remote control
- join a Teams screen-sharing session
- install a remote monitoring and management tool
- visit a fake Microsoft 365 sign-in page
- enter a password or MFA code
- approve an unexpected sign-in prompt
- run a command or installer
- disable a security control temporarily
The request is presented as the fix for the inbox problem.
Step 5: The Attacker Expands Access
Once the employee grants remote control or provides identity information, the attacker may:
- steal Microsoft 365 credentials or session tokens
- install malware or a remote access tool
- search email for financial and customer information
- download SharePoint or OneDrive files
- create mailbox rules or forwarding
- access other SaaS applications
- steal browser sessions or saved credentials
- move laterally to other systems
- prepare data theft, extortion, or ransomware
At that point, deleting subscription emails is no longer the main concern.
Warning Signs Employees Should Recognize
Employees should know that a sudden email flood is reportable even when none of the individual messages appears malicious.
Warning signs include:
- hundreds of unexpected subscription or registration messages arriving quickly
- unrelated messages in multiple languages
- a new Teams chat or call from an external user claiming to be IT
- someone contacting the employee immediately after the flood begins
- a support person who already knows about the mailbox problem but cannot provide a valid ticket number
- a request to open Quick Assist or another remote access tool during an unsolicited contact
- a request to read back a code or approve a sign-in
- pressure to act before contacting the normal help desk
- instructions to ignore Microsoft Defender, browser, or external-sender warnings
- a password-reset, bank, payroll, purchase, or security notice hidden among the flood
The safe response is direct: stop, disconnect, and contact the real help desk through the published support channel.
What an Employee Should Do Immediately
When an inbox flood starts, the employee should not try to solve it alone.
Use this response:
- Report the email flood to the real IT provider or internal help desk using a known phone number, support portal, or previously installed support application.
- Do not accept unsolicited Teams chats, calls, remote-control requests, or Quick Assist codes.
- Do not click unsubscribe links in the flood. Some may be legitimate, but the volume makes safe review difficult and malicious messages can be mixed in.
- Do not delete everything immediately. Evidence and important alerts may be buried in the messages.
- Note when the flood began and whether any unusual call, text, Teams message, sign-in prompt, purchase, or account change happened near the same time.
- If remote access was granted or credentials were entered, disconnect the device from the network when instructed by the real response team and treat the event as a possible compromise.
Employees should not be punished for reporting quickly. A short delay caused by verification is far less costly than handing an attacker remote control.
The IT Response: Treat the Flood as a Security Signal
The technical response should go beyond creating an Outlook rule.
1. Verify the Employee Through a Trusted Channel
Confirm the employee's identity and establish what happened.
Ask:
- When did the flood begin?
- How quickly are messages arriving?
- Did anyone call, text, email, or message through Teams?
- Did the employee open Quick Assist or another remote tool?
- Did the employee share a screen or allow control?
- Were credentials, MFA codes, or device codes entered?
- Were any unexpected prompts approved?
- Did the employee notice a hidden financial or security alert?
This timeline determines whether the case is an inbox-only incident or a broader compromise.
2. Preserve and Search the Messages
Do not bulk-delete the mailbox before checking what the flood may be concealing.
Search the relevant time window for:
- password resets
- MFA changes
- security information registration
- new-device or new-location alerts
- payment and banking notifications
- order and purchase confirmations
- payroll changes
- mail-forwarding notices
- OAuth consent or application notices
- unusual file-sharing activity
- messages from customers or vendors about unexpected requests
Message trace, Microsoft 365 audit data, Defender Explorer where licensed, mailbox search, and vendor logs can help reconstruct the event.
3. Review Microsoft Teams Activity
Check for external chats, calls, meeting invitations, files, and URLs around the time of the flood.
Record:
- sender and tenant information
- display name and actual address
- whether the thread was external
- call times and duration
- links, files, or remote-support instructions
- whether the employee accepted, blocked, or reported the contact
If the organization uses Defender for Office 365 capabilities for Teams, review applicable alerts and reported-message workflows. Licensing and available telemetry vary, so the response process should not depend on one portal view.
4. Review Identity Activity
Investigate:
- unusual or risky sign-ins
- unfamiliar IP addresses, devices, or applications
- new authentication methods
- password resets
- refresh-token and session activity
- device code authentication
- OAuth consent grants
- administrator-role changes
- authentication from unmanaged devices
If compromise is confirmed or strongly suspected, block sign-in as appropriate, revoke active sessions and refresh tokens, reset credentials through a trusted process, and remove unauthorized authentication methods or application grants.
A password reset alone may not terminate every active session or remove every persistence mechanism.
5. Review the Endpoint
If the employee shared a screen, opened Quick Assist, approved remote control, installed software, or ran a command, treat the endpoint as potentially compromised.
Review:
- Quick Assist and Teams artifacts
- remote access and RMM software
- browser history and downloads
- PowerShell and command-line activity
- newly installed MSI packages or applications
- persistence mechanisms
- security alerts and endpoint telemetry
- suspicious network connections
- saved browser credentials and sessions
Isolate the device when the risk justifies it. Rebuilding may be safer than trying to prove that a hands-on-keyboard attacker made no lasting changes.
6. Check Business Processes
The incident may be connected to a transaction or account change outside Microsoft 365.
Verify recent:
- wire, ACH, and vendor-payment activity
- payroll and direct-deposit changes
- credit card or e-commerce orders
- password resets for banking, payroll, and SaaS services
- customer refund requests
- vendor bank-detail changes
- sensitive file access or sharing
Contact banks, vendors, customers, insurers, or legal counsel according to the facts and the business's incident response plan.
Microsoft 365 Controls That Reduce the Risk
No single control stops every email bombing and fake-support attack. A layered approach is more effective.
Detect Mail Bombing as a Pattern
Email security should look for unusual message volume and subscription-confirmation patterns directed at one recipient.
Microsoft has documented a Mail bombing detection method in Defender hunting examples. Availability depends on licensing and data sources, so businesses should confirm what their tenant can actually detect and who receives the alert.
The important operational requirement is clear: a mailbox receiving a rapid, unusual flood should create a security investigation, not only a spam ticket.
Tighten Microsoft Teams External Communication
Review how external Teams users can contact employees.
Depending on business needs, consider:
- allowing external communication only with trusted domains
- restricting unmanaged or newly created external tenants
- using clear policies for external chat and calls
- training employees to inspect external-user labels
- enabling user reporting for suspicious Teams messages
- defining who investigates Teams phishing reports
- separating guest collaboration from unrestricted external access
Do not disable useful collaboration without understanding the business impact. The goal is to make external access intentional and support impersonation harder.
Control Remote Support Tools
Inventory every approved remote support tool.
If the business does not use Quick Assist, consider blocking or removing it. If Quick Assist or another remote tool is required, document:
- who may initiate a session
- how the employee verifies the technician
- how codes are exchanged
- whether sessions are logged
- whether privileged access is separate
- which tools are prohibited
- what employees should do after an unexpected request
Microsoft recommends that users allow a Quick Assist connection only when they initiated contact with the legitimate support team.
Improve Identity Protection
Use identity controls to reduce what an attacker can do after social engineering succeeds.
Priorities include:
- phishing-resistant MFA for high-risk users
- Conditional Access where licensing supports it
- managed or compliant-device requirements for sensitive resources
- blocking device code flow when there is no legitimate business need
- alerts for new authentication methods
- risk-based sign-in and user policies where available
- restricted application consent
- separate administrator accounts
- routine review of active sessions and registered methods
Identity protection does not replace help-desk verification, but it narrows the attacker's options.
Protect Email, Files, and Endpoints Together
The attack crosses product boundaries. Email creates the pressure, Teams or phone provides the impersonation channel, identity opens cloud access, and a remote support tool may expose the endpoint.
Monitor these as one sequence:
- sudden inbound mail volume
- external Teams contact
- Quick Assist or remote-control use
- unusual sign-in or MFA change
- mailbox rule creation
- SharePoint or OneDrive download activity
- endpoint script or installer execution
Separate tools and separate support queues can miss the pattern.
Build a Verifiable Help-Desk Process
The strongest small-business improvement may be procedural.
Employees should know:
- the official help-desk phone number and support portal
- whether IT ever initiates calls without a ticket
- how a technician proves their identity
- which remote support tool is approved
- what IT will never ask for
- how to report a suspicious Teams user
- how to respond to an email flood
- that they may end an unexpected support call and call back safely
Legitimate support should never ask an employee to disclose a password, read back an MFA code, approve an uninitiated prompt, enter a device code supplied by a caller, or bypass a security warning.
For high-risk actions, use a ticket visible in the normal portal, a callback to the published number, and another verification step. Caller ID and a familiar display name are not enough.
A Practical Email Bombing Incident Checklist
Use this as a starting point:
- Tell the employee not to engage with unsolicited support contacts.
- Verify the employee through a trusted channel.
- Record the start time and approximate volume of the flood.
- Preserve messages before bulk cleanup.
- Search for hidden security, financial, purchase, and account-change alerts.
- Review Teams chats, calls, files, links, and external contacts.
- Determine whether Quick Assist or another remote tool was used.
- Review sign-ins, authentication methods, sessions, and OAuth grants.
- Inspect the endpoint if remote access, downloads, or commands occurred.
- Review mailbox rules, forwarding, sent mail, and deleted items.
- Check SharePoint, OneDrive, and sensitive SaaS activity.
- Verify payroll, bank, vendor, and customer-payment changes.
- Block malicious senders, tenants, domains, and infrastructure where appropriate.
- Notify affected internal teams and external parties based on confirmed scope.
- Document what happened and update detection and support procedures.
Questions Business Owners Should Ask Their IT Provider
Leadership does not need to operate Microsoft Defender, but it should expect clear answers.
Ask:
- Would a rapid subscription bomb create an alert in our Microsoft 365 environment?
- Who investigates an email flood after business hours?
- Can employees report suspicious Teams chats and calls?
- Do we allow unknown external Teams users to contact everyone?
- Is Quick Assist approved, restricted, monitored, or blocked?
- How does an employee verify that a support caller is real?
- What will support never ask an employee to disclose or approve?
- Can we search for a hidden password-reset, purchase, or payment alert quickly?
- Can we revoke Microsoft 365 sessions and remove unauthorized MFA methods promptly?
- Do identity, email, Teams, endpoint, and finance investigations connect to one response plan?
If the answers are unclear, the business has a gap attackers can exploit.
How CybarWorks Can Help
CybarWorks helps small and midsize businesses secure Microsoft 365 across the full attack path—not only the inbox.
We can review Microsoft 365 email protections, mail-bombing visibility, Defender policies, Teams external access, Quick Assist and remote support controls, Conditional Access, MFA methods, endpoint protection, user reporting, help-desk verification, and account-compromise response.
The goal is to keep employees productive while making it harder for attackers to manufacture an emergency, impersonate support, and turn a noisy mailbox into access to the business.
If your organization is not sure how it would respond to an email bombing attack or a fake Microsoft Teams help-desk call, contact CybarWorks. We can identify the highest-risk gaps and build a practical Microsoft 365 security and incident-response plan around the way your team actually works.
Frequently Asked Questions
What is Microsoft 365 email bombing?
Microsoft 365 email bombing is an attack that sends a mailbox a very high volume of messages, often by registering the address with many legitimate newsletters and online services. The flood can disrupt work, hide an important alert, or prepare the employee for a fake IT support contact.
Why would fake IT support contact someone after an email flood?
The flood gives the attacker a credible reason to offer help. The attacker may then ask the employee to open Quick Assist, share a screen, approve remote control, visit a fake sign-in page, or disclose authentication information.
Does DMARC stop subscription bombing?
Not by itself. SPF, DKIM, and DMARC help recipients evaluate whether mail is authorized for the sender's domain. In a subscription bomb, many messages may come from legitimate services using properly authenticated domains. Detection needs to consider abnormal volume, message patterns, employee reports, and related activity.
Should employees click unsubscribe during an email bombing attack?
Employees should report the incident and follow the organization's response process instead of clicking large numbers of unsubscribe links. Malicious messages may be mixed into the flood, and important evidence or alerts may be buried in the mailbox.
Is Quick Assist unsafe?
Quick Assist is a legitimate Microsoft remote-support tool. The risk comes from granting access to an unverified person. Employees should use it only through the business's approved support process and only after independently verifying the technician.
What should IT investigate after an inbox flood?
IT should review the flood timeline, hidden security or financial alerts, Teams and phone contact, remote-support activity, Microsoft 365 sign-ins and MFA changes, mailbox rules, OAuth grants, endpoint activity, SharePoint and OneDrive access, and sensitive business transactions.
Works Cited
- Microsoft Security Blog, Email threat landscape: Q2 2026 trends and insights
- Microsoft Security Blog, Help on the line: How a Microsoft Teams support call led to compromise
- Microsoft Security Blog, Impersonating IT support: How threat actors turn a remote session into enterprise-wide access
- Microsoft Security Blog, Disrupting threats targeting Microsoft Teams
- Microsoft Security Blog, Threat actors misusing Quick Assist in social engineering attacks leading to ransomware
- Microsoft Community Hub, Protection Against Email Bombs with Microsoft Defender for Office 365
- CISA and partner agencies, #StopRansomware: Black Basta

