Worked example: a spoofed supplier payment request¶
title: 'Worked example: a spoofed supplier payment request' subtitle: The message looks familiar, but the delivery and authentication records point to unrelated infrastructure. slug: worked-example-spoofed-supplier-payment-request series: email-evidence section: worked-examples card_type: worked_example pathway_order: 45 section_order: 1 status: draft public_safe: true video_ready: true word_count: 505 estimated_read_time_seconds: 209 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - worked example - spoofing - payment fraud - DMARC sources: - title: 'NCSC: Phishing attacks — defending your organisation' url: https://www.ncsc.gov.uk/guidance/phishing - title: 'NCSC: How to spot and report phishing scams' url: https://www.ncsc.gov.uk/collection/phishing-scams - title: 'Microsoft Learn: Email entity page in Defender for Office 365' url: https://learn.microsoft.com/en-us/defender-office-365/mdo-email-entity-page - title: 'Microsoft Learn: Message trace in the Microsoft Defender portal' url: https://learn.microsoft.com/en-ca/defender-office-365/message-trace-defender-portal
Worked example: a spoofed supplier payment request¶
The message looks familiar, but the delivery and authentication records point to unrelated infrastructure.
Script¶
A finance officer receives an email that appears to come from a regular supplier.
The display name is familiar.
The message says the supplier has changed bank accounts and asks for the next payment to go to new details.
The officer notices the request before the money is sent.
What do we have?
We have a message presented as coming from the supplier.
We don’t yet have proof that the supplier’s account or staff sent it.
The first action is protective.
The payment change should be verified through a trusted route already held by the organisation, such as a known telephone number or established supplier portal.
Don’t use the telephone number or reply address supplied in the suspicious email as the verification route.
Then preserve the original message.
Keep the full header, body, attachment or invoice, underlying links and mailbox context.
Message trace may help show how it entered the recipient’s organisation.
Now examine the identity.
The display name matches the supplier, but the underlying From address uses a lookalike domain with one changed character.
Reply-To points to a free-mail account.
The recipient provider records that the message arrived from unrelated hosted infrastructure.
SPF and DKIM may pass for the lookalike domain because the fraudster controls that domain.
DMARC may also pass for that same false domain.
That doesn’t make the message genuine.
Authentication shows that the lookalike domain authorised its own sending route.
It doesn’t show that the real supplier sent the message.
The important comparison is between the domain presented in the message and the genuine supplier domain.
Now test the alternative explanation.
Contact with the real supplier confirms that its bank details haven’t changed and it doesn’t recognise the message.
The genuine supplier’s provider has no matching sent event.
That strengthens the conclusion that the message impersonated the supplier rather than coming from a compromised genuine account.
The underlying invoice may have been copied from earlier correspondence.
That could explain why the reference numbers, employee names and formatting look convincing.
The enquiry should now consider how the fraudster obtained that information.
Was an earlier mailbox compromised?
Was an invoice intercepted?
Was information available from another source?
Did other recipients receive similar requests?
The final report should keep the findings separate.
The message displayed a familiar supplier identity.
It used a lookalike domain and unrelated reply address.
The recipient’s provider recorded a delivery route that wasn’t associated with the genuine supplier.
The real supplier denied changing the bank details and had no matching sent event.
Those facts support an impersonation and payment-diversion attempt.
They don’t yet identify the person who registered the domain, controlled the sending account or expected to receive the money.
That requires further provider, domain, financial and account evidence.
The lesson isn’t that failed authentication reveals every spoofed message.
A fraudster’s own lookalike domain may authenticate perfectly.
The practical control is to verify important payment changes through a separate trusted channel.
The investigative task is to preserve the email and follow the domain, provider, account and payment route actually used.
Key takeaway
Verify an important payment request through a trusted second channel, then preserve the email and follow the actual delivery route.
Scenario at a glance¶
- Displayed identity: genuine supplier name.
- Underlying address: lookalike domain.
- Reply route: unrelated free-mail account.
- Authentication: may pass for the fraudster-controlled lookalike domain.
- Trusted delivery evidence: unrelated hosting or mail infrastructure.
- Independent check: genuine supplier denies the change and has no matching sent event.
- Next enquiries: domain control, sending account, source of copied invoice data and destination bank account.
Related questions¶
- What if the email address was spoofed?
- Does a failed SPF check prove the email is fraudulent?
- Does the From address identify the sender?
- What corroboration should I look for?
Source notes¶
- NCSC: Phishing attacks — defending your organisation
- NCSC: How to spot and report phishing scams
- Microsoft Learn: Email entity page in Defender for Office 365
- Microsoft Learn: Message trace in the Microsoft Defender portal