The message looked like it came from a colleague. The display name matched a real employee at the organization. The greeting used the payroll contact's first name. The tone was polite, professional, and consistent with the kind of brief, task-oriented message that moves between colleagues a dozen times a day.
The sending address was churchoffice11011[at]gmail[.]com.
There was no attachment to scan. No link to sandbox. No code to execute. The attack was entirely contained in a request: please update my direct-deposit banking information to a new account.
Business email compromise attacks that rely on display name spoofing are built on a fundamental asymmetry in how most people read email. The display name is visually prominent. The underlying address is secondary, often hidden in condensed mobile views, and requires an intentional extra step to inspect.
The attacker's email carried a display name matching a real internal employee at a financial institution. The recipient, identified by first name in the greeting, was the payroll contact. The sender's actual address was a free consumer Gmail account with a church-themed local part and a five-digit suffix, bearing no relationship to the impersonated employee or the organization.
Gmail's sending infrastructure authorized the outbound message correctly. SPF passed. DKIM passed. DMARC passed with p=none policy. From the authentication perspective, this was a legitimately sent Gmail message. DMARC does not evaluate whether the display name matches the authenticated domain; it evaluates whether the authenticated domain is consistent with the From header domain. For this message, it was.
The impersonation was entirely cosmetic, and cosmetic impersonation is invisible to every authentication protocol.
The request was direct. The message asked the payroll contact to update the employee's direct-deposit account information. No urgency marker. No deadline. No threat. Just a normal-sounding request from what appeared to be a trusted colleague, addressed personally.
See Your Risk: Calculate how many threats your SEG is missing
This is the structural pattern of payroll redirect BEC: the attacker uses the social weight of an impersonated colleague identity and the routine nature of a banking update request to insert a fraudulent account into payroll processing. If the request is processed, funds are redirected to an attacker-controlled account at the next payroll cycle. No malware executes. No credentials are harvested. The financial loss is the direct result of a human action taken in response to a convincing but fraudulent request.
The subject line was "Request to Update Bank Information," a phrase that reads as a standard HR or employee-services communication. The message was signed with the impersonated employee's full name. A payroll processor who receives this message from what appears to be a known employee, addressed by their own name, using standard HR terminology, faces a plausible-looking request that maps directly to their normal workflow.
IRONSCALES Adaptive AI flagged this message at 75% confidence and assigned it dual labels: BEC and Vendor Email Compromise. The labels reflect the system's characterization of the attack pattern, not the sending infrastructure. There was no malicious URL to detect, no attachment hash to match, and no payload to sandbox.
The detection rested on the gap between the claimed identity (a named internal employee) and the actual sending address (an unrelated consumer Gmail account). This mismatch is a behavioral signal: a legitimate employee at a financial institution sending a banking update request does not do so from a personal Gmail account. The compound signal of display name impersonation, a first-contact consumer address, a sensitive HR-process topic, and a personal greeting to a specific named recipient formed a risk cluster consistent with BEC campaigns targeting credential harvesting and financial fraud.
The Adaptive AI's flagging did not require any individual element to be a known bad indicator. The combination of elements that do not cohere as a plausible legitimate communication was sufficient.
The structural fact of this attack is that it bypassed every technical control precisely because it carried no technical payload. There is no category of gateway defense that catches a plain-text email with clean authentication and a request phrased in normal HR language, because that description also fits thousands of legitimate internal emails every day.
Require out-of-band verification for all banking changes. Any request to update direct-deposit, ACH, or wire information, regardless of the apparent sender, should be verified by calling the employee at a known, pre-existing number before being processed. A policy requiring this step makes the entire display-name impersonation technique ineffective.
Train payroll and finance teams on free-domain BEC. Consumer addresses (Gmail, Yahoo, Outlook.com) appearing in banking-change requests from apparent internal senders are a reliable indicator. Finance and HR teams should be trained to inspect the actual From address, not just the display name.
Treat first-contact addresses as high-risk for sensitive requests. If the underlying sending address has never previously sent to the organization, a banking-change request from that address should be escalated for review regardless of how legitimate the display name appears.
The Verizon DBIR 2026 consistently identifies BEC as the highest-cost category of social engineering fraud. MITRE ATT&CK T1534 covers internal spearphishing, where the impersonation of an insider bypasses trust assumptions. CISA guidance on BEC emphasizes out-of-band verification as the primary control. The Microsoft Digital Defense Report 2024 reports that BEC attacks are increasingly bypassing email authentication by operating entirely at the display name and social engineering layer, where technical controls have no purchase.
The message had no payload. It did not need one. It only needed a payroll team that processed the request before anyone checked the From address.
---
| Type | Indicator | Context |
|---|---|---|
churchoffice11011[at]gmail[.]com | Attacker-controlled Gmail address; display name fabricated to impersonate a named internal employee |
| Attack | What happened |
|---|---|
| Every Authentication Check Passed. There Was Nothing to Scan. The Attack Was the Reply. | A fully authenticated email with no links, no attachments, and no malicious content asked recipients to reply all. |
| The Reply-To Was One Letter Off: How a Typosquat Domain Turned a Gmail BEC Into a Payment Diversion | A Gmail-authenticated BEC used a typosquat Reply-To domain and a hidden HTML mailto mismatch to impersonate a steel distributor's credit manager. |
| Three Domains, One CEO: How a Payroll Group BEC Used Mailjet to Bypass Every Filter | A CEO impersonation attack targeted a payroll distribution group using Mailjet infrastructure, three separate domains for sending, reply capture. |
| The LinkedIn Invoice That Passed Every Email Check | A recently registered LinkedIn lookalike domain passed SPF, DKIM, and DMARC, then sent a one-line invoice probe to an accounts payable mailbox. |
| Past Due Invoice, Future Wire Fraud: How a BEC Campaign Passed Every Authentication Check | A BEC invoice diversion attack impersonated a known vendor contact through SendGrid, passed SPF/DKIM/DMARC. |