Two users in our organization have been receiving more than 100 phishing, newsletter, and spam messages per day, often in different languages. The attack started about three weeks ago and is still ongoing. Sender domains and IP addresses change constantly, so blocking individual sources has not been effective. I'm considering applying an aggressive, user-specific filtering policy in our email security system, but I'd like to know what has worked for others in the long term. Are there better ways to reduce the flood or determine whether the messages are hiding another compromise?
4 Answers
A targeted mail-flow policy can reduce the visible volume while the campaign is active. Detection for registration-bomb patterns, multilingual unsubscribe text, suspicious headers, and bursts from newly created or low-reputation senders may catch more than blocking individual domains. If your gateway supports it, apply the stricter policy only to the affected users and use quarantine or a separate holding mailbox so legitimate messages can still be recovered. Contact allow-listing can help, but it needs to be used carefully so important first-time senders are not silently lost.
Changing the users’ primary email addresses can be a last-resort containment step, but it is disruptive and may not stop every source because the registrations have already been submitted. Another temporary option is to route the original address into a controlled mailbox and filter it there while giving the users a clean address. Make sure important correspondents and automated systems are updated before doing this.
Treat the mail flood as possible cover for a more serious attack, not just an inbox nuisance. Search the affected mailboxes for legitimate purchase receipts, password resets, account changes, invoices, wire requests, and similar notifications during the entire attack window. Review sign-in logs, financial activity, payment details, and any privileged actions tied to those accounts. Reset passwords and verify MFA as a precaution. These campaigns are also commonly followed by fake IT-support calls, so warn the users not to allow remote access or follow unsolicited troubleshooting instructions.
In our case, the attackers used a fake support call to try to get the user to hand over access through a collaboration app. The filtering helped, but user awareness and blocking unexpected external contacts were just as important.
If the attack is coming through many legitimate senders, reputation-based blocking alone probably won’t solve it. Ask your mail-security provider whether it has a dedicated email-bombing or registration-flood feature, and consider narrowly scoped geographic or sender policies if the users do not need messages from those regions. Keep an exception list for business-critical external services so the defensive policy does not block required mail.
This worked well for us through our email gateway: the affected users saw only a handful of messages instead of hundreds. We kept the stricter policy temporary and moved users out of it once the flood subsided.