The Boleto-Swap Scam Behind a Familiar Vendor Name

An accounts-payable inbox at a Brazilian agribusiness and chemicals manufacturer received a short, businesslike message from what looked like the accounting department of a packaging supplier the company had been buying from. The note carried a familiar tone and a simple instruction: disregard the payment slip sent earlier, and use the updated one attached instead. The amount had changed. In Brazil, where the boleto bancario is the default way to settle a large share of business invoices, that instruction reads as deceptively ordinary. It is also the entire mechanism of a troca de boleto, or boleto-swap, scam.

A Payment Slip You Are Told to Replace

The boleto is a standardized payment document. It carries a barcode, a numeric line, a beneficiary, and an amount, and a payer settles it through a bank or app. Because vendors reissue them routinely for corrections, extensions, or clerical fixes, a "please use this corrected slip" email rarely raises an eyebrow inside a finance team. That routine is exactly what the attacker rented.

The message impersonated the vendor's accounting desk and told the recipient not to use the prior payment slip. It referenced a replacement slip as an attachment and, critically, a different payment amount than the one already in flight. The attached file itself could not be inspected. Its metadata showed a zero-byte, unretrievable object, so the slip document never resolved. But the swap did not depend on the file rendering. The body-level mechanics were the payload: an explicit instruction to discard the earlier boleto, paired with a changed figure. If the recipient had complied, payment would have flowed to the attacker's beneficiary rather than the real supplier, and the genuine invoice would still have been sitting open.

This is a payment-redirection variant of business email compromise, and it is one of the most expensive categories of email fraud in the world. The 2023 FBI IC3 Internet Crime Report attributed roughly 2.9 billion dollars in losses to BEC. Boleto swaps localize that playbook for a market where the corrected-slip motion is a normal part of doing business.

Perfect Authentication, Fake Identity

Here is the part that trips up gateway-era thinking. The email sailed through authentication. SPF passed, DKIM passed, and DMARC passed with an aligned header-from of gmail[.]com and a composite authentication result of reason 100. Nothing was spoofed at the protocol level, because nothing needed to be. The message genuinely originated from a free Gmail account, and Gmail's own infrastructure signed and aligned it correctly.

Authentication answers one narrow question: did this message really come from the address it claims? The answer here was yes. What authentication cannot answer is whether the display name honestly represents the party it names. The sending address was emon528626[@]gmail[.]com. The display name it wore read like the vendor's accounting department. A finance clerk skimming a crowded inbox sees the friendly name, not the raw address, so the impersonation lived entirely in the identity layer that SPF, DKIM, and DMARC do not evaluate.

The real supplier, for its part, does not send invoices from Gmail. The impersonated vendor's genuine corporate domains publish proper MX, SPF, and DKIM records and route mail through corporate infrastructure. A free consumer mailbox claiming to be that vendor's accounting desk was already out of character. The 2024 Verizon Data Breach Investigations Report names pretexting, the category that includes most BEC, as the leading social-engineering pattern, with a median transaction of roughly 50,000 dollars. These attacks succeed precisely because they carry no malware and no broken authentication to trip an inspection engine.

The One Thing That Did Not Match

Because every technical check was clean and the body carried no malicious link or executable, the only lever left was behavioral. The signal came from relationship history. The platform's sender fingerprint for this correspondence had previously logged the same vendor accounting display name arriving from a different Gmail address. Same friendly name, different mailbox, no prior legitimate use of that new address for this vendor relationship.

That single inconsistency is invisible to any check that looks only at the message in isolation. Content scanning sees a polite invoice note. Authentication sees a valid Gmail send. Only a system that models how each vendor identity normally reaches the organization can notice that a known display name has quietly changed its origin. That is the kind of pattern our Adaptive AI is built to surface, catching the impersonation on identity drift rather than on a payload that was never there.

Why Boleto Swaps Keep Working

Boleto swaps thrive on process, not technology. The correction is expected. The vendor is trusted. The amount change looks like a clerical fix rather than a heist. Attackers do not need to breach a mailbox or register a look-alike domain when a free Gmail account and a borrowed display name will clear authentication and reach a busy finance team. The zero-cost infrastructure is a feature: there is no attacker domain to blocklist and no signature to detonate.

The durable defense is a mix of process and detection. Treat any change to payment details, whether a new boleto, a new bank account, or a "corrected" invoice, as an event requiring out-of-band verification through a phone number already on file, never a number or reply address supplied in the suspect message. Pair that discipline with email security that understands each vendor's normal sending identity. If your team wants to see that identity-history modeling against your own vendor traffic, you can start a trial and watch how it treats a familiar name arriving from an unfamiliar place.

Indicators of Compromise

MITRE ATT&CK Mapping

• T1585.002 (Establish Accounts: Email Accounts): the attacker stood up a free webmail account to impersonate a known vendor identity.
• T1657 (Financial Theft): the objective was direct payment redirection through a swapped boleto.
• T1566 (Phishing): social-engineering delivery via a trusted-looking vendor message.

See You Next Time

Authentication tells you a message is who it says it is. It does not tell you the name on the envelope is honest. When a known vendor identity shows up from a place you have never seen it use, that is worth a phone call before it is worth a payment.