O roubo à Binance começou com uma entrevista de emprego: o acesso determinou o custo

Em setembro, um engenheiro de software da Binance participou de duas entrevistas de emprego com uma empresa que não existia. A primeira foi uma chamada de vídeo ao vivo com uma representante de RH, que compartilhou uma conta pessoal em uma rede social, com fotos e vídeos, para provar que era quem dizia ser. A segunda aconteceu em um aplicativo de mensagens, com alguém que se apresentava como CEO. Perto do fim, pediram ao engenheiro que baixasse uma tarefa de programação no computador de trabalho.

Em 29 de outubro, invasores retiraram cerca de US$ 6,34 bilhões das carteiras da Binance, a maior parte em aproximadamente 20 minutos. O FBI atribuiu o roubo ao TraderTraitor, grupo norte-coreano também responsabilizado pelo roubo de US$ 1,5 bilhão da Bybit em fevereiro de 2025. É o maior roubo de criptomoedas já registrado.

A Binance assumiu a responsabilidade e afirma que cobrirá as perdas. Em 3 de novembro, informou que 98% dos ativos afetados em tokens haviam sido repostos e que cerca de US$ 2,85 bilhões tinham sido congelados ou interceptados.

A pergunta que vale fazer é: a que poderia ter acesso um único laptop comprometido, e cada equipe pode testar isso hoje em seu próprio ambiente?

Dois pontos de entrada e uma campanha que se estendeu de junho a outubro

Nada na atualização da Binance de 3 de novembro aponta para deepfakes ou outras técnicas assistidas por IA. Os dois métodos de invasão envolveram pessoas: um engenheiro que confiou em um resultado de busca e outro que confiou em um recrutador.

A campanha durou pelo menos cinco meses. Em junho, um engenheiro de DevOps da infraestrutura de carteiras, à procura de uma ferramenta de programação com IA, baixou um instalador adulterado do Homebrew. A equipe de segurança da Binance detectou a anomalia, substituiu o dispositivo e trocou as credenciais. A essa altura, os invasores já tinham descoberto quem fazia parte da equipe de infraestrutura de carteiras.

Três meses depois, eles voltaram por outra via. O engenheiro abordado em setembro tinha um perfil em uma plataforma legítima de busca de emprego, no qual mencionava sua experiência na Binance. A tarefa de programação continha um malware que era executado durante a instalação, substituía um componente legítimo do pyenv por um malicioso, conectava-se a um servidor controlado pelos invasores e apagava seus rastros. A Binance afirma que sua proteção de endpoints não o detectou.

Em 20 de outubro, os invasores usaram aquele laptop e uma ferramenta interna de IA para assumir o controle dos computadores de mais dois engenheiros, um deles pertencente ao engenheiro de DevOps comprometido em junho. Nesse computador, encontraram um token com permissões para implantar contêineres. Em 29 de outubro, acessaram o computador do outro engenheiro, usaram as credenciais roubadas para implantar um contêiner e executaram o script que deu início ao roubo.

Por que as armadilhas de recrutadores ainda funcionam

Falsos recrutadores e testes de programação contaminados são uma tática antiga. Operadores norte-coreanos a usam contra desenvolvedores há anos, sobretudo na campanha conhecida como Contagious Interview. A Binance afirma que impediu 57 tentativas suspeitas ligadas à Coreia do Norte somente em 2026.

A armadilha funciona porque leva os engenheiros a fazer algo que fazem todos os dias. Executar um repositório desconhecido é parte normal de uma entrevista técnica. Não há um endereço de remetente suspeito nem um link para verificar passando o cursor sobre ele: há apenas um empregador plausível, uma pessoa em uma chamada de vídeo e uma tarefa que parece trabalho.

Uma mensagem de recrutador também é uma das poucas abordagens não solicitadas que as pessoas recebem de bom grado. Nenhum programa de conscientização pode garantir que todos os engenheiros identifiquem todas as mensagens convincentes, por isso os controles precisam partir do pressuposto de que uma delas vai passar despercebida.

Como um laptop chegou às carteiras

Minha primeira pergunta diz respeito aos controles de segurança no ambiente daquele engenheiro. O uso de um computador de trabalho para uma avaliação externa de programação merece ser investigado. A preocupação maior é como aquele único comprometimento permitiu o acesso a outros sistemas e, por fim, a uma infraestrutura financeira sensível.

Cada etapa após a infecção inicial se apoiou em uma confiança que já existia dentro da Binance. Uma ferramenta interna de IA aceitou instruções de uma máquina comprometida e as executou nos dispositivos dos colegas. Um token de implantação estava no laptop de um engenheiro. Uma implantação de contêiner feita com credenciais válidas movimentou bilhões. Nada disso exigiu outra armadilha.

As ferramentas internas de IA merecem atenção especial. Muitas funcionam com permissões amplas em repositórios, endpoints e serviços; assim, quem controla uma máquina capaz de dar instruções a uma delas herda o alcance dessa ferramenta.

Como proteger desenvolvedores sem paralisar a engenharia

Os desenvolvedores precisam baixar pacotes, executar código desconhecido e testar software. Bloquear seus laptops como se fossem estações de trabalho do setor financeiro paralisaria a engenharia e levaria os engenheiros a buscar alternativas. É razoável ter uma política que proíba atividades de busca de emprego em dispositivos corporativos, mas ninguém segue uma política o tempo todo. O objetivo prático é limitar o que uma máquina de desenvolvimento comprometida pode fazer em seguida.

Algumas medidas fazem a maior diferença. Códigos não confiáveis devem ser executados em máquinas virtuais descartáveis, sem acesso a credenciais corporativas. As credenciais de implantação devem ter validade curta, escopo restrito e, sempre que possível, ser emitidas para fluxos de trabalho de implantação controlados. As chaves de assinatura de carteiras ou suas partes devem ser protegidas separadamente das estações de trabalho dos desenvolvedores, com políticas de assinatura que restrinjam as transações e autorizações que podem ser aprovadas. Ações que envolvam carteiras, sistemas de pagamento ou sistemas de produção devem exigir a aprovação de uma segunda pessoa em outro dispositivo. As ferramentas internas de IA devem operar com permissões mínimas e registrar suas atividades.

A detecção também precisa funcionar quando as credenciais são legítimas. O monitoramento comportamental que sinaliza uma implantação feita a partir de uma máquina inesperada ou em um horário incomum dá à equipe a oportunidade de intervir mesmo quando todas as credenciais parecem válidas. A Binance afirma que ampliou esse tipo de detecção desde o incidente.

O papel da inteligência sobre ameaças

O alerta foi divulgado seis semanas antes do roubo. O comunicado conjunto sobre Contagious Interview descreveu agentes que se faziam passar por recrutadores de empresas de IA, criptomoedas e NFT para atacar profissionais de TI e roubar criptomoedas. O caso da Binance seguiu o mesmo roteiro.

A inteligência sobre ameaças tem uma função concreta em campanhas como essa. Os agentes podem mudar, mas suas táticas são conhecidas. As equipes que os monitoram podem bloquear infraestruturas conhecidas e alertar os engenheiros sobre os pretextos usados no momento.

A inteligência também informa quem precisa de proteção adicional. Quando um incidente revela quem tem acesso a informações confidenciais, como ocorreu no comprometimento da Binance em junho, essas pessoas devem ser tratadas como alvos prováveis por meses, com monitoramento mais rigoroso de seus dispositivos e das abordagens que recebem.

O que isso significa fora do setor de criptomoedas

As corretoras de criptomoedas são alvos óbvios porque os fundos roubados são transferidos rapidamente e difíceis de recuperar. Esse padrão se repete sempre que uma estação de trabalho de desenvolvedor está a poucas etapas de sistemas críticos, seja na cadeia de processamento de pagamentos de um banco, seja no processo de compilação e lançamento de um fornecedor de software. Os pretextos de recrutamento chegam aos engenheiros de todas essas organizações.

Para os responsáveis pela segurança que estiverem avaliando seus próprios ambientes nesta semana, duas verificações são as mais importantes. Primeiro, mapeie a que um único laptop de desenvolvedor comprometido poderia ter acesso hoje, incluindo tokens armazenados, chaves SSH, credenciais de nuvem e ferramentas internas de IA. Segundo, confirme que as implantações em produção e as transações de alto valor exigem uma aprovação independente, que uma única identidade comprometida não pode fornecer.

A Binance reconstruiu os sistemas afetados e contratou avaliadores independentes, tomando essas decisões após a perda. As organizações que fizerem o mesmo exercício agora poderão tomar essas decisões no seu próprio ritmo.