Three Domains, One Fake Invoice: The Pact Group Payment Confirmation Lure

The email looked routine. A subject line referencing outstanding invoices, a professional signature from an accounts receivable contact at Pact Group, and an attached spreadsheet asking the recipient to confirm which invoices had not been received. The kind of message that finance teams open every week.

But three distinct pieces of infrastructure behind that message had nothing to do with Pact Group, and two of them had nothing to do with each other.

The Identity Mismatch Pact Group's Name Could Not Paper Over

Impersonation attacks rely on a gap between what the recipient sees and what the infrastructure records. In this case, that gap was unusually wide.

The email's From header displayed an accounts receivable address at an unrelated legitimate organization, a long-established business domain with full SPF/DKIM/DMARC authentication, wholly separate from Pact Group. The message passed every domain-based authentication check for that sending domain. But the body signed off as "Lynsey Moore, Accounts Receivable, Pact Group." No connection between the authenticated domain and Pact Group exists in the public record.

The second data point sits in the Message-ID header. The originating mail server stamped the Message-ID with a domain belonging to a third organization, a packaging company with no evident relationship to either the sending domain or Pact Group. Message-ID values reflect the infrastructure that generated the message. When the Message-ID domain, the From domain, and the body's claimed identity all point to three different organizations, the message is structurally inconsistent in ways legitimate transactional email is not.

The third signal came from the origin relay. The first hop before Microsoft's Exchange Online protection layer was a server with no useful reverse DNS. Anti-spam processing flagged the PTR as nonexistent. Legitimate invoicing systems, even those routed through third-party mail platforms, typically operate from infrastructure with configured forward-confirmed reverse DNS. Missing PTR is not disqualifying alone, but it compounds the other inconsistencies.

The combination of display-name spoofing of a known brand, authentication passing for an unrelated domain, and Message-ID stamped by a third party placed this message in quarantine as a first-time high-risk sender.

What a 4KB Spreadsheet Can Carry

The attachment, named "Payment Confirmation Required: Cust 20352.xls," arrived in the legacy BIFF/OLE format and weighed 4,295 bytes (roughly 4KB). That figure matters.

A real invoice spreadsheet listing payment dates, amounts, and customer records for an accounts receivable reconciliation would be substantially larger. A workbook with even ten invoice rows, formatted columns, and customer metadata routinely exceeds 15-20KB. A 4KB .xls is either nearly empty or has been stripped down to a stub.

Stubs in legacy .xls format are a known pattern in malware delivery. The OLE container can hold VBA module code in a fraction of that space. The full workbook structure, including a macro-enabled sheet, can fit in a few kilobytes when the only "content" is the macro itself. The sandbox environment could not open the file to extract sheet contents or enumerate VBA modules. The declared MIME type was application/vnd.ms-excel and the file was quarantined as a precaution.

What the sandbox could not confirm, the context confirmed: a 4KB .xls named "Payment Confirmation Required" arriving from a first-time sender impersonating a known brand, accompanied by an accounts receivable inquiry asking for reply-by-email confirmation of payment amounts, is a BEC-adjacent setup optimized for one of two outcomes. Either the recipient opens the attachment and triggers whatever the file contains, or the recipient replies with payment confirmation details that feed a subsequent fraud step.

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

Why Full Authentication Did Not Signal Safety

MITRE ATT&CK T1566.001 covers phishing via spearphishing attachment, the delivery mechanism here. T1656 (impersonation) covers the Pact Group identity claim throughout the message body and signature. T1204.002 (user execution: malicious file) is the intended trigger; the recipient opening the .xls is what activates whatever payload the file contains.

The authentication result for the sending domain was SPF pass, DKIM pass, DMARC pass. That outcome reflects the state of one specific domain's authorization records. The compromised-or-controlled domain was correctly authorized to send email. The question the authentication layer does not answer is whether that domain has any relationship to Pact Group, whose name appears nowhere in the sending domain's DNS or public registration.

Display name spoofing at the brand level (writing "Pact Group" in the body and signature rather than in the From header) sidesteps header-based authentication entirely. The From header authenticates. The body does not. An attacker who controls any authenticated domain can sign as any company name they choose in the message body and signature without failing a single authentication check.

This is the authentication theater gap that practitioner defenses need to close. Passing auth means the domain authorized the send. It says nothing about whether the claimed identity is truthful.

Indicators of Compromise