Threat Intel Isn't Forensic Proof: Investigating Lookalike-Domain Payment Fraud

You cannot say where a payment-diversion attack happened without logs and mailbox evidence from every party’s systems. Threat-intelligence lookups can point an investigation in a direction. They cannot attribute fault.

The scenario is common. Two companies are negotiating a deal by email. Near the end, “updated bank details” arrive from what looks like the other side. The money goes to a criminal’s account. Each side then blames the other for being the one that was “hacked”.

In a recent expert review of another investigator’s findings, GSI Cyber saw the same pattern we see often. The attack was labelled and fault was implied, but key evidence had never been collected. This article sets out what a defensible investigation needs, and why anything less should be treated as a lead rather than a conclusion. Details of the engagement are withheld; the technical lessons are general.

How lookalike-domain attacks work

The attacker registers a domain one character away from a real one. Examples are a dropped letter (acme-partners.com becomes acme-parners.com), a swapped letter, or a different TLD. They then send mail from it that copies the real sender’s name, signature and thread.

The attacker usually gets their position in one of three ways:

• Account compromise. A real mailbox is taken over, often through credential phishing or token theft. The attacker reads the live thread and sets inbox rules to hide replies.
• Thread harvesting without a takeover. The attacker obtains copies of earlier emails, for example from a forwarded chain or a compromised third party. They then continue the conversation from the lookalike domain.
• Pure impersonation. No account is touched. The attacker relies on public information and a convincing lookalike.

The important detail is that many cases are multi-sided. The attacker registers lookalikes of both parties’ domains and sits in the middle. Each side then talks to a fake version of the other. When spoofed addresses exist for both sides, the evidence alone does not show whose environment leaked the conversation. Either side’s mailbox, a device, or a third party in the thread could be the source.

Threat intelligence is a lead, not proof

It is tempting to settle attribution with Cyber Threat Intelligence (CTI) platforms such as IntelX, SOCRadar or VirusTotal. They show whether a domain has appeared in leak data, phishing feeds or malware reports. They can also show that a company’s addresses turn up in old breach dumps.

That is useful context. It tells you about the threat environment and gives you leads to follow. It does not tell you how this attack happened.

An analogy helps. Learning that a certain type of crowbar has been used in burglaries in your area does not prove your premises were broken into with it. It does not even prove they were broken into at all. To know that, someone has to examine the door, the locks and the alarm logs.

In practice:

• A domain flagged as malicious shows the lookalike was used for fraud. It does not show which party’s systems leaked the thread.
• A company’s addresses in breach data show exposure at some point. They do not show that a breach of that company caused this incident.
• General remarks about a company’s security posture are not findings about this incident unless that company’s systems were examined.

Any conclusion built only on CTI, without host and log evidence, should be labelled as an investigative hypothesis.

The evidence that answers “where did it happen”

For organisations on Microsoft 365, attribution rests on a small set of primary sources. Each one answers a specific question, and each has to be collected from the tenant itself.

Evidence source	Where it lives	What it answers
Entra ID sign-in logs	Entra admin centre / Graph API	Who logged in, when, from which IP, device and location; whether MFA was met; risky or impossible-travel sign-ins
Unified Audit Log	Microsoft Purview Audit	Mailbox and admin actions: inbox rules created, forwarding set, mailbox permissions changed, app consents granted
Mailbox audit (MailItemsAccessed, Send, SearchQueryInitiated)	Purview Audit	Which messages an attacker opened, searched for or sent from the account
Inbox rules and forwarding	Exchange Online (Get-InboxRule, mailbox forwarding settings)	Hidden rules moving or deleting replies, a classic sign of takeover
OAuth app consents and MFA registrations	Entra ID	Persistence: rogue apps with mail access, or attacker-added MFA methods
Message trace	Exchange admin centre	Which messages actually passed through the tenant, to and from which addresses
Full message headers	The original messages (.eml / .msg)	True sending infrastructure: Received chain, SPF/DKIM/DMARC results, Message-ID, originating IP
Endpoint images	Laptops and phones that used the mailbox	Infostealer malware, token theft, malicious browser extensions, local mail rules
Lookalike domain records	WHOIS/RDAP, DNS (MX, SPF), registrar	When the fake domain was registered and set up for mail, relative to the timeline of the thread

Sign-in logs, audit records and message traces are the artefacts that answer "where". Most of them are on a deletion timer.

Together these answer three questions. Was any account actually compromised? If so, which one and when? How did the attacker get the content of the conversation? Without them, “Company X was compromised” is an assumption.

Examine every party, not just one

An investigation that examines one side and assigns fault to the other has not tested its own conclusion. If the side that was examined shows no signs of compromise, that is useful. It does not prove the other side was compromised, because the leak may have come from a device, a third party in the thread, or an account nobody looked at.

Our position is simple. Where an investigator could not access a party’s mailboxes, logs or devices, the report should say so plainly. It should then limit its conclusions to what the evidence supports. Calling the attack a man-in-the-middle and placing the point of compromise inside the unexamined environment goes beyond the evidence.

Think of investigating a burglary without being allowed into the burgled building. You can describe the neighbourhood and the burglar’s methods. You cannot say how this building was entered.

Collection and chain of custody

Evidence that will be relied on in a dispute has to be collected in a way another expert can check. Screenshots forwarded by one party, or emails re-sent by someone with an interest in the outcome, do not meet that bar.

A defensible collection looks like this:

1. Acquire from the source. Export logs and mailbox data directly from the tenant with an account created for the investigation, and record who ran each export and when.
2. Preserve originals. Keep messages as .eml or .msg with full headers. A pasted or forwarded copy loses the routing data that shows where a message really came from.
3. Image the endpoints. Take forensic images of the laptops and phones that used the affected mailboxes, and verify each image with a hash.
4. Hash and log everything. Record a SHA-256 hash for every exported file, and keep a custody log of each transfer.
5. Document the gaps. If a party, mailbox or device could not be examined, state it, and state which conclusions it limits.

If these steps are skipped, the conclusions may still be right. But nobody can verify them, and an opposing expert will say so.

Act fast: the logs expire

Much of this evidence is deleted automatically, often before anyone thinks to collect it. Disputes over a diverted payment usually start weeks after the transfer, when some of the key logs are already gone.

Evidence	Typical default retention
Entra ID sign-in logs	7 days (free tier), 30 days (Entra ID P1/P2)
Message trace	Up to 90 days
Purview Audit (Standard)	180 days
Purview Audit (Premium)	1 year, extendable

Retention depends on licence and settings and Microsoft changes it from time to time, so check your tenant’s current values. The practical rule doesn’t change: when a payment goes missing, export the logs from every party’s tenant the same week. Then argue about fault.

Checklist: if a payment has been diverted

For the business

• Call your bank immediately and ask for a recall of the transfer
• Report the fraud to the police and your national cyber or fraud reporting service
• Reset passwords, revoke active sessions and review MFA methods on every account in the thread
• Check for inbox rules, forwarding and unfamiliar app consents
• Export sign-in logs, audit logs and message traces now, before they expire
• Keep the original fraudulent emails as files, not forwards
• Don’t wipe or reissue the laptops and phones involved until they are imaged

For lawyers and reviewers of an expert report

• Were mailboxes, logs and devices examined for every party, or only one?
• Does the report separate evidence from CTI-based inference?
• Is each attribution backed by a primary artefact (a sign-in, a rule, a header)?
• Were exports collected from source, hashed, and logged?
• Are gaps in access stated, with the conclusions they limit?

About GSI Cyber

GSI Cyber provides digital forensics, incident response, OSINT and expert review of technical evidence in commercial disputes. We help businesses investigate email fraud and give lawyers an independent view of whether a forensic report’s conclusions hold up.

Ermin Klimenta is Director of GSI Cyber. Details of the engagement referred to in this article are withheld for confidentiality.