Between August 3 and 5, Microsoft detected a single campaign of more than a million emails aimed at enterprise users, with 87.7% of them delivered to recipients in the United States. The messages impersonated executives at the targeted companies themselves, asking accounts payable staff to process an Automated Clearing House (ACH) payment of nearly $50,000. Details in this article come from analysis published by Microsoft.

What makes this different from routine invoice fraud is the layering. Instead of one lure, the threat actor stacked executive impersonation, vendor branding, a fabricated invoice, and a supporting email conversation into one continuous narrative designed to reduce the recipient's skepticism.

The impersonated CEO appeared in the sender display name, the reply-to display name, and the email signature. The body was short and direct, an approval of the "invoice below," with an offer to send a PDF copy on request. Directly beneath that signature sat a fabricated "ServiceNow Platform Annual Subscription" invoice carrying ServiceNow branding, invoice number, issue and due dates, itemized line items, and bank transfer instructions pointing to accounts the attacker controlled.

Microsoft found no evidence that ServiceNow or any other referenced organization was compromised. The campaign ran entirely on attacker infrastructure, including the lookalike domain service-nowinc[.]com, registered on July 31, days before the emails started moving, and domainlify[.]net, used in the Reply-To header.

Microsoft observed indicators consistent with generative AI assisting the template build: extensive HTML comments, structured section labeling, and highly uniform construction across samples. Invoice identifiers and narrative structure stayed largely the same while organization-specific details changed per target, which points to template-based generation at scale.

If your finance team approves payments on the strength of an executive's name in a From field, this campaign is built for you. Targeted industries included IT services and business advisory alongside consumer goods, and payment destinations varied across multiple financial institutions between targets.

How the Impersonation and Payment Request Chain Works

The chain starts with open-source reconnaissance. Under T1591 (Gather Victim Organization Information) and T1598 (Phishing for Information), the actor collects publicly available detail on target organizations: who the executives are, who sits in accounts payable, which vendors the company works with, and how those business relationships are described publicly. That research is what lets the lure name the right executive and the right supplier for each recipient.

Infrastructure came next, and the timing is tight. The lookalike domain service-nowinc[.]com was registered on July 31, days before the sending activity began, and was used both for the spoofed ServiceNow President email address and as the contact address printed on the fabricated invoice. A second domain, domainlify[.]net, was registered the same day and used in the Reply-To field. Both map to T1583.001 (Acquire Infrastructure: Domains).

The separation matters. The impersonated executive identity lives in the display name, the signature block and the Reply-To display name, while the actual envelope sender is a working account on third-party email infrastructure (T1583, T1585.002, T1566.003 Spearphishing via Service). Sender addresses in the IOC set include notifications@uinsure[.]co[.]uk, info@tivityhealth[.]com, no-reply@lumalisboa[.]com and info@nuf[.]co[.]jp, none of which match the executive being impersonated.

That design sidesteps domain authentication. SPF, DKIM and DMARC validate the sending domain, and the sending domain here is a real, authenticated third-party service, so the messages pass alignment checks while the fraud sits entirely in human-readable fields. For your finance team, the practical consequence is that the message arrives without an authentication failure banner attached to it.

There is no malicious attachment and no credential-harvesting link. The invoice is rendered inline as HTML, complete with invoice number, issue and due dates, currency, amount due, payment method and itemized line items, with the "BILLED TO" block populated with the recipient company name and executive name. Detonation sandboxes and URL reputation checks have nothing to detonate or resolve.

Microsoft attributes the template construction to AI assistance based on extensive HTML comments, verbose capitalized section headers, structured section labeling, em dash usage, =========== banner separators, and near-identical template structure across samples. Invoice identifiers and narrative structure stayed largely consistent while organization-specific fields changed per target, which is what template-driven generation at volume looks like.

Several forgery tells survived generation. The quoted "forwarded" thread between the two spoofed executives lacks the date headers that genuine forwarded mail carries, the quoted blocks are left aligned instead of tabbed or visually grouped, and phrasing like "no need to copy me" appears in the thread. Subject lines use financial lure keywords including "due bill" and the misspelled "ACH Parment." There is also a logic break: the CEO in one thread asks that the invoice be sent to recipients without copying him, then states in the most recent message that the invoice is approved and is being sent from his own address.

Payment execution is the objective (T1657 Financial Theft). The invoice instructs a bank transfer, and Microsoft observed multiple financial institutions across samples, meaning destination accounts vary between targets. T1036 (Masquerading) and T1656 (Impersonation) cover the evasion throughout. An ACH transfer initiated by an authorized employee looks like an ordinary approved payment in accounting records.

Financial Loss, Recovery Limits and Liability Exposure

The loss starts as an ordinary outbound payment. Your accounts payable clerk approves what looks like a vendor subscription invoice, the ACH transfer settles into an account the attacker controls, and nothing in your finance system flags an exception because every step followed your normal process. MITRE tracks this outcome as T1657 (Financial Theft), and it is the only objective in this campaign. There is no malware to remove and no compromised mailbox to reset.

Recovery depends almost entirely on how fast your bank and the receiving bank cooperate, and that window is short. Microsoft observed multiple financial institutions used across samples, which means payment destinations varied between targets. For you, that fragments the recall process: your bank is not chasing one known mule account but a destination unique to the message your staff received, and the funds are typically moved onward before a fraud report reaches the receiving institution.

Insurance rarely closes the gap cleanly. Crime and cyber policies often treat a voluntary transfer induced by deception differently from a system intrusion, and social engineering fraud is commonly carved out into a separate endorsement with its own sub-limit. If your policy contains one, check whether it requires documented callback verification before payment, because insurers frequently condition payout on that control being followed. A claim denied on that basis leaves the full amount on your own balance sheet.

Then come the costs that never appear in the fraudulent invoice. You will likely pay for forensic review of the mail flow to confirm no mailbox was actually accessed, outside counsel to manage the bank dispute and the insurance claim, and internal finance hours reconstructing the approval trail. If the emails also carried payroll records, employee names, or personal data in the fabricated "BILLED TO" fields, your reporting obligations may be triggered by the exposure itself, regardless of whether money moved.

Supplier relationships absorb damage you did not cause. Microsoft found no evidence that ServiceNow or any other referenced organization was compromised or involved, yet the vendor's branding and a fabricated President's signature were used to move your money. Expect awkward conversations with the real supplier, requests to re-verify banking details across your entire vendor master file, and slower payment cycles while finance treats legitimate invoices with new suspicion. Campaigns of this kind concentrated on IT services, business advisory, and consumer goods firms, sectors where high-value vendor subscriptions are routine enough not to raise questions.

Your auditors will look at one thing: whether a payment authorisation control can be overridden by apparent seniority. If the answer is that a CEO display name in a sender field was sufficient to release funds, that is a control design finding, not an employee error. It reads badly in a management letter and worse in a claim file.

Boards and finance leadership are increasingly asked to evidence the opposite, that approval thresholds hold regardless of who appears to be asking, including a familiar voice on a call or a forwarded thread bearing an executive signature block. That evidence is documentary. It means being able to show the authorisation matrix, the verification requirement attached to each payment tier, and the exception log proving the requirement was applied. Firms that cannot produce it carry both the loss and the governance finding.

Detecting AI-Assisted Impersonation Attempts

Start with your mail logs. Hunt for messages where the sender display name matches one of your executives but the envelope sender fails SPF, DKIM, or DMARC, and treat any display-name match with a mismatched sending address as a candidate for review. In this campaign the reply-to path used a separate newly registered domain, domainlify[.]net, so a rule that compares the From header, the Reply-To header, and the authenticated sender will catch messages that individually look clean.

Subject-line keywords are a cheap second filter. The samples used financial-lure phrasing including "due bill" and a misspelled "ACH Parment," and the misspelling matters because scam templates reuse it across recipients. Pair that with alerts for mail that arrives through third-party sending services under addresses unrelated to your suppliers, such as notifications@uinsure[.]co[.]uk or info@lifeones[.]com, both listed by Microsoft as senders in this activity.

Quoted threads are where the fabrication shows. Genuine forwarded mail carries date headers in each From block and indents or visually groups prior replies, while these fabricated threads left the earlier messages left-aligned and stripped the date headers entirely. Phrases that discourage further verification, such as "no need to copy me," belong on your keyword list for the same reason.

Inspect the HTML source of suspicious messages rather than only the rendered view. The template artifacts Microsoft flagged as consistent with AI-assisted development include extensive comments describing each section, verbose capitalized section headers, banner rows built from equals signs, and heavy commenting on style elements. Invoice identifiers stayed largely constant across samples while company and executive names changed, which means one confirmed sample gives your team a reusable fingerprint for retroactive hunting across every mailbox.

Watch your identity and domain telemetry alongside the mail stream:

• Newly registered domains resembling your company name or your top suppliers, checked weekly against registration feeds
• New inbox rules and mail-forwarding entries in Microsoft 365 or Google Workspace, especially rules that move finance-related mail to obscure folders
• Impossible-travel sign-ins and repeated MFA prompts to a single finance user, the pattern of an attacker pushing approvals until one is accepted
• External-sender banners that have been suppressed by a transport rule, or that users routinely click past
• Vendor master-data change logs showing bank-detail edits, with every change reviewed against a second source

In environments Capstone manages, Adlumin monitors authentication behavior for those sign-in and mailbox-rule anomalies, which gives you a second signal when the email itself slips past filtering.

Your finance staff are the last detection layer, so tell them what to listen for. Refusal to move the conversation to a known channel, pressure to skip the normal approval route, a request to keep the payment quiet, and any instruction to send documents onward without copying the sender all warrant a stop. The decisive test is a callback to a number already held in your vendor or HR records, never a number supplied in the message, because it forces the conversation onto infrastructure the attacker does not control.

Do not build that control around deepfake detection tooling. Voice and video analysis is inconsistent on short, compressed phone audio, and it gives you a confidence score after the fact instead of a verified identity. Train the callback habit and log every exception to it.

Payment Controls and Verification Steps to Implement

The single most effective control against this campaign is a callback rule that does not depend on email at all. Any request to change vendor bank details, and any payment above a threshold you set (many finance teams use the low five figures, which would have caught the ACH request in these lures), gets verified by phone to a number already held in your vendor master file. Not a number in the invoice, not a number in the signature block.

Give your accounts payable team a written standing rule this week: no executive will approve a payment on a single call, a single email, or a video request. Pair that with an agreed challenge phrase for any executive-initiated payment instruction. Your CFO owns the rule, your AP supervisor owns enforcement, and the rule should be short enough to pin above a desk.

On the mail side, three Microsoft controls apply directly to what Microsoft Threat Intelligence documented here. Your messaging administrator should confirm all three are on:

• Zero-hour auto purge (ZAP) in Office 365, which pulls phishing and spam messages out of mailboxes retroactively once new intelligence lands. In a campaign that ran across three days, retroactive removal is what reaches the messages already sitting in an AP inbox.
• Automatic attack disruption in Microsoft Defender XDR, which contains activity in progress and buys your team time to work the incident.
• Enhanced filtering for connectors in Exchange Online, which matters specifically because these messages arrived through third-party email delivery services. Without it, filtering sees the relay rather than the original source.

Also enable mailbox rule auditing and review it. Auto-forwarding and auto-delete rules are how a fraud attempt stays invisible while the conversation continues.

Over the next 30 to 90 days, tighten the process controls. Enforce dual authorisation on vendor master data so the person who edits bank details is never the person who approves the payment, which removes the single-approver path this campaign depends on. Move your DMARC policy from monitoring to reject after you have confirmed SPF and DKIM alignment for every legitimate sending service, including marketing and billing platforms. Deploy phishing-resistant MFA on finance and executive mailboxes first. Register the obvious lookalike variants of your own domain and monitor new registrations that resemble your name or your top suppliers, since the infrastructure in this campaign was stood up days before sending.

Then run a simulation that includes a cloned-voice call to an AP clerk. The written callback rule only works if someone has practiced saying no to a voice that sounds like the boss.

Longer term, the work moves outside your walls. Write payment-change protocols into supplier contracts so both sides agree in advance how bank detail changes are confirmed, and name the contacts on each side. Review how much executive audio and video your organisation publishes and trim what is not commercially necessary. Have your broker confirm in writing whether your policy covers social engineering fraud where an employee authorises the transfer voluntarily, because that wording differs from computer fraud cover.

Finally, rehearse a funds-recall playbook with your bank. Document the named contact, the recall request process, the reporting route to law enforcement, and who in your organisation is authorised to start it at any hour. Your treasurer owns that document, and it should be tested before you need it.

Priorities for Finance and Security Teams

Every authority signal in these messages was content the sender chose: the display name, the signature block, the invoice layout, the quoted reply thread. None of it required access to your network or your executive's mailbox. That is the shift worth carrying out of this campaign, because your usual definition of an incident, something compromised that needs cleaning up, does not describe what happened here.

Treat this as a payments integrity problem that finance and security own together. Your security team sees the sender infrastructure and the header inconsistencies. Your finance team sees whether the vendor, the subscription, and the amount make sense against what the company actually bought. Neither view alone catches a fabricated vendor relationship that looks internally approved.

The single most important action is mandatory out-of-band callback verification on every bank-detail change and every high-value payment, applied without exception for senior staff. Senior exemptions are the specific thing this lure depends on, because the message arrives already framed as approved from above.

That creates a cultural problem you have to solve deliberately. A clerk who follows the rule is, in effect, questioning the CEO, and the rule only works if it is issued by someone senior enough that following it can never count against the person who does. Write it down, name the executive who owns it, and log each verification so the check can be reviewed afterward.

Authority can be convincingly faked in text, on a call, and on video. Verification has to rest on a process and a channel the sender does not control.