Analisando explorações e ataques

Quando um protocolo ou uma exchange sofre um ataque, os analistas recebem as mesmas perguntas em poucas horas: o que aconteceu, quanto foi levado, onde está agora e quem fez isso. As respostas vêm de um pequeno número de transações lidas em grande detalhe, seguido por um longo trabalho de rastreamento. Esta aula reúne as habilidades de decodificação deste módulo e dos anteriores (tokens, proxies, swaps, empréstimos-relâmpago e pontes) e as aplica a casos públicos.

O ciclo de vida da exploração nos dados

A maioria dos incidentes, independentemente da causa raiz, passa pelas mesmas fases, e cada fase deixa evidências diferentes:

As fases se sobrepõem e, nos comprometimentos de chaves, a preparação acontece fora da blockchain. Ainda assim, organizar as evidências dessa forma evita que uma investigação vá direto à transação mais visível e deixe de perceber o financiamento que poderia identificar o atacante.

Leitura da transação de ataque

Comece pelo rastro de execução, não pelos logs. Os logs registram o que os contratos escolheram anunciar; o rastro de execução registra cada chamada, seu valor e se ela foi bem-sucedida. Uma ordem prática de trabalho:

1. Liste os atores: a conta de propriedade externa que enviou a transação, o contrato de ataque que ela chamou, os contratos vítimas e qualquer endereço que termine com lucro.
2. Calcule as variações de saldo por endereço e por token para toda a transação (a consulta de cálculo de saldos líquidos da aula Swaps em DEX, exchanges instantâneas e fluxos de liquidez funciona aqui). O ganho líquido do atacante e a perda líquida da vítima dão contexto a todo o restante.
3. Percorra a árvore de chamadas a partir do topo, marcando os empréstimos-relâmpago (empréstimos sem garantia que precisam ser pagos, acrescidos de uma taxa, antes que a transação termine, ou toda a transação é revertida) para que o principal emprestado não seja contado como perda.
4. Encontre a etapa em que o estado do protocolo se tornou inconsistente. Essa é a causa raiz, e geralmente corresponde a uma única chamada de função.

Um resumo das variações de saldo de uma transação de ataque fictícia mostra o que a etapa 2 produz:

{
  "tx_hash": "0x7c0d…e91a",
  "block_number": 21000417,
  "balance_changes": [
    {"address": "0xa77a…c0de", "role": "contrato de ataque",     "token": "DAI", "delta": "+2400000.00"},
    {"address": "0x5af3…71b2", "role": "pool vítima",            "token": "DAI", "delta": "-2401000.00"},
    {"address": "0x87f1…4e2a", "role": "credor do empréstimo-relâmpago", "token": "DAI", "delta": "+1000.00"},
    {"address": "0x3e9d…02f7", "role": "EOA remetente",          "token": "ETH", "delta": "-0.041"}
  ]
}

O empréstimo-relâmpago de 2.000.000 DAI do credor nem aparece, porque saiu e retornou na mesma transação; resta apenas sua taxa de 1.000 DAI (0,05%). A vítima perdeu 2.401.000 DAI, o contrato de ataque ficou com 2.400.000, e o remetente pagou 0,041 ETH em gas.

A exploração da Euler Finance de 13 de março de 2023 demonstra o método. As análises publicadas por pesquisadores de segurança sobre uma das transações de ataque a resumem às seguintes etapas:

Contrato de ataque, uma de várias transações de ataque (pool de DAI)
  1. Empréstimo-relâmpago de 30.000.000 DAI da Aave
  2. Depositar 20.000.000 DAI na Euler             -> tokens de garantia (eDAI)
  3. mint(): autoalavancagem                      -> dívida de 200.000.000 dDAI, 195.600.000 eDAI
  4. Pagar 10.000.000 DAI                         -> 10.000.000 dDAI queimados
  5. mint() novamente                            -> mais 200.000.000 dDAI e 195.600.000 eDAI
  6. donateToReserves(100,000,000 eDAI)            -> sem verificação de solvência: conta agora insolvente
  7. Segundo contrato de ataque liquida o primeiro com um desconto de 20%
  8. Sacar 38.900.000 DAI, pagar o empréstimo-relâmpago mais a taxa, ficar com o restante

A etapa 6 é a causa raiz: uma função que reduzia a garantia sem verificar a saúde financeira da conta. As etapas 1 e 8 se compensam quanto ao capital emprestado. Repetido em vários pools, o ataque levou cerca de US$ 197 milhões em DAI, WETH, WBTC, stETH e USDC. O invasor trocou a maior parte por ETH e DAI, enviou 100 ETH para um mixer, depois negociou com o protocolo por meio de mensagens na blockchain e devolveu todos os fundos recuperáveis até 3 de abril de 2023. Vale a pena decodificar as mensagens na blockchain: elas são textos nos dados de entrada de transferências simples e fazem parte do registro.

Financiamento, preparação e imitadores

O financiamento de um endereço do invasor costuma ser a melhor pista para atribuição. Fontes comuns são saques de mixers (os pools do Tornado Cash usavam denominações fixas, como 0,1, 1, 10 e 100 ETH), pontes de outra blockchain, serviços de exchange instantânea e, ocasionalmente, um saque de exchange, que pode ser investigado por vias legais (veja a aula Rastreamento por exchanges e serviços de custódia). Verifique também:

• O implantador de cada contrato de ataque e outros contratos que ele implantou, incluindo versões de teste em outras blockchains.
• A similaridade de bytecode com contratos de ataque anteriores, que pode vincular incidentes.
• As tentativas malsucedidas anteriores à bem-sucedida: seus motivos de reversão mostram o que o atacante estava testando e quando começou.

Nem todo endereço que lucra é o atacante original. Bots de MEV copiam transações pendentes lucrativas, e alguns grupos de hackers éticos se antecipam aos ataques para resgatar fundos. No caso da Euler, um endereço que alegou que seu bot havia copiado acidentalmente o primeiro ataque acabou repassando o DAI ao invasor mesmo assim, porque o contrato copiado tinha o endereço do invasor fixado no código. No incidente da ponte Nomad de agosto de 2022, centenas de endereços simplesmente reproduziram a transação do primeiro atacante, substituindo o endereço dele pelo próprio. Rotule esses atores separadamente, com o grau de confiança declarado, e nunca publique a identidade de um indivíduo particular com base apenas nesses vínculos (veja a aula Do endereço à entidade e à pessoa: atribuição e rotulagem).

Quando o erro não está no código

Alguns dos maiores roubos não envolveram nenhuma falha de contrato inteligente. No roubo da ponte Ronin de março de 2022, os atacantes controlavam cinco das nove chaves de validadores exigidas pela ponte, o suficiente para assinar saques de cerca de 173.600 ETH e 25,5 milhões de USDC; isso passou despercebido por seis dias. As autoridades dos EUA atribuíram o roubo ao Lazarus Group, da Coreia do Norte, em abril de 2022. Na blockchain, os saques tinham assinaturas válidas; apenas o contexto (volume, destinatário e momento incomuns) os denunciava.

O roubo da Bybit de 21 de fevereiro de 2025, de cerca de US$ 1,5 bilhão, foi o maior roubo de criptoativos já registrado quando ocorreu e é uma aula sobre a leitura do que os signatários realmente aprovaram. A carteira fria da exchange era um proxy de múltiplas assinaturas da Safe. Os investigadores descobriram que a interface da carteira havia sido comprometida por meio de uma máquina de desenvolvedor no provedor da carteira, de modo que os signatários viam uma transferência rotineira enquanto suas carteiras de hardware assinavam outra coisa. Decodificada, a transação assinada se apresenta assim:

SafeProxy.execTransaction(...)                   -- seletor 0x6a761202, três assinaturas válidas
    to        = contrato do atacante
    data      = transfer(...)                    -- nome de função aparentemente inofensivo
    operation = 1                                -- DELEGATECALL, não CALL
  DELEGATECALL contrato do atacante.transfer(...) -- executa com o armazenamento do proxy
    SSTORE slot 0 := implementação maliciosa      -- ponteiro singleton da Safe substituído
Em seguida: sweepETH(...) e sweepERC20(...) chamados no proxy, sem necessidade de assinaturas

Como um proxy da Safe mantém seu ponteiro de implementação no slot de armazenamento 0 (veja a aula Decodificação de interações com contratos inteligentes), uma delegatecall que escreve no slot 0 entrega o controle de toda a carteira. As transações de esvaziamento então movimentaram cerca de 401.346 ETH, 90.375 stETH, 15.000 cmETH e 8.000 mETH. Em 26 de fevereiro de 2025, o FBI atribuiu o roubo a atores norte-coreanos que denomina TraderTraitor, publicou uma lista de endereços e informou que os fundos estavam sendo convertidos em Bitcoin e distribuídos por milhares de endereços em várias blockchains. As conclusões para o analista: decodifique cada campo operation nas transações de múltiplas assinaturas, gere alertas para qualquer delegatecall a um contrato desconhecido e monitore os slots de implementação de proxies de alto valor.

Rastreamento pós-incidente

As primeiras horas determinam quanto pode ser congelado ou sinalizado. Uma sequência típica:

1. Monte o conjunto inicial: todos os endereços controlados pelo atacante encontrados nas transações de ataque e nos vínculos de financiamento e de implantadores.
2. Fique atento a ativos passíveis de congelamento. Alguns emissores de stablecoins podem congelar saldos, motivo pelo qual os atacantes os trocam primeiro; comunique os endereços rapidamente.
3. Compartilhe endereços e hashes de transações com exchanges, pontes e outros serviços que possam receber os fundos, por meio dos canais de comunicação estabelecidos por eles.
4. Rastreie a consolidação e a dispersão para a frente, salto a salto, entre blockchains (veja as aulas Rastreamento segundo um padrão probatório, Saltos entre blockchains e rastreamento entre blockchains e Mixers custodiais).

-- Primeiros dois saltos a partir dos endereços iniciais de um incidente, maiores fluxos primeiro
WITH seeds AS (
  SELECT address FROM incident_addresses WHERE incident_id = 'INC-0142'
), hop1 AS (
  SELECT t.to_address, SUM(t.amount_usd) AS usd, MIN(t.block_timestamp) AS first_seen
  FROM value_transfers t JOIN seeds s ON t.from_address = s.address
  WHERE t.to_address NOT IN (SELECT address FROM seeds)
  GROUP BY t.to_address
)
SELECT h.to_address AS hop1, t.to_address AS hop2, SUM(t.amount_usd) AS usd
FROM hop1 h
JOIN value_transfers t
  ON t.from_address = h.to_address AND t.block_timestamp >= h.first_seen
GROUP BY h.to_address, t.to_address
ORDER BY usd DESC;

A consulta pressupõe uma tabela value_transfers que já combina transferências nativas dos rastros de execução com transferências de tokens, cada uma avaliada no momento da transferência. A primeira CTE encontra endereços que receberam fundos do conjunto inicial (excluindo movimentações entre endereços desse conjunto); a etapa final acompanha cada um deles por mais um salto, contando apenas as transferências posteriores ao primeiro recebimento. Grandes fluxos do segundo salto para serviços conhecidos indicam onde podem existir registros fora da blockchain.

Documentação de um incidente

Classifique a causa raiz, pois ela determina quais evidências importam:

Avalie as perdas pelos preços no bloco de cada transação de ataque, liste cada transação de ataque com a altura do bloco e mantenha os valores recuperados separados da perda. As aulas Redação do laudo pericial: confiança e linguagem e Ética, privacidade, proteção de dados e segurança do investigador abordam como apresentar e compartilhar essas constatações.

Foco no exame: as cinco fases de uma exploração e as evidências que cada uma deixa; leitura da transação de ataque a partir do rastro de execução, cálculo das variações de saldo e compensação do principal de empréstimos-relâmpago; as etapas do ataque à Euler e sua causa raiz (donateToReserves sem uma verificação de saúde financeira); fontes de financiamento, vínculos de implantador e bytecode, tentativas malsucedidas e imitadores como pistas para atribuição; comprometimentos de chaves e de interfaces (Ronin, Bybit) e a delegatecall da Safe que reescreveu o slot 0; prioridades das primeiras horas (conjunto inicial, ativos passíveis de congelamento, notificação de serviços); consultas de saltos sobre transferências nativas e de tokens combinadas; classes de causa raiz e avaliação das perdas pelos preços do bloco.