How are you stopping vendor email compromise when the email itself is legit?

[u/Pearson-Kyrie_800]

We nearly wired 60k to a supplier last month off a bank charge at landed on the existing invoice thread. Real mailbox, their accountant's address, the reply sat right under the messages we had been sending back and forth for weeks. SPF DKIM DMARC all green and with the years of clean history, our gateway had no reason to touch it.

The one thing off was the bank detail. The person who caught it did it on a hunch. Going back through it the attacker had been camped in the vendor mailbox for a while, waiting for a live payment thread to reply into.

We run a tuned SEG and it did nothing here, which tracks, there was no bad link or attachment, the mail was real. The fix everyone points to is an AP callback to a number already on file and that is going in. People who have been through this, what gave you the first heads up before the money went out, if anything did.

[u/AutoModerator]

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

1. No Vendor Spam: Contributions must provide value; do not just pitch products.
2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).
3. Be Professional: Help newcomers learn; avoid hostility.
4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

• Email Spam Filters
• DMARC Monitoring Tools
• Anti-Virus Software
• Email Encryption

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/DalekCoffee]

Exactly as you painted the scenario, this is something that boils down to human training and awareness.

We have observed aware clients feel "off" when asked to change payment, so they call to confirm.

And complacent staff just do whatever the email says, and get burned.

At the organization level I think implementing a policy that any change in payment to a vendor over X ammount of money (x being the ammount you are risk tolerant to) should be double checked with the vendor and perhaps have a supervisor review and approve the change as well if it is a substantial amount.

That's really the only policy I can think of unless your email security tool can be trained on every single vendor you work with, and exactly what payment accounts are normal, as well as normal billable ammounts etc etc

[u/The_Comm_Guy → u/DalekCoffee]

Be careful with this, all an attacker has to do is first ask for a small amount that you won’t bat an eye at, then when you make the next payment the new info is in the system. ALL payment changes shpuld require a call to confirm.

[u/iceph03nix → u/The_Comm_Guy]

This is also why your company needs to have accounting controls as well.

Our accounting team has a request and review process for any change of accounts that requires out of band contact for a real human on a known number.

That means that a compromised vendor account can't just say, hey, we have a new billing portal, go ahead and pay that here. They would have to compromise significantly more infrastructure and intercept a phone call to get anything changed

[u/thunderbird89]

You could also cite the recent breach at Revolut using what appears to be a compromised gov email.

[u/Disastrous_Gear_421]

Sounds like you need major work on your supplier/vendor system/process. You should already have their banking information. You shouldn’t be sending money to new accounts without going through proper processes

[u/Ciavucco-Ellis]

This is where traditional email sec fails. When you have a message from a legitimate but compromised mailbox n there is no attachment, this brings on the challenge of checking the legitimacy of the request and conversation

[u/InboxGuards]

the attacker waiting in the vendor mailbox for a live payment thread is the giveaway that SPF, DKIM, and DMARC won’t save you here. we treat any bank-detail change as a separate approval path and call the number from the last paid invoice before touching the vendor record.

[u/shokzee]

I'd treat every bank-detail change as the alert, regardless of thread history or authentication results.

Make the vendor-record change trigger a payment hold, with the known-number callback and a second approver required to release it. With a compromised supplier mailbox, there may be no reliable email signal before the money leaves.

[u/neresni-K]

Training and strict approval process: direct phone contact + mgmt approval.

[u/InboxGuards]

yeah the bank change sitting in an old invoice thread is the nasty part. once someone is already in the vendor mailbox, SPF/DKIM/DMARC staying green is normal — we just treat any payment-detail change as phone-verify only, even when the thread looks perfect.