What are the signs that an invoice fraud campaign is using a compromised mailbox instead of obvious spoofing?

Common signs include messages sent only from a trusted internal or partner mailbox, a believable reply chain, and a financial request hidden inside otherwise normal email traffic. Unusual PDF attachments, subtle domain misspellings, and repeated payment instructions across near identical messages are also indicators. In these cases, the body content is often more revealing than the email headers.

How to tell this is a mailbox compromise, not simple spoofing

A compromised mailbox usually leaves a different trail than a forged sender. The message often arrives from a real account that already has trust with the recipient, so the signal shifts from domain reputation to conversation context, reply-chain behaviour, and whether the payment request fits the account’s normal communication pattern.

One of the strongest clues is continuity. The attacker is not inventing a fresh persona, they are operating inside an existing thread or a believable new thread from the same mailbox, which makes the message look routine enough to bypass quick visual checks.

That means the practical question is not just “does the sender look legitimate?” but “does this message behave like the real mailbox owner would behave?” In a compromise, the answer often differs in tone, timing, attachments, and the type of request being made.

What the message body usually reveals that headers do not

Body content becomes the higher-value indicator because headers can be perfectly ordinary when the attacker is sending from a hijacked account. Look for a financial request inserted into otherwise normal operational chatter, especially when the request appears late in the thread or is phrased as a small process change rather than a dramatic fraud attempt.

Attachment choice is also revealing. A PDF attached to a routine invoice message, a near-identical invoice sent repeatedly, or subtle changes in payment instructions can indicate someone is using trust in the mailbox relationship to push payment redirection without triggering obvious anti-spoofing checks.

Domain misspellings still matter, but in mailbox compromise they are often secondary noise rather than the main signal. The more useful clue is that the content feels internally consistent at first glance while quietly diverging from prior payment history, invoice format, or the sender’s normal business language.

Why these campaigns succeed in practice

Mailbox compromise works because it abuses trust that has already been earned. If the recipient sees a known supplier, colleague, or partner mailbox, common domain checks may never fire, and the attacker can exploit the normal expectation that invoices, corrections, and payment instructions arrive through email.

That creates a detection gap: controls tuned for external spoofing can miss authenticated abuse of a real account. In practice, the attack is successful when reviewers focus on sender identity alone and do not compare the request against prior thread context, invoice history, and payment-change workflow.

Risk and Threat Considerations

Mailbox compromise is riskier than obvious spoofing because it removes the cheap visual tell and replaces it with trusted conversation context. Once an attacker controls a legitimate mailbox, they can steer payment workflows, sustain the fraud across multiple messages, and use the genuine account to reduce suspicion at the point of approval.

Failure mechanism: The attacker abuses an already trusted account, then hides the fraudulent request inside normal-looking correspondence, often with a believable thread and familiar formatting that bypasses superficial sender checks.

Impact: Organisations can approve fraudulent payments before the compromise is noticed, especially when invoice validation is based on email familiarity rather than independent callback or payment-change verification.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1566 — Phishing	Compromised-mailbox invoice fraud uses deceptive email delivery and trust abuse.
Recommendation — Map suspicious mail flow to phishing tradecraft and review for account abuse and delivery-path anomalies.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	A real mailbox compromise is an authentication and access-control failure.
Recommendation — Verify mailbox access controls and revoke unauthorized sessions before trusting inbound payment requests.
NIST SP 800-53 Rev 5	AU-6 — Audit Review, Analysis, and Reporting	Mailbox-compromise fraud is best confirmed by reviewing email and account activity logs.
	IA-5 — Authenticator Management	Compromised mailbox campaigns depend on stolen or abused authenticators and sessions.
Recommendation — Correlate mailbox login, forwarding, and message-sending activity to confirm compromise. Rotate or revoke mailbox authenticators and session tokens when compromise is suspected.
CIS Controls v8	5 — Account Management	Compromised mailboxes are fundamentally an account-control problem.
Recommendation — Review account ownership, access, and recovery paths for the affected mailbox immediately.

Practitioner Guidance

What to verify: Treat any payment instruction change, bank-detail update, or “urgent resend” as suspicious until it is validated outside the email thread. Compare the request against prior invoice patterns, known contacts, and the sender’s normal business cadence before routing it for approval.

Common mistake: Teams often over-weight domain reputation and under-weight message behaviour. If the mailbox is real, the safest assumption is not that the email is authentic, but that the account may be compromised and the content may be adversarially crafted.

Practitioner takeaway: The decisive indicator is usually not the sender’s header, it is the mismatch between a trusted mailbox and a request that breaks the account’s normal payment behaviour.