BEC Payroll Diversion via Display-Name Impersonation: No Links, No Attachments, High Confidence

# BEC Payroll Diversion via Display-Name Impersonation: No Links, No Attachments, High Confidence

The message had no links, no attachments, and no malware. It was three sentences. The attacker impersonated a senior sales executive at a technology company, directed the message to someone in the finance or payroll function, and asked a single question: can I still change my direct-deposit details before the next payroll run? Everything this attack needed to succeed was social, not technical.

The Sending Infrastructure: External Domain, Self-Published, No DKIM

The From header displayed the name of a senior executive at the target organization. The actual sending address was admin[@]rmbumi[.]com, a domain with no organizational relationship to the recipient company. rmbumi[.]com resolves to 110[.]4[.]45[.]212 and is hosted on mschosting infrastructure. The domain's SPF record explicitly authorized that IP, so SPF passed at the Microsoft inbound layer.

That is where the authentication story ends. The message carried no DKIM signature despite rmbumi[.]com publishing a DKIM key in DNS. The DMARC record specifies p=quarantine, but the receiver recorded dmarc=permerror, an error indicating a parsing or processing failure during DMARC evaluation. The result is that neither DKIM nor DMARC provided any usable cryptographic assertion for this message.

Note what this means in terms of impersonation mechanics: rmbumi[.]com is not a lookalike or typosquat of the target organization's domain. The attacker did not attempt domain-level deception. The entire impersonation rests on the display name in the From header, a field that email clients show prominently and that no authentication protocol validates. A recipient who reads "Senior VP, Sales" and a familiar name in their inbox may never think to expand the header to check the actual address.

Why Signature-Based Controls Missed It

Business email compromise attacks built around pure social engineering are structurally invisible to tools that rely on scanning content. There is no URL to submit to a sandbox, no attachment hash to compare against threat feeds, no payload to detonate. The composite authentication check at the inbound gateway recorded compauth=pass based on SPF passing for rmbumi[.]com, which is technically accurate: the message was sent from the domain it claims in the envelope. That accuracy is the problem. SPF passing for an external domain that happens to match nobody's internal directory is not a clearance.

The message was scored as spam (SCL=5) by the inbound mail filter, but spam scoring and BEC detection are different problems. A spam score addresses bulk-mail characteristics. This message was targeted, low-volume, and plain-text, none of the properties that drive a high spam score.

See Your Risk: Calculate how many threats your SEG is missing

What the Message Said and Why It Worked

The body opened with a first-name greeting, signed with a full name and senior title, and asked to confirm a direct-deposit change "before the upcoming payroll run." Each of those elements is doing work. The first-name greeting signals familiarity. The title asserts authority. The phrase "upcoming payroll run" introduces a time constraint without stating an explicit deadline, which is subtler than "urgent" but functionally the same.

The message lacked any corroborating detail: no internal ticket number, no HR system reference, no corporate signature block with a verified phone number. The sign-off showed an inconsistent capitalization in the title, a small tell that is easy to miss when you are already primed to expect an internal message from a senior colleague.

How Behavioral Analysis Caught It

Our Adaptive AI scored the message at approximately 82% confidence for BEC/payroll diversion based on behavioral and contextual signals: an external sender not matching the claimed organizational identity, a high-risk financial action request (direct-deposit change), authority-framed social engineering, and timing pressure. No link sandbox result and no attachment scan contributed to the verdict. The detection was based entirely on understanding what the message was asking and who appeared to be asking it.

Defender Takeaway: Train for the From Header, Not Just the Subject

Impersonation attacks that operate entirely through display-name manipulation require no lookalike domain, no malware, and no compromised account. The single most effective countermeasure is training recipients to verify the actual sending address when any email requests a financial action, regardless of how familiar the display name looks. On the process side: payroll or direct-deposit changes should require out-of-band verification through a known-good channel, and that policy should be explicit enough that no email alone, regardless of apparent sender, can trigger the change.

Indicators of Compromise