Em 29 de outubro, a Binance perdeu cerca de US$ 6,3 bilhões. O caminho até lá passou por um software adulterado, uma entrevista de emprego falsa e um token armazenado indevidamente num notebook. Cada um desses passos poderia ter sido barrado por controles básicos.
O que aconteceu
Foi o maior roubo de criptoativos já registrado, mais de quatro vezes o recorde anterior (o ataque à Bybit, de US$ 1,5 bilhão, em 2025). O FBI atribuiu a ação ao TraderTraitor, grupo ligado à Coreia do Norte e apontado também no caso Bybit. O relatório preliminar da própria Binance, publicado em 3 de novembro, mostra uma campanha de meses, em quatro etapas.
Em junho de 2026, uma pessoa do time de DevOps de carteiras procurou uma ferramenta de IA para programação e instalou uma versão adulterada do Homebrew, um gerenciador de pacotes muito usado em Mac. A Binance detectou, trocou a máquina e as credenciais. Só que o atacante já tinha mapeado a função dessa pessoa e quem trabalhava com ela.
Em setembro de 2026, outra pessoa da engenharia foi abordada por um falso recrutador. Depois de conversas com um suposto RH e um suposto CEO, recebeu um teste técnico e rodou o código no computador de trabalho. O teste instalou um malware que as ferramentas de proteção de endpoint não detectaram.
A partir desse computador, em 20 de outubro, e usando uma ferramenta interna de IA da própria Binance, o atacante assumiu as máquinas de mais duas pessoas. Em uma delas, encontrou um token com permissão para publicar containers, armazenado indevidamente no notebook.
Em 29 de outubro, com esse token, o atacante subiu um container, executou um script e chegou ao serviço interno que assina as transações das carteiras. Os saques saíram por fora do fluxo normal, em questão de horas.
Até 31 de outubro, 98% dos ativos haviam sido repostos e US$ 2,85 bilhões congelados ou interceptados. A Binance cobriu as perdas com reservas próprias, e os clientes da exchange não devem ter prejuízo. Mesmo assim, a própria empresa reconheceu que o ataque não deveria ter acontecido.
Uma corrente de falhas básicas
Nenhuma etapa dependeu de uma falha inédita nos sistemas da Binance. Cada uma explorou algo que controles básicos existem para impedir. Bastava quebrar um elo para o ataque parar no meio do caminho.
- Software instalado de fonte não oficial: inventário de software em cada máquina e instalação só a partir de fontes aprovadas.
- Pessoa enganada por um falso recrutador (fator humano): time treinado para reconhecer engenharia social e golpes de recrutamento.
- Código de um desconhecido rodando na máquina de trabalho: código não confiável só em ambiente isolado (VM ou sandbox).
- Malware que passou despercebido: EDR em 100% das máquinas, com alertas monitorados e situações suspeitas investigadas, e outras camadas para quando ele falhar.
- Ferramenta interna com acesso demais: menor privilégio e revisão periódica de acessos, principalmente para contas de serviço e ferramentas de IA.
- Token de produção armazenado indevidamente num notebook: credenciais de curta duração, guardadas em cofre e nunca soltas em estação de trabalho ou escritas no código (hard-coded).
- Acesso direto ao sistema que assina transações: segregação de funções, aprovação por duas pessoas e monitoramento comportamental para alertar sobre operações fora do padrão.
O básico bem feito
Cinco disciplinas, feitas com consistência, quebram a maior parte das correntes de ataque.
- EDR e monitoramento: Foi o EDR que detectou o primeiro comprometimento, em junho. Na segunda tentativa, o malware passou. EDR é obrigatório, mas precisa de alguém olhando os alertas e investigando situações suspeitas, além de outras camadas por trás dele.
- Controle de acessos: Todo acesso no mínimo necessário, principalmente para contas de serviço e agentes de IA. MFA resistente a phishing, revisão periódica de permissões e duas pessoas para qualquer ação crítica.
- Gestão de segredos: Tokens e chaves de produção nunca ficam em notebooks nem escritos no código, as chamadas credenciais hard-coded. Têm validade curta, ficam em cofre e têm o uso registrado. Se um notebook for comprometido, o estrago fica pequeno.
- Patches e software: Aqui a porta de entrada foi um software adulterado, e não uma falha sem correção. A disciplina é a mesma: saber o que roda em cada máquina, de onde veio e se está atualizado. Muitas invasões ainda exploram vulnerabilidades com correção disponível há meses.
- Pessoas e resposta a incidentes: Desenvolvedores viraram alvo preferido, porque têm acesso alto e instalam muita coisa. Treine o time para reconhecer vagas falsas e testes técnicos maliciosos. E, ao detectar um comprometimento, pergunte o que mais o atacante pode ter levado, em vez de só trocar a máquina.
Segurança raramente depende da ferramenta mais cara. Depende do básico bem feito, todos os dias.
5 perguntas para fazer esta semana
Leve esta página para a próxima reunião com o time de tecnologia. As respostas marcadas em laranja pedem tratamento prioritário. Um “não sei” em qualquer pergunta também é sinal de alerta.
1. Qualquer pessoa consegue instalar qualquer software no computador corporativo?
No caso Binance: tudo começou com um Homebrew adulterado, instalado por conta própria.
Respostas: Sim / Não / Não sei.
2. Existe algum token ou chave de produção salvo em notebook ou em código? Com qual validade?
No caso Binance: um token de deploy armazenado indevidamente num notebook abriu o último passo do ataque.
Respostas: Sim / Não / Não sei.
3. Quem tem acesso aos sistemas críticos hoje, e essas pessoas realmente precisam dele? Principalmente ferramentas de IA e contas de serviço.
No caso Binance: uma ferramenta interna de IA ajudou o atacante a pular de máquina em máquina.
Respostas: Sabemos / Em parte / Não sei.
4. O EDR cobre 100% das máquinas, incluindo os Macs do time de desenvolvimento? Quem olha os alertas, e em quanto tempo?
No caso Binance: o EDR pegou o primeiro ataque, em junho, e deixou passar o segundo, em setembro.
Respostas: Sim / Não / Não sei.
5. Se um computador fosse comprometido hoje, em quanto tempo vocês saberiam? E o que fariam depois?
No caso Binance: em junho a máquina foi trocada, mas o atacante já conhecia o time. Em outubro, voltou pela máquina da mesma pessoa.
Respostas: Temos plano / Em parte / Não temos.
Como a Taura pode ajudar
Trabalhamos lado a lado dos nossos clientes para identificar e corrigir exatamente esses elos, com a profundidade técnica de quem já esteve do lado do cliente.
Diagnóstico do básico (Security Compliance): Cybersecurity Assessment com base em CIS Controls v8, NIST CSF e nos controles de cibersegurança do Bacen, para mostrar onde estão os elos fracos e o que priorizar primeiro.
Revisão de acessos e identidades (Cloud Security): Em AWS, GCP e Azure, removemos privilégios excessivos, credenciais de longa duração e exposições públicas.
Simulado de ataque com funcionário comprometido (Offensive Security): Simulamos um ataque real a partir de um notebook invadido e medimos até onde ele chega, antes que alguém faça isso de verdade.
Credenciais hard-coded e DevSecOps (Application Security): Encontramos senhas, tokens e chaves escritos no código antes do atacante, tiramos os segredos dos notebooks e protegemos o pipeline.
Phishing e resposta a incidentes (Security as a Service): Testes de phishing para o time reconhecer o golpe e um plano de resposta para a empresa saber o que fazer quando algo escapar.
Time de segurança contínuo (Security as a Service): Tudo isso de forma recorrente, com monitoramento e governança sobre possíveis incidentes, para empresas que não têm, ou não querem montar, uma equipe interna.
Nossa equipe reúne:
- 35+ anos somados de experiência do time em cybersecurity.
- Bacen, PCI-DSS e ISO 27001: normas já implementadas em ambientes de alta complexidade.
- OSCP, OSEP, OSWE, AWS, GCP e Azure: certificações do time.
Plataforma Preemptive Security
Na Binance, a corrente só ficou visível depois do ataque. A Plataforma da Taura mostra a sua exposição real antes. Ela se conecta ao seu ambiente e usa IA para encontrar as brechas antes do atacante.
A plataforma atua em quatro etapas:
- Controles: Confere os controles com IA. Confere cada controle contra SOC 2, ISO 27001, PCI DSS e NIST CSF.
- Cenários: Antecipa cenários de ataque. Encadeia as brechas e mostra por onde o atacante chegaria aos seus dados. É a corrente da Binance, vista antes.
- Impacto: Precifica o impacto em R$. Converte cada cenário em reais, para priorizar pelo que mais custa ao negócio.
- Correção: Corrige cada gap passo a passo. Cada gap vira uma ação priorizada no plano de tratamento, com o passo a passo para corrigir.
Exemplo de cenário encadeado:
Internet → EC2 exposta → Role com Admin total → Dados no S3
Exemplo ilustrativo de como a plataforma mostra uma corrente de brechas.
A plataforma olha para contas AWS, código, credenciais hard-coded, superfície externa (ASM) e credenciais vazadas.
No dia a dia, riscos, planos de tratamento, aderência a frameworks e indicadores de maturidade em um só lugar, com monitoramento e governança sobre possíveis incidentes.
Do controle ao plano de correção, em velocidade de máquina.
Quantos elos dessa corrente existem hoje na sua empresa? Agende 30 minutos com a gente. Você sai da conversa com uma lista clara do que priorizar. Fale com nossos especialistas.
