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

Título original: How To Stop Losing Money To DeFi Hacks
Autor original: sysls, openforage
Tradução original: AididiaoJP, Foresight News

Introdução

Ao entender uma grande quantidade de eventos de ataques de hackers em protocolos DeFi, fiquei assustado com os “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

(Fonte de dados: https://defillama.com/hacks)

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 já registrado, e o segundo trimestre mal começou, mas 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 isso, os modelos básicos mais recentes podem 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 enfrentam um risco crescente de serem “eliminados em um segundo”.

Pensando superficialmente e em camadas

(Fonte de dados: https://defillama.com/hacks)

A superfície de ataque de hackers 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, adicione camadas de defesa:

· Prevenção: processos rigorosos que maximizam a redução da probabilidade de exploração.

· Mitigação: limitar o dano quando a prevenção falha.

· 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ê perder controle de componentes tóxicos ou comprometidos, descarte-os e substitua-os.

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

Princípios

Esses princípios orientam ações específicas 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 frontal para ver se elas atingem o backend. Os atacantes 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, não se preocupe tanto: a IA pode facilmente passar por essas fricções 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 desmorona.

Normalmente, você tem apenas algumas 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 comprometida, 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 (que restaura a estabilidade gerenciável, sem substituir ou derrubar a governança).

Problemas sempre surgirão

Parta do princípio: por mais inteligente que você seja, será hackeado. Seus contratos inteligentes ou dependências podem falhar. Você pode sofrer engenharia social, e novas atualizações podem introduzir vulnerabilidades não previstas.

Pensando assim, limites de taxa para limitar danos e disjuntores para bloquear o protocolo serão seus melhores aliados. 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 o máximo possível do processo 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, compartilhando resumos e detalhes com seu núcleo.

Você não precisa ser perfeito, mas precisa sobreviver. Nenhum sistema é imbatível desde o primeiro dia; com iterações, você se tornará mais resistente 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 risco costuma ser o mais confortável.

Medidas preventivas

Design de contratos inteligentes

Depois de definir 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 valor, revalide as invariantes principais que ela promete manter. Muitas vulnerabilidades, como ataques de CEI (Checks-Effects-Interactions), podem ser capturadas por verificações de invariantes ao final da função (ex: ataques de flashloan, liquidações assistidas por oráculos, drenagem de capacidade entre funções).

Testes de qualidade

Testes de fuzzing com estado (Stateful fuzzing) geram 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, e o 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 acessíveis. Seus invariantes principais devem aceitar esse método.

Oráculos e dependências

A complexidade é inimiga da segurança. Cada dependência externa aumenta a superfície de ataque. Ao projetar primitivas, deixe a escolha de confiar em quem e no quê 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, e aplique limites de taxa ao potencial desastre que suas falhas podem causar.

O recente exemplo do KelpDAO é ilustrativo: eles herdaram a configuração padrão do LayerZero, requiredDVNCount=1, que estava fora do escopo da auditoria. A vulnerabilidade foi explorada 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 sua IA procure vulnerabilidades ativamente; isso já é uma exigência básica atualmente.

Tenha capacidades de resgate nativas

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 autoridade muitas vezes se centraliza em algumas carteiras (às vezes uma única). Quando essas carteiras são comprometidas, o jogo acaba.

Implemente “carteiras guardiãs”, com permissões restritas: podem apenas pausar o protocolo e, com um limiar de >=4/7, podem trocar delegados danificados por carteiras substitutas predefinidas. Essas carteiras nunca podem propor governança.

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

Topologia de carteiras e chaves

Multiassinaturas são o mínimo necessário, com pelo menos 4/7. Nenhum indivíduo deve controlar todas as 7 chaves. Rotacione frequentemente os signatários de forma silenciosa.

As 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, considere que essa chave 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, de 7 a 8 dígitos mínimos).

Se você estiver sob ataque de agentes estatais, eles podem não negociar, mas ainda assim 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 taxa (na prática, um bônus pago 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ê estiver fazendo algo inovador, seu código e suas vulnerabilidades podem não estar nos dados de treinamento, e simplesmente aumentar tokens ainda não provou ser eficaz na descoberta de 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.

Práticas de segurança operacional

Considere a segurança operacional como um indicador de sucesso. Faça treinamentos de phishing; contrate (de confiança) equipes vermelhas para testar engenharia social com sua equipe. Tenha hardware e dispositivos de backup prontos para substituir toda a multiassinatura, se necessário. Você não quer correr para comprar esses itens na hora do “D-day”.

Medidas de mitigação

Seu caminho de saída é o limite de perdas

O limite máximo de valor que pode ser transferido para fora do protocolo define a maior perda teórica caso uma vulnerabilidade seja explorada. Simplificando: uma função de emissão sem limite por bloco é como um cheque em branco para qualquer emissão infinita. Uma função de resgate sem limite semanal é como um cheque em branco para qualquer saldo de ativos.

Pense cuidadosamente nos valores claros do seu caminho de saída. Esses números precisam equilibrar o dano máximo que você está disposto a suportar 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 listas negras)

A maioria dos protocolos possui listas de chamadas, transações ou recepções, 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, introduzindo fricções significativas. O atacante primeiro precisa adicionar à lista de permissões (ou remover da lista negra), antes de agir. Ter ambos os controles significa que, ao tentar introduzir um vetor de ataque, o invasor precisa comprometer dois processos: a listagem no mercado (integração / listagem) e a ação de segurança (revisão).

Recuperação

Monitoramento algorítmico

Se ninguém monitorar, o interruptor geral não serve de nada. Monitores off-chain devem acompanhar invariantes continuamente, e, ao detectar problemas, escalar alertas automaticamente. O caminho final deve chegar aos guardiões da multiassinatura, com contexto suficiente para que possam decidir em poucos minutos.

Recalibração

Se você foi comprometido, primeiro pare o sangramento, não tome decisões na contagem regressiva. Para o protocolo, isso é o kill switch (que também deve estar visível na interface): um botão que pausa todas as rotas de transferência de valor com um clique. 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 kill switch não deve 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 todas as pessoas de confiança (pequeno grupo, com acordo prévio) 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 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 linhas do tempo das decisões.

Quando todos souberem seus papéis e praticarem, você poderá reagir de forma estruturada, evitando o caos 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 totalmente errado, acionando uma vulnerabilidade real.

A pausa deve ser totalmente controlada, bem estudada e não explorável. Deve ser uma pausa total do protocolo: você não quer ser induzido a pausar um componente e abrir espaço para outro. Assim que identificar a causa raiz e o vetor de ataque, explore as superfícies expostas adjacentes e as reações em cadeia, corrigindo tudo de uma vez.

Rotacione sucessores previamente comprometidos

Somente com sucessores previamente conhecidos a troca é segura. Gosto da ideia de um registro de sucessores pré-registrados: dificulta que atacantes substituam guardiões ou carteiras de governança saudáveis por comprometidos. Essa abordagem é consistente com a ideia de listas brancas / listas negras nas medidas de mitigação.

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 os sucessores em tempos de paz: fazer uma diligência, conversar com quem propôs, etc.

Testes cautelosos antes de atualizações

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

Evite lançar sem testes completos. Se não houver tempo para auditoria, use relações com white hats ou configure uma competição de 48 horas antes do deploy para obter uma revisão adversarial recente.

Recuperação

Aja rapidamente

Fundos roubados têm meia-vida; assim que a vulnerabilidade é explorada, 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 notifique plataformas de troca ao cruzar esses endereços.

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

Negociação

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

Se estiver lidando com agentes estatais, pode não ter sorte, mas pode estar lidando com atacantes menos experientes, que apenas encontraram uma forma de explorar seu sistema 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ó vão aumentar. Apenas tornar os defensores “mais atentos” não é suficiente. Precisamos usar as mesmas ferramentas dos atacantes para fazer testes de red team, monitorar continuamente e impor limites rígidos ao dano, para que possamos sobreviver ao pior cenário.

Link do artigo original

Clique para conhecer as vagas na BlockBeats

Participe da comunidade oficial da BlockBeats:

Grupo no Telegram: https://t.me/theblockbeats

Grupo de discussão no Telegram: https://t.me/BlockBeats_App

Conta oficial no Twitter: https://twitter.com/BlockBeatsAsia