DeFi é frequentemente alvo de roubos, como prevenir ataques de hackers na era da IA?

Escrever artigo: systs

OpenBuild introdução:

Em abril de 2026, o DeFi enfrentou o seu momento mais sombrio, com o valor roubado num único mês a ultrapassar 625 milhões de dólares, atingindo um recorde histórico, sendo que apenas os ataques ao Drift e KelpDAO consumiram quase 580 milhões de dólares. A explosão da IA fez com que o cenário de ataque e defesa se invertesse completamente; o que antes levava semanas de trabalho manual para identificar vulnerabilidades em protocolos, agora modelos de grande escala conseguem fazer em poucas horas, levando a uma queda nos custos de ataque, aumento da superfície de ataque, e cada vez mais protocolos tornarem-se alvos.

Aqueles recursos robustos e especializados em estratégias de longo prazo, estão de olho em cada brecha dos protocolos, enquanto equipas comuns, dispersas e defensivamente passivas, só podem manter uma postura fraca e reativa. Só mantendo uma obsessão extrema, construindo defesas de ponta a ponta antecipadamente, controlando rigorosamente as perdas e preparando planos de contingência, é possível sobreviver nesta guerra de defesa e ataque liderada por IA. A seguir, o conteúdo original, compilado e organizado pelo OpenBuild.

Após desenvolver o projeto @openforage e estudar numerosos incidentes históricos de ataques a protocolos DeFi, comecei a ficar atento às ameaças de atores de nível estatal. Estes adversários são experientes, possuem recursos abundantes e dominam estratégias de longo prazo; como vilões de topo, vasculham cada brecha na infraestrutura e protocolos, procurando vulnerabilidades exploráveis. Equipes comuns, por sua vez, dispersas, gerenciam operações e segurança ao mesmo tempo, incapazes de dedicar-se totalmente à defesa. Não me considero um especialista em segurança, mas tenho liderado equipes em ambientes de alto risco (com experiência militar e gestão de grandes fundos em instituições financeiras de grande porte), possuindo uma experiência prática madura em planos de risco e resposta a emergências. Acredito firmemente: só os obstinados sobrevivem. Nenhuma equipe começa com uma postura de “segurança superficial”, mas ataques continuam a acontecer com frequência. Devemos fazer melhor.

/ 01 Era da IA: tudo mudou

Ataques de hackers sempre existiram, mas a frequência aumentou claramente recentemente. No primeiro trimestre de 2026, atingiu-se um recorde de ataques a protocolos DeFi na história, e no segundo trimestre, que acabou de começar, espera-se quebrar esse recorde.

Minha principal tese é: a IA reduziu drasticamente os custos de varredura e exploração de vulnerabilidades, ao mesmo tempo que ampliou exponencialmente a superfície de ataque. Inspecionar manualmente centenas de protocolos em busca de configurações vulneráveis leva semanas; os modelos de grande escala atuais conseguem fazer isso em poucas horas. Isso muda fundamentalmente a lógica de defesa de segurança de protocolos e resposta a incidentes. Protocolos tradicionais, criados antes do advento da IA e que usam métodos convencionais de segurança, enfrentam um risco enorme de serem explorados com precisão.

/ 02 Pensando na superfície de ataque e na defesa em camadas

Na prática, há apenas três principais vetores de ataque para hackers de DeFi:

Equipa operacional do protocolo

Contratos inteligentes e infraestrutura subjacente

Limites de confiança dos usuários (domínios, redes sociais etc.)

Após identificar esses vetores, constrói-se um sistema de defesa em cinco camadas:

Prevenção prévia: estabelecer processos padronizados, rigorosamente seguidos, para reduzir ao máximo a probabilidade de invasão.

Mitigação de perdas: quando a prevenção falha, controlar imediatamente a escala do dano.

Desligamento de emergência: sob alta pressão, ninguém consegue tomar a melhor decisão. Assim que detectar um ataque, ativar o interruptor de emergência, congelar ativos para evitar maiores perdas, e ganhar tempo para análise calma da equipe.

Recuperação de controle: se módulos maliciosos ou componentes invadidos estiverem fora de controle, removê-los ou substituí-los diretamente.

Recuperação pós-incidente: recuperar ativos roubados. Ter parcerias com instituições que possam congelar fundos, reverter transações e ajudar na investigação forense.

/ 03 Princípios centrais

Estes princípios orientam a implementação de toda a defesa em camadas.

Defesa com IA de ponta e vanguarda

Aproveitar modelos de grande escala para escanear códigos e configurações em busca de vulnerabilidades, realizando testes de penetração em red team e blue team: explorar proativamente vulnerabilidades front-end, verificando se é possível invadir o back-end. Os atacantes certamente farão isso; a defesa, através de varreduras, também pode detectar vulnerabilidades. Ferramentas como pashov, nemesis, além de plataformas de segurança IA como Cantina (Apex) e Zellic (V12), podem acelerar a triagem de código antes de auditorias formais.

Tempo e processos são, por si só, barreiras de defesa

Qualquer operação com potencial risco deve seguir processos em múltiplas etapas + mecanismos de bloqueio por tempo. Assim que detectar anomalias, reservar tempo suficiente para intervenção manual e congelamento de ativos. No passado, resistência a mecanismos de bloqueio por tempo e múltiplas permissões vinha da percepção de que dificultava a operação da equipe. Mas o cenário mudou: a IA pode contornar automaticamente esses processos manuais, tornando operações simples sem sentido.

Design de invariantes

Contratos inteligentes podem ser protegidos por invariantes essenciais e inalteráveis: se uma regra for violada, toda a lógica do protocolo é invalidada. O núcleo do @openforage é baseado em invariantes de solvência: ativos no cofre + ativos implantados ≥ créditos não pagos. Protocolos simples, que não envolvem muitas funções, podem definir poucos invariantes críticos; evitar codificar múltiplas verificações em cada função, pois isso torna o código difícil de manter.

Equilíbrio de poderes

Muitos ataques vêm de vazamentos de chaves privadas ou invasões de multiassinaturas. Uma configuração de permissões adequada deve garantir que, mesmo que a multiassinatura seja comprometida, seja possível limitar perdas rapidamente, colocando o protocolo em um estado estável gerenciável. Dois aspectos principais de controle de poder:

Permissões de governança: controle das decisões centrais do protocolo

Permissões de resgate de emergência: responsáveis por restaurar a estabilidade, sem substituir ou anular a governança original

Prever que algo pode dar errado

Deve-se estabelecer uma compreensão básica de que, por mais profissionais que sejam, ataques são inevitáveis. Contratos inteligentes ou componentes dependentes podem falhar, equipes podem ser vítimas de engenharia social, atualizações podem introduzir vulnerabilidades desconhecidas. Com essa mentalidade, mecanismos de limitação de fluxo, circuit breakers e pausas de emergência tornam-se essenciais: limitar perdas a 5-10%, congelar fundos e planejar ações com calma. Em momentos críticos, evitar decisões precipitadas.

Planos de contingência antecipados

A melhor hora para responder a um ataque é antes que ele aconteça. Formalizar e documentar processos de resposta, treinar a equipe repetidamente, para evitar confusão na hora do aperto. Na era da IA, é fundamental ter ferramentas e algoritmos capazes de coletar informações em tempo real, gerar resumos e detalhes completos, e comunicar tudo ao núcleo decisório instantaneamente.

Sobrevivência é o objetivo final

Não é preciso buscar perfeição absoluta, mas garantir que o sistema sobreviva. Nenhum sistema é imune desde o início; só evoluindo, aprendendo com os erros, é possível criar uma arquitetura antifrágil. Não ter sido atacado até agora não significa segurança natural; momentos de maior complacência são os mais arriscados.

/ 04 Sistema de prevenção prévia

Design de contratos inteligentes

Após definir invariantes essenciais, implementá-los na lógica de execução, escolhendo criteriosamente quais regras devem ser obrigatórias. Recomenda-se seguir o padrão FREI-PI (Função - Impacto - Interação externa - Invariantes do protocolo): todas as funções que envolvem movimentação de ativos devem revalidar seus invariantes ao final. Muitos ataques, como arbitragem de flash loans, manipulação de oráculos ou falhas de solvência entre funções, podem ser evitados com verificações finais de invariantes.

Sistema de testes aprimorado

Testes de fuzzing com estado: gerar chamadas aleatórias às interfaces do protocolo, verificando invariantes a cada passo. A maioria dos ataques on-chain envolve múltiplas transações; testes de fuzzing são uma das poucas formas confiáveis de detectar vulnerabilidades antes do atacante. Criar testes de invariantes que garantam sua validade em qualquer sequência gerada, combinados com verificações formais, que provem sua validade em todos os estados acessíveis. Os invariantes centrais do protocolo devem passar por validação formal.

Dependências externas e oráculos

Complexidade é a maior inimiga da segurança. Quanto mais dependências externas, maior a superfície de ataque. Ao desenvolver componentes básicos, deixe a escolha de confiança ao usuário; se dependências forem necessárias, implemente redundância e descentralização para evitar pontos únicos de falha. As auditorias devem cobrir falhas de oráculos e dependências externas, com limites de uso e limites de fluxo, para que, mesmo em caso de falha, os danos sejam controlados. O ataque ao KelpDAO recente é um exemplo: usaram configuração padrão do LayerZero (requiredDVNCount=1), que não foi auditada, e a infraestrutura fora da auditoria foi explorada.

Mapeamento completo da superfície de ataque

Vetores de ataque conhecidos no DeFi já estão bem documentados. Revisar cada um, verificar sua compatibilidade com o protocolo, e implementar controles correspondentes. Criar capacidades internas de red team e blue team, obrigando IA a explorar vulnerabilidades ativamente; isso já é uma exigência padrão do setor.

Permissões nativas de resgate de emergência

Em governança por votação, o poder inicialmente concentra-se na multiassinatura da equipe, depois se dispersa. Mesmo com tokens amplamente distribuídos, as permissões de delegação tendem a se concentrar em poucos wallets, e em casos extremos, apenas um endereço-chave. Se esse wallet for comprometido, o protocolo pode colapsar. Recomenda-se usar wallets de guardião, com permissões restritas: apenas para pausar o protocolo; em casos extremos, exigir 4 de 7 assinaturas para trocar as permissões de delegação por wallets de reserva. Guardiões não podem iniciar ou aprovar propostas de governança.

Assim, o protocolo terá uma camada de resgate de emergência independente: capaz de restaurar a estabilidade gerenciável, sem substituir a governança original. A probabilidade de todos os guardiões de 4/7 serem comprometidos simultaneamente é baixa, devido à dispersão de endereços. Quando a governança estiver madura e descentralizada, essa camada de emergência pode ser desativada.

Arquitetura de wallets e chaves

Carteiras multiassinatura são padrão, com pelo menos 4 de 7 assinaturas, e ninguém controla todas as chaves sozinho. Rotacionar periodicamente os endereços dos signatários. Chaves de assinatura nunca devem ser usadas em dispositivos de uso diário: se o dispositivo for usado para navegação, email ou trabalho, já está comprometido. Usar múltiplos wallets de multiassinatura, com funções distintas. Planejar que pelo menos uma dessas wallets seja eventualmente comprometida, e preparar planos de contingência. Nenhum indivíduo, mesmo sob coação ou ameaça, deve ter poder de invadir o protocolo sozinho.

Planejamento de recompensas por vulnerabilidades

Concordo com a visão do Nascent sobre programas de bug bounty. Protocolos com recursos devem oferecer recompensas proporcionais ao TVL, com valores elevados (pelo menos sete dígitos). Mesmo para protocolos menores, as recompensas devem ser generosas. Para adversários de nível estatal, as negociações de recompensa são pouco eficazes; mas podem criar programas de “white hat” para proteger fundos roubados, pagando uma porcentagem como recompensa, assumindo o custo pelo fundo de reserva.

Seleção de auditores de alta qualidade

Antes, achava que, com o avanço dos modelos de IA, o valor marginal das auditorias tradicionais diminuiria; agora, mudo de opinião:

As principais firmas de auditoria continuam na vanguarda. Protocolos com design inovador, cujo código e vulnerabilidades potenciais não estão nos dados de treinamento do modelo, não podem confiar apenas em poder de processamento. Ninguém quer ser a primeira vítima de uma nova técnica de ataque.

Um ponto muitas vezes negligenciado: as firmas de auditoria reforçam sua reputação com o mercado. Após emitir um relatório, se o protocolo for roubado, há forte motivação para ajudar na análise e recuperação. Estabelecer parcerias de longo prazo com equipes de segurança especializadas é um ativo valioso.

Segurança operacional e de manutenção

Incluir segurança operacional nos critérios de avaliação. Realizar treinamentos de phishing periodicamente; contratar equipes vermelhas externas confiáveis para testes de engenharia social. Manter hardware wallets e dispositivos de reserva, capazes de substituir toda a configuração de multiassinatura, evitando compras de emergência na hora de crise.

/ 05 Mitigação de perdas

Limite máximo de perdas na saída de fundos

Todas as rotas de saída de ativos devem ter limites de valor; o máximo dano teórico possível por vulnerabilidade deve ser definido. Por exemplo: funções de emissão sem limite de blocos equivalem a um cheque em branco para emissão ilimitada; funções de resgate sem limite semanal equivalem a permitir manipulação do saldo. Estabelecer limites rígidos para cada canal de saída, equilibrando perdas máximas aceitáveis e experiência do usuário. Assim, em caso de falha, essa camada evita que o protocolo vá à falência total.

Listas de permissões (whitelist e blacklist)

A maioria dos protocolos possui listas implícitas de interfaces acessíveis, ativos negociáveis e endereços autorizados, além de regras explícitas de ações proibidas. Mesmo que as regras sejam implícitas, devem ser formalizadas por escrito. Com listas claras, é possível implementar mudanças de permissão em duas etapas, dificultando ataques: primeiro, alterar whitelist/blacklist; depois, executar operações maliciosas. Com esse duplo mecanismo, o atacante precisa superar duas barreiras: passar pela revisão de entrada (integração/implantação) e contornar as restrições de segurança (revisão de risco).

/ 06 Recuperação de controle

Monitoramento automatizado por algoritmos

Ter um interruptor de emergência sem monitoramento é inútil. Criar sistemas de monitoramento off-chain, com inspeções 24/7 dos invariantes essenciais, e alertas automáticos em caso de anomalias. Os alertas devem chegar aos responsáveis pela multiassinatura, com contexto completo, para decisões em minutos.

Parar primeiro, analisar depois

Ao detectar um ataque, priorizar o corte de fluxo de ativos, sem decisões precipitadas. Para o protocolo, isso significa ativar o interruptor de emergência (exibido na interface): uma única transação pode pausar todas as rotas de movimentação de ativos. Preparar scripts de “pausa total com um clique”, que percorrem automaticamente todos os módulos pausáveis, executando a parada de forma atômica. Permissões de governança não podem ser desativadas; se o nível de guardião puder pausar contratos de governança, uma invasão a esses guardiões bloqueará o processo de recuperação.

Criar uma sala de operações de emergência

Após congelar ativos e conter perdas, reunir os membros confiáveis previamente designados, formando um canal de comunicação exclusivo. Controlar rigorosamente o acesso às informações, evitando vazamentos para atacantes, mídia ou especuladores. Definir papéis fixos e treinar rotinas:

Responsável pela decisão: coordena as ações gerais

Executores de operações: realizam scripts de defesa e pausas, seguindo as ordens

Analistas de incidentes: reconstruir a cadeia de ataque, identificar causas raízes

Contato externo: comunicar-se com parceiros e autoridades

Registrador de eventos: documentar toda a evolução, decisões e cronogramas

Equipe com responsabilidades claras, treinada antecipadamente, atuando conforme o procedimento na hora do incidente, sem confusão.

Prever riscos em cadeia e secundários

Assumir que os atacantes possuem alto nível: a primeira vulnerabilidade pode ser uma distração, ou uma preparação para ataques em cadeia. O ataque pode ser uma isca, induzindo a equipe a cometer erros e explorar vulnerabilidades mais profundas. As ações de pausa devem ser rigorosas, com avaliação completa e fechamento de todas as brechas. Não basta pausar um módulo isolado; o protocolo deve ser congelado globalmente, para evitar que vulnerabilidades remanescentes sejam exploradas. Após identificar as causas e vetores, verificar as áreas relacionadas e riscos em cadeia, e corrigir tudo de uma só vez.

Implementar mecanismo de sucessão predefinido

A troca de permissões só é segura se os endereços de sucessores estiverem pré-registrados. Recomendo usar um registro de endereços de sucessores pré-definidos: assim, é difícil para atacantes substituírem secretamente os guardiões ou wallets de governança por wallets maliciosos. A lógica é semelhante ao controle de listas brancas e pretas. Todos os papéis críticos devem ter endereços de sucessores registrados antecipadamente. Permissões de emergência só podem executar uma ação: substituir o endereço de um papel por seu sucessor pré-definido. Durante a operação normal, fazer uma triagem cuidadosa e diligente dos sucessores, sem decisões apressadas na crise.

Testes cuidadosos antes de atualizações

Após identificar causas e impactos, é preciso lançar patches de atualização. Essa é a fase de maior risco na implantação: escrever código às pressas sob pressão, com adversários já conhecendo a lógica do protocolo e suas vulnerabilidades. Nunca fazer deploy sem testes completos. Se não houver tempo para auditoria formal, usar redes de white hats ou lançar uma recompensa de 48 horas antes, para obter perspectivas externas de ataque e defesa, antes de uma implantação oficial.

/ 07 Recuperação pós-incidente

Ação rápida

Fundos roubados podem ser lavados em poucas horas, com transações cruzadas e fragmentação. Conectar-se a serviços como Chainalysis para monitorar endereços de atacantes em múltiplas cadeias, e enviar alertas automáticos às exchanges, rastreando o fluxo de fundos. Preparar uma lista de contatos: departamentos de conformidade de exchanges centralizadas, operadores de bridges cross-chain, administradores de custódia, e parceiros com capacidade de congelar ou interceptar ativos em trânsito.

Negociação e mediação

Apesar do desânimo, recomenda-se sempre tentar negociar com os atacantes. Tudo tem espaço para acordo. Publicar anúncios de bug bounty com prazo, prometendo devolver integralmente os fundos se a restituição for feita, e renunciando a ações legais. Se o adversário for de nível estatal, as negociações provavelmente fracassarão; mas muitos atacantes são apenas exploradores de vulnerabilidades que querem lucrar discretamente, e ainda há espaço para negociações. Envolver sempre equipe jurídica na condução.

/ 08 Ataques de hackers não vão desaparecer, e com a evolução da IA, eles só ficarão mais frequentes. Defesa por si só não basta; é preciso usar as mesmas ferramentas de IA dos atacantes, manter uma rotina de red team e blue team, monitoramento contínuo, limites de perdas rígidos, para resistir a riscos extremos e sobreviver ao ciclo do setor.