Introduction

If a mailbox is forwarding copies of mail to an attacker-controlled address, treat it as an active account compromise, not a simple mail setting mistake. Attackers often create inbox rules, forwarding rules, delegated access, or app-based mail access so they can keep receiving messages even after the password changes. This creates a serious security incident where sensitive communications continue leaking despite apparent recovery efforts.

The fix is to remove the unauthorized forwarding path, restore trusted control of the mailbox, and investigate how the attacker created persistence in the first place. Start by checking all possible forwarding layers, because the visible rule in a mail client may be only one part of the compromise. This type of attack is increasingly common in business email compromise (BEC) scenarios and can lead to significant data exfiltration.

Mailbox forwarding attacks are particularly dangerous because they can go undetected for long periods. Attackers typically set up forwarding rules to send copies of all incoming email to an external address, allowing them to monitor communications, gather credentials, or prepare for further attacks. The forwarding often survives password resets because the attacker has established persistence through multiple mechanisms.

Symptoms

  • Messages are being forwarded automatically to an unknown or suspicious external address
  • Users notice unexpected inbox rules, forwarding settings, or redirect behavior that they did not create
  • The mailbox shows suspicious login activity, consent prompts, or new connected apps in audit logs
  • Password resets alone do not stop the unauthorized forwarding activity
  • Sensitive messages continue leaking after initial recovery attempts
  • The problem appeared alongside unusual mailbox changes, deleted messages, or suspicious sign-ins from unfamiliar locations
  • External recipients report receiving emails that should have stayed internal
  • Mailbox rules appear with unfamiliar names, random characters, or disguised as legitimate filters
  • Organization receives reports that confidential information has been leaked
  • Login history shows access from unusual countries or IP addresses

Common Causes

  • An attacker gained mailbox access through phishing, credential theft, or brute force and created an inbox or forwarding rule
  • A compromised admin account enabled forwarding at the provider or tenant level for multiple mailboxes
  • Delegated mailbox access or a connected app (OAuth grant) still has permission to read and forward mail
  • Password theft, phishing, or token compromise gave the attacker persistent access that survives password changes
  • A previous recovery changed the password but did not revoke sessions, app access, or active tokens
  • The environment has multiple rule layers (client-side and server-side), and only one of them was reviewed
  • Legacy protocols like IMAP/POP3 allowed rule creation that bypasses modern security controls
  • Mobile device sync or third-party mail apps created hidden forwarding rules

Step-by-Step Fix

  1. 1.Treat the mailbox as compromised immediately and preserve enough evidence for investigation before making broad changes, because you may need sign-in history, rule details, and audit records to understand how the forwarding was created. Document the current state of all forwarding settings.
  2. 2.Identify every forwarding path affecting the mailbox, including inbox rules (Outlook rules, webmail filters), mailbox-level forwarding (server-side forwarding), admin transport rules, delegated access permissions, and connected apps/OAuth grants, because removing only the visible rule can leave the attacker with another way to keep receiving mail.
  3. 3.Remove the unauthorized forwarding destination and disable any suspicious rules only after recording what was present (rule name, conditions, target address, creation date), because the exact rule details can help trace the compromise path and identify other affected mailboxes.
  4. 4.Reset the mailbox password and revoke active sessions, refresh tokens, app passwords, and remembered logins across all platforms (Microsoft 365, Google Workspace, or other providers), because forwarding attacks often survive a password change when sessions or tokens remain valid.
  5. 5.Review delegated mailbox permissions, shared mailbox access, OAuth or connected-app grants, and mobile device enrollments, because attackers often create persistence outside the main inbox rule screen through Full Access delegations or app permissions.
  6. 6.Check sign-in logs, mailbox audit logs, admin audit logs, and recent configuration changes to determine whether the rule was created by the user account, an administrator, or an approved application acting with stolen access. Look for the rule creation timestamp and correlate with login events.
  7. 7.Inspect related accounts and high-risk users for similar forwarding or inbox rules, because mailbox compromises commonly spread through reused credentials, phishing campaigns, or tenant-wide admin abuse. Check executives, finance staff, and IT administrators.
  8. 8.Re-enable normal mail flow only after confirming no unauthorized forwarding remains and that new messages stay inside approved mailboxes, because a clean login alone does not prove the leakage path is gone. Test by sending a sensitive-looking email and checking for leaks.
  9. 9.Finish by enforcing stronger protections such as MFA for all users, alerting on external forwarding rule creation, tighter review of delegated access and app consent, and enabling mailbox auditing, because mailbox rule abuse often returns when the original control weakness is left unchanged.

Verification

Confirm the fix is complete:

  1. 1.Check all forwarding settings (inbox rules, mailbox forwarding, transport rules) and confirm no suspicious entries exist
  2. 2.Review mailbox audit logs for any new forwarding rule creation after the fix
  3. 3.Test by sending a message and verifying it does not appear in any external mailbox
  4. 4.Confirm MFA is enabled and active on the recovered mailbox
  5. 5.Review connected apps and ensure no suspicious OAuth grants remain
  6. 6.Monitor sign-in logs for 24-48 hours to confirm no suspicious access continues

Prevention

To prevent mailbox forwarding attacks:

  • Enable MFA for all mailboxes to prevent credential-based compromise
  • Configure alerts for new forwarding rules or external forwarding destinations
  • Block automatic forwarding to external domains via transport rules where appropriate
  • Require admin approval for OAuth app grants that access mail
  • Enable mailbox auditing to track rule creation and modifications
  • Conduct regular reviews of mailbox forwarding settings for high-risk accounts
  • Train users to recognize phishing attempts that could lead to mailbox compromise
  • Implement conditional access policies that block legacy authentication protocols
  • [Fix Fix Admin Panel Blocked After Malware Cleanup Issue in Security Recovery](fix-admin-panel-blocked-after-malware-cleanup)
  • [Fix Fix Admin Password Reset Email Sent To Attacker Issue in Security Recovery](fix-admin-password-reset-email-sent-to-attacker)
  • [Fix Fix Adminer Or Phpmyadmin Exposed Publicly Issue in Security Recovery](fix-adminer-or-phpmyadmin-exposed-publicly)
  • [Fix Fix Apache Mod Security False Positive Admin Issue in Security Recovery](fix-apache-mod-security-false-positive-admin)
  • [Fix Apache mod_security False Positive Blocking Admin (security recovery variant 2)](fix-apache-mod-security-false-positive-blocking-admin)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "How to Fix a Mailbox Forwarding Rule Sending Copies to an Attacker", "description": "Troubleshoot a mailbox forwarding rule sending copies to an attacker by removing malicious rules, revoking sessions, and reviewing compromise paths.", "url": "https://www.fixwikihub.com/fix-mailbox-forwarding-rule-sending-copies-to-attacker", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2025-10-31T11:25:03.711Z", "dateModified": "2025-10-31T11:25:03.711Z" } </script>