Invoice Fraud: When the Vendor Email Is Real

On 24 August 2026 we received an email from a supplier's accounting department. It announced a payment and attached a statement. It was malicious. Every automated check that is supposed to catch this passed it. This page is the full teardown: what the email was, what the attachment did, what the attacker wanted, and the four checks that actually work. We have removed the supplier's name. They are a victim here, and we told them before we told anyone else.

The Email

Five sentences, no attachment name in the body, no amount, no invoice number, and a reference code in the subject line that looks official and means nothing.

Two things in that text are wrong, and both are the kind of wrong that a spam filter cannot see.

The sender is French. The message announces an "ACH" payment. ACH is the United States bank clearing network. A French supplier sends a SEPA transfer, and their accounting software says "virement". The word is evidence that whoever typed this was not the person whose name is on the mailbox.

The grammar is also broken. "The applicable statement have also been included" is not a sentence a native speaker writes, and it is not a sentence an accounting system generates either.

Why Every Automated Check Passed It

Standard advice for spotting a fake invoice is to check the sender's address for a lookalike domain. That advice did nothing here. The address was correct, because the email came from the real mailbox.

The three email authentication standards agreed:

SPF, DKIM and DMARC all answer one question: did this message really come from the domain it claims? Here the honest answer was yes. They are not designed to answer the question that mattered, which is whether the person at the keyboard was supposed to be there.

The last line is the one that settles it. The message left through Microsoft's France South relay, and the internal hop records with mapi id. MAPI is the protocol an Outlook client uses when a signed-in user presses send. Nobody forged this. Somebody logged in to the supplier's accounting mailbox and sent it.

One more detail told us how big the send was. The "To" field was empty. We were blind-copied. That is what a bulk send to a stolen address book looks like.

What Was Actually in the PDF

The attachment was named after the company and weighed 22,912 bytes. We pulled it out of the mailbox without opening it and inflated every compressed stream inside it.

It contained no JavaScript. No /OpenAction, no /Launch, no embedded file, no auto-run behaviour of any kind. Modern readers block most of that anyway, and this attacker did not bother trying.

What it contained was one link annotation, pointing at an Amazon S3 bucket named after the supplier:

The PDF was a door, not a weapon. Attackers put the link inside a document because a link in the body of an email gets scanned and a link buried in an attachment often does not.

The choice of Amazon S3 is deliberate for the same reason. Mail gateways and web filters score a URL partly on the reputation of its domain, and amazonaws.com has about as much reputation as a domain can have. A bucket costs nothing, takes a minute to create, and is disposable.

Reading the Takedown

By the time we checked, the link was dead. The exact error matters:

A bucket with the wrong permissions returns AccessDenied. AllAccessDisabled is different. It is what Amazon returns after its abuse team suspends a bucket. The page was not misconfigured. It was taken down.

What Was Behind the Link

We cannot prove what that page served, and we will not pretend otherwise. It was gone before anyone scanned it. There is no record of it on urlscan.io and none in the Internet Archive.

The shape of the campaign says what it almost certainly was. The attacker already controlled one Microsoft 365 mailbox and was using it to reach that mailbox's contacts. That is a self-propagating credential campaign. Every mailbox you steal becomes the next sender, and the link is how you recruit the next one.

Worth knowing: S3 cannot receive a password. Static hosting serves files and accepts no form submissions. So the page either sent typed credentials onward to a different server, or redirected straight to the real phishing kit somewhere else. S3 was the doorway a second time.

Multi-Factor Authentication Would Probably Not Have Stopped It

This is the part most security training still gets wrong, so it is worth being precise.

Current phishing kits are adversary-in-the-middle. The kit sits between you and the genuine Microsoft login page and relays every request live. The login screens you see are real Microsoft screens, because they are real Microsoft screens, passed through the attacker's server.

You type your password. You approve the push notification on your phone. Microsoft, seeing a correct password and a correct second factor, issues a valid session cookie. The kit copies that cookie on its way past.

The attacker then replays your session cookie and is inside the mailbox with no password prompt and no second factor, because they are reusing a session that already passed both. This is, in all likelihood, exactly how the supplier's own mailbox was taken.

Codes and push prompts do not stop this. Passkeys and hardware security keys do, because the credential is cryptographically bound to the real domain, and a proxy in the middle cannot present that domain.

The Part That Costs Money

A stolen mailbox is not the goal. It is the tool. Once inside, the sequence is consistent:

1. Add a hidden inbox rule that deletes replies and security warnings, so the real owner never sees the complaints piling up.
2. Register an additional authentication method, so a password reset does not evict them.
3. Copy the address book and send the next wave. That wave is what reached us.
4. Wait inside a genuine invoice thread. When a real invoice goes out, resend it with the bank details changed.

Step four is where the loss happens, and it is why this attack targets the operations and finance side of a 10 to 200 person company rather than its IT department. The message arrives inside a thread you started, from the address you have always used, about an invoice you were already expecting. There is nothing to notice.

Four Checks That Actually Work

Sender address and spelling are not enough on their own. These are.

1. Does the payment language match the country? A European supplier writing "ACH", or a US supplier writing "BACS", is writing about a banking system they do not use.
2. Is the "To" field empty? Real remittance advice is addressed to you. A blind-copied blast is addressed to a list.
3. Does it name the specific transaction? Genuine accounting mail carries your company name, an invoice number and an amount, because it is generated from a record. Vagueness is the tell.
4. Have the bank details changed? Treat any change to payment details as hostile until a human at the supplier confirms it on a phone number you already had. Not a number from the email.

What We Did About It

We did not reply to the sender. An attacker reads that mailbox, and a reply confirms the address is live.

We found the supplier's public contact address and their managing director's name from company records, and wrote to them the same morning with the Message-ID, the file hash, the defanged link, and a containment checklist for their IT provider: reset the password, revoke every active session, enforce multi-factor authentication, inspect the inbox rules, pull the sign-in audit log, and warn their own customers about invoice fraud. We offered them the original message and attachment, and we did not attach the malicious PDF, because their mail filter would have quarantined the whole warning.

We are not naming them. They were breached, they did nothing careless that we can see, and publishing the name of a small family business during an active incident helps nobody except the next person searching for a reason not to trust them.

Why Email Is the Wrong Place to Approve a Payment

Every step of this attack depends on the same underlying condition. The payment decision lives in an inbox and a spreadsheet.

When supplier bank details live in a column of a shared workbook, nothing records who changed one, or when, or what it was before. When approval is a reply saying "yes, pay it", there is no second pair of eyes and no trail. When the vendor list is a tab that three people edit, a changed account number looks exactly like every other edit.

Software with a real workflow removes most of the attack surface without anyone having to be vigilant. Vendor bank details become a locked field with a change history. A change requires a second approver. Any payment above a threshold routes to someone who did not enter it. None of that is exotic. It is the ordinary shape of a system of record, and it is the difference between an attack that has to fool one distracted person and an attack that has to fool a process.

This is the work we do at LlamaPress: taking the spreadsheet a business already runs on and turning it into a database-backed application with the approvals, permissions and history the spreadsheet never had. If you want a wider look at where the manual steps and the risk sit in your own operation first, that is what an AI audit produces.

Written by Kody Kendall. Published 24 August 2026. The indicators on this page are shared so other recipients of the same campaign can match them. The affected supplier was notified before publication.