The email landed in the accounting inbox on a Monday morning. The subject line referenced a correction to an invoice due the same day. The sender appeared to be a finance department contact from a Brazilian supplier the recipient knew. The instruction was simple: do not pay the previous boleto, use the new one attached instead.
The sending domain was one day old.
That detail did not surface in the inbox. SPF, DKIM, and DMARC all passed cleanly. The message looked exactly like a routine payment-correction notice from a known vendor. And the fraudulent payment details lived inside an image-only PDF that no scanner could inspect.
A boleto bancario is a bank payment slip common in Brazilian business transactions. Finance teams receive them regularly by email, and the workflow around them, including corrections and reissuances, is familiar enough that a replacement request does not immediately raise questions.
The attacker rebuilt that workflow as a lure. The message, written in Portuguese, told the recipient to disregard the previous boleto and instead pay using the newly attached slip for R$1,099.65. It referenced an invoice number, included a full NFe electronic access key to signal legitimacy, and noted a small credit adjustment. The sender's signature carried the name of a finance department contact and the name of the impersonated supplier.
None of those details were verifiable from the message itself. There was no phone number to call, no CNPJ company registration number, and no official domain in the signature matching the supplier's actual web presence. The attacker provided enough specificity to look credible without providing enough to be checked.
This is the core pattern in invoice fraud: substitute payment details at the moment a legitimate payment is expected, and do it in a way that fits the recipient's normal workflow. The social engineering does not need to be elaborate when the context already primes the target to act.
The sending domain, pagtolivesoma[.]com, was registered through Namecheap on December 14, 2025, one day before the message was sent. It used a privacy protection service, so WHOIS returned no owner details. The mail server was a shared web-hosting IP, not a corporate mail gateway.
And yet: SPF passed. DKIM passed, with the signature tied to pagtolivesoma[.]com. DMARC passed. Composite authentication scored a clean result.
This is not a paradox. Authentication checks measure configuration, not age or intent. The attacker registered the domain, published valid SPF and DKIM records, and configured outbound mail from a hosting provider before sending. Every check confirmed what it was designed to confirm: the message came from infrastructure the domain owner authorized. The checks have no visibility into when that domain was registered or whether its owner has any legitimate relationship with the impersonated supplier.
The case maps to two MITRE ATT&CK techniques. Acquire Infrastructure: Domains describes registering attacker-controlled domains ahead of an operation. Phishing: Spearphishing Attachment covers the delivery mechanism, where the malicious payload rides inside an attached file rather than a link. Together they form a pattern where authentication launders a fresh domain's reputation and the attachment hides the payload from inspection.
Microsoft's antispam filters did assign a spam confidence level that placed the message in the junk folder, a signal that something was off even without content-level evidence. But for organizations that route junk-foldered messages through an accounts-payable review, or where filters are tuned differently, the delivery path is clear.
Both attachments, novo_tit_*.pdf (the replacement boleto) and comp_baix_*.pdf (an apparent adjustment document), came back clean from antivirus scanning. That verdict is accurate in a narrow sense: there were no embedded scripts, no JavaScript, no AcroForms, no extractable URLs.
What the scanners could not see was everything else. Both PDFs were image-based. The boleto document, including any bank account numbers, agency codes, PIX transfer keys, or QR codes, existed as rendered images inside the file. Standard PDF parsers extract text and links. They do not apply optical character recognition to images unless specifically configured to do so, and most production email security stacks are not.
The fraud lives in those images. The attacker needed only to swap in a fraudulent bank account or PIX key at the image-rendering stage, and no automated tool between the sender and the recipient would detect the substitution. The AV verdict of clean was technically correct and operationally meaningless.
This is the gap that business email compromise variants exploiting image payloads are built around: the gap between "no malicious code found" and "no fraud present."
| Type | Indicator | Context |
|---|---|---|
| Domain | pagtolivesoma[.]com | Attacker-registered sending domain, created 2025-12-14 (one day before send), now suspended (clientHold) |
| ribeiro@pagtolivesoma[.]com | Attacker sender address impersonating supplier finance department | |
| File | novo_tit_325684591[.]pdf | Fraudulent replacement boleto, image-only, no extractable text |
| File | comp_baix_72516704[.]pdf | Accompanying adjustment document, image-only |
| Behavior | Payment-replacement instruction referencing prior boleto | Classic payment-diversion social engineering pattern |
| Auth | SPF pass, DKIM pass, DMARC pass | Genuine authentication on attacker-owned one-day-old domain |
| Infrastructure | business179-2[.]web-hosting[.]com (162.254.39.236) | Shared hosting relay used as outbound mail server |
Content inspection had nothing to grab. Link scanning had no links to check. The attachment scan returned clean. The authentication stack returned clean.
What remained were two signals: domain age and behavioral pattern. The sending domain was one day old at the time of delivery, a fact visible in WHOIS but not surfaced by standard gateway verdicts. And the message followed the exact pattern of a payment-diversion request, a first-time sender impersonating a known finance contact, instructing a change to an in-flight payment, with urgency tied to a same-day due date.
Domain age is a signal that behavioral and reputation-based analysis can weight. A gateway evaluating authentication results alone would clear this message. A system that also scores sender history, domain registration recency, and the behavioral fingerprint of a payment-change request from an unknown sender has more to work with.
See Your Risk: Calculate how many threats your SEG is missing
Verizon's 2026 Data Breach Investigations Report puts the human element in 62 percent of breaches, and invoice fraud remains among the highest-dollar-loss categories in the FBI IC3 annual report. The Brazilian market's reliance on boleto-based payment flows makes this specific variant a recurring target. The payment instruction arrived looking like a correction. The fraud was in the image the scanner could not read.
Verify the account details through a channel you control before replacing any payment instrument. The attacker is counting on the deadline to prevent that call.
| Attack | What happened |
|---|---|
| Final Reminder, Fake Invoice: How a Same-Day Reply-To Domain Silently Rerouted Payments Through a Compromised Sender | A message bearing a 'FINAL REMINDER' subject line claimed an unsettled invoice was one step from collections, threatening a 15 percent penalty fee. |
| No Link, No Compromised Account, No Problem: How a Personal Outlook Address Delivered a Boleto Fraud | A personal Outlook address sent a same-day-due boleto PDF to a packaging manufacturer's Brazil operation. |
| SPF PermError Turned a Malformed Domain into an Invoice Fraud Launchpad | An attacker exploited a malformed SPF record that returned PermError instead of pass or fail, paired with a same-day-registered Reply-To domain. |
| A PDF Invoice Contained Bank Details for a Money-Mule Account | An invoice email delivered through SendGrid attached a PDF with bank routing details pointing to a money-mule account. |
| The Invoice Attachment Was Empty. The Attack Was Not. | A past-due invoice email from a legitimate IT services provider passed SPF, DKIM, and DMARC via Amazon SES, carried a zero-byte PDF attachment. |