R$1.5 Billion in 12 Months: What the Pix Settlement Attacks Reveal About Where Security Fails

Someone bribed a junior developer at a Brazilian payment technology provider for R$5,000. Five thousand reais. That's roughly a thousand US dollars. A month later, attackers used the access he gave them to forge payment orders that moved R$800 million out of the Central Bank's settlement infrastructure in a single night.

That was June 2025. Since then, three more attacks have followed the same basic playbook. Sinqia in August, R$710 million. Banco do Nordeste in January 2026. BTG Pactual in March 2026, roughly R$100 million from the largest investment bank in Latin America. Over R$1.5 billion diverted from Brazil's instant payment system in under a year.

I've been watching this unfold because the kill chain is uncomfortably familiar. And honestly, because it's a near-perfect case study of why the security model most organizations rely on doesn't work the way we assume it does.

What's actually happening

Brazil's Pix system settles payments in under three seconds through the SPI, a real-time gross settlement engine operated by the Central Bank. Every participating institution maintains a reserve account, and every transaction is authenticated using X.509 digital certificates and signed ISO 20022 messages transmitted over a private network called the RSFN.

Here's the thing. A lot of smaller banks don't connect directly. They use third-party technology providers called PSTIs. And those PSTIs held the private keys and digital certificates for hundreds of client institutions on shared infrastructure. One provider, one set of keys for 300 banks.

In the C&M Software attack, the bribed developer ran commands on internal infrastructure to give attackers persistent remote access. They spent a month mapping the system, extracted cryptographic certificates belonging to C&M's client institutions, and on a Sunday night at 12:18 AM started generating forged payment orders. The SPI validated them because the signatures were real.

The first people to notice were cryptocurrency exchanges flagging unusual Pix purchase volumes at midnight. Not the bank. Not the PSTI. Not the Central Bank's monitoring.

Every one of these four attacks was executed during off-hours, when staffing is minimal and the reserve transfer system that would let institutions replenish their accounts is closed until Monday morning. C&M also suffered a secondary breach by the DragonForce ransomware group in November 2025 that exfiltrated 393 GB of data, raising serious questions about their post-incident remediation.

Why detection didn't help

I spent about a decade building detection content. ESCU rules at Splunk, threat research, the whole stack. I believed in it deeply. So when I say this isn't a criticism from the outside, I mean it.

The core problem is that every one of these incidents involved valid credentials, a classic credential-based attack pattern. The certificates the attackers extracted were real. The ISO 20022 messages they generated were properly formatted and cryptographically signed. There is no detection signature for a legitimate credential doing legitimate-looking things through a legitimate protocol, especially in malware-free attacks like these.

Brazil deployed DetectaFlow, built by Nuclea, specifically to catch Pix fraud. But DetectaFlow is fundamentally a recovery tool with a 32% recovery rate and an average ticket of R$19,000. It's not built to handle R$800 million in forged settlement messages executed at midnight. The Central Bank's own monitoring caught the BTG anomaly at around 6:00 AM, after significant funds had already been dispersed across accounts at seven major banks and partially converted to cryptocurrency. When your settlement system processes transfers in under ten seconds and your detection operates on a timescale of hours, you're in a race you can't win.

Where the chain actually breaks

Every one of these attacks followed the same phases. Valid credentials got the attackers in the door, but between "attacker has a login" and "attacker moves R$800 million," there's an entire preparation chain that requires executing unauthorized software on critical infrastructure. That's the gap where prevention lives.

Phase 1: Persistence and defense evasion.

At C&M, the insider deployed what was almost certainly an unauthorized RMM tool or reverse shell. We track over 930 RMM tools in LOLRMM right now. Attackers who plan to operate for weeks also need to blind the defenders, which means deploying EDR killers or loading vulnerable kernel drivers to disable security tooling. Between LOLDrivers and the Microsoft Vulnerable Driver Block List, that's over 2,300 known-exploitable drivers blocked before they load into the kernel.

Phase 2: Certificate and credential theft.

Getting private keys off infrastructure requires tooling. Certutil abuse, PowerShell export cmdlets, NirSoft utilities for credential harvesting, Sysinternals tools like ProcDump. These are well-documented LOLBAS techniques. But the attacker's extraction tooling was almost certainly signed too, and this is where our certificate intelligence becomes critical.
We aggregate three feeds of known-bad code signing certificates: Actively Exploited Signers (~485 certs observed in active attack campaigns), Cert Graveyard (~925 certs documented by @SquiblydooBlog that were sold to criminals for signing malware), and MalwareBazaar's code signing blocklist (~360 entries). That's roughly 1,770 known-bad signing certificates evaluated against every binary that tries to execute. Traditional allowlisting checks whether something is signed. Threat-driven application control checks whether the certificate itself has been observed in malicious campaigns. If you want to understand why this matters, Squiblydoo's research on impostor certificates and certificates being reused across malware families is essential reading.

Phase 3: Execution and exfiltration.

The attackers ran custom scripts to forge hundreds of payment messages and inject them into the settlement network. They staged data, moved certificates between systems, and rapidly exfiltrated funds. LOLExfil (maintained by @mthcht) tracks about 188 legitimate tools attackers abuse for data staging, and Microsoft's own recommended application control block rules add another 665 entries for known bypass applications. ExtSentry (also by mthcht) adds coverage for over 3,500 malicious browser extensions, relevant because many PSTIs operate web-based management portals where browser-based credential theft is a viable initial access vector.

On infrastructure protected by default-deny application control, none of this executes. It doesn't matter that the attacker has admin credentials. If the binary isn't on the allowlist, it doesn't run.

Across all 15 of our intelligence feeds, we're evaluating every execution attempt against roughly 10,600 known-bad indicators. The combination is what makes the policy threat-driven rather than just a static allowlist someone set up two years ago and forgot about.

The regulatory context

The BCB has moved fast. Resolucao 541, effective March 1, 2026, mandated multi-factor authentication for administrative access, physical and logical isolation of Pix environments, and end-to-end transaction integrity validation. Resolucao 498 imposed R$15 million minimum capital requirements on PSTIs (previously zero) and mandated cybersecurity insurance.

The BTG Pactual attack happened three weeks later.

When the regulation calls for "physical and logical isolation of Pix environments," application control is arguably the most direct technical implementation at the endpoint level. You're defining exactly what software is authorized to execute within the settlement environment, and everything else is denied by default. That's what isolation means in practice.

Application control won't help if an attacker can submit forged payment orders from an already-authorized system using already-authorized software. That's a protocol-level validation problem the BCB needs to solve at the SPI layer. But it eliminates the entire preparation phase. The persistence, the EDR blinding, the certificate theft, the script execution. All of that requires running unauthorized software on critical infrastructure, and all of it is preventable today.

That's really what this comes down to. Not better alerts. Not a faster response. Preventing the execution in the first place. That’s the shift from detection to prevention-focused endpoint security.

Want to keep up with how modern attacks actually work? Subscribe to the MagicSword newsletter for practical research, real-world attack tradecraft, and prevention-focused intelligence from the team tracking abused tools every day.

If you want to see how this intelligence turns into real blocking, stopping abused tools before they execute, you can book a demo here.