Shell International Impersonated in BEC Invoice Fraud: DMARC Failure Exposes the Lookalike Payment Chain

# Shell International Impersonated in BEC Invoice Fraud: DMARC Failure Exposes the Lookalike Payment Chain

An attacker sent a "final payment notice before debt collection" email displaying info[@]shell[.]com as the From address. The message had no verifiable invoice details, no corporate payment portal, and no billing metadata. It had two things: the Shell International name in the From header and a Reply-To address at a domain registered weeks before the attack.

What the Attack Looked Like: Urgency, Brand Authority, and a Disposable Payment Drop

The email body opened with a debt-collection threat: payment must be received immediately or the account would be transferred to a collections agency. There was no invoice number, no contract reference, no purchasing contact at a verifiable Shell address. The only actionable element was a reply or payment instruction directing the recipient to write to kaitlyn[.]maye[@]ceo-coachinginternationalusa[.]info.

A second attacker-controlled address appeared: office[@]xoumail[.]com. WHOIS records for xoumail[.]com show a creation date of 2026-02-03, meaning the domain was registered within weeks of the attack. That timing is a textbook indicator of purpose-built scam infrastructure: a domain with no history, no business presence, and a plausible-sounding name.

The Return-Path used em5934[.]shell[.]com, and the message relayed through Mimecast infrastructure before reaching the recipient. The From header displayed shell[.]com, a long-established corporate domain registered in 1989.

Why DMARC Failed and Why That Matters Here

Business email compromise attacks often succeed when the target organization lacks enforcement policies. In this case, the opposite was true: Shell International publishes DMARC p=quarantine, meaning mail that fails alignment should be quarantined rather than delivered.

The message failed on both alignment checks. SPF failed because the actual sending IP (170[.]10[.]132[.]61, which reverse-DNS resolves to Mimecast delivery infrastructure) is not an authorized sender for em5934[.]shell[.]com. DKIM failed with a body-hash mismatch for shell[.]com, indicating the message body was modified in transit or was never signed by Shell's actual DKIM key in the first place.

The DMARC p=quarantine policy triggered correctly, and the message was quarantined at delivery. The attack did not bypass defenses. What this case illustrates is how an attacker constructs a convincing impersonation using a high-trust brand display name and hopes the recipient acts on it before the quarantine is reviewed.

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

How It Was Caught: Authentication Mismatch and Scam-Infrastructure Fingerprinting

The chain of detection signals was clear:

1. SPF fail on the sending IP against the envelope domain.
2. DKIM body-hash fail against the shell[.]com header domain.
3. DMARC fail on header.from=shell[.]com, triggering quarantine per the published policy.
4. Reply-To domain ceo-coachinginternationalusa[.]info: no public A record, no DMARC, no independently verifiable business presence.
5. xoumail[.]com registered 2026-02-03: weeks-old domain used for financial misdirection.
6. No invoice metadata: legitimate payment demands include invoice numbers, PO references, and verified billing contacts. This message had none.

Themis (our Adaptive AI) correlated the authentication failures with the payment-domain anomalies and the absence of any verifiable invoice context to classify the message as BEC.

Defender Takeaways: DMARC Enforcement Is the Last Line on Spoofed Sender Display

The entire credibility of this attack rested on the info[@]shell[.]com display in the From header. Enforced DMARC broke that credibility at the infrastructure level. Three lessons for defenders:

1. Your own DMARC posture matters. A domain publishing p=none cannot protect its recipients when the domain is impersonated. Shell's p=quarantine policy stopped delivery to the intended victim.
2. Payment-redirect domains deserve WHOIS scrutiny. A Reply-To domain registered weeks before the email arrives is not a business contact. No legitimate payment instruction comes from a domain that didn't exist last month.
3. Invoice emails without invoice metadata are not invoice emails. No number, no contract reference, no verified payment portal: the message is social pressure wearing a corporate costume.

See the MITRE ATT&CK technique references at https://attack.mitre.org/techniques/T1566/ and https://attack.mitre.org/techniques/T1036/.

Indicators of Compromise