A Violação Off-Chain de US$ 387,5 Milhões na Bitget: Além das Chaves e Contratos

Em 24 de setembro de 2026, aproximadamente $387,5M foram transferidos de algumas das carteiras operacionais da Bitget nas redes Ethereum e outras redes EVM, XRP Ledger, Zcash e TRON. A Bitget descreveu as carteiras afetadas como carteiras quentes e mornas (hot e warm wallets). As transações on-chain continham assinaturas de carteira válidas. A Bitget atribuiu o ponto de entrada a uma vulnerabilidade em um produto de segurança de terceiros e afirmou que as chaves privadas e as carteiras frias não foram comprometidas [1, 2].

Com base nas divulgações públicas e nas evidências on-chain disponíveis até 29 de setembro de 2026, 16h35 UTC, a primeira parte resume a sequência do ataque divulgada, as movimentações de fundos subsequentes, o restabelecimento do serviço e as diferentes respostas dos participantes do ecossistema. A segunda parte combina essas observações com nossa experiência em segurança para apresentar uma estrutura de defesa em profundidade para instituições cripto, juntamente com recomendações práticas de segurança.

1. Do Acesso Off-Chain à Perda e Recuperação On-Chain

A Bitget atribuiu o ponto de entrada a uma vulnerabilidade em um produto de segurança de terceiros, mas não divulgou o produto, o componente afetado ou o mecanismo técnico de exploração [1, 2]. Seu relato público descreve o caminho posterior como acesso interno, comandos de saque forjados, verificação de risco contornada, assinaturas válidas e transferências on-chain.

1.1 Linha do Tempo do Ataque e Atribuição

A linha do tempo relatada pela CEO da Bitget, Gracy Chen, juntamente com registros on-chain, mostra como o incidente se desenrolou [3]:

• 18h31 UTC, 24 de setembro: As primeiras movimentações foram 0,84 ETH e 93 TRX. Ambas estavam abaixo do limite de controle de risco da exchange.
• 18h58-20h09 UTC: Chen descreveu dezessete transferências maiores nas redes Ethereum, XRP Ledger, Zcash, BNB Chain, Base, Arbitrum, Optimism e Avalanche, totalizando aproximadamente $361M [3]. Os registros on-chain também mostram uma transferência de 20,59M TRX na TRON às 19h16 UTC.
• Sete minutos após a primeira grande transferência: O sistema de reconciliação da Bitget detectou uma discrepância e interrompeu os saques iniciados por usuários. A linha do tempo da Bitget distingue essa ação do desligamento posterior dos serviços de saque e assinatura de carteira às 21h44 UTC [1].

Chen afirmou que o invasor apagou os rastros deixados pelos comandos fraudulentos [3]. Sobre a atribuição preliminar, ela também disse que o comportamento dos endereços IP e os padrões on-chain eram altamente consistentes com grupos de hackers norte-coreanos conhecidos [4]. Isso permanece como uma atribuição preliminar e não uma conclusão final; a página oficial de incidentes da Bitget não nomeou um grupo responsável, e a investigação continua em andamento [1].

1.2 Fluxo de Fundos e Recuperação Operacional

Os registros on-chain refletidos no rastreador oficial da Bitget mostram que as stablecoins roubadas foram convertidas em ETH em questão de minutos [5]. Diferentemente de USDT ou USDC, ativos nativos como ETH não possuem função de congelamento controlada por um emissor. Esse comportamento é consistente com uma tentativa de reduzir a exposição a congelamentos controlados por emissores, mas não estabelece a identidade ou o nível de experiência do invasor.

O valor oficial afetado posteriormente subiu para aproximadamente $387,5M à medida que a Bitget incorporou uma contabilização mais completa que incluía Zcash e TRON [1]. A Bitget publicou os endereços do invasor, um portal de denúncia para recuperação e uma API de endereços [1, 6], juntamente com o site de rastreamento em tempo real [5]. A visualização de saldos do site relata a distribuição atual, enquanto seu gráfico de fluxo de fundos mapeia os endereços posteriores, serviços, pontes e rotas entre cadeias.

Às 16h35m28s UTC de 29 de setembro, o rastreador oficial relatou $322,67M em posses atuais do invasor, cerca de $632.700 congelados em oito entidades, $312.500 em stablecoins passíveis de congelamento pelo emissor e $55,87M em trânsito ou ainda em análise [5]. O total congelado incluiu $293.507 na NEAR Intents (que relatou aproximadamente $503.000 congelados durante a execução [12]), $239.242 congelados pela Tether e $99.990 congelados pela Circle. As fontes públicas não conciliam os números da NEAR Intents.

No mesmo horário, o explorador de endereços mostrou saldos de endereços atribuídos concentrados em BTC ($288,51M), ZEC ($28,91M) e ETH ($7,17M) [5]. O explorador usa um escopo de classificação diferente da visão geral, portanto seu total de $327,69M em nível de endereço não é diretamente comparável à cifra de $322,67M de posses atuais da visão geral.

A recuperação operacional também avançou. A Bitget retomou os saques de ETH às 08h00 UTC de 29 de setembro. Até as 09h00 UTC, relatou aproximadamente 9.674 ETH em entradas e 9.023 ETH em saídas, de modo que as entradas superaram as saídas em cerca de 651 ETH [7].

1.3 Depois que os Fundos Saem: Resposta da Comunidade

Uma vez que os ativos deixam as carteiras da instituição afetada, a recuperação depende de organizações fora do limite de segurança original. A Bitget abriu seus dados de rastreamento e lançou uma recompensa para assistência elegível que congelou ou recuperou fundos [1, 6]. A Binance afirmou que sua equipe de segurança compartilhou informações de inteligência, rastreou fundos e apoiou a recuperação [8]. O CEO da Bybit, Ben Zhou, ofereceu assistência e atualizou a plataforma de recuperação LazarusBounty, observando que a Bitget havia ajudado a Bybit após seu próprio incidente em 2025 [9]. A resposta da Bybit deu continuidade a um padrão de assistência mútua entre as duas exchanges.

Os provedores de infraestrutura tiveram opções diferentes devido a seus modelos de design técnico e governança. A Bitget pediu à THORChain que recusasse serviço a endereços do invasor publicamente listados e ativamente rastreados. Gracy Chen argumentou que "a descentralização é um princípio de design, não um escudo para facilitar fundos roubados conhecidos" [10]. A THORChain explicou que não oferece suporte a bloqueio seletivo (blacklisting): seus controles de emergência podem interromper atividades mais amplas ou uma rota de cadeia, mas não um único endereço ou transação. Alguns ativos roubados continuaram se movendo de ETH para BTC através da rede [11].

A NEAR Intents relatou uma resposta diferente. Seu sistema de risco SHIELD identificou e bloqueou mais de $50M em fluxos tentados vinculados aos invasores, após filtrar tentativas duplicadas; aproximadamente $503.000 foram congelados durante a execução, enquanto cerca de $166.000 passaram. A NEAR Intents também renunciou à sua parte na recompensa de recuperação da Bitget [12]. A cifra de $50M refere-se a fluxos tentados que o sistema se recusou a processar, e não a um valor congelado ou recuperado.

Grandes recuperações entre cadeias geralmente exigem vários participantes. As exchanges podem reter depósitos ou saques, os emissores de stablecoins podem congelar tokens, os serviços de roteamento podem rejeitar fluxos atribuídos quando seu design permite, e os protocolos de base podem apenas ser capazes de monitorar e compartilhar indicadores. Uma coordenação eficaz começa com cada participante declarando qual ação pode tomar e quais evidências exige.

A intervenção também gera riscos. Uma atribuição incorreta pode bloquear usuários inocentes, enquanto listas negras persistentes podem se expandir de ferramentas de resposta a incidentes para mecanismos mais amplos de restrição de transações. Uma resposta defensável utiliza evidências corroboradas, restrições estreitas e limitadas no tempo, um processo de recurso, registros de ações transparentes e revisão pós-incidente. Quando um sistema não possui controles seletivos, a divulgação transparente de capacidades ajuda a estabelecer expectativas realistas. Onde existe discricionariedade, critérios publicados e tomada de decisão responsável podem apoiar respostas consistentes.

2. Interrompendo e Contendo o Caminho de Exploração: Uma Estrutura Sistemática de Segurança em Defesa em Profundidade

Com base no caminho do incidente e na resposta documentados na Seção 1, juntamente com nossa experiência e expertise, propomos a estrutura de duas camadas abaixo. Para mais informações sobre por que auditorias de código e monitoramento não cobrem todo o caminho de manuseio de fundos, veja Why Crypto Institutions Need Blockchain Penetration Testing [13].

• O caminho de exploração divulgado vai do produto de segurança de terceiros até as transferências on-chain.
• A camada de prevenção e detecção da estrutura contém as três primeiras práticas de segurança. As Seções 2.1 e 2.2 examinam como os controles de acesso privilegiado e a verificação independente de intenção podem impedir que uma invasão da infraestrutura avance até a assinatura. A Seção 2.3 aborda o monitoramento do fluxo de ativos, que detecta e escala anomalias de saída e pode reter depósitos de entrada arriscados.
• A camada de resposta e recuperação contém a quarta prática. Ela pode ser acionada por um sinal de alta confiança proveniente de qualquer ponto da camada de prevenção e detecção, ou por uma falha operacional. A Seção 2.4 aborda a capacidade independente de pausar operações afetadas ou transferir ativos expostos para destinos seguros verificados.

Cada subseção segue a mesma estrutura: o objetivo de segurança, o risco exposto pelo caminho do incidente e as capacidades preventivas, detectivas ou de resposta que as instituições podem estabelecer. Essas práticas devem depender de autoridade e evidências separadas. Juntas, elas reduzem a dependência de qualquer salvaguarda isolada e oferecem às instituições opções preparadas para conter perdas.

2.1 Acesso Privilegiado e Comandos de Saque

O objetivo é impedir que o comprometimento de infraestrutura ou de sistemas privilegiados seja suficiente para criar um comando de saque confiável.

Um produto de terceiros não precisa ter acesso direto à assinatura para afetar a movimentação de ativos. O acesso a credenciais ou sistemas que moldam os comandos de saque pode ser suficiente para determinar o que outro sistema assina. Esses produtos fazem parte da superfície de ataque Web3 em nível institucional [14]. Seu risco depende do valor que podem influenciar e dos sistemas que podem alcançar.

Os controles necessários incluem privilégio mínimo, segmentação de rede, caminhos restritos de atualização e administração, credenciais de curta duração, logs resistentes a adulteração e um procedimento de revogação testado. O acesso interno não deve conceder automaticamente a capacidade de criar um comando de saque confiável. Todo comando deve carregar uma origem autenticada, um identificador de solicitação imutável e uma versão de configuração assinada ou autenticada de outra forma. A criação, aprovação, assinatura e transmissão de comandos devem pertencer a privilégios separados, e os sistemas posteriores devem rejeitar comandos com origens desconhecidas, configurações desatualizadas ou vinculações incompletas.

2.2 Intenção de Saque e Assinatura

O objetivo é impedir que um comando de saque forjado ou manipulado se torne uma transação validamente assinada.

Uma assinatura válida confirma que a chave privada correspondente assinou os dados da transação; ela não estabelece que a solicitação de saque subjacente fosse genuína ou tenha sido aprovada de forma independente.

O limite de assinatura deve reconstruir a transação esperada a partir de um registro confiável independente e comparar todos os campos que podem movimentar valor. No mínimo, a aprovação deve vincular a cadeia, o ativo, o valor, o destinatário, a carteira de origem, o nonce da transação, os limites de taxa, a expiração e a solicitação original de saque ou tesouraria.

O componente que constrói um saque não deve ser a única fonte usada para autorizá-lo. A avaliação de políticas deve consumir dados de conta e risco independentes, enquanto o sistema de assinatura verifica se os dados finais da transação correspondem à intenção aprovada. O conjunto ativo de signatários autorizados, o limite de assinatura, o nonce da transação e a configuração devem corresponder ao estado esperado de produção. Os revisores humanos precisam de uma visualização normalizada da transação gerada a partir dos bytes exatos a serem assinados, e não de um resumo mutável fornecido pelo backend solicitante.

2.3 Fluxos de Ativos de Saída e Entrada

O objetivo é detectar quando a movimentação real de ativos diverge da intenção de negócios reconstruída de forma independente.

Uma instituição cripto pode ser tanto origem quanto destino de fluxos de ativos digitais. O monitoramento de saída deve comparar a atividade real na cadeia com um conjunto independente e reconstruído de saques aprovados. Para preservar a independência, o monitor não deve depender exclusivamente do mesmo comando produzido pelo sistema de saque.

O monitor deve derivar a cadeia, ativo, valor, destinatário, tempo e carteira esperados a partir de um registro de negócios separado. Deve agregar comportamentos em dimensões que os limites por transação não capturam:

• Pequenas transferências de teste seguidas de rápida escalada.
• Reutilização de novos destinatários entre contas, ativos ou cadeias.
• Aumento repentino na velocidade de saques ou na exposição total.
• Saídas simultâneas de múltiplos níveis de carteiras operacionais.
• Mudança para ativos nativos que são mais difíceis de congelar.
• Diferenças entre a solicitação aprovada, os dados da transação assinada e a transação transmitida.

Os controles devem avaliar o valor acumulado, a velocidade, se um destino é novo, o nível da carteira, a facilidade de conversão de um ativo e o comportamento entre cadeias ao longo de uma janela de tempo. As movimentações iniciais de ETH e TRX da Bitget ilustram o valor de avaliar as transações como uma sequência, e não apenas como eventos isolados [3]. Uma incompatibilidade de alta confiança deve acionar o caminho de resposta de emergência descrito na Seção 2.4. Anomalias de menor confiança podem exigir uma segunda aprovação, período de espera do destino, limite reduzido ou retenção temporária de saque.

O monitoramento de entrada deve rastrear depósitos antes de creditá-los e reexaminá-los antes do saque. Deve acompanhar os fundos através de pontes, exchanges descentralizadas (DEXs), serviços de roteamento baseados em intenção e endereços intermediários, pois corresponder apenas ao primeiro endereço do invasor é insuficiente. Correspondências de alta confiança exigem um processo documentado para retenção de fundos, investigação da correspondência, tratamento de recursos e conclusão de qualquer transferência legal.

O compartilhamento rápido de inteligência entre exchanges transforma o monitoramento de entrada em um efeito de rede. Uma instituição pode detectar o incidente enquanto outra vê os proventos. Indicadores compartilhados e legíveis por máquina, além de contatos atualizados, reduzem o intervalo entre a atribuição e a ação.

2.4 Pausa de Emergência e Transferência de Ativos

O objetivo é conter a exposição remanescente assim que um sinal de segurança de alta confiança ou uma falha operacional for identificado.

Os sinais podem incluir violações de acesso privilegiado ou integridade de comandos, incompatibilidades de intenção de saque ou assinatura, atividade on-chain anômala de saída, entrada ou outra, e falhas de reconciliação. A instituição deve então ser capaz de pausar as operações afetadas de assinatura, transmissão, saque ou carteira. Se os ativos permanecerem expostos, ela também deve ser capaz de movê-los da carteira suspeita para destinos seguros predefinidos. Uma pausa ganha tempo de investigação; uma transferência reduz a exposição remanescente.

• Autoridade de pausa independente: A pausa deve permanecer disponível mesmo se o sistema de administração principal for comprometido. Seu escopo deve ser suficientemente restrito para interromper uma cadeia, carteira, ativo ou operação específica, quando a arquitetura permitir. A ativação e a liberação exigem autoridade autenticada, registros resistentes a adulteração, critérios explícitos de retomada e testes sob condições degradadas.
• Continuidade do caminho de transferência: Uma mudança de configuração não deve invalidar o caminho de emergência antigo antes que seu substituto tenha sido implantado, autorizado, assinado, armazenado e testado.
• Prontidão de transações executáveis: As transações de emergência armazenadas podem se tornar desatualizadas devido a mudanças de nonce, saldo insuficiente do token nativo para pagar taxas, mudanças no saldo do ativo de origem, mudanças no mercado de taxas que tornam os limites de taxa assinados inutilizáveis, expiração ou atualizações de configuração. As verificações de prontidão devem validar essas dependências continuamente. Os dados de transação totalmente assinados devem permanecer criptografados e com acesso controlado até que a ação de emergência seja aprovada e esteja pronta para transmissão imediata.
• Cobertura e failover: Cada carteira operacional, cadeia, ativo nativo e token suportado precisa de caminhos de transferência primários e de contingência. A infraestrutura de transmissão e verificação também precisa de redundância entre endpoints de chamada de procedimento remoto (RPC), sistemas de operações e ferramentas de recuperação manual.
• Verificações de conclusão e simulados: O procedimento de resposta a emergências deve definir a conclusão por meio de execução on-chain confirmada, verificação por ativo, verificações de saldo residual e reconciliação entre o estado on-chain e os registros internos. Também deve detectar reorganizações de cadeia e transações com falha. Simulados regulares devem medir o tempo completo de recuperação, desde a detecção até a verificação final do saldo.

Um teste de penetração blockchain autorizado pode transformar suposições entre camadas em evidências, exercitando o ambiente em produção dentro de um escopo acordado [15]. Para testes em produção, Regras de Engajamento (RoE) documentadas devem estabelecer autorização, técnicas permitidas, critérios de interrupção, limites de valor, comunicações, tratamento de evidências e autoridade de pausa antes do início dos testes [16].

Conclusão

O incidente da Bitget não foi nem um comprometimento de chave privada nem uma exploração de contrato inteligente. A Bitget afirmou que os invasores exploraram uma vulnerabilidade em um produto de segurança de terceiros para obter credenciais de acesso à intranet e, em seguida, forjaram comandos de saque que o sistema de carteiras processou em transferências on-chain validamente assinadas [1, 2]. Depois que os ativos saem da instituição afetada, a recuperação se torna um esforço compartilhado do ecossistema. As respostas da Bitget, Binance, Bybit, THORChain e NEAR Intents mostram que os participantes podem responder de maneiras diferentes [8-12]. Como a comunidade pode coordenar essas capacidades de forma rápida e responsável quando surge um grande incidente ou ameaça de segurança continua sendo um desafio mais amplo para o setor de criptoativos.

O caminho posterior conhecido fundamenta a estrutura sistemática proposta aqui, que conecta prevenção e detecção com resposta e recuperação. As instituições podem reduzir a dependência de qualquer salvaguarda isolada ao restringir o acesso privilegiado e autenticar a origem dos comandos, reconstruir de forma independente a intenção de saque aprovada no momento da assinatura, monitorar sequências de saída e proventos de entrada, e manter caminhos de pausa e transferência operáveis de forma independente. A custódia continua essencial, e essas práticas a complementam ao longo de toda a cadeia de manuseio de fundos [13, 15].

Referências

[1] Bitget. Bitget Security Incident: Official Progress Update. https://www.bitget.com/campaigns/bitget-security-incident-2026

[2] Gracy Chen. Security Incident Root-Cause Boundary. https://x.com/GracyBitget/status/2104515761691939026

[3] The Block. Bitget Attacker Tested Risk Controls with Small Transfers Before $388 Million Theft, CEO Says. https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] Gracy Chen. Preliminary Attribution Assessment. https://x.com/GracyBitget/status/2103359775723626736

[5] Bitget. Live Tracing Dashboard and Fund-Flow Graph. https://trace.bgblockchain.xyz/v2#track

[6] Bitget. Live Tracing Information and Recovery Portal. https://x.com/bitget/status/2103485491220033607

[7] Gracy Chen. ETH Withdrawal Resumption Update. https://x.com/GracyBitget/status/2104886024979816508

[8] Binance. Richard Teng Puts Binance's Security Muscle Behind an Industry-Wide Response. https://www.binance.com/en/square/post/09-25-2026-binance-news-richard-teng-puts-binance-s-security-muscle-behind-an-industry-wide-response-370442242243629

[9] Ben Zhou. Bybit Support for Bitget. https://x.com/benbybit/status/2103328213141508335

[10] Gracy Chen. Request to THORChain. https://x.com/GracyBitget/status/2103812967066439817

[11] CoinDesk. THORChain Rejects Bitget Request to Block Hacker as $6 Million Moves to Bitcoin. https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[12] Gracy Chen. NEAR Intents and SHIELD Response. https://x.com/GracyBitget/status/2104602301503816040

[13] BlockSec. From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing. https://blocksec.com/blog/why-crypto-institutions-need-blockchain-penetration-testing

[14] BlockSec. Web3 Attack Surfaces: A Penetration Testing Overview. https://blocksec.com/blog/web3-attack-surfaces-penetration-testing

[15] BlockSec. What Is Blockchain Penetration Testing? Definitions and Boundaries. https://blocksec.com/blog/what-is-blockchain-penetration-testing

[16] BlockSec. Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing. https://blocksec.com/blog/blockchain-penetration-testing-rules-of-engagement