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

Escrever artigo: sysls

Compilado por: AididiaoJP, Foresight News

Introdução

Ao entender uma grande quantidade de eventos de ataques de hackers a protocolos DeFi, fiquei com 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 sua atenção dispersa 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 fundos elevados), tendo 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

(Fontes de 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 maior número de ataques de hackers a DeFi já registrado, e o segundo trimestre, que acabou de começar, já promete superar 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 vasculhar a configuração de cem protocolos em busca de configurações incorretas; enquanto o modelo de base mais recente pode fazer isso em poucas horas.

Isso deve mudar completamente nossa forma de pensar e responder a ataques. Protocolos antigos que estavam acostumados a medidas de segurança antes do fortalecimento da IA correm cada vez mais risco de serem «derrotados em segundos».

Pensando na superfície e na hierarquia

(Fontes de 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 é confirmado, acione imediatamente o desligamento geral. Congelar evita perdas adicionais e dá espaço para pensar…

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

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

Princípios

Estes 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 larga escala: tente encontrar brechas na interface, verificando se elas podem alcançar o backend. Hackers fazem isso. O que você consegue detectar com escaneamentos defensivos, eles já detectaram com escaneamentos ofensivos.

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, resistíamos a bloqueios de tempo e etapas múltiplas por criarem fricção para a equipe do protocolo. Agora, com IA, essa fricção pode ser facilmente contornada nos bastidores.

Variáveis invariantes

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

Normalmente, há poucas invariantes. É preciso cuidado ao elevá-las ao código; forçar várias invariantes em cada função torna a gestão difícil.

Equilíbrio de poder

Muitos ataques vêm de carteiras comprometidas. Você precisa de uma configuração que, mesmo que uma multiassinatura seja invadida, possa rapidamente limitar o dano e trazer o protocolo de volta a um estado de governança controlável.

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 ou dependências podem falhar. Você pode sofrer engenharia social, atualizações podem introduzir vulnerabilidades não previstas.

Pensando assim, limites de taxa de dano e disjuntores de protocolo se tornam seus melhores amigos. Limite o dano a 5-10%, depois congele e planeje sua resposta. Ninguém consegue tomar a melhor decisão sob fogo cruzado.

O melhor momento para planejar é agora

Antes de ser hackeado, pense na sua resposta. Codifique os processos o máximo possível 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 muitas informações, resumidas e detalhadas, ao seu núcleo de decisão.

Você não precisa de perfeição, mas de sobrevivência. Nenhum sistema é imbatível desde o primeiro dia; com iterações, você se torna antifrágil ao aprender com os erros.

A ausência de provas 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

Depois de definir invariantes, eleve-os a verificações em tempo de execução. Pense cuidadosamente quais invariantes valem a pena serem obrigatoriamente verificadas.

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 fraudes por meio de CEI (Checks-Effects-Interactions), como ataques de sandwich em flash loans, liquidações assistidas por oráculos ou drenagem de capacidade entre funções, podem ser capturadas por verificações de invariantes ao final.

Testes de qualidade

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

Use testes de invariantes para garantir 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 segurança 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 primitives, deixe a escolha de quem e do quê confiar ao usuário. Se não puder 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; isso já é uma exigência básica hoje.

Tenha capacidade de resgate nativa

Em governança baseada em votação, o poder inicialmente está concentrado na multiassinatura 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 são invadidas, o jogo acaba.

Implemente «Carteira Guardiã», com permissões restritas: apenas para pausar o protocolo, e com um limiar de >=4/7 para, em casos extremos, substituir as carteiras comprometidas por outras predefinidas. Guardiãs nunca podem propor mudanças de governança.

Assim, você tem uma camada de resgate que sempre pode restaurar a estabilidade de governança, sem poder derrubar a governança em si. A probabilidade de perder >=4/7 das guardiãs é muito 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

Multiassinaturas 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, esse assinante já foi comprometido.

Tenha múltiplas multiassinaturas, cada uma com usos diferentes. Considere que pelo menos uma será invadida, e planeje a partir daí. Nenhuma pessoa deve ter controle suficiente para invadir 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ígitos mínimos).

Se você enfrenta ataques de agentes estatais, eles podem não negociar, mas você pode participar de programas «White Hat Security», autorizando hackers éticos a agir em seu nome para proteger fundos, recebendo uma porcentagem do valor da vulnerabilidade como recompensa (que na prática é paga pelos depositantes).

Encontre bons auditores

Antes, eu dizia que, com modelos de linguagem cada vez mais inteligentes, o valor marginal de contratar auditores diminui. Ainda penso assim, mas minha visão mudou.

Primeiro, bons auditores estão na vanguarda. Se você está fazendo algo inovador, seu código e suas vulnerabilidades podem não estar nos dados de treinamento, e aumentar tokens não garante descobrir vulnerabilidades novas. Você não quer ser o primeiro a ter uma vulnerabilidade única.

Segundo, um benefício subestimado é: contratar um auditor é usar sua reputação como garantia. Se eles assinarem e você for atacado, terão forte incentivo para ajudar. Relacionar-se com profissionais de segurança é uma vantagem enorme.

Praticar segurança operacional

Considere segurança operacional como um indicador de sucesso. Faça treinamentos de phishing; contrate (de confiança) red teams para tentarem engenharia social na equipe. Tenha hardware e dispositivos de backup prontos para substituir toda a multiassinatura, se necessário. Você não quer correr na hora H para comprar esses itens.

Medidas de mitigação

Sua rota de saída é o limite de perdas

Qualquer caminho de saída que transfira valor para fora do protocolo deve ter um limite máximo. Em outras palavras: funções de emissão sem limite por bloco são um cheque em branco para qualquer vulnerabilidade de emissão infinita. Funções de resgate sem limite semanal também.

Pense cuidadosamente no valor máximo que sua rota de saída pode ter. Esse número deve equilibrar o dano máximo que você tolera e a experiência extrema do usuário. Se algo der errado, isso pode te salvar de uma destruição total.

Lista de permissões (e de bloqueios)

A maioria dos protocolos tem listas de chamadas, transações ou recebimentos, e também listas de ações proibidas para usuários. Mesmo que implícitas, essas são fronteiras de confiança, que devem ser formalizadas.

Formalizá-las permite criar mecanismos de duas etapas na configuração, criando fricção significativa. O atacante precisa primeiro adicionar à whitelist (ou remover da blacklist), e só então agir. Ter ambos os controles significa que, ao tentar introduzir um vetor novo, o invasor precisa comprometer ambos os processos: o mercado deve permitir (listagem / entrada), e a ação não pode ser proibida (revisão de segurança).

Recuperação

Monitoramento algorítmico

Se ninguém monitora, o disjuntor é inútil. Monitores off-chain devem acompanhar invariantes continuamente, e, ao detectar problemas, disparar alertas automatizados. O caminho final deve chegar aos guardiões, que devem receber contexto suficiente para decidir em poucos minutos.

Recalibrar e parar

Se você foi atingido, pare o sangramento antes de tomar decisões na contagem regressiva. Para o protocolo, isso é o disjuntor (que também deve estar na interface): um botão que pausa todas as rotas de transferência de valor com um clique. Prepare um script auxiliar para pausar todos os componentes de forma atômica.

Somente a governança pode remover a pausa, portanto, o disjuntor não deve pausar o contrato de governança. Se os guardiões puderem pausar o contrato de governança, um guardião invadido pode travar o processo de recuperação para sempre.

Inicie sua sala de crise

Congele, pare o sangramento, e reúna todos os seus contatos confiáveis (pequeno grupo, previamente alinhado) em um canal de comunicação. Mantenha o grupo pequeno para evitar vazamentos para atacantes, público ou arbitradores maliciosos.

Faça simulações de papéis: um toma decisões; outro executa scripts de defesa e pausa; outro investiga vulnerabilidades e causas raízes; outro comunica com partes-chave; outro registra observações, eventos e decisões.

Quando todos souberem seus papéis e praticarem, você reagirá de forma coordenada, não na hora do aperto, mas de forma planejada.

Considere reações em cadeia

Suponha que seu atacante seja altamente experiente. A primeira vulnerabilidade pode ser um isca ou uma semente para ataques futuros. O ataque pode ser uma tentativa de induzi-lo a fazer algo errado, acionando uma vulnerabilidade real.

A pausa deve ser totalmente controlada, e o protocolo deve estar completamente congelado: você não quer que uma pausa induzida abra espaço para outra vulnerabilidade. Uma vez identificado o vetor de ataque, explore as superfícies expostas e as reações em cadeia, e corrija tudo de uma vez.

Rotacione sucessores previamente comprometidos

Só faz sentido trocar de sucessor se você já souber quem será. Recomendo um registro de sucessores pré-definidos: dificulta que atacantes substituam guardiões ou carteiras de governança por outros comprometidos. Essa ideia é compatível com a de «lista de whitelist/blacklist» de medidas de resgate.

Registre um sucessor para cada papel importante. A única operação de emergência é «substituir o papel X pelo seu sucessor». Assim, você pode avaliar os sucessores com calma, fazer due diligence, e conversar com quem pede a troca.

Antes de atualizar, teste cuidadosamente

Depois de entender a causa raiz e o impacto, prepare a atualização. Pode ser o código mais perigoso que você já escreveu: sob pressão, pensando em atacantes que já sabem do seu protocolo e podem explorar vulnerabilidades.

Não publique sem testes adequados. Se não houver tempo para auditoria, use relações com white hats ou faça uma competição de 48 horas antes do deploy, para obter uma revisão adversarial recente.

Restaurar

Aja rapidamente

Fundos roubados têm meia-vida; assim que o ataque acontece, eles entram em rotas de lavagem. Tenha parceiros de análise on-chain como Chainalysis prontos para monitorar endereços de atacantes, e notificar trocas ao cruzar informações.

Prepare uma lista de entidades de conformidade, administradores de pontes cross-chain, custodiante, e outros terceiros com autoridade para congelar mensagens ou depósitos em trânsito.

Negocie

Sim, é doloroso, mas vale tentar dialogar com os atacantes. Muitas vezes, a vida se resolve por negociação. Ofereça recompensas white hat com prazo, e declare publicamente que, se devolverem tudo até a data limite, não tomarão ações legais.

Se for um agente estatal, talvez não tenha sorte, mas pode ser um atacante menos experiente, que só quer usar sua vulnerabilidade e sair barato.

Antes, consulte um advogado.

Conclusão

Ataques não vão parar, e com IA mais inteligente, eles só aumentarão. Apenas tornar os defensores «mais atentos» não basta. Precisamos usar as mesmas ferramentas dos atacantes para fazer red team, monitorar continuamente, e impor limites rígidos ao dano, para que possamos sobreviver ao pior cenário.