An accounts payable clerk gets an email from the CEO. It approves an invoice below and asks them to process the payment. Attached in the thread is a detailed vendor invoice, and below that, a short forwarded conversation between the CEO and the vendor discussing the purchase. Everything lines up. The clerk pays.
Microsoft's threat researchers just documented a campaign built to produce exactly that outcome. Between August 3 and 5, they detected more than a million emails impersonating executives to push fraudulent payments, roughly 88% of them aimed at US organizations. The attacker impersonated CEOs, CFOs, and presidents of the target companies, then asked their finance teams to send an Automated Clearing House (ACH) payment of nearly $50,000 to attacker-controlled bank accounts.
What makes this one worth a close look is not a clever piece of malware. There is no malware. There is no link to click and no file to open. The entire attack is a convincing story delivered by email, and it was assembled well enough, with enough help from AI, that the usual advice to "look for something suspicious" no longer has much to work with.
Key takeaways
Microsoft detected an AI-assisted business email compromise campaign of more than 1 million emails (August 3 to 5, 87.7% targeting US organizations) impersonating executives to trick finance teams into wiring about $50,000 via ACH (source).
The attack layered four deceptions into one email: a spoofed executive as the sender, a fabricated vendor invoice (impersonating ServiceNow), a fake "forwarded" thread between two spoofed executives, and lookalike domains.
There was no malicious link, attachment payload, or login page. The requested action was simply to wire money, which means most link-and-file defenses have nothing to catch.
The deception's anchor is the sender: the executive is impersonated in the display name, the reply-to, and the signature, while the actual domain is attacker-controlled or a lookalike.
That sender mismatch is the one thing the attacker cannot make genuine, and it is exactly what a browser-level check on webmail can surface before finance acts.
How the attack builds a story that survives scrutiny
Traditional invoice scams lean on a single lure: one fake invoice, one urgent request. This campaign stacked several layers so that each one props up the next.
It starts with the sender. The executive is impersonated in three places at once: the sender display name, the reply-to display name, and the email signature, which includes the executive's name and email address. To a finance employee scanning quickly, every visible cue says this came from leadership.
Below the message sits a fabricated invoice. Microsoft observed a detailed "ServiceNow Platform, Annual Subscription" invoice, complete with ServiceNow branding, an invoice number, issue and due dates, itemized line items, and payment instructions pointing to a bank account the attacker controls. Parts of it are personalized: the "billed to" section carries the recipient's real company and executive name. Microsoft was clear that ServiceNow was not breached or involved; the invoice is a pure impersonation.
Then, below the invoice, the attacker pastes a short "forwarded" thread showing the company's executive and the vendor's president discussing the purchase and the invoice. It is there to answer the question a careful reader would ask: has this actually been agreed? The fake conversation says yes.
The whole package is designed to reduce skepticism by corroborating itself. And Microsoft found signs the templates were built with generative AI, including uniform structure and telltale artifacts in the underlying code, which is what let the attacker produce this at the scale of a million tailored messages.
Why the usual defenses have little to grab
Two things make this hard for conventional tools.
First, there is no technical payload. Most email security and endpoint tools are tuned to catch a malicious link, a weaponized attachment, or a credential-harvesting page. This email has none of those. The "payload" is a sentence asking someone to make a bank transfer. There is nothing to detonate in a sandbox and no bad URL to block.
Second, the content is flawless. The invoice is well designed, the branding is right, and the language is clean. As we wrote in why modern phishing no longer looks like phishing, AI has erased the spelling mistakes and awkward phrasing people were trained to notice. Asking a busy finance employee to sense that a professional, self-corroborating invoice is fake is not a fair test.
There are tells for a trained defender, and Microsoft lists them: the forwarded thread lacks the headers a real forward would carry, the previous messages are left-aligned rather than visually grouped, and the display name does not match the actual sender address. But most of these require someone to stop, inspect headers, and reason about email structure in the middle of a normal workday. That is not where the average approval decision gets made.
The one thing the attacker cannot fake: being your executive
Strip away the invoice and the fabricated thread and look at what the attack actually depends on. It needs the finance employee to believe the request came from their own executive. Everything else is set dressing that only matters if that first belief holds.
And that belief rests on something the attacker cannot genuinely reproduce. They can copy your CEO's name into a display field, put it in a signature, and set a matching reply-to name. What they cannot do is send from your executive's real address. So the message that says "from the CEO" is actually sent from an attacker-controlled account or a lookalike domain, with a reply-to on a freshly registered domain. Microsoft's indicators bear this out: the reply-to in this campaign used a newly registered domain, and the vendor lookalike (service-nowinc[.]com) was registered days before the campaign began.
That gap, between the identity the email claims and the domain it actually comes from, is the durable signal. It is present in every message, it does not depend on the recipient noticing anything, and it is exactly what the layered story is designed to distract from.
Where Haven fits
This is where Haven for Business does something most tools do not, because it works in the browser rather than only at the mail gateway.
When your team reads mail in a browser (webmail such as Outlook on the web or Gmail), Haven recognizes your teammates, including the extra addresses a team owner registers for them through business email aliases. Against that known picture, Haven flags the mismatch at the heart of this attack: an email that presents itself as coming from one of your executives while the actual sending or reply-to domain does not match any address Haven knows for that person. The forwarded thread and the polished invoice do not change that verdict, because Haven is checking who the message is really from, not how convincing the story below it looks.
The business email alias feature is what makes this trustworthy rather than noisy. The usual reason people ignore "this may be impersonation" warnings is false alarms, a real colleague emailing from a legitimate second domain. Because a team owner can register those real addresses, Haven can tell a genuine second domain from an impostor one, so a flag actually means something. For finance and accounts payable teams, that is the difference between a warning worth stopping for and one worth dismissing.
To be precise about scope, so this is not oversold: Haven is a browser extension, and this protection applies when mail is read in webmail in the browser, not in the native Outlook desktop application or a phone mail app. Haven does not sit at your mail server and it does not stop the ACH transfer itself; its role is upstream, at the moment of reading, flagging that the sender is not who it claims before anyone acts on the request. Its strongest signal here is the impersonated executive, your own registered teammate, rather than the impersonated outside vendor in the invoice body. That is why browser-level sender recognition works best paired with the basics finance teams should keep: a strict out-of-band verification rule for any payment or bank-detail change, correctly configured SPF, DKIM, and DMARC, and email gateway filtering.
For teams, Haven for Business extends this check across every employee's browser, which matters most for the people this campaign targets: finance and accounts payable, where a single trusted-looking request can move real money. We have written before about how invoice fraud works and how to protect your business and about the business guide to spear phishing and BEC; this campaign is what those attacks look like once AI makes them fast, clean, and convincing at scale.
The uncomfortable takeaway is that you can no longer verify a payment request by how legitimate it reads, because the reading is exactly what the attacker has learned to perfect. The reliable question is not "does this look real," it is "is this actually from who it says," and that is a question best answered before the money moves.
About Haven
Haven is a browser extension that helps people make safer trust decisions online, before a scam can cost anything. It works at the moment someone is about to click a link or enter a password, flagging fake and impersonated login pages, suspicious links, and look-alike sites, and pausing risky downloads. Rather than only checking a page against a list of known-bad sites, Haven analyzes the actual page in front of the user, so it can catch brand-new and convincing fakes that other tools miss.
Haven is free for individual use. For teams, Haven for Business extends this browser-level protection across every employee. Haven is operated by MirrorTab, Inc.