R$ 15 mil por uma senha: o que o ataque ao Pix ensina a quem trabalha com QA

Entre a madrugada de 30 de junho e o dia 1º de julho de 2025, enquanto quase todo mundo dormia, centenas de milhões de reais saíram das contas que instituições financeiras mantêm no Banco Central. O dinheiro foi transferido via Pix e espalhado por corretoras de criptomoedas em questão de horas.

Não houve invasão cinematográfica, com alguém quebrando criptografia em uma tela verde. Segundo a própria empresa atacada, os criminosos usaram credenciais legítimas. Para o sistema, aquelas transferências eram pedidos válidos, feitos por quem tinha permissão para fazê-los.

Esse detalhe muda tudo para quem trabalha com qualidade de software. Se você rodasse a suíte de testes daquele sistema na manhã seguinte, provavelmente tudo passaria. O login funcionava, as transações eram processadas, as mensagens chegavam ao destino. O sistema fez exatamente o que foi construído para fazer. O problema é que ninguém tinha perguntado com força suficiente o que ele deveria se recusar a fazer.

O que aconteceu, segundo as fontes

A empresa no centro do caso é a C&M Software, que faz a ponte tecnológica entre instituições financeiras menores e o Sistema de Pagamentos Brasileiro, incluindo o ambiente de liquidação do Pix. Quando uma fintech não tem conexão própria com essa infraestrutura, ela pode contratar uma empresa como a C&M para fazer essa ligação.

Os fatos abaixo vêm de reportagens publicadas na época e nos meses seguintes, listadas nas referências ao final:

• A C&M informou que o acesso ocorreu por meio de uma integração fraudulenta, usando credenciais legítimas de um cliente. A empresa afirmou que recursos de correntistas e dados de clientes não foram atingidos.
• O alvo foram as contas reserva, que as instituições mantêm no Banco Central para a liquidação entre bancos. O Banco Central determinou o desligamento do acesso das instituições à infraestrutura operada pela C&M.
• Seis clientes da C&M foram afetados. Só o BMP, um deles, teve mais de R$ 500 milhões desviados. Reportagens posteriores estimam o total em cerca de R$ 800 milhões.
• Em 3 de julho, a Polícia Civil de São Paulo prendeu um funcionário da área de tecnologia da C&M. Segundo a polícia, ele foi abordado na saída de um bar e vendeu seu acesso por R$ 15 mil, pagos em duas parcelas. O delegado responsável definiu as credenciais entregues como "a primeira porta" que facilitou a entrada do grupo.
• Dias depois, o Banco Central autorizou a C&M a voltar a operar em regime de produção controlada, com horário restrito, reforço no monitoramento de fraudes e limites transacionais.
• Em março de 2026, segundo o diretor-geral da Polícia Federal, 25 pessoas tinham sido presas e mais de R$ 500 milhões recuperados. A investigação continua.

Vale guardar dois números: o acesso foi vendido por R$ 15 mil e permitiu movimentar centenas de milhões. A diferença entre um valor e outro é o tamanho do estrago que um único acesso conseguia causar. E é nessa diferença que o trabalho de qualidade pode fazer diferença.

"Mas isso é problema do time de segurança"

É a reação mais comum, e ela é compreensível. QA não faz teste de invasão, não configura firewall e não investiga funcionário que vende senha. Nada disso muda. Ninguém está sugerindo que o QA vire especialista em segurança ofensiva.

O ponto é outro. A norma ISO/IEC 25010, uma das referências mais usadas para definir qualidade de software, lista a segurança como uma das características de qualidade de um produto, ao lado de adequação funcional, desempenho e confiabilidade. Se segurança faz parte da definição de qualidade, ela também faz parte da conversa de quem cuida da qualidade.

Pense no caso da C&M. Nenhuma revisão de código pegaria um funcionário sendo abordado em um bar. Mas a pergunta "o que acontece se uma credencial válida cair na mão errada?" pode ser feita em qualquer refinamento, por qualquer pessoa do time. E quem passa o dia pensando em como as coisas podem dar errado costuma ser o QA.

Existe uma diferença importante entre implementar um controle de segurança e perceber que ele está faltando. A primeira tarefa pode ser do time de segurança ou dos desenvolvedores. A segunda é de todo mundo, e o QA está numa posição privilegiada para isso, porque já lê critérios de aceite, conhece os fluxos de ponta a ponta e tem o hábito de perguntar "e se?".

Onde o estrago cresceu

Uma credencial vazada é um incidente. Centenas de milhões transferidos em poucas horas, de madrugada, é outra escala de problema. Entre um e outro existe uma série de perguntas que poderiam ter virado requisitos testáveis:

• Qual é o valor máximo que uma única credencial consegue movimentar em uma hora?
• O sistema se comporta da mesma forma às 4h da manhã e às 14h?
• Quantas transferências seguidas para destinos novos são consideradas normais antes de alguém ser avisado?
• Quem recebe o alerta, em quanto tempo, e o que essa pessoa consegue fazer para interromper a operação?
• Uma credencial criada para um cliente consegue agir em nome de outro?

Repare na resposta do Banco Central depois do ataque: produção controlada, horário restrito, monitoramento de fraudes e limites por transação. Meses depois, o regulador endureceu as regras para empresas que fazem esse tipo de intermediação, incluindo um limite de R$ 15 mil para transações Pix e TED feitas por instituições conectadas por meio desses provedores. Todas essas medidas são requisitos que podem ser escritos, testados e verificados. Nenhuma delas exige quebrar criptografia. Exigem que alguém tenha feito a pergunta antes.

O guia de segurança de APIs da OWASP, referência mundial no assunto, tem uma categoria inteira para isso: acesso irrestrito a fluxos de negócio sensíveis. O texto explica que esse tipo de fraqueza nem sempre é um erro de código. Muitas vezes, o sistema funciona perfeitamente e simplesmente não tem nenhuma proteção contra uso em excesso de uma funcionalidade que pode prejudicar o negócio. É um problema de requisito, e requisito é território do QA.

O papel do QA em cada momento do time

O QA não precisa esperar um projeto de segurança para contribuir. Os rituais que já existem no dia a dia são suficientes.

No refinamento

É o momento mais barato para levantar um risco. Quando uma história envolve dinheiro, dados pessoais ou permissões, inclua cenários de abuso ao lado dos cenários de uso. Em vez de só perguntar "o usuário consegue transferir?", pergunte também "o que impede alguém de transferir tudo?". Se a resposta for "nada", isso precisa virar um critério de aceite ou, no mínimo, uma decisão registrada de quem aceitou o risco.

No planejamento de testes

Para cada funcionalidade sensível, escreva pelo menos um teste negativo de autorização e um de limite. Uma credencial de leitura tenta escrever. Um usuário do cliente A tenta acessar dados do cliente B. Uma sequência de operações passa do limite esperado. Esses testes não exigem ferramenta de segurança. Exigem intenção.

Na daily

Se durante os testes você percebeu algo estranho, como um endpoint que aceita mais do que deveria ou um erro que expõe detalhes internos, fale na daily. Não precisa ter certeza de que é uma vulnerabilidade. Basta dizer "encontrei um comportamento que me preocupa, quero alinhar com alguém depois". Um alerta curto no momento certo vale mais do que um relatório perfeito tarde demais.

Na revisão de código e de pull requests

Mesmo sem ser especialista em segurança, dá para notar sinais simples: uma checagem de permissão que existe em uma rota e falta em outra parecida, um valor configurável sem limite máximo, um erro capturado e ignorado sem nenhum registro. Comentar "essa rota não tem a mesma validação da rota X, é intencional?" já é uma contribuição valiosa.

Nos testes exploratórios

Reserve parte do tempo para pensar como alguém mal-intencionado com acesso legítimo. Não alguém de fora tentando invadir, e sim alguém de dentro, com login válido, tentando fazer mais do que deveria. O caso da C&M mostra que esse é um cenário real.

Na retrospectiva e depois de incidentes

Quando algo dá errado, o QA pode ajudar a transformar a lição em teste. Toda falha relevante deveria gerar ao menos um caso de regressão, inclusive as falhas de segurança. Se o time não registrar, o mesmo buraco pode voltar na próxima refatoração.

Perguntas que todo QA deveria levar para o time

Guarde esta lista. Ela cabe em qualquer refinamento de funcionalidade que envolva dinheiro, dados ou permissões:

1. Quem pode fazer isso? E quem definitivamente não pode?
2. Quanto pode ser feito? Existe limite por operação, por hora, por dia?
3. Quando pode ser feito? Operações fora do horário comercial têm alguma regra diferente?
4. O que é comportamento fora do padrão? E o sistema consegue perceber quando isso acontece?
5. Quem fica sabendo? Existe alerta, para quem vai e em quanto tempo?
6. Como se interrompe? Existe uma forma rápida de bloquear uma credencial ou uma integração?
7. O que fica registrado? Se algo der errado, conseguimos reconstruir quem fez o quê?

Nenhuma dessas perguntas exige conhecimento avançado de segurança. Todas elas geram critérios de aceite que podem ser testados.

Como dar o alerta sem virar "o chato do time"

Muita gente deixa de levantar um risco por medo de parecer alarmista ou de invadir o espaço de outro time. Algumas práticas ajudam a ser ouvido:

• Descreva um cenário, não uma opinião. "Isso parece inseguro" gera discussão. "Um usuário com credencial válida consegue transferir sem limite às 3h da manhã sem disparar nenhum alerta" gera ação.
• Mostre o impacto. Dinheiro, dados expostos, multa, imagem da empresa. O caso da C&M é um bom exemplo para mostrar que esse risco não é teórico.
• Traga uma sugestão, mesmo simples. Um limite, um alerta, uma confirmação extra. Quem decide a solução final pode ser outra pessoa, mas uma sugestão concreta facilita a conversa.
• Registre. Abra um ticket, deixe um comentário na história, anote na ata. Se o time decidir aceitar o risco, que seja uma decisão consciente e documentada.
• Envolva quem entende do assunto. Se a empresa tem um time de segurança, leve o achado até ele. O seu papel é perceber e comunicar. A análise aprofundada pode ficar com quem é especialista.

E um cuidado importante: nunca teste uma suspeita de vulnerabilidade em produção nem tente explorá-la para provar que ela existe. Comunique pelos canais certos e use ambientes autorizados.

O que não é papel do QA

Para ser justo, é bom deixar claro o limite dessa responsabilidade. O QA não é responsável por evitar que um funcionário seja aliciado. Não responde pela política de senhas da empresa, pela segregação de redes ou pela investigação de incidentes. Não precisa saber fazer teste de invasão.

O que o QA pode fazer é garantir que as perguntas certas apareçam cedo, que os controles virem requisitos e que esses requisitos sejam testados como qualquer outra funcionalidade. Em um time maduro, segurança é responsabilidade compartilhada. O QA não substitui o especialista, mas pode ser a pessoa que acende a luz amarela antes que a vermelha seja necessária.

Conclusão

O ataque à C&M começou com uma senha vendida por R$ 15 mil. Essa parte, nenhum QA teria impedido. Mas o tamanho do estrago dependeu de outras perguntas: quanto uma credencial podia movimentar, em que horário, sem que ninguém fosse avisado. Essas perguntas cabem em um refinamento comum, numa terça-feira qualquer.

Testar se o sistema faz o que deveria continua sendo o centro do nosso trabalho. Mas, em sistemas que movimentam dinheiro, testar o que ele deveria se recusar a fazer é igualmente importante. Um QA que entende isso deixa de ser a última barreira antes da produção e passa a ser uma das primeiras vozes a apontar o risco.

No seu time, alguém já perguntou quanto uma única credencial consegue movimentar antes de alguém perceber?

Referências

1. Poder360. Empresa de serviços financeiros é alvo de ataque hacker. 2 de julho de 2025.
2. Diário de Pernambuco. Ataque hacker não envolveu extração de dados de clientes, diz C&M Software. 3 de julho de 2025.
3. Gazeta do Povo. Reportagem sobre a prisão do técnico que vendeu o acesso. Julho de 2025.
4. Baguete. Funcionário da C&M vendeu senha por R$ 15 mil. Julho de 2025.
5. Finsiders Brasil. Reportagem sobre o que mudou um ano depois do ataque à C&M Software. 2026.
6. OWASP. OWASP API Security Top 10, edição 2023 (categorias API5:2023 e API6:2023).
7. Sonar. Understanding the ISO/IEC 25010: framework for software quality (resumo da norma ISO/IEC 25010:2023).