Às 20:05 UTC de 29 de outubro de 2026, um único comando começou a drenar a maior exchange de criptomoedas do mundo. Vinte minutos depois, $6.3 bilhões tinham evaporado de carteiras da Binance espalhadas por dez blockchains diferentes. Não foi uma falha criptográfica. Não foi um zero-day em algum smart contract. Foi um laptop de um engenheiro DevOps que, semanas antes, provavelmente abriu o arquivo errado.
Esse é o maior roubo de criptomoedas da história, superando o hack da Bybit em fevereiro de 2025 ($1.5 bilhão) por uma margem absurda. E a parte que deveria tirar o sono de qualquer pessoa que trabalha com infraestrutura: os atacantes não precisaram roubar nenhuma chave privada.
O Laptop que Valia Bilhões
Tudo começou com engenharia social. Pesquisadores de segurança já documentaram a tática: entrevistas de emprego falsas direcionadas a engenheiros DevOps e fintech. Repositórios no GitHub com arquivos Terraform maliciosos. Registries customizados que executam malware quando o desenvolvedor roda um build normal.
O grupo por trás do ataque, o TraderTraitor (ligado ao Lazarus Group da Coreia do Norte), vem aperfeiçoando esse playbook há anos. Eles não vão atrás dos servidores. Vão atrás das pessoas que têm acesso aos servidores. Recentemente, 5.000 devs foram hackeados via backdoor SSH no Cursor usando tática parecida.
No caso da Binance, o alvo foi um engenheiro DevOps. Quando o laptop dele foi comprometido, os atacantes ganharam acesso a algo muito mais valioso que uma senha de Wi-Fi: kubeconfigs, credenciais de cloud, chaves SSH, tokens de CI/CD. Tudo que um engenheiro DevOps precisa para fazer seu trabalho é, coincidentemente, tudo que um atacante precisa para drenar bilhões.
A TRM Labs e a Chainalysis atribuíram o ataque ao TraderTraitor “com alta confiança”. O CEO da Chainalysis, Jonathan Levin, foi direto: “Avaliamos que o hack da Binance de $6.4B foi provavelmente realizado pelo grupo norte-coreano TraderTraitor devido a conexões com hacks anteriores.”
A Anatomia de 20 Minutos que Mudaram o Mercado Cripto
O ataque não foi improvisado. A preparação começou pelo menos 36 horas antes da execução. Veja a timeline:
| Momento | O que aconteceu |
|---|---|
| ~36h antes | Fase de preparação e reconhecimento interno |
| Dia anterior | Wallets de destino financiadas via Tornado Cash |
| Horas antes | Código testado contra três carteiras de baixo valor |
| 20:05 UTC (29/out) | Início da drenagem |
| 20:20 a 20:23 UTC | Sweep principal concluído em dez blockchains |
Foram 18 minutos entre o primeiro movimento e a conclusão do ataque principal. O que aconteceu nesses 18 minutos é tão sofisticado que merece ser destrinchado.
Como os Fundos Foram Movidos
Uma única transação carregou 50 autorizações pré-assinadas, cada uma apontando a hot wallet da Binance para um contrato sweeper controlado pelo atacante. Em minutos, essa transação moveu:
- 167.464 ETH
- 63 tokens adicionais
- 1.615 bilhão de USDT
- Ativos em 10 blockchains diferentes
Na rede Ethereum especificamente, os atacantes utilizaram autorizações EIP-7702 para forçar uma carteira da Binance a executar código controlado pelo atacante e transferir fundos repetidamente.
Repare no detalhe: nenhuma chave privada vazou (diferente do caso onde a chave privada era literalmente o número 4). A TRM Labs confirmou que “não há evidência de que qualquer chave privada de carteira tenha vazado”. Os atacantes não roubaram a chave. Eles controlaram o sistema que pede para a chave assinar. É como se alguém não tivesse arrombado o cofre do banco, mas convencido o gerente a abrir para ele.
Por Que DevOps é o Novo Vetor de Ataque
Aqui está o problema fundamental: tratamos laptops de desenvolvedores como dispositivos de produtividade, mas na prática eles são infraestrutura de produção.
O laptop de um engenheiro DevOps típico contém:
~/.kube/config → Acesso direto a clusters Kubernetes
~/.aws/credentials → Credenciais AWS com permissões amplas
~/.ssh/id_rsa → Chaves SSH para servidores de produção
~/.docker/config.json → Tokens de registry
.env → Variáveis de ambiente com secrets
CI/CD tokens → Acesso a pipelines de deploy
Comprometer um desses laptops é, em termos práticos, comprometer toda a infraestrutura. E os times de segurança sabem disso, mas raramente aplicam os mesmos controles de um servidor de produção.
O co-CEO da Binance, Richard Teng, reconheceu depois que o ataque envolveu “um processo mais complexo” do que a exploração de um único laptop. A investigação revelou múltiplos pontos de falha. Mas o laptop foi a porta de entrada.
A Comparação Inevitável com Bybit
Quem acompanha segurança cripto já viu esse filme antes:
| Aspecto | Bybit (Fev/2025) | Binance (Out/2026) |
|---|---|---|
| Valor roubado | $1.5 bilhão | $6.3 bilhões |
| Vetor de ataque | Infraestrutura comprometida | Infraestrutura comprometida |
| Criptografia quebrada? | Não | Não |
| Atribuição | TraderTraitor (Coreia do Norte) | TraderTraitor (Coreia do Norte) |
| Tempo de execução | Minutos | ~20 minutos |
| Staging pré-ataque | Sim (Tornado Cash) | Sim (Tornado Cash) |
Ambos os incidentes passaram por infraestrutura e pessoas comprometidas, não por criptografia quebrada. A lição que ninguém aprendeu entre fevereiro de 2025 e outubro de 2026 é que engenharia social e supply chain attacks são mais eficazes que qualquer exploit de smart contract.
O Que Foi Congelado (e o Que Sumiu)
A resposta da indústria foi rápida. Circle e Tether congelaram stablecoins quase que imediatamente. No total, cerca de $3 bilhões foram congelados em transfers suspeitas.
Mas o que não é freezable continuou andando:
| Tipo de ativo | Status |
|---|---|
| USDT e USDC | ~$2.7 a $2.8 bi congelados |
| ETH | Sob controle do atacante |
| BTC | Sob controle do atacante |
| XRP | Sob controle do atacante |
| TRX | Sob controle do atacante |
| Outros tokens | Parcialmente congelados |
Isso expõe uma ironia central das stablecoins: elas são “descentralizadas” até o emissor decidir congelar seu saldo. Por outro lado, é exatamente essa capacidade que permitiu recuperar quase metade do valor roubado.
A Binance ativou seu fundo SAFU (Secure Asset Fund for Users) e comprometeu-se a cobrir todas as perdas com recursos próprios. Depósitos foram retomados normalmente, mas saques permaneceram suspensos durante a remediação de segurança, com previsão de retorno em 45 horas.
Tornado Cash: A Lavanderia de Dinheiro On-Chain
Se você trabalha com blockchain, já ouviu falar do Tornado Cash. Se não ouviu, é um mixer de criptomoedas que funciona como uma lavanderia de dinheiro descentralizada. Você deposita ETH em um pool, recebe um “note” criptográfico, e saca de outro endereço sem conexão on-chain com o depósito original.
No hack da Binance, os atacantes usaram Tornado Cash para:
- Financiar as wallets operacionais dias antes do ataque, fazendo saques pequenos para não chamar atenção
- Obscurecer a origem dos fundos após o roubo
- Dificultar o rastreamento por ferramentas de análise blockchain
Esse padrão é uma assinatura do TraderTraitor. Tanto no hack da Bybit quanto no da KelpDAO (abril de 2026), os mesmos passos foram observados: saques pequenos do Tornado Cash financiando uma wallet operacional, staging que começa bem antes do roubo, e assinaturas obtidas antecipadamente para serem executadas em rajada.
EIP-7702: A Arma que Poucos Conheciam
Um detalhe técnico que passou despercebido na maioria das coberturas: os atacantes usaram autorizações EIP-7702 na rede Ethereum. Essa proposta, implementada na atualização Pectra em março de 2025, permite que contas EOA (Externally Owned Accounts) deleguem execução para contratos smart temporariamente.
Na prática, isso significa que uma carteira comum pode “virar” um smart contract por uma transação. O atacante usou isso para transformar a hot wallet da Binance em um executor automático que rodava código malicioso, drenando tokens em loop sem precisar de múltiplas aprovações.
É uma feature legítima do Ethereum, criada para melhorar a experiência do usuário com account abstraction. Mas nas mãos de alguém com acesso ao sistema de signing, vira uma ferramenta de extração em massa. Ninguém na Ethereum Foundation imaginou esse caso de uso? Provavelmente sim. Mas a feature foi aprovada mesmo assim, porque a comunidade priorizou UX sobre segurança operacional.
Isso abre um precedente preocupante. Qualquer exchange que usa hot wallets Ethereum com EOAs agora precisa considerar que um atacante com acesso ao signing pode transformar a carteira em um bot de drenagem automatizado, sem nem precisar mover as chaves privadas.
O Que Deveria Mudar (Mas Provavelmente Não Vai)
Depois de cada hack bilionário, a indústria faz as mesmas promessas. Aqui está o que realmente deveria acontecer:
1. Laptops de Devs São Infraestrutura de Produção
Trate-os como tal. Hardware attestation, endpoint detection, segmentação de rede. Se o laptop do seu engenheiro DevOps pode acessar o sistema de signing em produção direto, sem intermediários, seu modelo de segurança tem um buraco do tamanho de $6.3 bilhões.
2. Credenciais de Curta Duração
Kubeconfigs que não expiram são uma bomba-relógio. Tokens de CI que duram para sempre são uma bomba-relógio. Implemente credenciais de curta duração com just-in-time access. Ferramentas como o HashiCorp Vault existem exatamente para isso:
# Em vez disso (estático, eterno, perigoso):
export AWS_ACCESS_KEY_ID=AKIA...permanente...
# Faça isso (temporário, escopado, auditável):
vault read aws/creds/deploy-role
# Gera credenciais que expiram em 1 hora
3. Policy Constraints no Signing Service
Um sistema de signing que aceita 50 autorizações de uma vez, movendo bilhões sem nenhum circuit breaker, é um sistema desenhado para ser explorado. Limites de valor por transação, allowlists de destinos, rate limiting por janela de tempo: nada disso é tecnologia nova.
# Exemplo simplificado de policy constraint
def validate_withdrawal(request):
if request.amount > MAX_SINGLE_WITHDRAWAL:
raise PolicyViolation("Valor excede limite")
if request.destination not in APPROVED_ADDRESSES:
raise PolicyViolation("Destino não aprovado")
recent = get_withdrawals_last_hour()
if sum(r.amount for r in recent) + request.amount > HOURLY_LIMIT:
raise PolicyViolation("Limite horário excedido")
return approve(request)
4. Anomaly Detection para Autorizações em Lote
50 autorizações pré-assinadas apontando para contratos desconhecidos deveriam acionar todos os alarmes. Se o seu sistema de monitoramento não consegue detectar isso em tempo real, ele não serve para nada.
5. Hot Wallets com Saldo Mínimo
A regra mais simples de todas: não guarde $6.3 bilhões em hot wallets. Cold storage existe por um motivo. Mova para hot wallets apenas o necessário para operações do dia.
O Elefante na Sala: $2.4 Trilhões em Exchanges Centralizadas
O hack da Binance levanta uma questão que a indústria cripto prefere ignorar: exchanges centralizadas são single points of failure com trilhões de dólares em custódia. O problema não é “a Binance tinha segurança ruim”. O problema é que qualquer sistema centralizado grande o suficiente será alvo de ataques com recursos de nação-estado.
A Coreia do Norte financia parte significativa do seu programa nuclear com criptomoedas roubadas. Estimativas da ONU colocam o total acumulado em mais de $6 bilhões antes mesmo do hack da Binance. Com esse ataque, o número provavelmente ultrapassou $9 bilhões.
Quando o incentivo financeiro é desse tamanho, nenhuma exchange está segura. A questão não é se a próxima vai ser hackeada, mas quando. E se o alvo for uma exchange menor, sem um fundo SAFU de bilhões, os usuários é que pagam a conta.
Lições para Quem Não Trabalha com Cripto
Mesmo que você nunca tenha tocado em uma criptomoeda, esse hack tem lições relevantes. O vetor de ataque (engenharia social + laptop comprometido + escalação para infraestrutura) se aplica a qualquer empresa que:
- Usa Kubernetes em produção
- Tem engenheiros com acesso privilegiado
- Guarda secrets em arquivos locais
- Não implementa zero-trust internamente
Algumas perguntas que todo líder técnico deveria se fazer:
- Se o laptop do meu melhor engenheiro DevOps for comprometido amanhã, quanto tempo até alguém perceber?
- Quais credenciais nesse laptop dão acesso direto a produção?
- Existe algum circuit breaker que impedira operações anômalas, mesmo com credenciais válidas?
- Meus logs e alertas conseguem detectar um padrão de acesso incomum em tempo real?
Se a resposta para qualquer uma delas for “não sei”, você tem trabalho a fazer.
O Que Vem Agora
A Binance afirmou que vai cobrir todos os prejuízos. Saques estão sendo restaurados gradualmente. A investigação continua, com múltiplas firmas de blockchain intelligence rastreando os fundos não congelados.
Para o mercado cripto, o impacto de curto prazo já passou. Bitcoin caiu brevemente após a notícia, mas recuperou nas 24 horas seguintes. O mercado, aparentemente, já precificou que hacks bilionários são um custo de fazer negócios nesse ecossistema.
Para a comunidade de segurança, esse incidente reforça algo que deveria ser óbvio: a criptografia forte não protege nada se as pessoas e os processos ao redor dela são fracos. Você pode ter a melhor criptografia do mundo no seu vault de signing. Se o cara que opera o vault caiu num phishing de entrevista de emprego falsa, seus bilhões vão embora em 20 minutos.
Fontes: Wired, Forbes, HackRead, TRM Labs via CNBC













