Invoice fraud, and the question every business gets asked next

What happened

A customer of one of our managed services clients received an invoice that looked exactly like the ones they were used to. It arrived inside an existing payment conversation, referenced real details, and asked for payment to updated banking information. It had not come from our client.

An attacker had registered a look-alike domain that differs from the real one by a single character, the kind of substitution that survives a careful read because the eye corrects it. They stood that domain up as a legitimate business email tenant of their own, which meant the messages passed authentication checks and carried none of the usual warning signs. Then they inserted themselves into a live invoice thread.

This is conversation hijacking, and it is the more dangerous form of business email compromise. There is no clumsy pretext to notice, because the conversation is real. Only the sender changed.

Why the first question is the important one

When fraud moves through a payment relationship, the immediate question is not how much was lost. It is whose email was compromised. That question carries real consequences: customers pause payments, insurers ask for evidence, and the answer tends to be assumed rather than established.

As their IT provider, producing that answer was our job. It also meant our own word was never going to be enough on its own, because the party asking the question was a customer deciding whether to release a payment. The finding had to rest on evidence anyone could check, not on assurance from the vendor responsible for the environment.

What we did

Sylerity administers the client's Google Workspace environment, so we began the investigation with existing super-administrator access and no discovery delay. We audited the three mailboxes involved in the invoice thread end to end.

That meant reviewing the full sign-in history for anomalous locations, devices, and times, enumerating every third-party OAuth application authorized against the tenant, and inspecting each account for the artifacts an attacker leaves when they do gain access: forwarding rules that quietly copy mail to an outside address, filters that hide replies, and delegated access granted to another account. We also traced the message path of the fraudulent invoice itself to establish where it entered the conversation.

What we found

The client's environment was clean. Sign-in history showed no unauthorized access. No unexpected OAuth grants existed against the tenant. None of the three mailboxes carried forwarding rules, filters, or delegates that would let a third party read or redirect mail. The exposure that gave the attacker the thread originated outside our client's environment.

We documented the finding in a written incident report covering the timeline, the evidence reviewed, the basis for the determination, and the remaining risk. It is the kind of document that answers a customer, an insurer, or an auditor without requiring them to take anyone's word for it.

What we did next

Establishing that a client was not breached is not the same as leaving them safe. The look-alike domain still exists, and the technique works against any business that sends invoices by email.

We blocked the fraudulent domain at the mail gateway so further attempts do not reach anyone, and delivered a prioritized remediation list: publishing a DMARC policy so that mail claiming to come from the client can be verified and impersonation attempts become visible, and closing multi-factor authentication enrollment gaps, including the grace period that leaves newly created accounts unenrolled longer than most people realize.