How Attackers Use Mailbox Rules to Hide Email Fraud

title: How Attackers Use Mailbox Rules to Hide Email Fraud meta_title: “Mailbox Rules Attack: How Inbox Rules Hide Email Fraud” meta_description: Attackers abuse mailbox rules to forward, move, delete, or mark messages read—hiding BEC and phishing. Learn detection steps and fixes. date: 2026-05-16 updated: 2026-05-16 keywords: - mailbox rules - inbox rule attack - BEC detection - OAuth consent phishing - Microsoft 365 security - Google Workspace security - email fraud - mail forwarding - incident response tweet_draft: Attackers often don’t “hack email” by brute force—they add mailbox rules to hide replies, forward messages, and delete alerts. Here’s how inbox rules power BEC, what to hunt for, and how to lock them down. linkedin_draft: Mailbox rules are a quiet but powerful tactic in email fraud (BEC/phishing). Attackers create rules to auto-forward sensitive threads, move messages into obscure folders, mark them read, or delete security alerts—buying time and hiding victim replies. This short guide explains common rule patterns, what to check in M365/Google Workspace, and practical prevention + hunting ideas.—

Attackers frequently abuse mailbox rules (an “inbox rule attack”) to hide email fraud like BEC and phishing—without needing noisy malware or constant logins. By auto-forwarding, moving, deleting, or marking messages as read, they quietly suppress warnings and control payment conversations long enough to get a wire sent.

TL;DR - Attackers create/modify mailbox rules to auto-forward, move, mark-as-read, or delete messages related to fraud. - This hides victim replies, suppresses bank/security notifications, and keeps finance threads under attacker control. - Treat unexpected rule/forwarding changes as high priority: review rules, revoke sessions/tokens, reset creds, and hunt audit logs.

Detailed Explanation

Mailbox rules (often called inbox rules) are meant for productivity—sorting newsletters, routing support mail, labeling projects. Attackers abuse the same feature because it’s native, quiet, and works even after the attacker logs out.

Why rules are effective for fraud

Email fraud—especially Business Email Compromise (BEC)—depends on controlling the conversation. The attacker wants to:

See inbound replies from the victim or vendor
Hide warnings (bank confirmations, password reset emails, MFA prompts)
Steer invoice/wire instructions without the victim noticing inconsistencies
Maintain persistence while avoiding obvious account lockouts

A well-placed rule turns the mailbox into an automated “traffic cop” that silently reroutes or destroys evidence.

Common malicious mailbox rule patterns

Below are the patterns most often used to hide fraud. Attackers may create one rule or multiple staged rules.

1) Auto-forwarding to an external address (exfiltration + persistence)

The attacker creates a rule to forward all mail—or mail matching key terms—to an external mailbox they control. This allows them to monitor conversations without repeatedly logging in (reducing MFA prompts and suspicious sign-ins).

Typical targets:

Finance/AP/AR mailboxes (invoices, remittance)
Executives and assistants
Shared mailboxes used for purchasing or vendor onboarding

Forwarding can be:

A visible rule the user could find (if they look)
Hidden via server-side forwarding settings (depending on platform/admin settings)
Implemented via OAuth app access rather than a classic rule (see below)

2) Move messages to obscure folders (hiding the thread)

Instead of deleting mail (which can be noticed), attackers move messages into:

RSS / Feeds
Archive
Conversation History
Junk/Spam (less likely to be checked)
A newly created folder with a benign name (“Notes”, “Receipts”, “_”, “.”)

This is common when the attacker wants to keep the messages for later but prevent the user from seeing them in the inbox.

3) Mark as read (reducing user attention)

Marking messages as read removes “unread” indicators and reduces the chance the victim opens and scrutinizes an email. Attackers often combine this with moving messages away from the inbox.

4) Delete messages (suppression of alerts)

Deletion is used to suppress:

Bank “new payee” or “wire scheduled” notifications
Security alerts (“Unusual sign-in”, “MFA code”, “password reset”)
Vendor emails that would expose the fraud (“We didn’t change our bank details”)

Attackers may also delete replies from internal staff questioning changes.

5) Keyword- or sender-based filtering (surgical fraud)

To avoid disrupting normal business, attackers target only messages that can expose the scheme. Common keyword triggers include:

“invoice”, “payment”, “wire”, “ACH”, “bank”, “routing”, “SWIFT”
“change”, “update”, “new account”, “remittance”
“MFA”, “verification”, “security”, “alert”, “sign-in”

Sender-based rules may target:

Your bank domain
Key vendors
Internal security notifications (or your helpdesk/ticketing system)

6) “Stop processing more rules” (ensuring attacker rule wins)

Rules often have a “stop processing” option that prevents later rules from applying. Attackers use it to ensure their hiding/exfil rule executes first, even if the org already has legitimate rules.

7) Rules created without password compromise (OAuth and delegated access)

Not every inbox rule attack requires a stolen password. Two common paths:

OAuth consent phishing: A user is tricked into granting a malicious app access to mailbox data. The app then reads mail or sets forwarding/rules via API (depending on granted scopes and platform).
Delegated access abuse: The attacker obtains access through shared mailbox permissions, compromised admin, or exposed app passwords/legacy auth (where still enabled).

What to Do Next (Incident Response Checklist)

Treat mailbox rule abuse as an incident indicator, not just a “weird setting.” Recommended response steps:

Review inbox rules and forwarding settings immediately for the suspected mailbox (and adjacent accounts: assistant, finance team, shared mailboxes).
Capture evidence before removing anything: export rule details, record timestamps, and keep screenshots/log exports.
Remove/disable suspicious rules and block new external forwarding if feasible.
Terminate active sessions and revoke refresh tokens (critical if OAuth consent or token theft is involved).
Reset credentials and enforce phishing-resistant MFA where possible.
Hunt tenant-wide for similar rules and review audit logs for rule creation/changes.
Validate payment changes out-of-band (call a known number, not one provided over email) if BEC is suspected.

If you’re building a broader response playbook, it helps to understand the mechanics of a supply chain attack as well—BEC can intersect with vendor compromise and invoice tampering. See: /content/faq-what-is-a-supply-chain-attack/.

Technical Notes: What to Look For (Patterns + Practical Checks)

The exact commands depend on platform and licensing, but these are practitioner-friendly starting points.

Microsoft 365 / Exchange Online: suspicious rule behaviors

Look for rules that:

Forward/redirect to external recipients
Move to RSS/Archive/Junk/hidden folders
Delete messages
Match finance/security keywords
Include StopProcessingRules
Were created recently or outside normal working hours

PowerShell: list inbox rules for a mailbox

# Requires Exchange Online PowerShell module and appropriate permissions
Connect-ExchangeOnline

Get-InboxRule -Mailbox user@domain.com |
  Select-Object Name,Enabled,Priority,From,SubjectContainsWords,BodyContainsWords,RedirectTo,ForwardTo,MoveToFolder,DeleteMessage,MarkAsRead,StopProcessingRules |
  Format-List

PowerShell: check mailbox-level forwarding

Get-Mailbox user@domain.com | Select-Object ForwardingSmtpAddress,ForwardingAddress,DeliverToMailboxAndForward

What to pull from audit logs (hunting)
Search for activities commonly named like:

New-InboxRule
Set-InboxRule
Remove-InboxRule
Set-Mailbox (forwarding changes)
Add-MailboxPermission / Add-RecipientPermission (delegation changes)

Exact event names vary by audit pipeline and tooling, so use your SIEM/Unified Audit Log search terms around “InboxRule” and “Forward”.

Google Workspace: filters, forwarding, and delegated access

In Gmail, the equivalent of “rules” are Filters and Forwarding settings. Attackers may also use delegation (“Grant access to your account”) to persist.

Admin-side investigation often includes checking:

User’s forwarding addresses
Filters that “Skip Inbox,” “Mark as read,” “Delete,” or apply labels
Recently added delegates or suspicious OAuth apps

Key indicator: filters that target finance/security keywords and apply “Delete it” or “Skip the Inbox (Archive it).”

Prevention: Reduce Mailbox Rule Abuse Risk

Tenant controls that help (M365 and Google Workspace)

Restrict or disable external auto-forwarding (where business allows).
Require strong MFA (phishing-resistant where feasible) and block legacy authentication.
Limit OAuth app consent (admin approval workflows; restrict high-risk scopes).
Turn on and retain audit logs, and alert on rule/forwarding changes.
Conditional access / risk-based sign-in policies for privileged and finance users.

User-level hygiene that prevents BEC from sticking

Train finance and exec assistants on out-of-band verification for bank detail changes.
Encourage reporting of “missing emails” or “emails marked read” anomalies.
Reduce password reuse and improve credential hygiene.

For SMBs that want a practical improvement quickly, adopting a business password manager reduces credential reuse and makes recovery faster after incidents. See our guide: /content/best-password-manager-for-small-business-2026/. If you choose a commercial option, 1Password is a common pick for small teams (Try 1Password →) because it supports shared vaults, admin controls, and recovery workflows.

Common Misconceptions

“If the user changed their password, the problem is solved.”

Not always. If the attacker established persistence via OAuth tokens, app consent, delegation, or forwarding, they can retain access after a password reset. You must revoke tokens/sessions and remove malicious grants/settings.

“Inbox rules are user-only; admins don’t need to worry.”

Admins should worry because rule abuse can indicate a larger compromise (credential theft, OAuth abuse, lateral movement). Also, tenant-wide settings can prevent or limit external auto-forwarding and improve auditing.

“Deleting emails would be too obvious—attackers won’t do it.”

Attackers often delete selectively: bank alerts, vendor corrections, and internal warnings. Victims may not notice missing emails in high-volume mailboxes, especially if messages are moved to obscure folders rather than deleted.

“This only happens in big enterprises.”

SMBs are frequent targets because payment processes are often informal and security controls (MFA enforcement, auditing, conditional access) may be lighter. Mailbox rule abuse is low-cost and scales well for attackers.

“If we block external forwarding, we’re safe.”

Blocking external forwarding helps, but attackers can still:

Move/hide messages internally
Use internal forwarding to another compromised mailbox
Abuse delegated access or malicious OAuth apps to read mail directly

Microsoft Learn: Manage mail flow and anti-spam policies (including controls for automatic forwarding)
Microsoft Learn: Exchange Online mailbox auditing and Unified Audit Log investigation
Google Workspace Admin Help: Gmail forwarding, filters, and delegation auditing
NIST: Guidance on email security, phishing-resistant MFA, and incident response fundamentals
Your internal runbooks: BEC response checklist (payment recall steps, vendor verification, legal/insurance notification paths)

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.