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

Título original: Como Parar de Perder Dinheiro com Hacks DeFi Autor original: sysls, openforage Tradução do artigo original: AididiaoJP, Foresight News

Autor do artigo:律动BlockBeats

Fonte original:

Reprodução: 火星财经

Introdução

Ao entender uma grande quantidade de incidentes de hackers em 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 focam em revisar cada canto do seu protocolo e infraestrutura em busca de vulnerabilidades, enquanto as 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

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 DeFi registrados até hoje, 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 o vetor de ataque. Levaria semanas para um humano revisar a configuração de cem protocolos em busca de erros; enquanto o modelo 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 «eliminados em um segundo».

Pensando superficialmente e em camadas

A superfície de ataque de um protocolo 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, reduz ao máximo a probabilidade de exploração de vulnerabilidades.

· 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 botão de desligar geral. Congelar pode impedir perdas adicionais e dar tempo para pensar…

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

· Restabelecimento: recupere o que foi perdido. Planeje previamente contatos de parceiros capazes de congelar fundos, cancelar 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 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, resistir a bloqueios de tempo e etapas múltiplas era justificado por causar atrito às equipes de protocolo. Agora, com IA, esse atrito pode ser facilmente contornado nos bastidores.

Variáveis invariantes

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

Normalmente, há poucas 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 multiassinatura seja invadida, possa rapidamente limitar o dano e trazer o protocolo de volta a um estado gerenciável.

Isso exige um equilíbrio entre governança (que decide tudo) e resgate (recuperar estabilidade gerenciável, sem substituir ou derrubar a governança).

Sempre há problemas

Desde o início, deve-se assumir: 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 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 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 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 muitas informações, compartilhando resumos e detalhes com 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.

A ausência de provas de que não 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 realmente 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 valores, revalide as invariantes essenciais. Muitas vulnerabilidades de ataques de drenagem (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 interface 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 garantir que propriedades se mantenham em todas as sequências geradas pelo fuzzing. Complementado por verificação formal, pode provar que as propriedades valem em todos os estados acessíveis. Seus invariantes de segurança devem aceitar esse método.

Oráculos e dependências

A complexidade é inimiga da segurança. Cada dependência externa amplia o vetor de ataque. Ao projetar primitives, deixe a escolha de quem e do quê confiar para o 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 exemplo da vulnerabilidade do KelpDAO ilustra isso: 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 da 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 hoje.

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, 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 substituir as carteiras comprometidas por alternativas predefinidas. Guardiãs nunca podem propor governança.

Assim, você terá uma camada de resgate que sempre pode restaurar a estabilidade gerenciável, sem poder derrubar a governança. 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 eliminada progressivamente.

Carteiras e topologia de chaves

Multiassinaturas são essenciais, com mínimo de 4/7. Nenhum indivíduo controla todas as 7 chaves. Rotacione assinantes frequentemente, de forma silenciosa.

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

Tenha múltiplas multiassinaturas, cada uma com usos diferentes. Suponha que pelo menos uma seja comprometida, e planeje a partir daí. Nenhum indivíduo 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 que seja um protocolo menor, a recompensa deve ser generosa (por exemplo, no mínimo 7-8 dígitos).

Se estiver enfrentando ataques de atores estatais, eles podem não negociar, mas você ainda pode participar de programas de «white hat» e autorizar 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 avançados, 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ê estiver 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, terão forte incentivo para ajudar. Relacionar-se com profissionais de segurança é uma vantagem enorme.

Praticando segurança operacional

Considere a segurança operacional como um indicador de sucesso. Faça treinamentos de phishing; contrate (de confiança) red teams para testar 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 saída que transfira valor para fora do protocolo deve ter um limite máximo. 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 comprometido.

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

Lista de permissões (whitelist) e listas negras

A maioria dos protocolos possui listas de chamadas, transações ou recebedores autorizados, e listas de usuários proibidos. 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, gerando atrito significativo. O atacante precisa primeiro adicionar à whitelist (ou remover da blacklist) antes de agir. Ter ambos significa que, ao introduzir um vetor novo, o invasor precisa comprometer dois processos simultaneamente: o mercado deve permitir (integração/listagem) e a ação não pode ser proibida (revisão de segurança).

Recuperação

Monitoramento algorítmico

Se ninguém monitorar, o botão de desligar será inútil. Monitores off-chain devem acompanhar invariantes continuamente e, ao detectar problemas, disparar alertas automatizados. O caminho final deve chegar às mãos de guardiãs multiassinatura humanas, com contexto suficiente para que possam decidir em poucos minutos.

Recalibrar após o ataque

Se você foi atingido, pare o sangramento antes de tomar decisões na contagem regressiva. Para o protocolo, isso é o botão de desligar (que também deve estar na interface): um botão que pausa todas as rotas de transferência de valor em uma única transação. Prepare um script auxiliar de «pausa total», enumerando componentes pausáveis e pausando-os de forma atômica.

Somente a governança pode remover a pausa, portanto, o botão de desligar não deve pausar o contrato de governança. Se a camada de guardiãs 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 combinado). Mantenha a comunicação restrita para evitar vazamentos para atacantes, público ou arbitradores maliciosos.

Faça simulações de papéis: um tomador de decisões; um operador habilidoso em scripts de defesa e pausas; 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á de forma coordenada, sem pânico na hora do aperto.

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 bem estudada, totalmente controlável e não explorável. Ela deve congelar toda a rede: você não quer que uma pausa induzida abra espaço para outra. Assim que identificar a causa raiz e o vetor de ataque, explore as superfícies expostas e reações em cadeia, corrigindo tudo de uma vez.

Rotacione sucessores previamente comprometidos

Somente com sucessores previamente conhecidos a troca de responsáveis é segura. Gosto da ideia de um cadastro de sucessores pré-registrados: dificulta que atacantes substituam guardiãs ou carteiras de governança saudáveis por comprometidas. Essa abordagem é consistente com a ideia de «whitelist/blacklist» nas medidas de resgate.

Registre sucessores para cada papel importante. A única operação de troca autorizada na emergência é «substituir o responsável X pelo seu sucessor». Assim, você pode avaliar os sucessores em tempos de paz: fazer uma diligência, conversar com quem propôs, etc.

Antes de atualizar, teste cuidadosamente

Depois de identificar a causa raiz e o impacto, é hora de lançar a atualização. Pode ser o código mais perigoso que você já implantou: escrito sob pressão, visando um atacante que já conhece seu protocolo e suas vulnerabilidades.

Atrasar a implantação sem testes adequados é arriscado. Se não houver tempo para auditoria, use relações com white hats ou configure uma competição de 48 horas antes do lançamento, para obter uma revisão adversarial recente.

Recuperação rápida

Ações rápidas

Fundos roubados têm meia-vida; uma vez que o ataque se concretiza, eles entram rapidamente em rotas de lavagem. Prepare-se com Chainalysis ou outros provedores de análise on-chain para marcar endereços de atacantes em tempo real, e notifique plataformas de troca ao cruzar informações.

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

Negociação

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

Se estiver lidando com atores estatais, talvez não tenha sorte, mas pode enfrentar atacantes menos experientes, que apenas encontraram uma forma de explorar sua vulnerabilidade e querem sair com custos baixos.

Antes de agir, consulte um advogado.

Conclusão

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