Exploração do DotSwap V1 drena aproximadamente 8,5 BTC, com perdas estimadas em US$ 685.000
Exploração do DotSwap V1 drena aproximadamente 8,5 BTC, com perdas estimadas em US$ 685.000
Em 25 de outubro, a versão legada da plataforma de negociação DotSwap, o DotSwap V1, foi alvo de uma exploração que resultou no roubo de aproximadamente 8,5 BTC, avaliados em cerca de US$ 685.000 no momento do incidente.
O caso destaca um desafio de segurança cada vez mais presente nas aplicações baseadas em Bitcoin: mesmo quando os usuários interagem com ativos descentralizados, sistemas de autorização em back-end, infraestruturas de liquidez sob custódia e serviços automatizados de assinatura podem criar pontos centralizados de falha.
Segundo uma atualização sobre o incidente publicada pela On Nexus, a plataforma afetada foi retirada do ar enquanto a equipe investiga o ataque, rastreia os fundos roubados e trabalha em conjunto com corretoras e empresas especializadas em inteligência de blockchain.
O que aconteceu com o DotSwap V1?
O DotSwap V1 utilizava um modelo de assinatura no servidor para gerenciar pools de liquidez. Sua infraestrutura de liquidez operava por meio de um arranjo multisig sob custódia, o que significa que os BTC depositados eram controlados pelo processo de assinatura da plataforma, e não diretamente por cada provedor de liquidez.
Segundo relatos, o invasor explorou um mecanismo de assinatura legado que continuava ativo no back-end do V1. Ao longo de aproximadamente quatro horas, scripts automatizados interagiram com as interfaces disponíveis da plataforma e transferiram gradualmente fundos dos pools de liquidez e das contas de usuários do V1.
O ataque não se limitou a um único token ou endpoint. Os scripts teriam testado as interfaces da plataforma e direcionado ativos associados a 99 tokens Runes, permitindo que o invasor identificasse e explorasse vulnerabilidades em um ambiente mais amplo da aplicação.
A perda total foi estimada em aproximadamente:
- 8,5 BTC roubados
- Cerca de US$ 685.000 em fundos afetados
- Depósitos de provedores de liquidez no DotSwap V1 comprometidos
- Carteiras controladas pelos próprios usuários fora da plataforma não foram afetadas
O DotSwap V1 foi posteriormente encerrado. A On Nexus declarou que está trabalhando para restaurar os serviços relacionados e que publicará uma análise pós-incidente mais completa, juntamente com um plano para os usuários afetados.
Por que os provedores de liquidez foram as principais vítimas
A distinção mais importante neste incidente está na diferença entre os fundos administrados pela plataforma e os ativos mantidos na carteira do próprio usuário.
Os provedores de liquidez que depositaram BTC no DotSwap V1 ficaram expostos à arquitetura de custódia e assinatura da plataforma. Embora o sistema utilizasse controles multisig, o processo de assinatura ainda estava conectado a serviços de back-end que podiam ser consultados e acionados por meio das interfaces da aplicação.
Isso significa que a proteção multisig, por si só, não eliminou o risco operacional. Se a lógica de autorização, as permissões de API, as políticas de assinatura ou os controles do lado do servidor forem projetados de maneira inadequada, um invasor ainda poderá encontrar uma forma de produzir transações válidas.
Por outro lado, os usuários que mantiveram seus ativos em carteiras autocustodiadas e não os depositaram nos pools do V1 não foram afetados pelo incidente. Suas chaves privadas permaneceram fora do ambiente comprometido da plataforma.
Essa distinção é fundamental para compreender os riscos dos pools de liquidez:
Um protocolo pode utilizar liquidação em blockchain e, ainda assim, depender de uma infraestrutura centralizada para custódia, assinatura, formação de preços, roteamento ou controle de acesso.
Por isso, os usuários devem avaliar não apenas se uma aplicação está “on-chain”, mas também onde está localizada a autoridade de assinatura, quem controla as permissões de saque e se os fundos depositados podem ser congelados ou redirecionados por um sistema de back-end.
Um possível exemplo de automação de ataque com auxílio de IA
A On Nexus classificou o incidente como compatível com uma tendência recente envolvendo ataques conduzidos por IA ou altamente automatizados.
O uso de automação pode aumentar significativamente a velocidade e o alcance de uma exploração. Em vez de testar manualmente uma função por vez, um invasor pode programar ferramentas para:
- Descobrir endpoints de API expostos
- Enviar grandes quantidades de solicitações
- Comparar respostas entre diferentes ativos
- Detectar comportamentos inconsistentes de autorização
- Identificar rotas anômalas de assinatura ou saque
- Executar transações em rápida sequência
Em um ambiente que oferece suporte a dezenas de contratos de tokens e rotas de negociação, a automação facilita a identificação de pequenas diferenças de implementação que podem não ser percebidas durante testes manuais de rotina.
A principal lição é que as equipes de segurança agora precisam se proteger contra ataques que combinam scripts tradicionais com agentes de IA cada vez mais capazes. A descoberta de APIs, a classificação de vulnerabilidades, a construção de transações e o monitoramento podem ser acelerados por ferramentas automatizadas.
Essa tendência torna cada vez mais importantes recursos como limitação de requisições, isolamento de endpoints, detecção de anomalias, aplicação de políticas de assinatura e monitoramento de transações em tempo real para plataformas de ativos digitais.
O que o incidente revela sobre a infraestrutura das Runes
O ecossistema Runes ampliou a variedade de ativos fungíveis que podem ser emitidos e negociados na rede Bitcoin. No entanto, a infraestrutura que dá suporte a esses ativos ainda está em desenvolvimento, e muitas aplicações dependem de uma combinação de indexadores, serviços off-chain, pools sob custódia e lógicas de negociação especializadas.
Isso cria várias áreas de risco:
- Dependência de indexadores: Os saldos das carteiras e o estado dos tokens podem depender de serviços de indexação de terceiros.
- Autorização no back-end: Uma plataforma pode utilizar APIs centralizadas para determinar se uma transação pode ser assinada.
- Liquidez sob custódia: Os usuários podem depositar BTC em carteiras compartilhadas administradas pela aplicação.
- Complexidade de contratos e ativos: O suporte a muitos ativos Runes aumenta a quantidade de rotas, interfaces e situações excepcionais que precisam ser testadas.
- Concentração operacional: Um único serviço de assinatura comprometido pode afetar vários pools simultaneamente.
Os usuários que estiverem explorando negociação ou provisão de liquidez em Runes devem analisar o modelo de custódia do projeto antes de depositar fundos. A interface de uma plataforma pode parecer descentralizada, enquanto funções importantes de controle continuam centralizadas.
Para obter informações sobre o ecossistema de ativos do Bitcoin, os usuários podem consultar a documentação para desenvolvedores do Bitcoin e o boletim Bitcoin Optech, que aborda regularmente desenvolvimentos em protocolos, carteiras e infraestrutura do Bitcoin.
Lições práticas de segurança para usuários de criptomoedas
1. Confirme se os fundos continuam sob seu controle
Antes de fornecer liquidez ou depositar ativos, determine se a plataforma pode movimentar os fundos sem uma transação assinada diretamente pela sua carteira.
Algumas perguntas importantes incluem:
- Os depósitos são enviados para um endereço controlado pelo usuário ou pela plataforma?
- Quem possui as chaves privadas?
- A assinatura é realizada localmente, por meio de um dispositivo físico, ou em um servidor?
- Os administradores podem pausar saques ou alterar as regras de assinatura?
- Os limites de saque e os controles de monitoramento estão documentados publicamente?
As respostas podem alterar de forma significativa o perfil de risco do serviço.
2. Considere produtos legados como possíveis superfícies de ataque
O incidente do DotSwap V1 mostra por que versões antigas de uma plataforma não devem permanecer conectadas a serviços ativos. Mesmo que uma nova versão tenha controles mais robustos, APIs desatualizadas, rotas de assinatura antigas e permissões de contas ainda podem ser exploradas.
Os projetos devem desativar completamente os produtos aposentados por meio de medidas como:
- Revogar credenciais de API
- Remover permissões antigas de assinatura
- Desativar endpoints não utilizados
- Rotacionar as chaves de serviço
- Separar bancos de dados legados dos sistemas de produção
- Monitorar a infraestrutura histórica em busca de atividades inesperadas
3. Evite concentrar ativos em uma única aplicação
Os provedores de liquidez devem considerar a diversificação entre carteiras, protocolos e modelos de custódia. Concentrar uma grande quantidade de BTC em uma única aplicação pode aumentar o impacto de uma exploração ou falha operacional.
Isso não elimina o risco do protocolo, mas pode reduzir a possibilidade de que um único incidente afete todo o portfólio.
4. Monitore a atividade da carteira e as autorizações
Os usuários devem revisar regularmente os saldos das carteiras, as aplicações conectadas, as sessões das contas e o histórico de transações. Solicitações inesperadas de assinatura, endereços de saque desconhecidos ou novos logins em dispositivos devem ser tratados como possíveis sinais de alerta.
No caso de transações de alto valor, os usuários devem verificar de forma independente:
- O endereço de destino
- O ativo e o valor
- A rede
- A taxa da transação
- O domínio da aplicação
- Os detalhes finais da transação exibidos pela carteira
5. Entenda que multisig não significa descentralização completa
Arranjos multisig podem aumentar a resiliência, mas sua eficácia depende da forma como os signatários estão distribuídos e de como a autorização é aplicada.
Se todos os signatários forem controlados pela mesma organização, estiverem conectados ao mesmo back-end ou sujeitos ao mesmo mecanismo de políticas defeituoso, o sistema ainda poderá ter um ponto centralizado de falha relevante.
A segurança depende de toda a arquitetura de assinatura, e não apenas da presença de múltiplas assinaturas.
O que os usuários afetados devem observar
Os usuários conectados ao DotSwap V1 devem ter cuidado com mensagens de phishing que afirmem oferecer reembolsos, compensações ou ferramentas emergenciais de saque. Os invasores frequentemente exploram incidentes públicos fingindo representar as equipes dos projetos e direcionando as vítimas para sites falsos.
Os usuários afetados devem:
- Seguir apenas os canais de comunicação verificados do projeto
- Evitar inserir frases-semente ou chaves privadas em sites
- Tratar formulários de reembolso não solicitados como suspeitos
- Salvar IDs de transação e registros de depósitos
- Consultar a blockchain de forma independente
- Monitorar a movimentação dos endereços de carteira relacionados
- Aguardar um processo oficial de recuperação ou reivindicação antes de assinar qualquer coisa
Uma equipe legítima de suporte jamais deve exigir a frase de recuperação de uma carteira para verificar a titularidade ou processar um reembolso.
Para orientações gerais sobre a proteção de ativos digitais, o guia de cibersegurança da CISA oferece informações úteis sobre phishing, segurança de contas e atividades maliciosas.
As implicações mais amplas para DeFi e aplicações de Bitcoin
A exploração do DotSwap V1 não é apenas a história de uma plataforma vulnerável. Ela reflete uma tensão mais ampla no setor de criptomoedas: as aplicações podem apresentar aos usuários uma interface descentralizada e, ao mesmo tempo, depender de componentes centralizados nos bastidores.
À medida que as aplicações financeiras baseadas em Bitcoin amadurecem, as revisões de segurança precisarão abranger mais do que o código de contratos inteligentes. As auditorias também devem examinar:
- Autenticação e autorização de APIs
- Serviços de assinatura no lado do servidor
- Gestão de chaves e isolamento dos signatários
- Permissões de bancos de dados
- Sistemas de indexação de ativos
- Procedimentos de atualização e encerramento
- Monitoramento e resposta a incidentes
- Mecanismos de saque emergencial
Em 2025, o uso crescente de agentes automatizados e o desenvolvimento assistido por IA tornam esse processo de revisão ainda mais importante. O desenvolvimento mais rápido de software e as interações automatizadas podem ampliar a superfície de ataque se os controles de segurança não evoluírem no mesmo ritmo.
Para os usuários, a proteção mais confiável continua sendo compreender claramente o modelo de custódia. Os ativos mantidos diretamente em uma carteira autocustodiada estão expostos a um conjunto de riscos diferente daquele associado aos ativos depositados em um pool controlado por uma plataforma. Nenhum dos modelos é isento de riscos, mas a origem desses riscos é substancialmente diferente.
Como as carteiras de hardware se encaixam em uma estratégia mais segura de autocustódia
Uma carteira de hardware pode ajudar a reduzir a exposição a comprometimentos de servidores ao manter as chaves privadas isoladas de aplicações conectadas à internet. Ao interagir com aplicações descentralizadas, os usuários podem revisar e aprovar os detalhes das transações em um dispositivo dedicado de assinatura, em vez de depender exclusivamente de uma interface de navegador.
As carteiras de hardware OneKey foram desenvolvidas para fluxos de autocustódia, incluindo proteção offline das chaves e confirmação de transações no próprio dispositivo. Elas não eliminam riscos de contratos inteligentes, phishing, interfaces maliciosas ou volatilidade do mercado, mas podem ajudar os usuários a manter o controle sobre ativos que não foram depositados intencionalmente em plataformas sob custódia ou pools de liquidez.
O princípio fundamental é simples: antes de fornecer liquidez ou autorizar uma transação, os usuários devem entender quem controla os fundos, o que estão assinando e se a plataforma pode movimentar os ativos sem sua aprovação direta.
A perda de aproximadamente 8,5 BTC pelo DotSwap V1 reforça por que a arquitetura de custódia, as permissões de assinatura e a segurança operacional merecem tanta atenção quanto a utilidade dos tokens ou o volume de negociação. Em um ambiente de criptomoedas cada vez mais automatizado, a autocustódia consciente e a verificação cuidadosa das transações continuam sendo defesas essenciais.
