Colleague-Confirmed Fraud: When the Invoice Already Has an Internal Warning Attached

The fraud confirmation was already in the thread. An internal employee had replied, named the invoice fraudulent, and told recipients to report it as phishing. That warning was visible to anyone who read the chain from top to bottom. The email -- and its payment link -- kept circulating anyway.

This case is not about a gateway failure to detect a malicious URL. It is about how invoice fraud survives even when a human catches it in real time, because the detection channel and the attack surface are the same inbox thread.

The Billing Chain and the Payment Link

The email arrived as part of a property-services billing thread. It included personalized invoice details: a Lease ID, a named contact, a property address, and a direct link to an online bill-payment portal. The sender domain is a long-established billing and services organization whose domain has been registered since 2001 and routes outbound mail through Barracuda, a recognized enterprise email security gateway. That infrastructure posture -- aged domain, reputable relay -- is exactly the kind of technical profile that prevents automated blocks.

The payment link pointed to an online billpay endpoint at the sender's established domain. Gateway scanners assessed it as clean. There was no credential-harvest redirect, no malware on the landing page, no typosquatted domain in the URL path. The fraud, if confirmed, would materialize at the payment destination level: funds wired or processed to an account the attacker controls, not through any technical exploit on the link itself.

MITRE ATT&CK T1566.001 covers spearphishing with attachments and links; T1036.005 captures the match-legitimate-name technique used by invoice fraud operators who borrow established domain identities to launder their payment requests. T1657 (financial theft) maps to the ultimate payment-diversion objective.

The Anomalies the Scanner Ignored

Two technical irregularities appeared in the thread that automated systems did not act on.

The first was a malformed mailto string -- a contact-us email address that included a pipe character and appended digits after the address, producing a syntactically broken contact link. Malformed contact strings appear in invoice fraud emails when a template was assembled from multiple sources and not fully cleaned before sending. Legitimate billing systems do not produce broken mailto values.

The second was the misspelling in the internal warning itself: the alert text used "FRADULENT" instead of "FRAUDULENT." This is consistent with a hurried reply, but it also illustrates how a warning embedded in a phishing thread can itself contain the markers of urgency and informality that reduce recipient confidence in the message.

Neither anomaly surfaces as a signal in standard gateway rule sets. Text analysis for typos and malformed syntax is not a default filter category.

See Your Risk: Calculate how many threats your SEG is missing

Why the Internal Alert Was Not Enough

The business email compromise detection problem in invoice fraud is not primarily technical. The internal employee's fraud flag was accurate. It was placed in the right medium -- a reply in the thread carrying the suspicious invoice. But thread-based alerts have a structural weakness: they depend on every at-risk recipient reading the replies in order, before acting on the original message.

Billing staff under operational pressure often open email threads looking for the action item. If the payment-link email landed before the warning reply, or if the original email was forwarded independently of the chain, the alert never reaches the decision-maker who processes the payment.

The result is a detection event that generates no remediation. The fraud flag existed. The payment link was still live. The thread kept circulating.

The Authentication Picture

The internal segment of the thread -- the reply from the employee -- showed DKIM absent and DMARC absent for the organization's own sending domain. This is standard for messages that originate inside a Microsoft Exchange-hosted environment. Exchange applies internal authentication through its own trust fabric, reflected in the X-MS-Exchange-Organization-AuthAs: Internal header and the MessageDirectionality: Originating marker. Treating absent DKIM on an internal reply as a spoofing signal would generate constant false positives in any organization running Exchange Online.

For vendor email compromise at the receiving end, the more relevant authentication signal is the external billing sender's posture: an established domain, Barracuda relay authorized in SPF, no DMARC enforcement. That DMARC p=none means the domain publishes no policy for what receivers should do with mail that fails alignment. A domain handling billing traffic for multiple tenants and carrying no DMARC enforcement is a target profile for compromise or impersonation.

The Control Gap This Attack Exposes

Invoice fraud at this sophistication level is not detected by URL scanning. It is detected by verifying payment instructions through an independent channel before processing. The threat-intelligence value of this case is the confirmation pattern: an insider caught it and the email still circulated. That gap -- between detection and remediation -- is where organizations lose money.

IRONSCALES detected the behavioral anomaly: first-time relationship between the billing sender and this mailbox population, payment-link content, and the internal fraud flag that elevated the incident to confirmed phishing status. The billpay link itself produced no automated malware verdict because none was required. The fraud was the payment request, and the evidence was already in the thread.

Indicators of Compromise