Resolv Ataque de Hackers: Como uma Chave Comprometida Levou à Cunhagem Ilegal de 23 Milhões de Dólares

Escrito por: Chainalysis

Traduzido por: AididiaoJP, Foresight News

22 de março de 2026, o protocolo Resolv DeFi tornou-se o mais recente exemplo, demonstrando quão rapidamente o setor DeFi pode entrar em crise quando as hipóteses de segurança falham. Em poucos minutos, um atacante cunhou dezenas de milhões de tokens de stablecoin Resolv USR sem suporte de garantia e extraiu cerca de 25 milhões de dólares em valor, causando uma rápida desconexão do preço do USR, levando à suspensão do protocolo.

À primeira vista, parece mais um incidente de vulnerabilidade em contratos inteligentes. No entanto, a realidade é diferente. A forma como o código relacionado foi executado está totalmente de acordo com seu design.

Na verdade, trata-se de um acidente causado por confiança excessiva na infraestrutura fora da cadeia. À medida que os sistemas DeFi se tornam mais complexos e dependem cada vez mais de serviços externos, chaves privilegiadas e infraestrutura em nuvem, sua superfície de ataque ultrapassa amplamente o escopo da própria blockchain.

Este artigo irá revisar o ocorrido e seus impactos, além de discutir: quando componentes fora da cadeia são invadidos, somente mecanismos de detecção e resposta em tempo real na cadeia podem atuar como a última linha de defesa, distinguindo essencialmente entre eventos controlados e vulnerabilidades exploradas que causam milhões de dólares em perdas.

Resumo do incidente

O atacante inicialmente depositou uma quantia pequena (cerca de 100 a 200 mil dólares em USDC) e interagiu com o sistema de cunhagem de USR do Resolv. Normalmente, após depositar USDC, o usuário receberia uma quantidade equivalente de USR. No entanto, neste caso, o atacante conseguiu cunhar aproximadamente 80 milhões de tokens USR, muito além do valor depositado.

Isso ocorreu porque a aprovação de cunhagem dependia de um serviço fora da cadeia que utilizava uma chave privada privilegiada para autorizar a quantidade de USR a ser cunhada. Contudo, o contrato inteligente em si não impunha limite algum na quantidade de cunhagem — apenas verificava a validade da assinatura.

Após cunhar USR sem suporte de garantia, o atacante rapidamente converteu-os em uma versão lastreada, wstUSR, e posteriormente trocou por outras stablecoins, finalizando com ETH. Ao final do ataque, o atacante lucrou cerca de 25 milhões de dólares em ETH. Uma grande quantidade de USR sem lastro entrou repentinamente no mercado, levando o preço do token a despencar cerca de 80%.

Após entender o resultado do incidente, a seguir analisaremos como as falhas no design da etapa de cunhagem facilitaram o ataque.

Processo normal de cunhagem de tokens Resolv

Para compreender as causas do ataque, é necessário entender o mecanismo de cunhagem do Resolv.

Quando um usuário deseja cunhar o token nativo USR, sua interação não ocorre com um mecanismo totalmente autônomo na cadeia, mas passa por um processo fora da cadeia composto por duas etapas:

requestSwap — o usuário deposita USDC no contrato USR Counter e inicia uma solicitação de cunhagem.

completeSwap — um serviço fora da cadeia, controlado por uma chave privada com a função SERVICE_ROLE, revisa a solicitação e, por meio de uma chamada de retorno ao contrato, determina a quantidade final de USR a ser cunhada.

No contrato, apenas foi definido um mínimo de USR a ser cunhado, sem limite superior. Não há verificação na cadeia do rácio entre o valor depositado e a quantidade de USR cunhada, nem integração com oráculos de preço, limites totais ou proporções máximas de cunhagem. Em outras palavras, qualquer quantidade assinada por essa chave pode ser cunhada.

Detalhamento das etapas do ataque

Primeira etapa: obtenção de acesso ao ambiente AWS KMS do Resolv

O atacante invadiu a infraestrutura de nuvem do Resolv, obtendo acesso ao ambiente do AWS KMS utilizado pelo protocolo, onde estavam armazenadas as chaves de assinatura privilegiadas. Com o controle do KMS, o atacante pôde usar a chave de cunhagem do próprio Resolv para autorizar operações de cunhagem arbitrárias.

Segunda etapa: cunhagem de tokens USR

Após obter a chave de assinatura, o atacante realizou duas solicitações de swap, cada uma com uma quantia menor de USDC, totalizando cerca de 100 a 200 mil dólares, dispersas em várias transações. Depois, usou a chave SERVICE_ROLE para chamar a função completeSwap, preenchendo uma quantidade de saída inflada artificialmente, autorizando assim a cunhagem de dezenas de milhões de USR com pouco USDC investido.

Duas transações principais na cadeia foram identificadas:

cunhagem de 50 milhões de USR

cunhagem de 30 milhões de USR

No total, foram cunhados 80 milhões de USR, avaliado em aproximadamente 25 milhões de dólares.

Terceira etapa: uso de wstUSR para evitar restrições de liquidez

O atacante converteu USR em wstUSR, um token derivado que representa uma participação em um pool de staking, cujo valor não é fixo em relação ao USR. Assim, evitou impactar diretamente o mercado de USR, transferindo sua posição para um ativo com liquidez relativamente menor, porém mais substituível.

Quarta etapa: retirada e lavagem de dinheiro

Com wstUSR em mãos, o atacante trocou por stablecoins, depois por ETH, e utilizou múltiplos pools de liquidez descentralizados e pontes cross-chain para mover os fundos, maximizando o valor retirado e dificultando o rastreamento.

Até o momento da redação, o endereço do atacante ainda possui aproximadamente:

11.400 ETH (valor cerca de 24 milhões de dólares)

2000 milhões de wstUSR (valor aproximadamente 130 mil dólares, considerando o preço após o descongelamento)

Impacto para os detentores de USR

Este incidente causou um impacto direto e severo aos detentores de USR.

As 80 milhões de USR recém cunhadas, sem lastro, entraram nos pools de liquidez das exchanges descentralizadas. Com a oferta em rápida expansão, o preço do USR caiu abruptamente, chegando a cerca de 0,20 dólares, uma queda de 80%. Posteriormente, em algumas horas, o preço se recuperou para aproximadamente 0,56 dólares.

Após o incidente, a Resolv Labs publicou uma declaração, suspendendo todas as funções do protocolo para evitar perdas adicionais e iniciando uma investigação sobre o ataque. Dado que o atacante ainda tentava cunhar mais USR, a ação rápida foi essencial para evitar perdas maiores, destacando a importância de respostas ágeis a esse tipo de ameaça.

Princípios de segurança robusta devem partir do pressuposto de que vulnerabilidades são inevitáveis

Apesar de o Resolv ter implementado todas as medidas de segurança convencionais e realizado até 18 auditorias, o ataque revela, sob certa perspectiva, uma história simples: o atacante obteve a chave, usou-a para cunhar ativos ilegalmente e, antes que as partes percebessem, liquidou-os.

Por outro lado, o incidente também evidencia como os protocolos DeFi dependem de hipóteses de segurança na infraestrutura fora da cadeia e como essas hipóteses podem ser vulneráveis. Os contratos inteligentes na cadeia operam de forma consistente com seu design, mas o sistema como um todo, incluindo a infraestrutura fora da cadeia invadida, não atingiu os padrões de segurança necessários.

Num cenário onde vulnerabilidades podem ser exploradas em minutos e os prejuízos se tornam irreversíveis rapidamente, mecanismos de monitoramento em tempo real e resposta automática deixam de ser complementos opcionais e passam a ser essenciais para proteção.

Análise de prevenção com Hexagate

O ataque ao Resolv demonstra claramente a importância de mecanismos de monitoramento em tempo real na cadeia. Se tivesse sido utilizado o Hexagate da Chainalysis, duas abordagens específicas poderiam ter detectado a ameaça:

1. Monitoramento de eventos de cunhagem anormais

Configurando o Hexagate, seria possível monitorar as chamadas à função completeSwap, identificando situações em que a quantidade de USR cunhada seja desproporcional ao valor depositado.

Por exemplo, uma entrada de USDC de 10 mil dólares que autorize a cunhagem de 50 milhões de USR é um sinal de alerta. Regras de alerta poderiam ser configuradas para disparar quando a proporção de cunhagem ultrapassar 1,5 vezes o valor normal, permitindo uma resposta imediata.

O sistema de monitoramento personalizado do Hexagate poderia, ao detectar comportamentos anômalos na lógica de cunhagem do Resolv, acionar respostas automáticas.

2. Uso de GateSigner e monitoramento de eventos críticos

Cada etapa do processo — requestSwap e completeSwap — gera eventos na cadeia. Combinando o GateSigner do Hexagate com o monitoramento desses eventos, seria possível configurar uma ação automática para pausar o contrato ao detectar uma emissão de USR fora do padrão, impedindo que os 80 milhões de tokens entrem no mercado aberto antes que qualquer dano maior ocorra.