Nenhuma chave roubada, $351 milhões em uma hora — a intrusão na hot wallet da Bitget e a fronteira de confiança do fluxo de aprovação
A Bitget confirmou em 25 de setembro que aproximadamente $351.6 milhões saíram de partes das suas hot wallets e warm wallets em transferências não autorizadas detectadas às 18:31 UTC de 24 de setembro. Relata-se que as suas cold wallets offline não foram afetadas, os saques estão pausados, e a exchange diz que o seu User Protection Fund de $464 milhões cobre a perda integral. Segundo a Bitget, o atacante não levou as chaves privadas, mas alcançou um sistema de backend e falsificou dados de transação para direcionar o fluxo de aprovação para a liberação de fundos. Examinamos a questão da atribuição ao Lazarus e o isomorfismo com o tema do plano de gestão e de identidade que este observatório abordou nas últimas semanas.
Este artigo foi traduzido por máquina.
Às 18:31 UTC de 24 de setembro de 2026, os sistemas de segurança da Bitget sinalizaram transferências não autorizadas a partir de uma parte das suas hot wallets, e os procedimentos de resposta de emergência foram ativados dentro de minutos. No dia 25, a CEO Gracy Chen declarou publicamente que os ativos afetados totalizam aproximadamente $351.6 milhões. A estrutura de carteiras da Bitget tem 3 níveis (hot / warm / cold); segundo a exchange, a intrusão se limita a partes das camadas hot e warm e não alcançou as cold wallets offline, e os saldos das contas dos clientes permanecem coerentes com os ativos que os clientes detêm. Os saques estão temporariamente suspensos, enquanto a negociação e os depósitos continuam. A exchange relata que identificou e sinalizou os endereços dos destinatários, notificou órgãos de aplicação da lei e contratou empresas de segurança de blockchain para rastrear os fundos, e que um relatório completo do incidente — que cobre a causa raiz e as medidas corretivas — seguiria no prazo de 24 horas após o aviso inicial (segundo a declaração de Gracy Chen no X, o aviso oficial de segurança da Bitget, Cryptopotato, InvestingLive e CyberSecurityNews).
Sobre o caminho do ataque, o relato da Bitget é que o atacante alcançou um sistema de backend dentro da sua infraestrutura de carteiras, falsificou dados de transação e, com isso, direcionou o processo de aprovação para a liberação de fundos. Em outras palavras, segundo a exchange, não se trata de um vazamento das chaves privadas que controlam as próprias carteiras. Estimativas iniciais de pesquisadores on-chain (analistas como Arkham Intelligence) se situaram em $174M–$183M, cerca de metade do valor confirmado; observadores on-chain acompanharam movimentos que envolviam ETH, BNB, AVAX, USDT e USDC. Uma transação notável, relatada por Decrypt: uma carteira recém-criada trocou aproximadamente $19.7M de USDT0 (a versão entre cadeias da Tether) por 7,111 ETH em cerca de 6 minutos, pagando até 5% acima do preço de mercado para levar a troca a termo rapidamente. O User Protection Fund da exchange detém $464M, acima da perda, e a Bitget se comprometeu a cobrir o valor integral com ele. A TFTC observa que a composição de ativos do fundo não foi verificada de forma independente.
Sobre a atribuição: o investigador on-chain Specter afirmou que o Lazarus Group ligado à Coreia do Norte está por trás do ataque, e a HackRead relatou que a Bitget suspeita do envolvimento do grupo, enquanto a própria Bitget se recusou a atribuir formalmente, segundo relatos de que «se recusou a especular». Convém caracterizar a atribuição atual como uma «suspeita», não como uma «atribuição». Como contexto, há relatos de que grupos afiliados ao Lazarus estiveram envolvidos em muitas das maiores intrusões em exchanges dos últimos anos — os $1.5B da Bybit em fevereiro de 2025 (o FBI o atribuiu ao Lazarus), os ~$308M da DMM Bitcoin e os ~$234.9M da WazirX em 2024. Segundo a Chainalysis, o roubo de criptoativos em 2025 totalizou $3.4B, dos quais $2.02B (mais de 60%) foram estimados como ligados à Coreia do Norte. Só no primeiro semestre de 2026, $1.1B foi tomado ao longo de 212 incidentes, uma maioria atribuída ao Lazarus Group. A rápida dispersão multicadeia deste incidente, a conversão imediata para ETH e a entrada por um sistema interno sem vazamento de chave coincidem com assinaturas operacionais de grupos ligados a um Estado — mas a semelhança de técnica não é prova de identidade.
Análise (separada do relato factual): o que importa é que «as chaves não foram roubadas» não é necessariamente um bom resultado. Segundo o relato da Bitget, o atacante não levou as chaves de assinatura, mas alcançou o sistema de backend que fornece dados ao processo de aprovação, e falsificou dados de transação. O que se rompeu não é a fronteira criptográfica (as chaves), mas a fronteira de confiança (a fonte de informação da decisão de aprovação). Isso é isomorfo ao tema do «plano de gestão e de identidade» que este observatório tratou nas últimas 2 semanas — o zero-day de OAuth do F5 BIG-IP APM (RCE sem autenticação do lado que emite a identidade), o bypass de autenticação da API de gestão do Cisco ISE (CVSS 10.0) e o alcance de root do Secure Email Gateway por meio de código de parsing — todos compartilhando a estrutura: quando o plano que toma a própria decisão é capturado, não se pode mais confiar na decisão. O fluxo de aprovação da infraestrutura de carteiras é precisamente um plano de decisão desse tipo; a integridade dos saldos e dos dados de transação que lhe são entregues, e a autoridade dos sistemas internos que podem criar ou alterar pedidos de saque, definem a fronteira de confiança. O relatório de 24 horas, se mostrar qual sistema de backend foi comprometido, a quais aprovadores os dados falsificados apareceram e se a aprovação em várias etapas podia distinguir «o caminho dos dados falsificados» de «um pedido genuíno», tornará o ponto de falha mais concreto. Até lá, convém modelar a falha como «comprometimento do caminho dos dados para o processo de aprovação».
Implicações defensivas: (1) Operações que detêm ativos on-chain devem tratar o próprio pipeline de aprovação como uma fronteira de confiança de primeira ordem — não apenas a custódia de chaves, mas a proveniência dos dados de transação (autenticação/atestação na camada de API, visões de dados independentes por aprovador, multissinatura com visões independentes) como exigência de desenho. (2) Definir em conjunto a velocidade de saque e os tetos por cadeia, e monitorar anomalias on-chain (velocidade de troca anômala, spread anômalo em relação ao preço de mercado) como sinais de triagem em tempo real — a passagem USDT0 → ETH deste incidente em ~6 minutos com prêmio de até 5% é exatamente esse tipo de sinal. (3) Como a dispersão multicadeia enfraquece os efeitos de congelamento, combinar de antemão canais de congelamento/rastreamento com as contrapartes de bridges e de DEX. (4) A suspensão dos saques, a divulgação rápida e o compromisso de compensação limitam o dano secundário — mas a compensação só é tão sólida quanto a verificabilidade independente do tamanho do fundo e da composição de ativos, por isso mantenha essa verificabilidade no dia a dia. Os dados factuais aqui se apoiam na declaração de Gracy Chen no X (https://x.com/GracyBitget/status/2103235655879074084), no aviso oficial de segurança da Bitget (https://www.bitget.com/support/articles/12560603896024), na Cryptopotato (https://cryptopotato.com/bitget-reports-351m-hot-wallet-breach-says-user-funds-are-covered/), na InvestingLive (https://investinglive.com/cryptocurrency/hackers-drain-351-6-million-from-bitget-in-possibly-2026-s-biggest-crypto-heist/), na CyberSecurityNews (https://cybersecuritynews.com/bitget-hot-wallet-hacked/), na shattered.io (https://shattered.io/bitget-hack-351-million-2026/) e na HackRead (https://hackread.com/bitget-hack-suspects-north-korea-lazarus-group/). A análise é mantida separada do relato.