Hundreds of fraudulent Pix transactions, and nothing was forged. The only sum Google names is tens of thousands.
The attacker never steals the signing key. They reach the application that asks the hardware module to sign, and ask it to sign something else.
By Parminder Kumar Sharma · · 8 min read
Start with what the number actually is
Google Threat Intelligence published on Breeze Comet, formerly UNC5669, on 1 September 2026. The headline everywhere is hundreds of fraudulent transactions. Here is the sentence it comes from:
"Within 24-48 hours of establishing this access, the threat actor executed two waves of hundreds of fraudulent transactions, based on reporting by a client and third party forensic analysis."
Two things follow. The count is not Google’s. It is a victim’s figure, relayed through a third-party forensics firm. No exact number, no date, no named institution.
And there is only one money figure in the entire report. It sits in a different section, and Google never connects the two:
"Since 2024, BREEZE COMET has steadily increased the complexity and effectiveness of their operations manipulating Brazilian financial systems and software, and has successfully executed at least one heist of tens of thousands of USD in assets."
One further correction. At least one outlet states that Google and Mandiant attribute this "with high confidence". The word "confidence" does not appear in Google’s report at all. What Google says is that the activity "overlaps with operations publicly reported as Plump Spider and SHADOW-AETHER-064", which is a cluster-overlap observation, not an attribution.
What actually happened, and why it worked
The mechanism is the reason this is worth your time, and it is not in Google’s report. Google lists the prerequisites but never describes the technique. The clearest account comes from Axur, writing on the overlapping Plump Spider cluster:
"the final step is manipulating the application to generate the XML pacs.008 with fraud data and then abusing the interaction with the Hardware Security Module (HSM). The attacker doesn't need to steal the private key, but only force the legitimate application to use the key to sign the malicious payment order."
Nothing was forged, which is why it settled
That is the whole thing. The certificate belongs to the institution. The signature is valid. The mutual TLS connection is authorised. Every cryptographic property the payment system can check is genuinely true.
The only false thing is the intent, and no payment rail validates intent. Settlement on an instant rail is immediate, so there is no window in which anyone notices before the money is gone.
Where in the chain, precisely
Google names the prerequisites and they are worth reading as a target profile rather than a description of one victim: access to the national financial system network through an entity that has it, mutual TLS credentials allowing authenticated transactional payloads, persistent access to multiple directory or cloud accounts, and an understanding of the organisation’s transfer procedures and anti-fraud systems.
Reconnaissance searched for the credential material by name, with terms including boleto, cnab, remessa, webhook.*pix and instant.*payment, and mined CI/CD pipelines for hard-coded credentials and cloud tokens.
Note what is not claimed. Google names Pix, STR and Boleto as a target class and never says which rail the fraudulent transactions actually used. It never names the victim or even the victim type. "Brazilian payment systems" in the headline is doing a lot of unspecified work.
This is the third one, and none of them broke Pix
Three Brazilian payment incidents, and where each one actually got in
| When | Who | Route in | Reported value |
|---|---|---|---|
| Jun to Jul 2025 | C&M Software, a technology provider | An employee sold his credentials for about $2,700 after being approached in a bar | Over R$540m, with R$270m frozen |
| 29 Aug 2025 | Sinqia, owned by Evertec | Legitimate IT vendor credentials, per Evertec’s own 8-K | R$710m, about £101m |
| 2024 onwards | Breeze Comet target | Vishing, remote tools, rogue hardware, stolen mTLS material | Tens of thousands of USD, per Google |
Evertec’s filing is unusually direct about the route: "the unauthorized transactions were introduced into Sinqia’s Pix environment by exploiting legitimate Sinqia IT vendors’ credentials." Its later annual report confirms the affected customers "successfully recovered significant portions" of the amounts.
Not one of the three broke Pix, and not one touched the Central Bank. Each compromised a participant, or a participant’s supplier, and then used that participant’s legitimate authority.
Brazil regulated the supplier tier, not the rail
This is the part a UK reader should take seriously, because it is a regulator responding to exactly this pattern. From the Banco Central do Brasil’s own Pix management report:
Since September 2025, Pix participants not authorised by the Central Bank, or that connect to the national financial system network through a technology service provider, are limited to R$15,000 per transaction, and transactions above that are rejected automatically by the instant payment system.
About £2,100. Alongside it: cautionary blocking extended to corporate users, key data withheld from fraud-marked users, monitoring and manual blocking tools for direct participants, and a minimum capital requirement to participate.
The regulator did not change the rail. It constrained the tier of suppliers sitting behind the institutions connected to it.
The UK parallel, and the one that does not work
The parallel that does hold is the supplier one. The UK stood up a critical third parties regime under FCA PS24/16 and Bank of England PS16/24, in force since 1 January 2025, under which HM Treasury designates critical suppliers and the regulators oversee the services they provide to the sector, including major incident reporting. The Bank and FCA said in July 2026 they would begin overseeing the first designated firms.
So both jurisdictions have concluded, within roughly a year of each other, that the security perimeter of an instant payment system is the whole participant population plus its suppliers. Brazil reached that conclusion after three incidents. The UK has reached it in advance, and has only just begun designating.
Be honest about the strength of that comparison. It is architectural, not evidenced by matching events. There is no UK incident comparable to C&M or Sinqia, and no evidence Faster Payments has suffered a participant signing compromise.
What to do
Take this with you
If you run, supply, or depend on payment infrastructure
- Monitor signing requests, not just signing keys. The key was never stolen in any of these cases. What was abused was the authority to ask for a signature, so the control that matters is anomaly detection on what the HSM is being asked to sign and by which service.
- Treat the payment gateway as Tier 0. The application that assembles and signs payment orders is more sensitive than the key store it calls, because it is what decides what gets signed.
- Audit mutual TLS certificate custody. Google’s actor searched specifically for this material. Know where every client certificate lives, which service uses it, and what would happen if a build agent could read it.
- Check CI/CD for hard-coded credentials and cloud tokens. That is where the reconnaissance went, in this case and in Sinqia’s.
- If you are a supplier to a regulated firm, assume the perimeter now includes you. The UK critical third parties regime has been in force since January 2025 and designations began this July.
- Ask your payment provider which of their suppliers can reach their signing environment. In two of the three Brazilian cases, that answer was the whole story.
The position
There is no CVE here. Verified against the CISA Known Exploited Vulnerabilities catalogue, version 2026.08.31: nothing matches, and Google names no vulnerability beyond a reference to JBoss servers being exploited for initial access, itself without a CVE.
The uncomfortable conclusion is structural rather than technical. An instant payment rail can verify that a message came from an authorised institution and was not altered in transit. It cannot verify that the institution meant to send it. Once settlement is instantaneous and irreversible, that gap is not recoverable by process.
Which means the security of the rail is the security of everyone connected to it, and of everyone who writes software for them. Brazil worked that out across three incidents and roughly R$1.25bn of attempted fraud, and responded by capping the tier it could not otherwise assure. The UK has drawn the same conclusion on paper and has not yet been tested on it.
