13.5 The Fraudulent Email

The Fraudulent Email

This subsection dissects the fraudulent payment diversion email — the attacker’s weapon. Understanding exactly how it was constructed teaches you to recognise BEC emails in future incidents and to explain the technique to non-technical stakeholders in the IR report.

Anatomy of the fraudulent email

The attacker’s email to a.patel (received 12 March, 3 days before the CFO flagged it):

From: accounts@meridian-precision.co.uk (displayed) — or accounts@meridian-precisi0n.co.uk (actual, if lookalike domain) To: a.patel@northgateeng.com Subject: Re: March Invoice #MP-2026-0847 — Updated Bank Details Thread: Continues the legitimate invoice thread between a.patel and Meridian’s real accounts team

Body (reconstructed from investigation): “Hi Anika, Quick update regarding our banking details — we have recently changed our primary banking provider. For the March payment (£47,000, Invoice #MP-2026-0847), please use the following details: [new bank name, sort code, account number]. All future payments should also be directed to this account. Please confirm once updated. Kind regards, Sarah Mitchell, Accounts Department, Meridian Precision Components Ltd”

Why this email is convincing

Thread continuity. It appears within an existing email thread about a real invoice (MP-2026-0847) that a.patel has been actively corresponding about. The recipient does not treat it as a new, standalone request — it is a continuation of a conversation.

Correct invoice details. The attacker monitored the email thread (subsection 13.4) and knows: the invoice number, the amount, the payment timeline, and the vendor contact name. These details are correct because the attacker read the legitimate emails.

Reasonable pretext. “We changed our bank” is plausible. Vendors change banks. The request is not unusual in isolation — it becomes suspicious only when verified against the vendor’s actual bank details.

Professional tone. The email matches the tone and formatting of legitimate Meridian emails. The attacker studied the vendor’s communication style during reconnaissance.

No technical indicators. No malicious URLs. No attachments. No unusual formatting. Nothing for Defender for Office 365 to detect.

Technical analysis of the email

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// Full technical details of the fraudulent email
EmailEvents
| where TimeGenerated between(datetime(2026-03-11T00:00:00Z) .. datetime(2026-03-13T00:00:00Z))
| where RecipientEmailAddress == "a.patel@northgateeng.com"
| where Subject has "Updated Bank Details" or Subject has "MP-2026-0847"
| project
    TimeGenerated,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderIPv4,
    AuthenticationDetails,
    Subject,
    InternetMessageId = tostring(InternetMessageId),
    NetworkMessageId,
    DeliveryAction,
    DeliveryLocation,
    ThreatTypes,
    DetectionMethods

Key analysis points:

Sender domain verification. Extract the exact domain from SenderMailFromAddress. Compare character-by-character with the legitimate vendor domain. Common lookalike techniques: 0 replacing o, rn replacing m, 1 replacing l, adding a hyphen or subdomain (meridian-precision-uk.co.uk vs meridian-precision.co.uk).

Authentication result interpretation. If the fraudulent email came from a lookalike domain: SPF and DKIM will PASS for the attacker’s domain (they configured DNS correctly on their own domain). DMARC will show “none” or “pass” for the attacker’s domain — not the legitimate vendor’s domain. The authentication checks verify that the email came from the claimed domain — they do NOT verify that the claimed domain is the legitimate vendor.

If the email came from the real vendor domain with passing authentication: Meridian’s email infrastructure is compromised. This is a supply chain BEC — the attacker compromised the vendor, not Northgate. Notify Meridian immediately.

The social engineering technique: authority and urgency

BEC emails exploit two psychological triggers:

Authority. The email appears to come from a known, trusted source — either an internal executive or an external vendor the recipient regularly deals with. The recipient defers to the authority of the sender rather than questioning the request.

Urgency. “Please update before the March payment” creates a time constraint. The recipient processes the change quickly to meet the payment deadline rather than pausing to verify through a separate channel.

The combination is effective because the recipient is already expecting to make this payment. The attacker does not create a new transaction — they modify an existing one. The cognitive load of questioning a routine update within a trusted thread is higher than simply processing it.

This is why technical controls alone cannot prevent BEC. The defence is procedural: a verbal verification policy requiring that any bank detail change is confirmed via phone call to a known number (not a number provided in the email). Subsection 12.11 covers this hardening recommendation.

Subsection artifact: The email analysis query and the social engineering technique description. These feed the IR report (the “how the attack worked” section) and the security awareness training update (the “what to look for” section).

Knowledge check

Lookalike domain detection techniques

Automated detection of lookalike domains is challenging — the differences are designed to be invisible on quick inspection. Here are the techniques for systematic detection.

Character-by-character comparison. Extract the sender domain from the fraudulent email. Place it next to the legitimate vendor domain. Compare character by character:

Position 17: lowercase ‘o’ replaced with digit ‘0’. This is invisible in most email clients at normal font sizes.

KQL-based lookalike detection. For systematic detection across all incoming email:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// Find emails from domains similar to known vendor domains
// Uses Levenshtein-style comparison via string functions
let VendorDomains = datatable(Domain:string) [
    "meridian-precision.co.uk",
    "northgate-suppliers.com"
    // Add your vendor domains
];
EmailEvents
| where TimeGenerated > ago(7d)
| where SenderFromDomain !in (VendorDomains)
| extend DomainChars = split(SenderFromDomain, "")
| where SenderFromDomain has_any ("meridian", "northgate")  // Partial match
| where SenderFromDomain !in (VendorDomains)  // But not exact match
| project TimeGenerated, SenderFromAddress, SenderFromDomain,
    RecipientEmailAddress, Subject

This query finds emails from domains that contain vendor name fragments but are not the exact legitimate domain — catching lookalikes like meridian-precisi0n.co.uk, meridian-precision-uk.com, or meridiann-precision.co.uk.