~$418M Perdidos: Explorações do Bitget e NEAR Intents | BlockSec Weekly

Nas últimas duas semanas (21/09/2026 - 04/10/2026), 8 incidentes de segurança blockchain causaram perdas totais estimadas em aproximadamente US$ 418,4 milhões.

Motivos da seleção

• Bitget: O incidente é responsável pela maior parte das perdas do período e traça um comprometimento fora da cadeia por meio de comandos de saque forjados que levaram a transferências válidas na cadeia, sem comprometimento de chave privada ou de contrato inteligente.
• NEAR Intents: Uma falha na validação de reembolso e a ausência de rollback de estado transformaram a resolução malsucedida de um depósito entre cadeias em saldos internos sem lastro que conseguiram passar pelo caminho normal de saque.

Bitget

Em 24 de setembro, aproximadamente US$ 387,5 milhões deixaram partes da infraestrutura de hot e warm wallets da Bitget nas redes Ethereum e outras redes EVM, XRP Ledger, Zcash e TRON. As transações na cadeia continham assinaturas de carteira válidas. A Bitget afirmou que o atacante explorou uma vulnerabilidade em um produto de segurança de terceiros, obteve credenciais de acesso à intranet e forjou comandos de saque, enquanto as chaves privadas e as cold wallets permaneceram seguras[1][2].

Visão Geral do Incidente

Investigações independentes acrescentam detalhes à trajetória do ataque, sem citar os nomes dos dois produtos de segurança afetados. A atividade maliciosa mais antiga identificada no Produto A remonta a 31 de agosto, quando uma vulnerabilidade zero-day afetou um serviço em um dos nós. O invasor também obteve acesso privilegiado a dois dispositivos de segurança, implantou um web shell, estabeleceu uma conexão de comando e controle no Produto B e realizou um movimento lateral até o servidor de processamento de carteiras (wallet job server) do ambiente de produção.

O invasor utilizou a identidade de um funcionário interno para acessar a plataforma de gerenciamento do Produto B. Os investigadores também recuperaram uma ferramenta de saque personalizada, capaz de forjar parâmetros de controle de risco, criar solicitações de saque e acionar o processo de retirada de fundos. A forma como o invasor transitou entre todos os sistemas envolvidos permaneceu sob investigação. As blockchains públicas registraram apenas as transferências finais assinadas, e não essas operações preliminares.

Os registros na cadeia mostram que as primeiras movimentações foram de 93 TRX e, 11 segundos depois, 0,84 ETH às 18h31 UTC. A linha do tempo atual da Bitget registra a detecção de reconciliação às 19h05 UTC e a ativação de sua resposta emergencial de nível mais alto às 19h14 UTC[1]. Uma transferência separada de 20,59M TRX chegou ao endereço TRON controlado pelo atacante às 19h16 UTC; Chen descreveu 17 transferências maiores em outras oito redes, totalizando aproximadamente US$ 361M[3]. A contenção começou às 19h40 UTC, e os serviços de saque e assinatura de carteira foram desativados às 21h44 UTC[1].

Status dos Fundos e Resposta da Comunidade

Às 16h35m28s UTC de 29 de setembro, o rastreador de ativos oficial da Bitget reportou US$ 322,67 milhões em posses atuais do atacante, cerca de US$ 632.700 congelados, US$ 312.500 em stablecoins passíveis de congelamento pelo emissor, e US$ 55,87 milhões em trânsito ou ainda sob análise. Sua visão de endereços separada mostrou saldos concentrados em BTC (US$ 288,51M), ZEC (US$ 28,91M) e ETH (US$ 7,17M); essa visão usa um escopo de classificação diferente do visão geral.

A Binance compartilhou inteligência e apoiou o rastreamento de fundos, enquanto a Bybit atualizou o LazarusBounty e ofereceu assistência[4][5]. Os provedores de infraestrutura fizeram escolhas diferentes. A Bitget pediu à THORChain que recusasse serviço aos endereços do atacante listados, argumentando que a descentralização não deveria proteger a circulação de fundos conhecidamente roubados[6]. A THORChain rejeitou a lista negra seletiva e afirmou que seus controles poderiam interromper uma atividade mais ampla ou uma rota de cadeia, não um único endereço ou transação[7].

A NEAR Intents informou que o SHIELD identificou e bloqueou mais de US$ 50 milhões em tentativas de fluxos vinculados ao atacante, após a filtragem de duplicatas. Aproximadamente US$ 503.000 foram congelados durante a execução e cerca de US$ 166.000 passaram; o valor de US$ 50 milhões refere-se a fluxo tentado, não a um montante congelado ou recuperado[8]. O rastreador posteriormente classificou US$ 293.507 como congelados na NEAR Intents, e as fontes públicas não reconciliam a diferença.

Lições Aprendidas

• O atacante entrou por meio de produtos de segurança de terceiros, alcançou o servidor de jobs da carteira e transformou solicitações de saque forjadas em transações validamente assinadas. Qualquer produto de terceiros com esse alcance pertence ao perímetro efetivo de segurança de ativos: as instituições devem isolá-lo, restringir identidades e privilégios, monitorar seu comportamento e verificar de forma independente a intenção de saque antes de assinar.
• A autoridade de recuperação estava fragmentada entre exchanges, emissores de stablecoins, serviços de roteamento e protocolos base, de modo que nenhum participante conseguiria gerenciar a resposta sozinho. A instituição afetada precisa compartilhar rapidamente endereços verificados e dados de transações, enquanto provedores de infraestrutura e equipes de segurança coordenam o rastreamento, o congelamento, a triagem de transações e a recuperação dentro de suas restrições técnicas e de governança.
• Para os controles preventivos derivados deste incidente, consulte Bitget's $387.5M Off-Chain Breach: Beyond Keys and Contracts, que desenvolve uma estrutura de defesa em profundidade para acesso privilegiado, intenção de saque, monitoramento de fluxo de ativos e resposta a emergências.

NEAR Intents

Entre 30 de setembro e 1º de outubro, a NEAR Intents perdeu aproximadamente US$ 3,87 milhões depois que uma falha de validação de reembolso e uma ausência de rollback de estado no intents.near criaram um saldo interno sem o lastro de ativo correspondente. O atacante usou esse saldo para obter assinaturas válidas de saque do HOT MPC e liberar USDT real do cofre do protocolo na BNB Chain[9][10].

Contexto

A NEAR Intents é um sistema de execução de intenções na NEAR. Seu contrato principal, intents.near, mantém omni-ativos, registra os saldos internos dos usuários e processa trocas e saques de ativos com base em intenções assinadas.

Para um depósito entre cadeias, um cofre na cadeia de origem bloqueia o ativo real. A Omni cria o omni-ativo correspondente na NEAR e o transfere para intents.near, que credita o saldo interno do usuário.

Para um saque, intents.near pede à Omni que queime o omni-ativo correspondente e crie um registro de saque. O HOT MPC verifica esse registro e emite uma assinatura. O cofre na cadeia de destino verifica a assinatura antes de liberar o ativo real. Esse processo exige que os saldos internos registrados pelo intents.near permaneçam lastreados pelos omni-ativos que o contrato de fato possui.

Análise da Vulnerabilidade

O caminho de depósito creditava o saldo interno do destinatário antes que a transferência entre contratos tivesse sido totalmente resolvida. Durante a resolução, resolve_deposit_internal() limitava o requested_refund, controlado pelo destinatário, pelo saldo total do destinatário naquele token, mas não por deposited, o valor efetivamente transferido no depósito que estava sendo resolvido. O saldo total mostrava apenas o que a conta poderia pagar; deposited definia o que essa transferência tinha permissão de reembolsar. Sem esse segundo limite, um destinatário com um saldo preexistente grande poderia solicitar um reembolso muito acima do depósito atual[10].

Para um depósito em lote com muitos IDs de token longos, os valores de reembolso incorretos ampliaram o MtBurnEvent serializado. O caminho check_refund().unwrap_or_panic_display().emit() então entrava em pânico quando o evento excedia o limite total de comprimento de log da NEAR, fazendo com que o recibo mt_resolve_deposit falhasse.

O saldo interno havia sido creditado em um recibo anterior. O pânico reverteu as tentativas de dedução de saldo e de suprimento do recibo de callback, mas não reverteu aquele crédito anterior. A Omni então devolveu os ativos transferidos ao remetente, deixando o atacante com um saldo interno sacável que já não correspondia aos omni-ativos mantidos por intents.near. A vulnerabilidade combinou uma falha de validação de reembolso com a ausência de rollback de estado ao longo da sequência assíncrona de recibos.

Análise do Ataque

A reconstrução a seguir é baseada em informações disponíveis publicamente[11].

Fase 1: Criar um Saldo Interno Sem Lastro na NEAR

• Passo 1: O atacante depositou 10 USDT por meio do cofre Omni/HOT na BNB Chain, dando à conta destinatária maliciosa um saldo de omni-ativo diferente de zero na NEAR.

• Passo 2: O atacante chamou mt_batch_transfer_call() em v2_1.omni.hot.tg. Em mt_on_transfer(), intents.near primeiro creditou o destinatário por meio de deposit(), depois notificou o destinatário malicioso e passou sua resposta para mt_resolve_deposit().

• Passo 3: O destinatário malicioso retornou um requested_refund muito acima do depósito atual. Como a validação usava o saldo total do destinatário naquele token como limite, o valor anormal seguiu adiante no processamento de reembolso.

• Passo 4: Nas entradas em lote, os valores de reembolso superdimensionados fizeram o MtBurnEvent serializado exceder o limite total de comprimento de log da NEAR. O callback mt_resolve_deposit entrou em pânico, o que reverteu suas tentativas de dedução de reembolso, mas não o crédito interno já confirmado pelo recibo anterior. A Omni devolveu os ativos transferidos, enquanto o saldo creditado permaneceu disponível em intents.near. Repetir essa sequência criou um saldo sem lastro que o atacante podia sacar.

Fase 2: Sacar Ativos Reais do Cofre na BNB Chain

• Passo 5: Às 18h57 e 20h05 UTC de 30 de setembro, o atacante usou autorizações válidas do HOT MPC para testar o cofre da BNB Chain com saques de 10 USDT e 11 USDT. A primeira transação de teste confirmou que o cofre aceitava a autorização anterior.

• Passo 6: Das 23h54 UTC de 30 de setembro até as 06h08 UTC de 1º de outubro, o atacante fez cinco saques maiores de 800.000 USDT, 1,2M USDT, 1,5M USDT, 330.000 USDT e 35.000 USDT. Essas transações liberaram um total de 3,865M USDT do cofre.

Conclusão

A NEAR Intents foi explorada por meio de validação incorreta de reembolso e ausência de rollback após a falha na resolução do depósito. O atacante usou solicitações de reembolso superdimensionadas para preservar o crédito interno depois que os ativos subjacentes já haviam sido devolvidos, e então usou esse saldo sem lastro para solicitar saques. A Omni criou os registros de saque correspondentes, o HOT MPC os assinou e o cofre na BNB Chain liberou USDT real.

O processamento de reembolso deve limitar o reembolso de cada token ao valor do depósito que está sendo resolvido. O protocolo também deveria tornar atômicos o crédito de saldo e a resolução, sempre que possível, ou aplicar um rollback compensatório garantido após uma falha. Antes de emitir assinaturas de saque, deveria reconciliar os saldos internos agregados com as reservas reais de omni-ativos e pausar os saques em caso de qualquer divergência. A geração de eventos também precisa ter limites para que um log superdimensionado não consiga abortar um caminho de resolução crítico para o estado.

Referências

[1] https://www.bitget.com/academy/bitget-security-incident-what-happened-timeline-impact-response

[2] https://x.com/GracyBitget/status/2104515761691939026

[3] https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] 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

[5] https://x.com/benbybit/status/2103328213141508335

[6] https://x.com/GracyBitget/status/2103812967066439817

[7] https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[8] https://x.com/GracyBitget/status/2104602301503816040

[9] https://x.com/near_intents/status/2105642219357241796

[10] https://github.com/near/intents/pull/362

[11] https://x.com/Phalcon_xyz/status/2105680009687957909

Sobre a BlockSec

A BlockSec é uma provedora full-stack de segurança blockchain e conformidade cripto. Construímos produtos e serviços que ajudam os clientes a realizar auditoria de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou diversos artigos de segurança blockchain em conferências de prestígio, reportou vários ataques de dia zero (zero-day) em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.

• Site oficial: https://blocksec.com/

• Conta oficial no Twitter: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Envie uma solicitação

• 🔗 Phalcon Security APP: Agende uma demonstração

• 🔗 Phalcon Compliance