Guia de Segurança DeFi: Como se Defender Eficazmente de Ataques de Hackers na Era da IA?

Escrevendo: sysls

Compilado por: AididiaoJP, Foresight News

Introdução

Ao entender uma grande quantidade de eventos de ataques de hackers a protocolos DeFi, isso me fez sentir medo dos «agentes estatais». Eles são altamente habilidosos, possuem recursos abundantes e jogam um jogo de longo prazo extremo; esses supervilões se concentram em vasculhar cada canto do seu protocolo e infraestrutura em busca de vulnerabilidades, enquanto equipes de protocolos comuns têm suas atenções dispersas em seis ou sete áreas de negócio diferentes.

Não me considero um especialista em segurança, mas já liderei equipes em ambientes de alto risco (incluindo forças armadas e o setor financeiro com grandes fundos), tendo ampla experiência em pensar e planejar planos de contingência.

Acredito sinceramente que apenas os paranoicos sobrevivem. Nenhuma equipe começa pensando «vou agir com descaso e negligência em relação à segurança»; no entanto, ataques ainda acontecem. Precisamos fazer melhor.

IA significa que desta vez realmente é diferente

(Origem dos dados:

Ataques de hackers não são incomuns, mas a frequência está claramente aumentando. O primeiro trimestre de 2026 foi o trimestre com o maior número de ataques de hackers a DeFi já registrado, e o segundo trimestre, que acabou de começar, já promete quebrar o recorde do trimestre anterior.

Minha hipótese central é: IA reduziu drasticamente o custo de encontrar vulnerabilidades e expandiu enormemente a superfície de ataque. Humanos levam várias semanas para revisar a configuração de cem protocolos em busca de erros; enquanto os modelos básicos mais recentes podem fazer isso em poucas horas.

Isso deve mudar completamente nossa forma de pensar e responder a ataques de hackers. Protocolos antigos que estavam acostumados a medidas de segurança antes do fortalecimento da IA estão cada vez mais vulneráveis a «serem eliminados em segundos».

Pensando na superfície e na hierarquia

(Origem dos dados:

A superfície de ataque de hackers na verdade pode ser resumida em três: equipe do protocolo, contratos inteligentes e infraestrutura, limites de confiança dos usuários (DSN, redes sociais etc.).

Uma vez identificadas essas superfícies, podemos sobrepor camadas de defesa:

Prevenção: se aplicada rigorosamente, maximiza a redução da probabilidade de exploração.

Mitigação: quando a prevenção falha, limita a extensão do dano.

Pausa: ninguém consegue tomar as melhores decisões sob enorme pressão. Assim que um ataque for confirmado, acione imediatamente o interruptor geral. Congelar pode impedir perdas adicionais e ganhar tempo para pensar…

Recuperação: se você perdeu o controle de componentes tóxicos ou comprometidos, descarte-os e substitua-os.

Restaurar: recupere o que foi perdido. Planeje com antecedência contatos de parceiros capazes de congelar fundos, revogar transações e ajudar na investigação.

Princípios

Esses princípios orientam ações concretas para implementar cada camada de defesa.

Uso intensivo de IA de ponta

Utilize modelos avançados de IA para escanear seu código e configurações, procurando vulnerabilidades, e realize testes de red team em toda a superfície: tente encontrar brechas na interface, verificando se elas podem alcançar o backend. Hackers fazem isso. O que você consegue detectar com varreduras defensivas, eles já detectaram com varreduras ofensivas.

Use habilidades como pashov, nemesis, além de plataformas de IA como Cantina (Apex) e Zellic (V12) para escanear rapidamente seu código antes de uma auditoria completa.

Tempo e fricção são boas defesas

Adicione múltiplas etapas e bloqueios de tempo para qualquer operação que possa causar dano. Você precisa de tempo suficiente para intervir e congelar ao detectar anomalias.

No passado, a resistência a bloqueios de tempo e etapas múltiplas vinha do receio de criar fricções para a equipe do protocolo. Agora, com IA, essa preocupação diminui: ela pode passar facilmente por esses obstáculos nos bastidores.

Variáveis invariantes

Contratos inteligentes podem ser defensivamente construídos ao escrever «fatos» imutáveis: se esses fatos forem quebrados, toda a lógica do protocolo entra em colapso.

Normalmente, há apenas algumas invariantes. É preciso elevá-las cuidadosamente ao código; forçar várias invariantes em cada função torna-se difícil de gerenciar.

Equilíbrio de poder

Muitos ataques vêm de carteiras comprometidas. Você precisa de uma configuração que, mesmo que uma multi-assinatura seja comprometida, possa rapidamente conter o dano e trazer o protocolo de volta a um estado de governança decisório.

Isso exige um equilíbrio entre Governança (que decide tudo) e Resgate (que restaura a estabilidade de governança, sem substituir ou derrubar a governança em si).

Sempre há problemas

Desde o início, suponha: por mais inteligente que você seja, será hackeado. Seus contratos inteligentes ou dependências podem falhar. Você pode sofrer engenharia social, atualizações podem introduzir vulnerabilidades não previstas.

Pensando assim, limites de dano, restrições de taxa e disjuntores de protocolo se tornam seus melhores aliados. Limite o dano a 5-10%, congele e planeje sua resposta. Ninguém consegue tomar as melhores decisões sob fogo cruzado.

O melhor momento para planejar é agora

Antes de ser hackeado, pense na sua resposta. Codifique o máximo possível dos processos e pratique com a equipe, para não ficar perdido na hora do impacto. Na era da IA, isso significa ter habilidades e algoritmos capazes de apresentar rapidamente uma grande quantidade de informações, resumidas e detalhadas, ao seu núcleo.

Você não precisa de perfeição, mas precisa sobreviver. Nenhum sistema é invulnerável desde o primeiro dia; com múltiplas iterações, você se torna antifrágil ao aprender com os erros.

A ausência de evidências de que foi hackeado não significa que você não será. O ponto de maior conforto costuma ser o maior risco.

Medidas preventivas

Design de contratos inteligentes

Ao identificar invariantes, eleve-os a verificações em tempo de execução. Pense cuidadosamente quais invariantes valem a pena reforçar.

Este é o método FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants): ao final de cada função que manipula valor, revalide as invariantes essenciais. Muitas vulnerabilidades de ataques de múltiplas transações (flash loans, liquidações assistidas por oráculos, drenagem de capacidade entre funções) podem ser capturadas por verificações de invariantes ao final da função.

Testes de qualidade

Fuzzing com estado (Stateful fuzzing) gera sequências aleatórias de chamadas na superfície pública do protocolo, verificando invariantes a cada passo. A maioria das vulnerabilidades em produção envolve múltiplas transações; o fuzzing com estado é quase a única forma confiável de descobrir esses caminhos antes do atacante.

Use testes de invariantes para assegurar que propriedades se mantenham em todas as sequências geradas pelo fuzzing. Com verificação formal, pode-se provar que essas propriedades valem em todos os estados acessíveis. Seus invariantes de topo da coroa devem aceitar esse método.

Oráculos e dependências

Complexidade é inimiga da segurança. Cada dependência externa amplia a superfície de ataque. Ao projetar primitivas, deixe a escolha de quem e do que confiar ao usuário. Se não for possível eliminar dependências, diversifique-as, de modo que nenhum ponto único de falha possa destruir seu protocolo.

Expanda o escopo de auditoria para simular falhas de oráculos e dependências, impondo limites de taxa ao que pode acontecer se eles falharem.

O recente caso de vulnerabilidade do KelpDAO é um exemplo: eles herdaram a configuração padrão do LayerZero requiredDVNCount=1, que estava fora do escopo da auditoria. O ataque final ocorreu na infraestrutura off-chain fora do escopo de auditoria.

Ataques de superfície

A maioria das superfícies de ataque em DeFi já foi listada. Verifique cada categoria, pergunte se ela se aplica ao seu protocolo, e implemente controles contra esses vetores. Desenvolva habilidades de red team, permitindo que seus agentes de IA busquem vulnerabilidades ativamente no seu protocolo; isso já é uma exigência básica hoje.

Tenha capacidades nativas de resgate

Em governança baseada em votação, o poder inicialmente está concentrado nas multi-assinaturas da equipe, levando tempo para se dispersar. Mesmo com ampla distribuição de tokens, a delegação muitas vezes concentra autoridade em poucas carteiras (às vezes até uma única). Quando essas carteiras forem comprometidas, o jogo acaba.

Implemente «Carteiras Guardiãs», com permissões restritas: apenas podem pausar o protocolo, e, com um limiar de >=4/7, podem trocar os delegados em caso extremo. Essas carteiras nunca podem executar propostas de governança.

Assim, você terá uma camada de resgate que sempre pode restaurar a estabilidade de governança, sem poder derrubá-la. A probabilidade de perder >=4/7 das carteiras guardiãs é extremamente baixa (considerando a diversidade de detentores), e, uma vez que a governança esteja madura e dispersa, essa camada pode ser gradualmente eliminada.

Carteiras e topologia de chaves

Multi-assinaturas são o mínimo necessário, com pelo menos 4/7. Nenhuma pessoa controla todas as 7 chaves. Rotacione assinantes frequentemente, de forma silenciosa.

Chaves nunca devem interagir com dispositivos de uso diário. Se você usar um dispositivo de assinatura para navegar na internet, enviar e-mails ou abrir Slack, já considera que esse assinante foi comprometido.

Tenha múltiplas multi-assinaturas, cada uma com usos diferentes. Suponha que pelo menos uma delas seja comprometida, e planeje a partir daí. Nenhuma pessoa deve ter controle suficiente para derrubar o protocolo, mesmo em cenários extremos (sequestro, tortura etc.).

Considere recompensas

Se tiver recursos, defina uma recompensa alta por vulnerabilidades, proporcional ao TVL do protocolo; mesmo que seja um protocolo menor, a recompensa deve ser generosa (por exemplo, sete ou oito dí