Crédito da imagem: Foto de Vadim Art na Unsplash
O que você vai encontrar neste artigo
Análise do incidente: detalhamento completo da cadeia de ataque, desde a engenharia social e o comprometimento das estações de desenvolvimento até a exploração do serviço de assinatura das hot wallets.
Arquitetura Duranium: proposta detalhada de contenção baseada em um gate obrigatório, onde cada nó de assinatura MPC valida obrigatoriamente uma decisão de risco assinada em HSM e vinculada ao conteúdo exato da transação antes de assinar.
Paralelo com Pix/TED: comparativo com incidentes no sistema financeiro brasileiro, demonstrando como o ponto vulnerável é o conector que assina mensagens para o SPI/STR sem passar pelo motor de risco interno da instituição.
Plano de Ação: recomendações técnicas e organizacionais divididas em ações imediatas (como o mapeamento de acessos e remoção de segredos em estações) e mudanças estruturais na arquitetura antifraude.
Resumo
No dia 29 de outubro de 2026, a Binance teve cerca de US$ 6,34 bilhões em ativos retirados das suas hot wallets, pela estimativa da própria empresa. O invasor não precisou roubar uma chave privada. Ele chegou ao serviço interno que assina as operações das carteiras e obteve dali assinaturas válidas para transferências e autorizações que, segundo a Binance, foram processadas fora da infraestrutura normal de saques.
Visão de antifraude: a invasão das máquinas não seria evitada; a perda, muito provavelmente, sim. Para isso, a chave da carteira só poderia assinar algo (seja transferência, autorização de delegação ou mensagem) diante de uma decisão de risco assinada para exatamente aquele conteúdo e conferida em cada nó de assinatura. O invasor então precisaria comprometer também o motor de risco, que fica em outro ambiente, com administradores e credenciais próprios.
O caso interessa também a quem não opera cripto. Bancos e instituições de pagamento têm um componente que assina ordens antes de mandá-las para fora, e no Pix e na TED esse componente é o conector com o Banco Central. Se você levar uma única pergunta deste texto para o seu time, que seja esta: que caminhos chegam a esse componente sem passar pelo motor de risco?
Escrevemos este advisory com as conclusões iniciais que a Binance divulgou em 3 de novembro de 2026 e com análises públicas de terceiros. Não temos acesso a informação interna da empresa. Os termos técnicos estão explicados no glossário, no fim do texto.
Ficha do advisory
Classificação: TLP:CLEAR, divulgação sem restrição; baseado só em fontes públicas
Versão: 1.1, com revisão técnica interna
Incidente: Uso indevido do serviço interno de assinatura das hot wallets da Binance, em 29/10/2026
Impacto informado: Cerca de US$ 6,34 bilhões retirados (Binance); cerca de US$ 2,85 bilhões congelados ou apreendidos (Binance, confirmado pela Elliptic)
Atribuição: TraderTraitor, grupo ligado à Coreia do Norte, segundo alerta do FBI de 31/10/2026. A Coreia do Norte nega
Público: CISOs e times de antifraude, engenharia de plataforma e AppSec de instituições financeiras
Status: Conclusões iniciais; a Binance diz que os achados terão revisão independente
Declaração de interesse: A Duranium desenvolve e implanta soluções antifraude. Esta análise usa apenas fontes públicas
Cadeia do ataque
Entre o primeiro comprometimento e o roubo passaram cerca de cinco meses. A execução, em si, aconteceu em apenas uma noite. Três engenheiros da Binance aparecem ao longo do texto, sempre identificados pela função: o engenheiro de DevOps, da equipe de carteiras; o candidato, engenheiro de software abordado na entrevista falsa; e o engenheiro de carteiras, também de software, cuja máquina foi usada no dia do ataque. Os horários estão em UTC, como aparecem na imprensa e nas análises da TRM Labs e da Hypernative; os trechos publicados do relatório da Binance não informam o fuso. Para o horário de Brasília, subtraia três horas.
Cadeia do ataque, de junho a 30 de outubro de 2026. Horários em UTC.
Detalhe de cada etapa
Jun/2026 · Primeiro comprometimento. O engenheiro de DevOps procura no buscador uma ferramenta de IA para programar e baixa uma instalação adulterada do Homebrew. A Binance detecta a anomalia, troca o dispositivo e rotaciona as credenciais relacionadas, mas o cargo do engenheiro de DevOps e a composição da equipe de carteiras ficam expostos ao invasor.
Set/2026 · Entrada. O candidato, cujo perfil profissional citava a experiência na Binance, é abordado numa plataforma de vagas legítima por um falso diretor de projeto. Depois de duas entrevistas falsas, com um RH por vídeo e um falso CEO por app de chat, ele baixa uma “tarefa” no computador de trabalho. O malware, que a Binance chama de 0-day, passa pela proteção de endpoint, substitui o binário do pyenv, instalado via Homebrew, por uma versão adulterada e remove artefatos forenses.
20/10 · Movimento lateral. Do computador do candidato, o invasor usa uma ferramenta de IA interna para tomar o controle das máquinas do engenheiro de DevOps e do engenheiro de carteiras. Na do engenheiro de DevOps, encontra um token com permissão de deploy de containers.
28/10, 07h39 · Preparação. A carteira do invasor é abastecida com três pequenos valores sacados do Tornado Cash.
29/10, 02h28 e 15h59 · Ensaio. O invasor publica um contrato de teste e, depois, o contrato final. O código é testado em duas carteiras próprias e ensaiado numa terceira.
29/10, 17h15 a 19h56 · Coleta de assinaturas. Na máquina do engenheiro de carteiras, com as credenciais do engenheiro de DevOps, o invasor sobe um container e dispara um script contra o serviço de assinatura. Segundo a TRM, as assinaturas foram todas obtidas primeiro e só enviadas às redes a partir das 20h05. Nessas quase três horas, nenhum ativo saiu.
29/10, 20h05 · Saídas. Começam as transferências: cinco hot wallets na XRP Ledger e, em seguida, Solana, Optimism, Bitcoin e Tron. Nessas redes, as assinaturas autorizavam transferências comuns.
29/10, 20h20 · Delegação. Uma única transação na Ethereum leva 50 autorizações EIP-7702 assinadas pela hot wallet Binance 14, uma para cada nonce consecutivo. Só vale a que traz o nonce vigente da conta, e a carteira passa a executar o contrato do invasor.
29/10, 20h24 · Saída principal. US$ 2,53 bilhões saem da Ethereum numa única transação, parte do total que saiu por essa rede. Novas varreduras ocorrem às 21h04, 21h44, 22h39 e 23h56.
29/10, 21h01 e 21h04 · Contenção. A Tether congela 971 milhões de USDT e a Circle, 823 milhões de USDC.
30/10, 00h10 · Contenção. A Binance revoga a delegação com uma nova autorização para o endereço zero. A revogação exigiu reunir o quórum de assinatura da carteira MPC e só saiu quase quatro horas depois da delegação. O invasor, por sua vez, obteve as assinaturas dele pelo serviço de assinatura, sem essa espera.
O que saiu e o que foi contido
Mais da metade do valor saiu pela Ethereum, a rede em que a delegação EIP-7702 deixou uma carteira aberta por horas. A TRM conta dez redes atingidas; a Elliptic chega a onze porque inclui a NEAR.
Fonte: TRM Labs. A Binance estima o total em US$ 6,34 bilhões.
O noticiário costuma misturar três situações diferentes:
Congelado: a Elliptic confirmou cerca de US$ 2,85 bilhões congelados ou apreendidos, cerca de 45% do total, a maior parte em USDT e USDC. O que saiu em Bitcoin, XRP Ledger, Solana e NEAR não foi congelado.
Reposto aos clientes: a Binance repôs os saldos com dinheiro próprio, inclusive do fundo SAFU, e retomou os saques em fases a partir de 1º de novembro.
Recuperado: nenhuma das duas situações anteriores significa que os fundos voltaram. Congelar não é recuperar, e repor saldos também não.
Do lado das autoridades, o FBI publicou 628 endereços ligados ao ataque e pediu ao setor que bloqueie transações com eles e com fundos derivados deles.
Análise técnica: o atalho até a assinatura
Estações comprometidas são um problema sério, mas raramente custam bilhões por si só. O que fez a diferença aqui foi o acesso ao serviço de assinatura. A própria Binance diz que as autorizações funcionaram “independentemente da infraestrutura normal de saques”, e o co-CEO Richard Teng afirmou que a delegação “não passou pelos nossos controles normais de aprovação”.
Caminho normal e atalho do invasor: os dois chegam à mesma assinatura.
O diagrama resume o problema. Num saque normal, o pedido do cliente passa pela política de saques e pelo antifraude antes de chegar a quem assina. Pela leitura da Halborn, essa política ficava na camada que o invasor contornou: ele não forjou ordens de saque, pediu assinaturas ao serviço. Do outro lado, a blockchain só verifica se a assinatura confere, mais ou menos como uma câmara de compensação que valida o certificado digital do participante sem ter como saber se a ordem passou pela alçada interna.
Dois detalhes do caminho até o serviço de assinatura merecem atenção de qualquer time de segurança:
O primeiro é a ferramenta de IA interna, que virou ponte entre máquinas: do computador do candidato, o invasor a usou para agir nas máquinas do engenheiro de DevOps e do engenheiro de carteiras. Um agente que executa ações na estação de outra pessoa tem, na prática, o poder de uma ferramenta de administração remota, e deveria ter o mesmo tratamento, com escopo mínimo, aprovação humana para ações remotas e registro guardado fora da máquina.
O segundo é o token de deploy guardado no computador do engenheiro de DevOps. Com ele, o container foi criado sem passar pelo pipeline, onde haveria revisão e registro.
Sobre o malware, uma ressalva. A Binance o chama de 0-day, mas os trechos publicados não descrevem exploração de vulnerabilidade. O que se sabe é que ele era desconhecido da proteção de endpoint e se aproveitou de algo comum em Macs de desenvolvedores: o diretório do Homebrew pertence ao próprio usuário logado, então um programa que roda como esse usuário consegue trocar os binários ali sem pedir senha de administrador.
A conclusão que tiramos é simples de dizer e trabalhosa de implementar. O controle de risco tem de estar no ponto onde a operação é assinada. Se ele fica apenas na porta de entrada dos saques, protege o caminho principal e deixa os outros abertos.
Por que pausar saques não parou a Ethereum
Na Ethereum o ataque teve um ingrediente a mais. A chave da hot wallet não assinou apenas transferências; assinou também uma autorização EIP-7702, que funciona como uma procuração passada a um contrato do invasor. Uma vez publicada na rede, essa procuração vale até ser revogada, estejam os saques pausados ou não.
Delegação EIP-7702 em quatro passos: por que a pausa de saques não a desfez.
A técnica das 50 autorizações contornou um problema prático. Cada carteira na Ethereum tem um nonce, um número de sequência que funciona como o número de um cheque. Como o invasor não sabia qual seria o nonce no momento exato do envio, pediu ao serviço uma autorização para cada um de 50 números consecutivos e mandou todas numa única transação; a que coincidisse com o nonce vigente no momento valeria. O serviço aceitou assinar para nonces que a carteira ainda nem tinha alcançado, o que por si só deveria ter acendido um alerta.
A delegação atingiu uma única carteira, a Binance 14. Nas demais redes, e também na Binance 16, o serviço assinou transferências comuns direto para o invasor.
Para quem desenha controles, o recado é incômodo. Uma autorização EIP-7702 não tem destino nem valor; tem rede, endereço do contrato e nonce. Um controle que só olha para destino e valor fica sem ter o que avaliar. Por isso a verificação precisa cobrir tudo o que a chave assina, e uma hot wallet, na nossa opinião, não deveria assinar delegação alguma.
Arquitetura proposta pela Duranium
A ideia central é que a chave da carteira não assine nada, seja transferência, autorização ou mensagem, sem uma decisão de risco assinada para exatamente aquele conteúdo, e que essa decisão seja conferida por cada nó que participa da assinatura.
Arquitetura proposta: decisão de risco assinada e gate antes da última milha.
Na prática, isso exige quatro coisas funcionando juntas.
Motor de risco que assina a decisão. Todo pedido passa pelo motor de risco, venha do app, de uma API de parceiro, de um serviço interno ou de um script. O motor avalia regras, comportamento e limites, confere no ledger que existe um débito real por trás do pedido e, se aprovar, assina a decisão com uma chave própria guardada em HSM.
Decisão presa ao conteúdo. A decisão descreve o tipo de operação e o conteúdo exato que será assinado, vale por pouco tempo e só uma vez. A aprovação de um saque não serve para outro saque, muito menos para uma delegação.
Verificação em cada nó. Em custódia MPC, a verificação roda dentro de cada nó que participa da assinatura, e não no coordenador que recebe os pedidos. Quem domina o coordenador pode trocar o que é enviado aos nós; quem domina um nó sozinho não reúne o quórum. Com isso, o limiar criptográfico passa a funcionar também como limiar de política: para obter uma assinatura, o invasor teria de enganar a maioria dos nós, e não só o coordenador.
Domínio separado. Motor, ledger e política ficam num ambiente separado, com administração, pipeline de deploy e credenciais próprios. Um token de deploy encontrado na estação de um desenvolvedor não deve alcançar nenhum deles.
Algumas regras fecham as brechas que o caso expôs:
Lista fechada de operações. Hot wallets assinam apenas o que foi liberado para elas, como transferências nativas e transferências de tokens para contratos conhecidos. Delegações, permits, trocas de chave de conta e assinaturas de mensagens arbitrárias vão para o caminho frio, com quórum humano.
Nada de assinar hash. O nó recebe o payload inteiro, decodifica com o próprio decodificador e recusa o que não conseguir ler. Assim, um pedido do tipo “assine este hash” não existe.
Validade curta também na rede. Na Ethereum, o nonce tem de ser o próximo da conta, nunca um futuro. As outras redes têm equivalentes, listados abaixo.
XRP Ledger: LastLedgerSequence curto
Solana: Blockhash recente
Tron: Expiração curta
Bitcoin: Entradas atuais
Há ainda limites que o motor não pode alterar. Cada nó guarda os próprios tetos por carteira, rede e janela de tempo, porque o motor cuida do risco comportamental e os nós cuidam das invariantes, os tetos fixos que valem em qualquer situação. Trocar a chave pública do motor, um limite ou uma lista de destinos exige aprovação de várias pessoas, com período de espera para afrouxar e efeito imediato para endurecer. E o procedimento de emergência não pode virar atalho: o break-glass é um conjunto de regras ainda mais restrito, com destinos fixos, como evacuar para a carteira fria ou revogar delegações, e quórum humano.
Nada disso é inédito. Custodiantes de ativos digitais já usam motores de política e co-assinadores. O que o caso Binance mostra é que essas peças só protegem quando estão no caminho obrigatório da assinatura e fora do alcance das credenciais de quem origina os pedidos.
O contrato da decisão e a verificação no gate
Para que o nó consiga provar sozinho que aquele conteúdo exato foi avaliado agora, a decisão precisa carregar um conjunto preciso de campos. Organizamos os campos em torno de quatro perguntas.
Quem pediu. Canal e identidade da carga de trabalho de origem, iniciador pseudonimizado, aprovações humanas exigidas. Para quê: recusar origens desconhecidas, como um container nunca visto.
O que será assinado. Rede, carteira de origem, tipo de operação de uma lista fechada, ativo, valor em unidade mínima (como satoshi ou wei), destinatário, teto de taxa, digest exato do payload. Para quê: amarrar a decisão ao conteúdo, e não a uma descrição dele.
Até quando. Emissão, validade curta, identificador de uso único, referência de frescor na rede. Para quê: impedir reuso e assinaturas guardadas para depois.
Que prova existe. Referência ao débito no ledger, versão da política, simulação usada, assinatura do motor com identificador da chave. Para quê: mostrar que houve débito real e avaliação.
Antes de participar de qualquer assinatura, cada nó segue esta ordem:
Recebe o payload completo, a decisão e a atestação do ledger. Recusa qualquer pedido de “assinar um hash”.
Confere se o tipo de operação está liberado para aquela carteira. Delegações, permits e trocas de chave são recusados por padrão em hot wallets.
Decodifica o payload com o próprio decodificador e recalcula o digest.
Verifica a assinatura do motor com uma chave fixada e não revogada.
Confere a validade e consome o identificador de uso único.
Compara o conteúdo decodificado com a decisão: rede, origem, tipo, ativo, valor, destino, taxa e digest.
Confere o frescor na rede: nonce igual ao próximo da conta, nunca futuro, ou o equivalente em cada rede.
Aplica os limites e a lista de destinos do próprio nó e confere o débito no ledger.
Registra a decisão num log fora da máquina e só então participa da assinatura.
Se qualquer passo falhar, o nó não assina, registra o motivo num alerta e bloqueia temporariamente a origem. O trabalho também não termina na assinatura. Uma reconciliação confere se cada assinatura emitida aparece na rede dentro da janela esperada, e qualquer saída on-chain sem par nessa reconciliação deve ser tratada como alerta crítico.
O que teria mudado
Convém deixar claro o alcance da proposta: ela não impediria a invasão. O que ela muda é o desfecho a partir do momento em que o invasor pede a primeira assinatura, e no caso Binance esse momento chegou quase três horas antes de qualquer ativo sair.
Instalador adulterado e malware (jun e set): Não muda. A arquitetura atua na assinatura, não na estação.
Movimento lateral pela IA interna (20/10): Não muda. Depende dos controles de agentes descritos na análise técnica.
Coleta de assinaturas pelo container (17h15 a 19h56): Muda. Nenhum nó participa sem decisão válida, e o pedido vira alerta horas antes da primeira saída.
50 autorizações EIP-7702: Muda. Delegação é tipo negado em hot wallet, e nonces futuros são recusados.
Transferências comuns nas outras redes: Muda, desde que o gate cubra todas as redes atendidas pelo serviço de assinatura.
Varreduras de depósitos novos: Muda. Sem delegação, não há varredura; se houvesse delegação, o monitoramento do código associado à carteira a detectaria.
Essa defesa também tem limites, e preferimos dizê-los.
O motor vira alvo. O HSM protege a chave, mas não impede o uso dela: quem consegue executar código no motor pede a assinatura que quiser. Por isso o motor precisa de imagens assinadas, deploy aprovado por duas pessoas e uso da chave condicionado à identidade da carga de trabalho.
A posição do gate importa. Se a verificação ficar no serviço que recebe os pedidos, quem controla esse serviço passa por cima dela.
Fluxos legítimos podem ser abusados. Um rebalanceamento interno aprovado, por exemplo, pode reabastecer uma carteira que já está comprometida. Por isso, endereços internos precisam de registro sob quórum, e todo saque precisa de um débito no ledger.
O gate entra no caminho crítico. Se ele cair, a operação para. Em degradação, o certo é reduzir limites, nunca desligar a verificação.
Não substitui os controles de estação, identidade e IA. A cadeia começou meses antes, em laptops.
Além disso, não conhecemos a arquitetura interna da Binance. É possível que o invasor tenha alcançado também a camada de política, por caminhos que ainda não foram divulgados.
Sinais de detecção
Olhando para trás, o caso deixou rastros em quatro camadas, e vários apareceram horas antes da primeira saída. Nenhum deles exigia saber de antemão quem era o invasor.
Sinais de detecção por camada e quando cada um ficou visível.
Mapeamento para MITRE ATT&CK
Fizemos o mapeamento abaixo a partir dos fatos públicos. Ele é nosso, não da Binance, e serve para o seu time cruzar com as detecções que já tem.
T1583.008 Malvertising: Provável origem do instalador adulterado do Homebrew, não confirmada
T1566.003 Spearphishing via Service: Abordagem do candidato por uma plataforma de vagas
T1204.002 Malicious File: “Tarefa” de código baixada e executada no computador de trabalho
T1554 Compromise Host Software Binary: Substituição do binário do Pyenv instalado via Homebrew
T1070 Indicator Removal: Remoção de artefatos forenses
T1072 Software Deployment Tools: Ferramenta de IA interna usada para agir nas máquinas do engenheiro de DevOps e do engenheiro de carteiras (aproximação)
T1552 Unsecured Credentials: Token de deploy guardado na máquina do engenheiro de DevOps
T1078 Valid Accounts: Credenciais do engenheiro de DevOps usadas na máquina do engenheiro de carteiras
T1610 Deploy Container: Container criado para chegar ao serviço de assinatura
T1657 Financial Theft: Transferências e delegação nas hot wallets
Paralelo no Brasil: Pix, SPI e STR
Quem acompanha o sistema financeiro brasileiro vai reconhecer o padrão. Nos incidentes de 2025, que envolveram prestadores de tecnologia ligados ao Pix, ninguém forjou a ordem do cliente. Os criminosos usaram credenciais legítimas para chegar ao ponto que emite a ordem já assinada, e o sistema de liquidação a executou porque a assinatura estava correta.
Vale lembrar como a ordem chega ao Banco Central: no Pix, a instituição monta a mensagem, assina com o certificado digital ICP-Brasil e a envia pela Rede do Sistema Financeiro Nacional (RSFN) ao SPI, o sistema que liquida os pagamentos instantâneos. Na TED, a liquidação passa pelo STR, que movimenta as contas reserva. Instituições menores costumam se conectar por um PSTI, um prestador de tecnologia que opera essa ponte em nome delas. Assim como a blockchain, o SPI e o STR conferem assinatura e saldo. Eles não têm como saber se a ordem passou pelo antifraude da instituição.
Paralelo no Brasil: o atalho até o conector que assina as mensagens ao SPI e ao STR.
O quadro abaixo coloca os dois mundos lado a lado.
Binance e Pix/TED lado a lado.
Depois dos ataques de 2025, o Banco Central reagiu. A Resolução BCB nº 498, de 5 de setembro de 2025, limitou a R$ 15 mil cada Pix e cada TED de instituições de pagamento não autorizadas e das que se conectam por PSTI, até que comprovem os novos controles, e endureceu as exigências para os próprios PSTIs.
A Resolução BCB nº 547, de 30 de janeiro de 2026, ajustou essas regras. O teto ajuda a limitar o impacto de cada ordem, mas não diz se a ordem passou pelo antifraude. Um invasor com acesso ao conector ainda pode fracionar o desvio em várias ordens abaixo do teto, todas com assinatura válida.
Num banco brasileiro, a arquitetura que propomos ficaria assim:
O gate fica no conector que assina as mensagens enviadas ao SPI e ao STR, e não apenas no canal do cliente.
A decisão de risco se prende a:
o identificador da transação (o EndToEndId, no Pix),
a conta debitada,
a instituição e a conta ou chave do recebedor,
o valor e a janela de tempo.
Além da decisão assinada, a segunda prova é o débito correspondente no core bancário;
A invariante a ser vigiada, quase em tempo real, é que a soma das mensagens enviadas deve bater com:
a soma dos débitos,
com teto de saída da conta reserva por janela de tempo.
Para quem depende de um PSTI, há um passo que pode entrar na próxima negociação de contrato:
exigir que o prestador só envie mensagens acompanhadas da decisão assinada pelo antifraude da sua instituição e recuse as demais. Assim, uma credencial vazada no fornecedor deixa de bastar para emitir ordens em seu nome.
Recomendações
Comece pelo mapa de caminhos: qualquer rota que chegue à assinatura sem passar pelo motor de risco é um atalho do mesmo tipo do que foi usado contra a Binance.
Ações imediatas
Mapear todos os caminhos que chegam ao serviço de assinatura ou à execução de transações, incluindo serviços internos, scripts e jobs (responsável: arquitetura e segurança).
Bloquear em hot wallets os tipos de assinatura que não são transferência, como delegações e assinatura de hash arbitrário (responsável: custódia ou pagamentos).
Tirar tokens de deploy e segredos das estações; deploy só pelo pipeline, com credenciais de curta duração (responsável: engenharia de plataforma).
Listar o que cada agente de IA interno executa e em quais máquinas; remover a execução remota onde não for indispensável (responsável: segurança e donos das ferramentas).
Ensaiar a revogação de tokens, acessos e autorizações já concedidas, inclusive as registradas on-chain (responsável: resposta a incidentes).
Mudanças estruturais
Fazer o motor de risco assinar cada decisão, com chave em HSM e conferência do débito no ledger (responsável: antifraude).
Colocar o gate em cada nó de assinatura, com o contrato e a sequência descritos acima (responsável: custódia ou pagamentos e segurança).
Aplicar antifraude comportamental na última milha também para transações internas (responsável: antifraude).
Enviar a telemetria de estações e serviços críticos para fora deles em tempo real (responsável: segurança).
Monitorar on-chain as próprias carteiras e manter contato pronto com emissores de stablecoins (responsável: custódia e resposta a incidentes). Vale para quem opera ativos digitais.
Para instituições reguladas no Brasil, esses controles cabem na política de segurança cibernética exigida pela Resolução CMN nº 4.893/2021. No caso das prestadoras de serviços de ativos virtuais, entram nas exigências de segurança cibernética da Resolução BCB nº 520/2025.
Checklist técnico
São doze itens, divididos entre o que acontece na estação de desenvolvimento e o que envolve credenciais, IA e transações. Eles detalham, no nível operacional, as recomendações acima.
Estação de dev e pacotes
Bloqueador de anúncios nos navegadores corporativos. Instalador falso em anúncio de buscador é um vetor conhecido e, no caso Binance, o mais provável, ainda que não confirmado.
Proxy para instalação de pacotes, de modo que Homebrew, npm e pip só baixem de um repositório interno que inspeciona o que entra.
Tempo mínimo desde a publicação de cada pacote, com quarentena para versões recém-publicadas antes que cheguem às máquinas.
Versões fixadas em lockfile, com hash conferido e atualização revisada. Sem atualização automática para a versão mais recente (latest).
Desafios técnicos de candidatos em máquina descartável. Código de terceiros não roda no computador de trabalho.
Purple team para dev, simulando vagas falsas e tarefas maliciosas com os próprios engenheiros.
Credenciais, IA e transações
Secret manager com detecção de abuso, que alerte para uso fora do padrão de horário, máquina ou volume.
Tokens de deploy de curta duração, emitidos pelo pipeline e nunca guardados em laptops.
IA interna com menor privilégio e um inventário do que cada ferramenta alcança, com log de uso.
Decisão de risco assinada e um gate que confere essa assinatura antes da última milha.
Revogação ensaiada de tokens, acessos e autorizações já concedidas.
Logs enviados para fora da máquina em tempo real, para sobreviver a quem tenta apagar rastros.
Perguntas para levar ao seu time
Que caminhos chegam ao componente que assina transações ou mensagens de pagamento sem passar pelo motor de risco?
Quem consegue subir um container ou serviço que fala com esse componente, e com que credencial?
Há credenciais de deploy ou segredos de produção em estações de trabalho?
O que nossos agentes de IA internos conseguem executar, e nas máquinas de quem?
Nossos controles conferem o conteúdo exato que será assinado, ou só uma descrição dele?
Quanto tempo levamos para revogar um acesso ou uma autorização já concedida, e quando ensaiamos isso pela última vez?
O que ainda não sabemos
O relatório da Binance deixa várias perguntas sem resposta, e algumas delas podem alterar o aprendizado.
Qual era a ferramenta de IA interna e como ela deu controle sobre outros computadores.
O que o serviço de assinatura conferia antes de assinar, e se ele autenticava quem fazia o pedido.
Se o serviço recebia o conteúdo completo das operações ou apenas hashes para assinar.
Por que ele assinou autorizações para nonces que a carteira ainda não tinha alcançado.
Por que o token de deploy estava na máquina do engenheiro de DevOps em outubro, se o computador dele foi trocado em junho, e quais eram as permissões e a validade desse token.
Se a declaração de 30/10, de que não havia evidência de vazamento de chave privada, se mantém. Ela não foi repetida no relatório de 3/11.
A Binance diz reter alguns detalhes técnicos de propósito, para não orientar futuros ataques. Atualizaremos este advisory se novas informações mudarem a análise.
Glossário
0-day: Vulnerabilidade ainda desconhecida pelo fabricante e sem correção disponível. No caso, a Binance usa o termo para um malware que a proteção de endpoint não reconhecia.
Autorização EIP-7702: Mensagem assinada pela carteira que liga a delegação EIP-7702. Pode ser assinada antes e enviada depois.
Blockhash: Identificador de um bloco recente da Solana. A rede recusa transações que citam um blockhash antigo, o que dá validade curta à assinatura.
Break-glass: Procedimento de emergência que libera ações excepcionais. Na proposta, é um conjunto de regras ainda mais restrito, com destinos fixos e quórum humano.
Chave privada: Segredo que gera a assinatura. Quem assina com ela move os fundos da carteira.
Cold wallet: Carteira mantida fora da internet para guardar a reserva. Equivale ao cofre.
Container: Pacote de software isolado que roda numa máquina ou num cluster.
Coordenador: Componente da custódia MPC que recebe os pedidos de assinatura e os distribui aos nós.
Digest: Resumo criptográfico (hash) de um conteúdo. Qualquer alteração no conteúdo muda o digest.
EIP-7702: Recurso da Ethereum que permite a uma carteira comum passar a executar o código de um contrato escolhido por ela.
Gate de validação: Verificação obrigatória que confere a decisão assinada antes de a carteira assinar qualquer coisa.
Hot wallet: Carteira conectada à internet, usada para pagar saques do dia a dia. Equivale ao numerário do caixa.
HSM: Equipamento dedicado a guardar chaves e assinar com elas, sem deixar a chave sair.
Invariante: Regra fixa que vale em qualquer situação, como um teto de saída por carteira, e que o motor de risco não pode alterar.
LastLedgerSequence: Campo de uma transação na XRP Ledger que define até qual bloco ela pode ser incluída. Depois disso, a transação expira.
Ledger: Registro contábil interno da instituição, com saldos e débitos de cada cliente. Não confundir com a XRP Ledger, que é uma blockchain.
Motor de risco: Sistema que avalia cada pedido, como destino, valor e padrão de uso, e decide se ele pode seguir.
Movimento lateral: Quando o invasor passa de uma máquina comprometida para outras dentro da rede.
MPC: Computação multipartidária: a chave é dividida entre vários servidores, os nós, que assinam juntos sem que a chave inteira exista em um só lugar.
Nonce: Número de sequência de cada operação de uma conta. Impede que a mesma ordem seja executada duas vezes, como o número de um cheque.
On-chain: O que fica registrado na própria blockchain, de forma pública e difícil de desfazer.
Payload: Conteúdo completo da operação que será assinada, como destino, valor e parâmetros.
Permit: Assinatura que autoriza um terceiro a movimentar tokens da carteira sem que a carteira envie uma transação própria.
PSTI: Provedor de serviços de tecnologia da informação que conecta instituições ao SPI e ao STR pela RSFN, em nome delas.
Quórum: Número mínimo de nós ou de pessoas que precisam participar para que uma assinatura ou decisão seja válida.
SAFU: Fundo de reserva da Binance para cobrir perdas de clientes em incidentes.
Serviço de assinatura: Sistema interno que usa a chave da carteira para assinar transações e mensagens antes de enviá-las à rede.
Stablecoin: Token atrelado a uma moeda, geralmente o dólar, como USDT e USDC. O emissor consegue congelar saldos em endereços específicos.
TLP:CLEAR: Marcação do Traffic Light Protocol que permite divulgar o material sem restrição.
Token de deploy: Credencial que permite publicar ou rodar software no ambiente. Quem tem o token age como o pipeline.
Tornado Cash: Serviço que mistura transações na Ethereum para esconder a origem dos fundos.
Última milha: A etapa final antes de o dinheiro sair: assinar a operação e enviá-la à rede ou ao sistema de pagamentos.
Varredura: Retirada repetida dos saldos de uma carteira. No caso, o contrato do invasor esvaziava a carteira delegada à medida que novos depósitos chegavam.
Fontes
Não tivemos acesso ao texto integral do relatório da Binance. Os fatos vêm de trechos do relatório reproduzidos pela imprensa e de análises on-chain independentes.
Cobertura do relatório da Binance
The Hacker News: Binance reveals how fake job interviews and AI tool abuse led to theft
Help Net Security: Fake job interview opened the door to Binance heist
The Register: North Korean fake job interview led to Binance heist
Análises on-chain e técnicas
Atribuição e contexto
Incidentes no Brasil e regulação