Em 1º de abril de 2026 (UTC), o protocolo Drift na Solana foi comprometido por meio de um ataque coordenado combinando manipulação de aprovação multisig e exploração de nonce durável — um mecanismo de transação da Solana que permitia que aprovações pré-assinadas permanecessem válidas indefinidamente —, resultando em uma perda estimada de aproximadamente $285,3M [1, 2]. Após semanas de preparação on-chain, o atacante induziu dois dos cinco signatários do multisig do Conselho de Segurança a pré-assinar transações de governança maliciosas por meio de phishing ou solicitações de assinatura enganosas. As instruções assinadas foram retidas até o momento escolhido pelo atacante e, em seguida, executadas em duas transações rápidas para concluir a tomada de controle administrativo e transferir o controle do administrador. Com privilégios totais de administrador, o atacante introduziu um ativo colateral malicioso (CVT), inflou seu preço de oráculo, relaxou as proteções de saque e drenou ativos de alto valor por meio dos caminhos de empréstimo do protocolo.
No momento em que este texto foi escrito, o Drift publicou uma declaração inicial [1], mas ainda não havia divulgado um post-mortem completo. A análise abaixo é baseada em dados on-chain publicamente disponíveis, na linha do tempo oficial do Drift e em pesquisas independentes [2]. Primeiro examinamos como os nonces duráveis alteram fundamentalmente as premissas de segurança da governança multisig, depois reconstruímos a preparação do ataque ao longo de várias semanas, a execução da tomada de controle da governança e o processo de extração de fundos, e concluímos com lições aprendidas para mitigar esse tipo de risco.
Melhor Auditoria de Segurança para Web3
Valide design, código e lógica de negócios antes do lançamento
Contexto
Protocolo Drift e Multisig Squads
O Drift Protocol é um protocolo DeFi na Solana que suporta negociação com margem, empréstimos, mercados à vista e derivativos. Suas operações de alto privilégio — incluindo alterações de administrador, criação de mercados, configuração de oráculos, atualizações de parâmetros de risco e ajustes de limites de saque — são governadas por um multisig, em vez de uma única chave privada.
O Drift utiliza o framework multisig Squads, um sistema de governança on-chain comum na Solana. No Squads, ações privilegiadas são empacotadas como transações em uma proposta. Quando membros suficientes aprovam a proposta, as instruções armazenadas podem ser executadas atomicamente por meio de vaultTransactionExecute. No momento do ataque, o Conselho de Segurança do Drift operava sob uma configuração de limiar 2-de-5 com timelock zero, o que significa que quaisquer dois dos cinco signatários podiam autorizar ações administrativas com efeito imediato. A segurança desse sistema depende não apenas da custódia das chaves dos signatários, mas também da integridade de todo o pipeline de aprovação: qual transação foi criada, o que os signatários acreditavam estar aprovando e se as instruções finais executadas correspondiam a esse contexto de revisão.
Contas de Nonce Durável
As contas de nonce durável introduzem uma dimensão temporal crítica na execução de transações [3]. Em condições normais, as transações da Solana dependem de um blockhash recente e expiram rapidamente após a assinatura caso não sejam transmitidas a tempo. Os nonces duráveis substituem esse blockhash de curta duração por um nonce armazenado em uma conta dedicada, permitindo que uma transação assinada permaneça válida indefinidamente até que o nonce seja avançado. Esse recurso é útil em casos legítimos, como assinatura offline ou envio com atraso, mas também cria uma primitiva de ataque importante: ele separa quando uma transação é assinada de quando ela é executada on-chain. De forma crítica, uma vez que um signatário aprova uma transação com nonce durável, ele não pode revogar sua assinatura a menos que a autoridade do nonce avance manualmente a conta de nonce.
Essa separação tem um impacto sutil, mas fundamental, na segurança do multisig. Sob transações normais baseadas em blockhash, a janela de expiração curta atua como uma camada de segurança implícita: a autorização de um signatário é executada prontamente ou expira de forma inofensiva. Essa restrição temporal significa que, mesmo que um signatário seja enganado para aprovar uma transação maliciosa, o atacante deve transmiti-la dentro de uma janela estreita, limitando o escopo para exploração coordenada e em múltiplas etapas. Os nonces duráveis removem essa restrição completamente. Com assinaturas válidas indefinidamente, o custo de um único erro de assinatura muda fundamentalmente: uma aprovação obtida por engano não expira mais em minutos, mas permanece explorável sem limite de tempo automático, dando ao atacante controle total sobre o momento da execução e a capacidade de coordenar etapas subsequentes à vontade.
Análise do Ataque
O ataque se desenrolou em três fases distintas. Na fase de Preparação Pré-Ataque, o atacante conduziu uma operação de várias semanas para fabricar um ativo colateral falso e obter acesso à governança por meio de solicitações de assinatura enganosas. Na fase de Tomada de Controle da Governança, duas transações com nonce durável pré-assinadas foram enviadas em rápida sucessão para assumir o controle administrativo. Na fase de Extração de Fundos, o atacante manipulou parâmetros do protocolo e drenou ativos reais por meio dos caminhos de empréstimo do protocolo. O diagrama abaixo ilustra o fluxo de execução do ataque nas três fases, correspondendo às subseções a seguir. A trilha paralela de fabricação do CVT, detalhada na Preparação Pré-Ataque, não está mostrada no diagrama.
Preparação Pré-Ataque
O ataque não foi um golpe único e oportunista, mas uma operação de várias semanas executando duas trilhas de preparação paralelas. A primeira trilha focou na fabricação de um ativo colateral plausível. Em 11 de março, o atacante sacou 10 ETH do Tornado Cash e usou os fundos para implantar o CarbonVote Token (CVT), cunhando 750 milhões de unidades. Nas semanas seguintes, o atacante semeou uma pequena quantidade de liquidez na Raydium e usou wash trading para construir um histórico de preços artificial próximo a $1, conferindo ao CVT uma aparência superficial de legitimidade de mercado [4].
A segunda trilha visava o acesso à governança. De acordo com a linha do tempo oficial do Drift [1], em 23 de março, quatro contas de nonce durável foram criadas: duas vinculadas a membros do multisig do Conselho de Segurança do Drift e duas controladas pelo atacante. Isso indicava que pelo menos dois dos cinco signatários já haviam assinado transações vinculadas a contas de nonce durável, conferindo ao atacante o limiar de aprovação 2-de-5 necessário.
Em 27 de março, o Drift executou uma migração planejada do Conselho de Segurança devido a uma mudança de membro do conselho. Essa migração invalidou as assinaturas previamente coletadas sob a configuração antiga. No entanto, até 30 de março, uma nova conta de nonce durável surgiu vinculada a um membro do multisig atualizado, indicando que o atacante havia re-obtido o limiar de aprovação dois-de-cinco necessário sob a nova configuração.
Essa sequência revela que o atacante estava monitorando ativamente as mudanças de governança on-chain e se adaptando em tempo real. Em vez de uma única campanha de phishing, a coleta de assinaturas foi uma operação contínua que sobreviveu a uma reconfiguração do multisig no meio da preparação. A própria migração pode ter inadvertidamente auxiliado o atacante: durante transições de governança, os signatários têm maior probabilidade de encontrar e aprovar solicitações de assinatura administrativas, criando uma janela natural de engenharia social.
Em 1º de abril, o atacante escolheu uma janela de execução precisa. O Drift primeiro realizou um saque de teste legítimo do fundo de seguros. Aproximadamente um minuto depois, o atacante enviou as transações de ataque pré-assinadas. Esse timing sugere que o atacante estava monitorando a atividade on-chain em tempo real e aguardou uma operação legítima bem-sucedida para confirmar que o sistema estava em um estado operacional normal antes de agir.
Tomada de Controle da Governança
Aproximadamente às 16:05 UTC em 1º de abril, o atacante enviou as duas transações com nonce durável pré-assinadas com quatro slots de diferença. A primeira transação (2HvMSg...2C4H) criou e aprovou a proposta maliciosa de transferência de administrador. A segunda transação (4BKBmA...RsN1) aprovou e a executou, começando com AdvanceNonceAccount para ativar o nonce armazenado, depois prosseguindo com proposalApprove e vaultTransactionExecute, invocando por fim UpdateAdmin para transferir o controle administrativo para um endereço controlado pelo atacante.
Esse fluxo de execução destaca uma propriedade fundamental do ataque: a autorização decisiva não ocorreu no momento da execução, mas na etapa anterior de assinatura. As transações on-chain apenas materializaram permissões que já haviam sido concedidas.
Extração de Fundos
Após obter o controle administrativo, o atacante realizou três etapas preparatórias antes de extrair os fundos: criando um mercado de colateral malicioso para o CVT, mudando para um oráculo controlado pelo atacante para inflar seu preço e relaxando as proteções de saque para viabilizar a extração em larga escala.
O primeiro passo foi criar um mercado de colateral malicioso para o CVT. O problema com esse mercado não era apenas o fato de ser novo, mas de não ter liquidez real enquanto recebia parâmetros de risco excessivamente permissivos. Um ativo sem valor resgatável, uma vez aceito como colateral de alto peso no protocolo, pode ser usado para criar poder de empréstimo inexistente.
O segundo passo foi mudar para um oráculo controlado pelo atacante e inflar o preço. Com permissões de administrador, essa etapa não exigiu contornar restrições adicionais. Uma vez que o oráculo estava sob controle do atacante, o preço de livro do CVT podia ser inflado arbitrariamente, fazendo com que um ativo com quase nenhum valor real de mercado parecesse um colateral de alto valor dentro do protocolo.
O terceiro passo foi relaxar as proteções de saque e os disjuntores de circuito. Mesmo com a precificação inflada do colateral, os limites de saque nos principais mercados de ativos teriam restringido a extração em larga escala. Essas proteções precisavam ser aumentadas ou removidas antes que o valor fabricado do colateral pudesse ser convertido em ativos reais extraíveis.
Uma vez concluídas essas etapas, o atacante depositou uma grande quantidade de CVT sobrevalorizado no protocolo e então executou 31 saques rápidos ao longo de aproximadamente 12 minutos, drenando ativos reais incluindo USDC, JLP, SOL, cbBTC, USDT, wETH, dSOL, WBTC, JTO e FARTCOIN. Isso fechou o ciclo de extração de lucro: obter controle da governança, alterar parâmetros, empacotar um ativo sem valor como colateral de alto valor e mover os fundos para fora pelos caminhos de empréstimo e saque preexistentes do protocolo.
No momento em que este texto foi escrito, a perda total era de $285.279.417,69, calculada com base na conta de saque do atacante (HkGz4K...pZES).
Lições Aprendidas
-
A segurança do multisig vai além da custódia de chaves. Proteger chaves privadas e impor limiares de assinatura é insuficiente. Todo o pipeline de autorização — incluindo construção de transações, exibição e interpretação pelo signatário — deve ser confiável. Neste incidente, as chaves dos signatários não foram comprometidas, mas o processo de aprovação foi manipulado para autorizar ações não intencionadas.
-
Timelocks são críticos para operações de alto privilégio. Ações administrativas como transferências de propriedade não devem ser executáveis imediatamente. A configuração de timelock zero do Drift significava que, uma vez acionadas as transações pré-assinadas, o controle administrativo foi transferido e explorado em minutos, sem deixar nenhuma oportunidade de detecção ou intervenção. Um timelock teria criado uma janela de resposta para identificar e bloquear a transferência maliciosa.
-
Mecanismos de execução com atraso exigem salvaguardas adicionais em contextos de governança. Os nonces duráveis desacoplam a assinatura da execução, removendo as garantias temporais implícitas nas quais os signatários dependem. Em sistemas de governança, essa classe de mecanismo deve ser combinada com limiares de assinatura mais elevados, aprovações com prazo determinado ou revogáveis, e restrições que impeçam que transações assinadas permaneçam válidas indefinidamente.
Conclusão
Este incidente não foi causado por uma vulnerabilidade em contrato inteligente ou comprometimento de chaves, mas por uma falha no processo de autorização multisig combinada com execução adiada baseada em nonce durável. O atacante pré-coletou aprovações multisig válidas de dois dos cinco signatários do Conselho de Segurança por meio de assinaturas enganosas, as preservou usando transações com nonce durável e as executou posteriormente para obter controle administrativo. A extração subsequente de fundos foi uma consequência direta da governança comprometida, realizada por meio de operações de protocolo que seriam, em outros contextos, válidas. Mitigar essa classe de risco exige proteger todo o pipeline de autorização, impor timelocks em operações de alto privilégio e implementar salvaguardas adicionais para mecanismos de execução com atraso. Combinadas com sistemas de monitoramento on-chain capazes de detectar atividades de governança anômalas em tempo real, essas medidas formam um sistema de segurança abrangente contra essa classe de ataques na camada de governança.
Referências
[1] DriftProtocol, "Declaração oficial": https://x.com/DriftProtocol/status/2039564437795836039
[2] Phalcon (BlockSec), "Análise do Exploit do Drift Protocol": https://x.com/Phalcon_xyz/status/2039602380074016909
[3] Solana, "Introdução aos Nonces Duráveis": https://solana.com/developers/guides/advanced/introduction-to-durable-nonces
[4] CoinDesk, "Como os atacantes do Drift drenaram mais de $270 milhões usando um recurso da Solana criado para conveniência": https://www.coindesk.com/tech/2026/04/02/how-a-solana-feature-designed-for-convenience-let-an-attacker-drain-usd270-million-from-drift
Sobre a BlockSec
A BlockSec é uma fornecedora completa de segurança em blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam nossos clientes a realizar auditorias 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 múltiplos artigos acadêmicos de segurança em blockchain em conferências de prestígio, reportou vários ataques de dia zero 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
