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

Escrevendo: sysls

Compilado por: AididiaoJP, Foresight News

Link do artigo original:

Aviso: Este artigo é uma reprodução de conteúdo, os leitores podem obter mais informações através do link original. Se o autor tiver alguma objeção à reprodução, por favor, entre em contato conosco, faremos as devidas alterações conforme solicitado pelo autor. A reprodução é apenas para compartilhamento de informações, não constitui aconselhamento de investimento, nem reflete opiniões ou posições do Wu.

Introdução

Ao entender uma grande quantidade de eventos de hackers em protocolos DeFi, fiquei com medo de «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 grandes fundos), tendo ampla experiência em pensar e planejar planos de contingência.

Acredito sinceramente que só 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 a coisa é 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 em DeFi já registrado, e o segundo trimestre, que acabou de começar, já promete quebrar esse recorde.

Minha hipótese central é: IA reduziu drasticamente o custo de encontrar vulnerabilidades e expandiu enormemente o vetor de ataque. Humanos levam várias semanas para revisar a configuração de cem protocolos em busca de erros de configuração; já os modelos de base 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 se acostumaram a medidas de segurança antes do fortalecimento da IA estão cada vez mais vulneráveis a serem «derrotados em segundos».

Pensando em superfície e 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 interruptor geral. Congelar pode impedir perdas adicionais e dar tempo 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 podem alcançar o backend. Hackers fazem isso. O que você consegue detectar com varreduras defensivas, eles já detectaram com varreduras ofensivas.

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

Tempo e atrito 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 atritos para a equipe do protocolo. Agora, com IA, esses atritos podem ser facilmente contornados 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 desmorona.

Normalmente, há poucas invariantes. É preciso cautela 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 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).

Sempre há problemas

Desde o início, assuma: por mais inteligente que seja, você 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 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.

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 sua 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 é imbatível desde o primeiro dia; com iterações, você se torna mais resistente ao aprender com os erros.

Ausência de ataque não significa que você não será hackeado. O ponto de maior risco costuma ser o máximo conforto.

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. Muitos ataques de drenagem via CEI (Checks-Effects-Interactions), como sanduíches de flash loans, liquidações assistidas por oráculos e drenagem de capacidade entre funções, podem ser capturados 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 interface pública do protocolo, verificando invariantes a cada passo. A maioria das vulnerabilidades em produção são múltiplas transações, e fuzzing com estado é quase a única forma confiável de descobrir esses caminhos antes do atacante.

Use invariantes para afirmar que propriedades se mantêm em todas as sequências geradas pelo fuzzing. Com verificação formal, pode-se provar que essas propriedades valem em todos os estados alcançáveis. Seus invariantes de topo devem aceitar esse procedimento.

Oráculos e dependências

Complexidade é inimiga da segurança. Cada dependência externa amplia o vetor de ataque. Ao projetar primitives, 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 potencial desastre de suas falhas.

O recente bug 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 foi na infraestrutura off-chain fora do escopo de auditoria.

Superfície de ataque

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 atualmente.

Tenha capacidade de resgate nativa

Em governança baseada em votação, o poder inicialmente está concentrado nas multiassinaturas da equipe, levando tempo para se dispersar. Mesmo com ampla distribuição de tokens, delegações tendem a concentrar 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, em situações extremas, trocar os delegados por carteiras substitutas predefinidas. Guardiãs nunca podem propor ou aprovar governança.

Assim, você terá 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, com pelo menos 4/7. Nenhuma pessoa controla todas as 7 chaves. Rotacione frequentemente os signatários, de forma silenciosa.

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

Tenha múltiplas multiassinaturas, cada uma com usos diferentes. Assuma que pelo menos uma será comprometida, e planeje a partir daí. Nenhuma pessoa deve ter controle suficiente para comprometer 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 para protocolos menores, a recompensa deve ser generosa (por exemplo, sete ou oito dígitos mínimos).

Se estiver enfrentando ataques de agentes estatais, eles podem não negociar, mas você pode participar de programas de «White Hat», 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

Já escrevi antes que, com modelos de linguagem cada vez mais inteligentes, o valor marginal de contratar auditores diminui. Ainda mantenho essa opinião, mas minha perspectiva 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 simplesmente aumentar tokens não foi comprovado como método eficaz para descobrir vulnerabilidades novas. Você não quer ser o primeiro a ter uma vulnerabilidade única.

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

Praticando 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

Seu caminho de saída é o limite de perdas

Qualquer caminho de retirada de valor do protocolo deve ter um limite máximo teórico de perdas. Em termos simples: 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 são um cheque em branco para qualquer saldo de ativos corrompido.

Pense cuidadosamente no valor numérico do seu limite de saída. Esse número deve equilibrar o máximo dano que você aceita e a extrema necessidade de UX dos usuários. Se algo der errado, isso é o que pode evitar uma destruição total.

Lista de permissões (e listas negras)

A maioria dos protocolos possui 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 atritos significativos. 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 atacante precisa comprometer ambos os processos: o mercado deve estar permitido (listado/negociado) e a ação não pode ser proibida (revisão de segurança).

Recuperar

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 multiassinatura, com contexto suficiente para que possam decidir em poucos minutos.

Recalibrar e pausar

Se você foi atingido, pare o sangramento antes de tomar decisões. Para contratos, isso é o disjuntor (que também deve estar visível na interface): um botão que pausa todas as rotas de movimentação de valor com um clique. Prepare um script auxiliar de «pause all» que enumere todos os componentes pausáveis e os pause de forma atômica.

Somente a governança pode remover a pausa, portanto, o disjuntor não pode pausar o contrato de governança. Se a camada de guardiões puder pausar o contrato de governança, ela pode travar o processo de recuperação de forma permanente.

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 role-playing dos papéis necessários: um tomador de decisão; um operador habilidoso em executar scripts de defesa e pausar componentes; alguém que reestruture vulnerabilidades e identifique causas raízes; alguém que comunique com partes-chave; alguém que registre observações, eventos e decisões em uma linha do tempo.

Quando todos souberem seus papéis e praticarem, você reagirá por procedimento, não por improviso na hora crítica.

Considere reações em cadeia

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

A pausa deve ser totalmente controlada, com estudo aprofundado, e não pode ser explorada. A pausa deve congelar toda a rede: você não quer que uma pausa induzida abra caminho para outra. Uma vez identificada a causa raiz e o vetor de ataque, explore as superfícies expostas e as reações em cadeia, e corrija tudo de uma vez.

Troca antecipada de sucessores

Só faz sentido trocar alguém se você já conhece o sucessor com antecedência. Gosto da ideia de um registro de sucessores pré-registrados: dificulta que atacantes substituam guardiões ou carteiras de governança por comprometidos. Essa abordagem é compatível com a ideia de listas brancas/negras de medidas de resgate.

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

Antes de atualizar, teste cuidadosamente

Depois de identificar a causa raiz e o impacto, você precisa lançar uma atualização. Essa pode ser a parte mais perigosa do seu código: escrito sob pressão, visando um atacante que já conhece seu protocolo e suas vulnerabilidades.

Aposte na demora: não lance sem testes completos. Se não houver tempo para auditoria, use relações com white hats, ou crie uma corrida de 48 horas antes do deploy para uma revisão adversária.

Restaurar

Ação rápida

Fundos roubados têm meia-vida; uma vez que o ataque acontece, eles entram rapidamente em rotas de lavagem. Prepare-se com fornecedores de análise on-chain como Chainalysis, para marcar endereços de atacantes em tempo real, e notificar trocas ao cruzar informações.

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

Negociação

Sim, é doloroso, mas você ainda deve tentar dialogar com os atacantes. Muitas coisas na vida podem ser resolvidas por negociação. Ofereça recompensas white hat com prazo, e declare publicamente que, se devolverem o valor integral até a data limite, não tomarão ações legais.

Se estiver lidando com agentes estatais, pode ser azar, mas talvez esteja lidando com atacantes menos experientes, que só encontraram uma forma de explorar sua vulnerabilidade e querem sair com um custo menor.

Antes de fazer isso, consulte um advogado.

Conclusão

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