Quando um trojan bancário decide estudar Febraban, o problema deixou de ser só da TI.
Enquanto boa parte do mercado discute APIs, Open Finance e Pix Automático, um pedaço silencioso da rotina financeira brasileira continua rodando em arquivos .REM e .RET — o bom e velho CNAB 240/400. E foi exatamente aí que um malware chamado #CNABHunter resolveu morar.
A peça foi identificada por pesquisadores e chamou atenção por um detalhe pouco usual: antes de roubar qualquer coisa, ela precisou entender o que é um layout posicional bancário. É raro ver um trojan estudando manual da Febraban — mas aqui estamos.
O que é o CNABHunter
Diferente dos banking trojans clássicos, que dependem de overlay de tela ou captura de credenciais em internet banking, o CNABHunter vai direto à fonte do pagamento: o arquivo de remessa.
Em vez de tentar enganar o usuário no momento da transação, ele monitora diretórios onde arquivos CNAB 240 e CNAB 400 são gerados, salvos ou movidos. Ao encontrar um arquivo válido, faz o que qualquer fraudador faria com tempo livre e conhecimento de layout: substitui dados bancários do favorecido (banco, agência, conta, dígito) por contas controladas pelo atacante, mantendo a integridade estrutural do arquivo para não levantar suspeita no envio.
Em termos práticos, o arquivo continua “válido” para o banco. O total bate, os registros somam, o trailer fecha. Só que o dinheiro vai para outro lugar.
Por que isso é, antes de tudo, um problema fiscal e financeiro
A área de Segurança da Informação tende a tratar isso como incidente de endpoint. Faz sentido — mas subestima o estrago. O impacto real chega primeiro no Financeiro, no Fiscal e no Controller, justamente porque o ataque acontece depois de toda a aprovação interna ter sido concluída.
Pense no fluxo típico de uma remessa de pagamentos:
- Fornecedor emite documento fiscal.
- Contas a Pagar registra, concilia, agenda.
- Gerente aprova o lote.
- Sistema ERP gera o arquivo CNAB.
- Arquivo é enviado ao banco.
- Banco processa, debita, transfere.
O CNABHunter ataca entre o passo 4 e o passo 5 — exatamente o intervalo em que ninguém mais está olhando, porque presume-se que tudo o que precisava ser revisado já foi. É o ponto cego perfeito: depois da governança, antes da execução.
As consequências que aparecem no fechamento
Conciliação bancária quebrada. O razão registra pagamento a um fornecedor; o extrato mostra débito para uma conta desconhecida. A diferença pode levar dias para ser notada, especialmente em empresas com volume alto de pagamentos diários.
Duplicidade de pagamento. O fornecedor real cobra novamente — afinal, ele não recebeu. A empresa paga duas vezes: uma para o fraudador, outra para regularizar a relação comercial. Isso também distorce DRE, fluxo de caixa e indicadores de DSO/DPO.
Risco de compliance. Pagamentos a contas não cadastradas violam controles internos previstos em SOX, na LGPD (quando há vazamento associado) e em políticas antifraude. Auditoria externa costuma transformar isso em ponto de relatório.
Recuperação parcial, na melhor das hipóteses. Como o débito sai de forma autorizada — afinal, a empresa enviou o arquivo — a discussão com o banco vira longa. Bloqueio de valores via MED (Mecanismo Especial de Devolução do Pix) não se aplica a TED/DOC originadas em CNAB. Sobra ação cível, normalmente lenta.
Sinais de que algo está errado
Alguns indicadores que o time financeiro pode adotar sem depender só da TI:
- Divergência entre o relatório de remessa do ERP e o arquivo efetivamente enviado ao banco. Se você ainda não compara hash ou checksum desses arquivos, este é o momento.
- Aparição de favorecidos com CNPJ/CPF não cadastrados na base de fornecedores aprovados. Validação no retorno (
.RET) é tão importante quanto na remessa. - Pagamentos a contas em bancos digitais recém-abertos, especialmente quando o fornecedor histórico opera em outro banco há anos.
- Aumento de “ajustes manuais” de conciliação no fechamento. Esse é o ruído que costuma esconder o sinal.
O que dá para fazer hoje, sem reformar a infraestrutura
Não existe bala de prata, mas existem barreiras razoáveis:
Centralizar a geração do CNAB em servidor com acesso restrito, em vez de permitir que cada estação gere e mova arquivos localmente, reduz drasticamente a superfície de ataque. Assinar digitalmente o arquivo de remessa antes do envio ao banco, quando o canal permite, impede alteração silenciosa em trânsito. Reconciliar o arquivo enviado com o relatório do ERP usando hash (SHA-256, por exemplo) — e não só por totais — detecta substituições que mantêm a soma. Cruzar o .RET com a base de fornecedores aprovados, e não apenas com o .REM original, ajuda a flagrar trocas. E, talvez o mais subestimado: encerrar de vez a prática de circular arquivos CNAB por e-mail ou pasta compartilhada sem controle de versão.
O ponto que costuma escapar
CNAB é uma tecnologia da década de 80 que continua movimentando bilhões de reais por ano no Brasil. Atacantes profissionais sabem disso há muito tempo — a novidade aqui não é a vulnerabilidade, é o nível de especialização. O CNABHunter não é um malware genérico que tropeçou em um arquivo bancário; é uma peça desenhada para esse layout específico, nesse mercado específico.
A leitura para Fiscal, Financeiro e Controladoria é direta: a segurança do arquivo de remessa deixou de ser um detalhe operacional da TI. Passou a ser um controle interno, com impacto direto em conciliação, fechamento e auditoria. Ignorar isso é, na prática, terceirizar para a sorte uma parte relevante do caixa.
O fraudador estudou. Vale o time financeiro estudar também.
