Uma entrevista de emprego falsa foi uma das peças de um roubo de cerca de US$ 6,34 bilhões na Binance. Quem conta é a própria exchange, em relatório preliminar divulgado em 3 de novembro de 2026 e relatado por veículos como o Tecnoblog e a CoinDesk Brasil. O detalhe que interessa a quem cuida de tecnologia: o ataque não começou com uma falha exótica de blockchain, e sim com uma conversa de recrutamento, meses antes do dinheiro sair.
Vale uma ressalva antes de seguir. Tudo o que se sabe até agora vem do relato da Binance, repetido pela imprensa. A investigação é preliminar e a empresa disse que vai contratar especialistas independentes para revisá-la. Separo abaixo o que está nas fontes do que é leitura minha.
O que a Binance diz que aconteceu
Segundo o CoinDesk Brasil, Richard Teng, da Binance, descreveu o caso como uma campanha construída ao longo de muitos meses, e o FBI atribui o ataque ao grupo TraderTraitor, ligado à Coreia do Norte. A cronologia, conforme Tecnoblog e Security Affairs, tem quatro momentos:
- Junho: um engenheiro de infraestrutura de carteiras baixou uma versão adulterada do Homebrew, gerenciador de pacotes do macOS, ao procurar uma ferramenta de IA para programar. A segurança detectou, trocou a máquina e renovou as credenciais, mas os atacantes já tinham aprendido o papel dele e o de colegas.
- Setembro: outro engenheiro foi abordado em uma plataforma de vagas por alguém que se passava por diretor de projeto. Houve entrevista em vídeo com uma falsa representante de RH e uma segunda com um suposto CEO de empresa fictícia. Ao fim, ele baixou uma “tarefa técnica” com código malicioso, que as ferramentas de proteção da máquina não detectaram.
- 20 de outubro: com esse computador, os atacantes usaram uma ferramenta interna de IA da Binance para chegar às máquinas de mais dois engenheiros de carteiras. Em uma delas havia um token com permissão para implantar contêineres.
- 29 de outubro: com credenciais roubadas, implantaram um contêiner, rodaram um script malicioso e alcançaram o serviço interno de assinatura de carteiras, iniciando transferências fora do fluxo normal de saques.
Há divergências entre os veículos. A Fortune diz que o segundo engenheiro foi abordado pelo LinkedIn e que o engenheiro de junho clicou em um anúncio de versão maliciosa do Homebrew; os demais falam em plataforma de vagas genérica e em busca por uma ferramenta de IA. Os números também variam: o Tecnoblog e o Security Affairs falam em cerca de US$ 2,85 bilhões congelados ou interceptados, enquanto a Fortune cita cerca de US$ 2,5 bilhões recuperados após congelamentos da Tether e da Circle. A Binance afirma ter reposto 98% dos ativos afetados com recursos próprios.
Por que suspender saques não resolveu
O trecho mais técnico do relatório é o das autorizações. De acordo com o Security Affairs, os atacantes usaram o EIP-7702 do Ethereum, que permite delegar a um contrato inteligente direitos parciais de execução sobre uma carteira. Quando a Binance suspendeu os saques, essas autorizações já estavam registradas na blockchain e funcionavam fora da infraestrutura de saques. Como a empresa usa computação multipartidária (MPC), nenhuma chave isolada podia revogá-las, e foi preciso criar um procedimento específico, concluído em 30 de outubro.
A lição de engenharia é incômoda: um plano de resposta que assume “corta o acesso e pronto” falha quando o acesso malicioso já virou estado persistente em outro sistema. Vale perguntar se o seu runbook de incidente cobre revogação de tokens, delegações e permissões emitidas, e não só o desligamento de serviços.
Recrutamento é superfície de ataque
Esta parte é análise minha, não afirmação da Binance. Em muitas empresas, a conversa de recrutamento fica fora do perímetro de segurança: acontece em perfil pessoal, em chat de aplicativo popular, no computador de trabalho ou no pessoal, e termina com um desafio de código para rodar localmente. O caso mostra que isso é um caminho de entrada. O atacante não precisou quebrar nada: pediu para a vítima executar o código.
A própria Binance reconhece o risco. A Fortune reporta que a empresa tem uma política que proíbe perfil no LinkedIn para funcionários em funções não públicas, e que um porta-voz não quis dizer se ela foi violada. Esconder perfis, por si só, não resolve, porque engenheiros mudam de emprego. O que dá para controlar é onde o código desconhecido roda.
- Rodar testes técnicos e repositórios de terceiros apenas em máquina virtual ou contêiner descartável, nunca na estação com acesso a repositórios, VPN ou credenciais.
- Orientar times de engenharia, e não só RH, a tratar “desafio técnico” recebido de recrutador externo como código não confiável.
- Bloquear a instalação de pacotes e ferramentas fora de fontes aprovadas, inclusive as de IA para programação, que o caso de junho mostra como isca.
- Definir um canal oficial para o funcionário reportar abordagens suspeitas de recrutadores, sem constrangimento.
Privilégio mínimo é o que limita o estrago
Do ponto de vista de arquitetura, o caso é um encadeamento: uma máquina comprometida levou a uma ferramenta interna de IA, que levou a outras máquinas, que guardavam um token com permissão ampla, que levou ao serviço de assinatura. Cada salto foi um privilégio que talvez não precisasse existir naquele lugar. Também é um aviso para quem está plugando assistentes de IA em sistemas internos: a ferramenta passa a ser um caminho de movimentação lateral e precisa ser tratada como tal.
- Tokens de deploy com escopo curto, vida curta e sem permanência em disco de estações de trabalho.
- Separação entre quem desenvolve e quem pode acionar serviços de assinatura ou de produção crítica, com aprovação de mais de uma pessoa.
- Ferramentas internas de IA com as permissões do usuário que as chama, e não com uma identidade própria poderosa, além de registro de uso.
- Após qualquer incidente em uma estação, revisar o que o atacante pode ter aprendido, como papéis e colegas, e não apenas trocar o equipamento.
O que isso significa para TI e CIOs no Brasil
O Tecnoblog registra que a exchange brasileira Mercado Bitcoin também foi alvo em 2 de novembro, com movimentações suspeitas que podem ter envolvido cerca de US$ 40 milhões, e que a empresa diz que os clientes não tiveram perdas. Não há, nas fontes que consultei, ligação confirmada entre os dois casos. Mesmo assim, o recado vale para qualquer empresa com ativos digitais, código proprietário ou acesso a dados sensíveis, em fintech, saúde, educação ou SaaS: o ataque seguiu o caminho de menor resistência, que passou por pessoas, ferramentas e permissões.
Um bom exercício para esta semana: pegue seus dois ou três serviços mais críticos e trace o caminho inverso. Quem pode chegar a eles, de que máquina, com qual token e com que aprovação? Se o caminho começa em um laptop que roda qualquer coisa que um recrutador mandou, há trabalho a fazer.
Se o seu time quer revisar acessos, arquitetura de segurança e processos de desenvolvimento com apoio de quem faz isso em projetos reais, fale com a Luby.