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

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

Introdução

Ao conhecer 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; esses supervilões focam em revisar cada canto do seu protocolo e infraestrutura em busca de vulnerabilidades, enquanto equipes comuns de protocolos 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 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 é realmente diferente

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

Ataques de hackers não são raros, 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 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 revisar a configuração de cem protocolos em busca de erros; enquanto isso, os modelos de base mais recentes podem fazer isso em poucas horas.

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

Pensando na superfície e na hierarquia

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

A superfície de ataque de fato 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 que, se rigorosamente seguidos, maximizam a redução da probabilidade de exploração.

· Mitigação: ao falhar na prevenção, limita o 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 parada geral. Congelar pode impedir perdas adicionais e dar espaço para pensar…

· Recuperação: se você perdeu 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

Estes princípios orientam ações concretas para implementar múltiplas camadas 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. 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ção para a equipe do protocolo. Agora, com IA, essa fricção pode ser facilmente contornada nos bastidores.

Invariantes

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

Normalmente, há poucos invariantes. É preciso elevá-los cuidadosamente ao código; forçar múltiplos 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 configurações que, mesmo que uma multi-assinatura seja invadida, possam 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 pressuposto: por mais inteligente que seja, você será hackeado. Seus contratos ou dependências podem falhar. Você pode sofrer engenharia social, e novas 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 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 uma grande quantidade de informações, compartilhando resumos e detalhes com seu núcleo.

Você não precisa de perfeição, mas precisa sobreviver. Nenhum sistema é invulnerável desde o início; com múltiplas 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

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 (Requisitos de Função, Efeitos, Interações, Invariantes do Protocolo): ao final de cada função que manipula valores, revalide os invariantes essenciais. Muitas vulnerabilidades, como ataques de CEI (Checks-Effects-Interactions), podem ser capturadas por essas verificações ao final da função (ex: ataques de sandwich com flash loans, 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 ao 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 dos atacantes.

Use 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

A complexidade é inimiga da segurança. Cada dependência externa aumenta a superfície 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, e aplique limites de taxa ao impacto potencial de suas falhas.

O recente exemplo do bug na KelpDAO ilustra isso: 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 de auditoria.

Ataques de superfície

A maioria dos ataques de superfície em DeFi já foi listada. Verifique cada categoria, pergunte se ela se aplica ao seu protocolo e implemente controles específicos. Desenvolva habilidades de red team, fazendo seu IA procurar vulnerabilidades ativamente; isso já é uma exigência básica atualmente.

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 tokens amplamente distribuídos, 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 «carteiras guardiãs», com permissões restritas: apenas podem pausar o protocolo e, com um limiar de >=4/7, podem trocar delegados em situações extremas. Essas carteiras 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 dessas carteiras é 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

Multi-assinaturas são o mínimo necessário, com pelo menos 4/7. Nenhuma pessoa deve controlar todas as 7 chaves. Rotacione assinantes frequentemente, 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 assinatura já foi comprometida.

Tenha múltiplas multi-assinaturas, cada uma para usos diferentes. Suponha que pelo menos uma delas seja invadida, 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 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 ainda assim pode participar de programas «white hat», autorizando hackers éticos a agir em seu nome para proteger fundos, recebendo uma porcentagem do valor do bug 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 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 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. 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 sua equipe com engenharia social. Tenha hardware e dispositivos de backup prontos para substituir toda a multi-assinatura, 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 limite máximo de valor que pode ser transferido para fora do protocolo é a maior perda teórica possível se uma vulnerabilidade for explorada. Em resumo: uma função de emissão sem limite por bloco é um cheque em branco para qualquer vulnerabilidade de emissão infinita. Uma função de resgate sem limite semanal é um cheque em branco para qualquer saldo de ativos comprometido.

Pense cuidadosamente nos valores desses limites. Eles precisam equilibrar o dano máximo que você está disposto a suportar e a experiência extrema do usuário. Se algo der errado, esses limites podem evitar uma destruição total.

Listas de permissões (whitelist e blacklist)

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

Formalizá-las permite criar mecanismos de duas etapas para alterar essas listas, criando fricção significativa. Um atacante precisa primeiro adicionar algo à whitelist (ou remover da blacklist) antes de agir. Ter ambas as listas significa que, ao introduzir um novo vetor de ataque, o invasor precisa comprometer ambos os processos: 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 monitora, o botão de parada geral é inútil. Monitores off-chain devem acompanhar invariantes continuamente, e, ao detectar problemas, escalar alertas automaticamente. O caminho final deve chegar aos guardiões multi-assinatura, 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 botão de parada (que também deve estar na interface): um botão que pausa todas as transferências de valor em uma única transação. Prepare um script auxiliar para pausar todos os componentes de forma atômica.

Apenas a governança pode remover a pausa, portanto, o botão de parada não deve pausar o contrato de governança. Se os guardiões puderem pausar o contrato de governança, eles podem travar o processo de recuperação de forma permanente.

Monte sua sala de crise

Congele, pare o sangramento e reúna todas as pessoas de confiança (pequeno grupo, previamente combinado) 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 que decide, um que executa scripts de defesa e pausa, um que identifica vulnerabilidades e causas raízes, um que comunica com partes-chave, e um que registra observações, eventos e decisões.

Quando todos souberem seus papéis e praticarem, você reagirá de forma coordenada, sem pânico 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 futuros. 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. Ela deve congelar toda a rede: você não quer que uma pausa em um componente abra espaço para outro. Assim que identificar a causa raiz e o vetor de ataque, explore as superfícies expostas e reações em cadeia, e corrija tudo de uma vez.

Rotacione sucessores previamente comprometidos

Só faz sentido trocar de sucessor se você já sabe quem será. Recomendo um registro de sucessores pré-definidos: dificulta que atacantes substituam guardiões ou carteiras de governança por invasores. Essa ideia é compatível com a de listas brancas e pretas de medidas de mitigação.

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

Testando antes de atualizar

Depois de identificar a causa raiz e o impacto, é hora de lançar uma atualização. Essa pode ser a parte mais perigosa, pois envolve código que será implantado sob pressão, muitas vezes contra atacantes que já entenderam seu protocolo.

Evite atrasar a implantação sem testes adequados. Se não houver tempo para auditoria, use relações com white hats ou realize 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 notificar plataformas de troca ao cruzar informações.

Tenha uma lista de terceiros autorizados a congelar mensagens cross-chain ou depósitos em trânsito, incluindo plataformas de troca, administradores de pontes, custodiante, etc.

Negociação

Sim, é doloroso, mas vale a pena 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 o valor for devolvido integralmente até a data limite, nenhuma ação legal será tomada.

Se o atacante for um agente estatal, talvez não seja possível negociar, mas você pode participar de programas «white hat», autorizando hackers éticos a agir em seu nome para proteger fundos, recebendo uma porcentagem do valor do bug como recompensa (pagas 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 penso assim, mas minha visão mudou.

Primeiro, bons auditores estão na linha de frente. Se você está fazendo algo inovador, seu código e vulnerabilidades podem não estar nos dados de treinamento, e simplesmente aumentar tokens não é uma solução 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 sua equipe com engenharia social. Tenha hardware e dispositivos de backup prontos para substituir toda a multi-assinatura, 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 limite máximo de valor que pode ser transferido para fora do protocolo é a maior perda teórica possível se uma vulnerabilidade for explorada. Em resumo: uma função de emissão sem limite por bloco é um cheque em branco para qualquer vulnerabilidade de emissão infinita. Uma função de resgate sem limite semanal é um cheque em branco para qualquer saldo de ativos comprometido.

Pense cuidadosamente nos valores desses limites. Eles precisam equilibrar o dano máximo que você está disposto a suportar e a experiência extrema do usuário. Se algo der errado, esses limites podem evitar uma destruição total.

Listas de permissões (whitelist e blacklist)

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

Formalizá-las permite criar mecanismos de duas etapas para alterar essas listas, criando fricção significativa. Um atacante precisa primeiro adicionar algo à whitelist (ou remover da blacklist) antes de agir. Ter ambas as listas significa que, ao introduzir um novo vetor de ataque, o invasor precisa comprometer ambos os processos: 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 monitora, o botão de parada geral é inútil. Monitores off-chain devem acompanhar invariantes continuamente, e, ao detectar problemas, escalar alertas automaticamente. O caminho final deve chegar aos guardiões multi-assinatura, 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 botão de parada (que também deve estar na interface): um botão que pausa todas as transferências de valor em uma única transação. Prepare um script auxiliar para pausar todos os componentes de forma atômica.

Apenas a governança pode remover a pausa, portanto, o botão de parada não deve pausar o contrato de governança. Se os guardiões puderem pausar o contrato de governança, eles podem travar o processo de recuperação de forma permanente.

Monte sua sala de crise

Congele, pare o sangramento e reúna todas as pessoas de confiança (pequeno grupo, previamente combinado) 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 que decide, um que executa scripts de defesa e pausa, um que identifica vulnerabilidades e causas raízes, um que comunica com partes-chave, e um que registra observações, eventos e decisões.

Quando todos souberem seus papéis e praticarem, você reagirá de forma coordenada, sem pânico na hora crítica.

Considere reações em cadeia

Suponha que seu atacante seja altamente experiente. A primeira vulnerabilidade pode ser uma 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, com estudo aprofundado, e não pode ser explorada. Ela deve congelar toda a rede: você não quer que uma pausa em um componente abra espaço para outro. Assim que identificar a causa raiz e o vetor de ataque, explore as superfícies expostas e reações em cadeia, e corrija tudo de uma vez.

Rotacione sucessores previamente comprometidos

Só faz sentido trocar de sucessor se você já sabe quem será. Recomendo um registro de sucessores pré-definidos: dificulta que atacantes substituam guardiões ou carteiras de governança por invasores. Essa ideia é compatível com a de listas brancas e pretas de medidas de mitigação.

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

Testando antes de atualizar

Depois de identificar a causa raiz e o impacto, é hora de lançar uma atualização. Essa pode ser a parte mais perigosa, pois envolve código que será implantado sob pressão, muitas vezes contra atacantes que já entenderam seu protocolo.

Evite atrasar a implantação sem testes adequados. Se não houver tempo para auditoria, use relações com white hats ou realize 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 notificar plataformas de troca ao cruzar informações.

Tenha uma lista de terceiros autorizados a congelar mensagens cross-chain ou depósitos em trânsito, incluindo plataformas de troca, administradores de pontes, custodiante, etc.

Negociação

Sim, é doloroso, mas vale a pena 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 o valor for devolvido integralmente até a data limite, nenhuma ação legal será tomada.

Se o atacante for um agente estatal, talvez não seja possível negociar, mas você pode participar de programas «white hat», autorizando hackers éticos a agir em seu nome para proteger fundos, recebendo uma porcentagem do valor do bug como recompensa (pagas 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 penso assim, mas minha visão mudou.

Primeiro, bons auditores estão na linha de frente. Se você está fazendo algo inovador, seu código e vulnerabilidades podem não estar nos dados de treinamento, e simplesmente aumentar tokens não é uma solução 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 sua equipe com engenharia social. Tenha hardware e dispositivos de backup prontos para substituir toda a multi-assinatura, 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 limite máximo de valor que pode ser transferido para fora do protocolo é a maior perda teórica possível se uma vulnerabilidade for explorada. Em resumo: uma função de emissão sem limite por bloco é um cheque em branco para qualquer vulnerabilidade de emissão infinita. Uma função de resgate sem limite semanal é um cheque em branco para qualquer saldo de ativos comprometido.

Pense cuidadosamente nos valores desses limites. Eles precisam equilibrar o dano máximo que você está disposto a suportar e a experiência extrema do usuário. Se algo der errado, esses limites podem evitar uma destruição total.

Listas de permissões (whitelist e blacklist)

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

Formalizá-las permite criar mecanismos de duas etapas para alterar essas listas, criando fricção significativa. Um atacante precisa primeiro adicionar algo à whitelist (ou remover da blacklist) antes de agir. Ter ambas as listas significa que, ao introduzir um novo vetor de ataque, o invasor precisa comprometer ambos os processos: 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 monitora, o botão de parada geral é inútil. Monitores off-chain devem acompanhar invariantes continuamente, e, ao detectar problemas, escalar alertas automaticamente. O caminho final deve chegar aos guardiões multi-assinatura, 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 botão de parada (que também deve estar na interface): um botão que pausa todas as transferências de valor em uma única transação. Prepare um script auxiliar para pausar todos os componentes de forma atômica.

Apenas a governança pode remover a pausa, portanto, o botão de parada não deve pausar o contrato de governança. Se os guardiões puderem pausar o contrato de governança, eles podem travar o processo de recuperação de forma permanente.

Monte sua sala de crise

Congele, pare o sangramento e reúna todas as pessoas de confiança (pequeno grupo, previamente combinado) 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 que decide, um que executa scripts de defesa e pausa, um que identifica vulnerabilidades e causas raízes, um que comunica com partes-chave, e um que registra observações, eventos e decisões.

Quando todos souberem seus papéis e praticarem, você reagirá de forma coordenada, sem pânico na hora crítica.

Considere reações em cadeia

Suponha que seu atacante seja altamente experiente. A primeira vulnerabilidade pode ser uma 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, com estudo aprofundado, e não pode ser explorada. Ela deve congelar toda a rede: você não quer que uma pausa em um componente abra espaço para outro. Assim que identificar a causa raiz e o vetor de ataque, explore as superfícies expostas e reações em cadeia, e corrija tudo de uma vez.

Rotacione sucessores previamente comprometidos

Só faz sentido trocar de sucessor se você já sabe quem será. Recomendo um registro de sucessores pré-definidos: dificulta que atacantes substituam guardiões ou carteiras de governança por invasores. Essa ideia é compatível com a de listas brancas e pretas de medidas de mitigação.

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

Testando antes de atualizar

Depois de identificar a causa raiz e o impacto, é hora de lançar uma atualização. Essa pode ser a parte mais perigosa, pois envolve código que será implantado sob pressão, muitas vezes contra atacantes que já entenderam seu protocolo.

Evite atrasar a implantação sem testes adequados. Se não houver tempo para auditoria, use relações com white hats ou realize 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 notificar plataformas de troca ao cruzar informações.

Tenha uma lista de terceiros autorizados a congelar mensagens cross-chain ou depósitos em trânsito, incluindo plataformas de troca, administradores de pontes, custodiante, etc.

Negociação

Sim, é doloroso, mas vale a pena 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 o valor for devolvido integralmente até a data limite, nenhuma ação legal será tomada.

Se o atacante for um agente estatal, talvez não seja possível negociar, mas você pode participar de programas «white hat», autorizando hackers éticos a agir em seu nome para proteger fundos, recebendo uma porcentagem do valor do bug como recompensa (pagas 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 penso assim, mas minha visão mudou.

Primeiro, bons auditores estão na linha de frente. Se você está fazendo algo inovador, seu código e vulnerabilidades podem não estar nos dados de treinamento, e simplesmente aumentar tokens não é uma solução 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 sua equipe com engenharia social. Tenha hardware e dispositivos de backup prontos para substituir toda a multi-assinatura, 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 limite máximo de valor que pode ser transferido para fora do protocolo é a maior perda teórica possível se uma vulnerabilidade for explorada. Em resumo: uma função de emissão sem limite por bloco é um cheque em branco para qualquer vulnerabilidade de emissão infinita. Uma função de resgate sem limite semanal é um cheque em branco para qualquer saldo de ativos comprometido.

Pense cuidadosamente nos valores desses limites. Eles precisam equilibrar o dano máximo que você está disposto a suportar e a experiência extrema do usuário. Se algo der errado, esses limites podem evitar uma destruição total.

Listas de permissões (whitelist e blacklist)

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

Formalizá-las permite criar mecanismos de duas etapas para alterar essas listas, criando fricção significativa. Um atacante precisa primeiro adicionar algo à whitelist (ou remover da blacklist) antes de agir. Ter ambas as listas significa que, ao introduzir um novo vetor de ataque, o invasor precisa comprometer ambos os processos: 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 monitora, o botão de parada geral é inútil. Monitores off-chain devem acompanhar invariantes continuamente, e, ao detectar problemas, escalar alertas automaticamente. O caminho final deve chegar aos guardiões multi-assinatura, 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 botão de parada (que também deve estar na interface): um botão que pausa todas as transferências de valor em uma única transação. Prepare um script auxiliar para pausar todos os componentes de forma atômica.

Apenas a governança pode remover a pausa, portanto, o botão de parada não deve pausar o contrato de governança. Se os guardiões puderem pausar o contrato de governança, eles podem travar o processo de recuperação de forma permanente.

Monte sua sala de crise

Congele, pare o sangramento e reúna todas as pessoas de confiança (pequeno grupo, previamente combinado) 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 que decide, um que executa scripts de defesa e pausa, um que identifica vulnerabilidades e causas raízes, um que comunica com partes-chave, e um que registra observações, eventos e decisões.

Quando todos souberem seus papéis e praticarem, você reagirá de forma coordenada, sem pânico na hora crítica.

Considere reações em cadeia

Suponha que seu atacante seja altamente experiente. A primeira vulnerabilidade pode ser uma 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, com estudo aprofundado, e não pode ser explorada. Ela deve congelar toda a rede: você não quer que uma pausa em um componente abra espaço para outro. Assim que identificar a causa raiz e o vetor de ataque, explore as superfícies expostas e reações em cadeia, e corrija tudo de uma vez.

Rotacione sucessores previamente comprometidos

Só faz sentido trocar de sucessor se você já sabe quem será. Recomendo um registro de sucessores pré-definidos: dificulta que atacantes substituam guardiões ou carteiras de governança por invasores. Essa ideia é compatível com a de listas brancas e pretas de medidas de mitigação.

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

Testando antes de atualizar

Depois de identificar a causa raiz e o impacto, é hora de lançar uma atualização. Essa pode ser a parte mais perigosa, pois