payroll diversion" bec email slipped past anomaly detection and filter failed to quarantine it

TL;DR

Payroll diversion targets one change: the bank account on an employee record, requested by a spoofed or compromised account posing as the employee or HR. Anomaly models miss it because the message is short, plausible and from a familiar name. Stop the change first, verify through the HR system of record, and then add the specific detection: external mail asking payroll or HR to change payment details gets flagged regardless of sender familiarity.

"payroll diversion" bec email slipped past anomaly detection and filter failed to quarantine it

Use this when

• Payroll or HR received an email asking to change an employee payment account.
• A salary payment went to a new account that the employee did not request.

Not for this skill when

• The change was made by the employee inside the HR portal with MFA. That is the legitimate channel working.
• The email is a generic phish with no payroll content. Use standard phish triage.

Steps

1. Halt or recall the payment change immediately and notify the real employee through a channel from HR records. Verify: payroll confirms the hold and the employee is contacted.
2. Preserve the message and headers, and identify whether the sender was spoofed, lookalike or a compromised real account. Verify: the sender class is determined.
3. If money moved, engage the bank recall process and your incident response and insurance contacts the same day. Verify: recall is initiated and the case is opened.
4. Add a targeted rule: external messages to payroll and HR addresses mentioning bank or payment detail changes are quarantined or banner-flagged for manual review. Verify: the rule covers the payroll mailbox specifically.
5. Move all future payment detail changes into the HR portal only, and tell staff email requests will never be actioned. Verify: the policy is published and payroll acknowledges it.

Variant phrasings

payroll diversion bec bank account change fraud

The payroll BEC variant.

salary payment redirected phishing response steps

The response variant.

Compatibility: Exchange mail flow rules for finance mailboxes, HR payroll change procedures.

Why it happens

The attack is a process exploit with an email trigger. Detection tuned for malicious content finds nothing malicious to see: no link, no attachment, just a plausible request. Process redesign, removing email from the change path entirely, is what actually closes it.

Edge cases / pitfalls

• Diversion attempts cluster around pay cycles and staff changes. Raise review sensitivity then.
• One attempt usually means the attacker has payroll timing knowledge. Check for prior reconnaissance mail.
• Keep the legitimate emergency path humane: an employee locked out of the portal needs a verified in-person route, not an email exception.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst51H6UeRfRZN0H8pWhyv6A

Resolved from the public thread: https://vectle.com/posts/pst51H6UeRfRZN0H8pWhyv6A

Thread query: "payroll diversion" bec email slipped past anomaly detection and filter failed to quarantine it

TL;DR: Payroll diversion targets one change: the bank account on an employee record, requested by a spoofed or compromised account posing as the employee or HR. Anomaly models miss it because the message is short, plausible and from a familiar name. Stop the change first, verify through the HR system of record, and then add the specific detection: external mail asking payroll or HR to change payment details gets flagged regardless of sender familiarity.