The entire attack was one sentence.
"Good Morning [name], Please i will like my net-pay check for this pay period to get process into my new financial institute, Kindly advise!."
No link. No attachment. No attacker-controlled domain anywhere in the message. The sender's display name matched the CEO and founder of the organization. The recipient was a senior HR business partner addressed by first name. The subject line read "Timely Update - 11/24." The message arrived, scored SCL=1, and landed in the inbox.
This is CEO fraud in its most stripped-down form: a single ask directed at the one person whose job function includes processing exactly this kind of request, with no technical payload for any control to catch.
The message came from a consumer RoadRunner webmail address, not a corporate domain. The display name was set to match the organization's CEO; the actual sending address had no connection to the company. That mismatch is the tell, but it requires comparing the display name against a known-good address list, not inspecting content.
The relay path ran from a Charter Communications outbound mail server through Mimecast's gateway and into Microsoft Exchange Online. SPF passed for the envelope domain. DKIM passed at the Mimecast gateway then failed at the Microsoft MX with a body-hash mismatch, consistent with the gateway modifying the message after signing. ARC preserved the upstream authentication result across the relay, so the final composite authentication passed.
The message scored SCL=1. It was not moved to junk. The Mimecast Impersonation Protect policy evaluated eight signals, including display-name matching and newly observed domain, and returned false on all of them. No policy fired.
The body is a plain-text payroll redirect request. There is no malicious link to detonate. There is no attachment to sandbox. The grammar is poor (lowercase "i," "get process," misplaced punctuation), which is sometimes a heuristic signal, but poor grammar alone does not produce a block in most enterprise configurations.
The request itself is the threat. Social engineering attacks of this type depend entirely on the recipient believing they are talking to the person named in the From display. A content scanner can tell you whether a link resolves to a known phishing kit. It cannot tell you whether the person whose name appears in the From header would actually ask for a payroll change from a consumer email address.
The message did reach a second mailbox at the organization beyond the original HR recipient. Mitigation data shows no action was recorded for either, which is consistent with a detection that fired automatically rather than an employee response that needed to be reversed.
This is the structural weakness that business email compromise exploits. A secure email gateway (SEG) is optimized for the threat model it was built against: malicious URLs, malicious attachments, known spam infrastructure. A first-time external sender on a consumer email account who sends one polite sentence asking HR to change a bank account number produces no signal in any of those channels.
The missing signals are relational. Has this sender ever contacted this mailbox before? Has this sender ever contacted anyone at this organization before? The SOC data shows sender_to_recipient: false, sender_to_organization: true: the specific address had reached the organization, but had no prior correspondence with the target mailbox. Does the claimed identity (a corporate CEO) match the known email infrastructure for that organization? A display name on a consumer webmail account is not a match.
This maps to two MITRE ATT&CK techniques: Impersonation for the display-name match used to borrow the executive's identity, and Phishing for Information for the social-engineering request directed at HR as the person who controls the payroll action.
The request asked the HR business partner to advise on rerouting a payroll direct deposit. The operationally correct response is out-of-band verification: call the executive directly using a number from the internal directory, not a number provided in the message. Open a ticket in the HR or payroll system that requires the requester to authenticate through their corporate identity. Require a signed written request through official channels for any payroll routing change. None of those controls require the email security stack to catch anything.
| Type | Indicator | Context |
|---|---|---|
| theguy[@]sw.rr.com | Attacker-controlled consumer RoadRunner address used to send impersonation message | |
| Domain | sw.rr.com | Consumer webmail subdomain; SPF passes for Charter outbound infrastructure |
| Behavior | Display name matched organization CEO; sending address was consumer webmail | Identity mismatch visible only by comparing display name to known-good address list |
| Behavior | Zero links, zero attachments | No technical payload; entire attack is a social-engineering request |
| Behavior | First-time sender to target mailbox, high sender-risk score | No prior correspondence; behavioral baseline violated |
| Auth | SPF pass (consumer relay), DKIM pass at gateway then fail at MX, ARC pass | ARC preserved upstream result; downstream DKIM failure from gateway message modification |
No content scanner fired. The attachment list was empty. The link list consisted only of the recipient's own Mimecast gateway banners, not attacker infrastructure. Detection came from behavioral context: a first-time external sender claiming a corporate executive identity, arriving from a consumer webmail address that bore no relationship to the organization, directing a specific financial request at the one function that processes exactly that kind of change.
The FBI's IC3 2024 report ranks BEC as the costliest category by total adjusted losses, with payroll-redirect fraud a documented and growing sub-category. Verizon's 2026 DBIR places the human element in 62 percent of breaches. CISA guidance on BEC reinforces the operational fix: any request to change banking or payroll information must be verified through a separate, known channel.
See Your Risk: Calculate how many threats your SEG is missing
A SEG blocks what it can inspect. IRONSCALES data shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes each month, and text-only BEC is the category most likely to be among those misses because there is nothing in the message body for inspection to find. The only defense against a sentence is knowing who is allowed to send it, and from which address.
The attacker knew a name, an email address for HR, and how to write a payroll-change request. That was enough to deliver it to the inbox.
| Attack | What happened |
|---|---|
| The Wire Transfer Confirmation That Had No Body, No Links, and Full Authentication | A wire-transfer confirmation BEC email used a text/calendar content type to evade body-based scanning. |
| The DKIM Key That Was Too Small to Verify: When Cryptographic Weakness Becomes a Detection Gap | A BEC attack impersonated a VIP executive using exact display-name matching, requesting sensitive financial documents. |
| SPF PermError Turned a Malformed Domain into an Invoice Fraud Launchpad | An attacker exploited a malformed SPF record that returned PermError instead of pass or fail, paired with a same-day-registered Reply-To domain. |
| The Work Order That Didn't Need a Link, an Attachment, or Even a Lie | A routine telecom work order arrived with perfect authentication, no links, no attachments, and one small request: reply all. |
| Three Real Companies, None of Them Matching: A Contract Lure That Scanned Clean | An authenticated email from a real industrial supplier's mailbox carried the branding of an unrelated construction consultancy and a 'sign the contract'... |