The Invoice Was Built by a Robot (and Signed by the CEO)

The attached PDF invoice passed every static analysis check. No JavaScript. No embedded links. No form actions. No OpenAction triggers. It was, by every technical measure, a clean file.

It was also built by a robot. The PDF metadata field /Creator reads HeadlessChrome, a headless browser commonly used in web automation. The attacker rendered a fake ZoomInfo subscription invoice as a web page, then printed it to PDF. The result is an image-only document where every line of text, every dollar amount, and every "remit payment" instruction exists as a rasterized image rather than extractable text. Scanners that parse PDF text streams for malicious keywords found nothing to parse.

The email carrying this attachment impersonated the CEO of a regional financial institution by name, splitting the attacker's identity across three unrelated domains and manufacturing a fake email thread to make the payment request look pre-approved.

A Robot Forger With a Headless Browser

The invoice (INV-3102450062259.pdf, 49KB) was created on April 8, 2026, the same day it was sent. The /Creator metadata identifies HeadlessChrome, Google Chrome's headless rendering engine. Developers use it for automated testing and web scraping. Attackers use it to mass-produce documents that look legitimate but contain no machine-readable text.

This matters because most email security gateways analyze PDF content by extracting text streams. They look for suspicious phrases ("wire transfer," "update payment details," "act immediately"), known malicious URLs, and embedded scripts. An image-only PDF returns nothing from text extraction. The scanner sees a valid PDF structure, finds no active content, and marks it clean. The Microsoft Digital Defense Report 2024 documented a sharp rise in attachment-based evasion techniques specifically designed to defeat automated content inspection.

A second attachment (325KB) shared the ZoomInfo branding but could not be analyzed by the sandbox environment due to file access errors. That is not a coincidence. Oversized or malformed PDFs that crash sandbox parsers are a known evasion technique. When one attachment crashes the analyzer and the other is image-only, the attacker has effectively blinded both layers of attachment inspection.

Three Domains, One Fake Identity

The attacker did not just forge a document. They built a complete social engineering package around it by fragmenting their identity across three domains:

The From address used info@castomer[.]eu, a domain hosted on Polish infrastructure (cyber-folks.pl, IP 91[.]237[.]52[.]216). WHOIS records for castomer.eu show DNS servers at linuxpl.com with no registrant information. The domain exists for one purpose.

The Reply-To header pointed to protection[.]mail@usa[.]com. If the recipient replied to question the invoice, that reply would route to a free email account on usa.com (a legitimate, 27-year-old domain operated by a web services company). The attacker chose a Reply-To address that sounds vaguely official while being completely disconnected from both the sending domain and the impersonated organization.

The manufactured thread contained a quoted reply block at the bottom of the email, formatted to look like a forwarded message from "ZoomInfo Technologies Inc" at zoominfopay@post[.]com. This fake thread created the illusion that the CEO had received and approved the invoice before forwarding it for payment. The FBI IC3 reported that vendor invoice fraud accounted for a significant portion of the $2.9 billion in BEC losses in 2024. The IBM Cost of a Data Breach Report found that BEC attacks carry one of the highest average costs per incident across all breach categories. Manufactured threads are a core technique because they bypass the recipient's instinct to verify: the approval already happened (it didn't).

The Authentication Contradiction

Here is where the infrastructure gets interesting. At the original mail server (s180a[.]cyber-folks[.]pl), the email passed SPF, DKIM, and DMARC for castomer.eu. The attacker had properly configured DNS records for their throwaway domain. Authentication was clean.

Then the message hit the recipient organization's Votiro CDR gateway, which relayed it from 44[.]206[.]222[.]91 (an AWS EC2 instance). That IP is not in castomer.eu's SPF record. The relay also altered the message body during content sanitization, which broke the DKIM body hash. At the final Microsoft 365 hop, all three checks failed: SPF fail, DKIM fail, DMARC fail.

This should be a red flag. But the Votiro relay is a trusted connector in the recipient's mail flow, and the post-relay antispam score dropped to SCL=-1 (trusted). The pre-relay score at the original hop was SCL:9 (high-confidence spam). The CDR gateway, designed to protect against malicious content, inadvertently laundered the spam score while breaking the authentication signals that would have flagged the message.

If you are running a CDR or secure mail gateway, audit whether your connector trust rules override authentication failures. A message that fails SPF, DKIM, and DMARC after transiting your own infrastructure is not the same as a message that passed them all.

What Behavioral Detection Found That Static Analysis Missed

The email carried no links. The PDFs contained no active content. Authentication results were contradictory. Every static indicator said "inconclusive at worst."

IRONSCALES detection worked on a different layer entirely. The platform matched the display name "Jeff Sinnott" against the organization's VIP directory and found an exact match to the CEO. The legitimate address for that executive is an internal domain. This email came from castomer.eu. That single behavioral signal (known name, unknown domain) triggered the impersonation flag.

Community threat intelligence added weight. Similar messages from the same sending infrastructure had already been reported across the IRONSCALES network of thousands of organizations. The combination of VIP impersonation, community signals, and first-contact sender status from a high-risk external domain pushed the message to quarantine.

The recipient never saw the invoice. The HeadlessChrome forgery never reached a human who might have opened it, read the fabricated payment instructions, and wired money to the attacker's account.

Curious how many fabricated invoices are reaching your mailboxes right now? See Your Risk.

The Takeaway for Defender Teams

This attack combined five techniques that individually look minor but together form a high-confidence fraud attempt: VIP display-name impersonation, image-only PDF generation via headless browser, manufactured conversation threads, identity fragmentation across three domains, and CDR relay trust exploitation.

None of these techniques triggered a malware verdict. None required the victim to click a link. The entire attack was social engineering wrapped in a technically clean package, the kind of attack that the Verizon DBIR consistently identifies as the most financially damaging category in email-based threats.

If your detection stack only analyzes what is inside the email (links, attachments, content), this attack is invisible. Detection has to start with who is sending it and whether the claimed identity matches reality. CISA's phishing guidance emphasizes verifying sender identity through out-of-band channels before acting on any payment request, especially when the email references executive approval.

Indicators of Compromise