~$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

Os relatórios de investigação independentes acrescentam detalhes ao caminho do ataque sem nomear os dois produtos de segurança afetados. A SlowMist rastreou a primeira atividade maliciosa no Produto A até 31 de agosto e identificou um zero-day afetando um serviço em um nó. A Mandiant encontrou acesso privilegiado a dois appliances de segurança, um web shell e conexão de comando e controle no Produto B, além de movimentação lateral até o servidor de jobs da carteira de produção.

A SlowMist também constatou que o atacante usou 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 que forjava parâmetros de controle de risco, construía solicitações de saque e invocava o processo de saque. A forma como o atacante se movimentou entre todos os sistemas envolvidos permanece sob investigação. As blockchains públicas registraram as transferências finais assinadas, não essas operações anteriores.

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