A password sold for R$ 15,000: what the Pix attack teaches QA engineers

Between the early hours of June 30 and July 1, 2025, while most of Brazil was asleep, hundreds of millions of reais left the accounts that financial institutions hold at the country's Central Bank. The money was moved through Pix, Brazil's instant payment system, and scattered across cryptocurrency exchanges within hours.

There was no movie style hacking scene, no one breaking encryption on a green terminal. According to the company that was attacked, the criminals used legitimate credentials. As far as the system was concerned, those transfers were valid requests made by someone who had permission to make them.

That detail changes everything for people who work in software quality. If you had run that system's test suite the next morning, it would probably have passed. Login worked, transactions were processed, messages reached their destination. The system did exactly what it was built to do. The problem is that nobody had pushed hard enough on the question of what it should refuse to do.

What happened, according to the sources

The company at the center of the case is C&M Software, which provides the technical bridge between smaller financial institutions and the Brazilian Payment System, including the Pix settlement environment. When a fintech has no direct connection to that infrastructure, it can hire a company like C&M to provide it.

The facts below come from reports published at the time and in the following months, listed in the references at the end:

• C&M said the access happened through a fraudulent integration using a client's legitimate credentials. The company stated that account holders' funds and customer data were not affected.
• The target was the reserve accounts that institutions keep at the Central Bank for interbank settlement. The Central Bank ordered institutions' access to the infrastructure operated by C&M to be shut off.
• Six C&M clients were affected. One of them alone, BMP, had more than R$ 500 million diverted. Later reports put the total at around R$ 800 million.
• On July 3, São Paulo's Civil Police arrested a C&M technology employee. According to the police, he was approached outside a bar and sold his access for R$ 15,000, paid in two installments. The detective in charge described the credentials he handed over as "the first door" that let the group in.
• Days later, the Central Bank allowed C&M to resume operations under controlled production, with restricted hours, stronger fraud monitoring and transaction limits.
• In March 2026, according to the head of Brazil's Federal Police, 25 people had been arrested and more than R$ 500 million recovered. The investigation is still ongoing.

Keep two numbers in mind: the access was sold for R$ 15,000 and was used to move hundreds of millions. The gap between those numbers is the amount of damage a single access could cause. And that gap is where quality work can make a difference.

"But that's the security team's problem"

It is the most common reaction, and it is understandable. QA does not run penetration tests, configure firewalls or investigate employees who sell passwords. None of that changes. Nobody is suggesting QA engineers should become offensive security experts.

The point is a different one. ISO/IEC 25010, one of the most widely used references for defining software quality, lists security as one of a product's quality characteristics, alongside functional suitability, performance and reliability. If security is part of the definition of quality, it is also part of the conversation for the people responsible for quality.

Think about the C&M case. No code review would have caught an employee being approached in a bar. But the question "what happens if a valid credential falls into the wrong hands?" can be asked in any refinement session, by anyone on the team. And the person who spends the day thinking about how things can go wrong is usually the QA engineer.

There is an important difference between implementing a security control and noticing that it is missing. The first task may belong to the security team or the developers. The second belongs to everyone, and QA is in a privileged position to do it, because QA engineers already read acceptance criteria, know the flows end to end and are used to asking "what if?".

Where the damage grew

A leaked credential is an incident. Hundreds of millions transferred in a few hours, in the middle of the night, is a problem of a different scale. Between the two lies a series of questions that could have become testable requirements:

• What is the maximum amount a single credential can move in one hour?
• Does the system behave the same way at 4 a.m. as it does at 2 p.m.?
• How many consecutive transfers to new destinations count as normal before someone is notified?
• Who receives the alert, how quickly, and what can that person do to stop the operation?
• Can a credential created for one client act on behalf of another?

Look at how the Central Bank responded after the attack: controlled production, restricted hours, fraud monitoring and transaction limits. Months later, the regulator tightened the rules for companies that provide this kind of connection, including a R$ 15,000 limit on Pix and TED transfers made by institutions connected through these providers. Every one of these measures is a requirement that can be written down, tested and verified. None of them requires breaking encryption. They require someone to have asked the question first.

The OWASP API Security Top 10, a global reference on the subject, has an entire category for this: unrestricted access to sensitive business flows. It explains that this kind of weakness is not always a coding bug. Often the system works perfectly and simply has no protection against excessive use of a feature that can hurt the business. That makes it a requirements problem, and requirements are QA territory.

The QA engineer's role at every stage

QA engineers do not need to wait for a security project to contribute. The rituals the team already has are enough.

In refinement

This is the cheapest moment to raise a risk. When a story involves money, personal data or permissions, add abuse scenarios next to the usage scenarios. Instead of only asking "can the user make a transfer?", also ask "what stops someone from transferring everything?". If the answer is "nothing", that needs to become an acceptance criterion or, at the very least, a recorded decision by whoever accepted the risk.

In test planning

For every sensitive feature, write at least one negative authorization test and one limit test. A read only credential tries to write. A user from client A tries to access client B's data. A sequence of operations goes beyond the expected limit. These tests do not require security tooling. They require intent.

In the daily stand-up

If you noticed something odd while testing, like an endpoint that accepts more than it should or an error message that exposes internal details, bring it up in the daily. You do not need to be sure it is a vulnerability. It is enough to say "I found a behavior that worries me, I would like to go over it with someone afterwards". A short warning at the right moment is worth more than a perfect report delivered too late.

In code reviews and pull requests

Even without being a security specialist, you can spot simple signals: a permission check that exists on one route and is missing on a similar one, a configurable value with no upper limit, an error that is caught and silently ignored. A comment like "this route doesn't have the same validation as route X, is that intentional?" is already a valuable contribution.

In exploratory testing

Set aside part of your time to think like someone with bad intentions and legitimate access. Not an outsider trying to break in, but an insider with a valid login trying to do more than they should. The C&M case shows this is a real scenario.

In retrospectives and after incidents

When something goes wrong, QA can help turn the lesson into a test. Every relevant failure should produce at least one regression case, security failures included. If the team does not record it, the same hole can come back in the next refactor.

Questions every QA engineer should bring to the team

Keep this list. It fits into the refinement of any feature that involves money, data or permissions:

1. Who can do this? And who definitely cannot?
2. How much can be done? Is there a limit per operation, per hour, per day?
3. When can it be done? Do operations outside business hours follow any different rule?
4. What counts as unusual behavior? And can the system tell when it happens?
5. Who finds out? Is there an alert, who receives it and how fast?
6. How do we stop it? Is there a quick way to block a credential or an integration?
7. What gets logged? If something goes wrong, can we reconstruct who did what?

None of these questions requires advanced security knowledge. All of them produce acceptance criteria that can be tested.

How to raise the alarm without becoming "the annoying one"

Many people hold back from raising a risk because they are afraid of sounding alarmist or stepping on another team's toes. A few practices help you get heard:

• Describe a scenario, not an opinion. "This looks insecure" starts a debate. "A user with a valid credential can transfer without any limit at 3 a.m. without triggering a single alert" starts action.
• Show the impact. Money, exposed data, fines, the company's reputation. The C&M case is a good example to show that this risk is not theoretical.
• Bring a suggestion, even a simple one. A limit, an alert, an extra confirmation step. Someone else may decide on the final solution, but a concrete suggestion makes the conversation easier.
• Write it down. Open a ticket, leave a comment on the story, add it to the meeting notes. If the team decides to accept the risk, let it be a conscious, documented decision.
• Bring in the people who know the subject. If the company has a security team, take your finding to them. Your role is to notice and communicate. The deep analysis can stay with the specialists.

One important caution: never test a suspected vulnerability in production or try to exploit it to prove it exists. Report it through the proper channels and use authorized environments.

What is not QA's job

To be fair, the limits of this responsibility should be clear. QA is not responsible for preventing an employee from being bribed. QA does not own the company's password policy, network segmentation or incident investigation. QA engineers do not need to know how to run penetration tests.

What QA can do is make sure the right questions come up early, that controls become requirements and that those requirements are tested like any other feature. In a mature team, security is a shared responsibility. QA does not replace the specialist, but it can be the one who turns on the yellow light before the red one is needed.

Conclusion

The attack on C&M started with a password sold for R$ 15,000. No QA engineer would have prevented that part. But the size of the damage depended on other questions: how much a credential could move, at what time, without anyone being notified. Those questions fit into an ordinary refinement session on any given Tuesday.

Testing that the system does what it should is still the core of our work. But in systems that move money, testing what it should refuse to do matters just as much. A QA engineer who understands that stops being the last barrier before production and becomes one of the first voices to point out the risk.

On your team, has anyone asked how much a single credential can move before someone notices?

References

The news sources below are in Portuguese.

1. Poder360. Financial services company targeted by hacker attack. July 2, 2025.
2. Diário de Pernambuco. Hacker attack did not involve extraction of customer data, says C&M Software. July 3, 2025.
3. Gazeta do Povo. Report on the arrest of the technician who sold the access. July 2025.
4. Baguete. C&M employee sold password for R$ 15,000. July 2025.
5. Finsiders Brasil. Report on what changed one year after the attack on C&M Software. 2026.
6. OWASP. OWASP API Security Top 10, 2023 edition (categories API5:2023 and API6:2023).
7. Sonar. Understanding the ISO/IEC 25010: framework for software quality (overview of ISO/IEC 25010:2023).