Attaque de pirates informatiques contre Resolv : comment une seule clé exposée a permis la frappe illégale de 23 millions de dollars
TechFlow SélectionTechFlow Sélection
Attaque de pirates informatiques contre Resolv : comment une seule clé exposée a permis la frappe illégale de 23 millions de dollars
À mesure que les systèmes DeFi deviennent de plus en plus complexes et dépendent davantage de services externes, de clés privilégiées et d’infrastructures cloud.
Dédié à des analyses Web3 approfondiesRédaction : Chainalysis
Traduction : AididiaoJP, Foresight News
Le 22 mars 2026, le protocole DeFi Resolv est devenu le dernier exemple illustrant à quelle vitesse le secteur DeFi peut basculer dans une crise lorsque ses hypothèses de sécurité échouent. En quelques minutes seulement, un attaquant a frappé des dizaines de millions de pièces de la stablecoin USR de Resolv, non adossées à aucune garantie, et en a retiré environ 25 millions de dollars de valeur, provoquant un décrochage brutal du cours de l’USR et forçant l’arrêt immédiat du protocole.
À première vue, cet incident semble être une nouvelle vulnérabilité de contrat intelligent. Or ce n’est pas le cas. Le code concerné fonctionnait exactement comme prévu.
En réalité, il s’agit d’un incident causé par une confiance excessive envers des infrastructures hors chaîne. À mesure que les systèmes DeFi deviennent plus complexes et dépendent davantage de services externes, de clés privilégiées et d’infrastructures cloud, leur surface d’attaque dépasse largement le cadre de la blockchain elle-même.
Cet article retrace les circonstances et les conséquences de cet incident, puis examine plus en profondeur comment, lorsqu’un composant hors chaîne est compromis, seules des mécanismes de détection et de réponse aux menaces en temps réel, opérant directement sur la chaîne, peuvent constituer une ligne de défense critique indispensable — permettant de faire la différence fondamentale entre un incident maîtrisé et une exploitation entraînant des pertes de plusieurs millions de dollars.
Résumé de l’incident
L’attaquant a d’abord déposé un montant relativement modeste (environ 100 000 à 200 000 dollars en USDC) et interagi avec le système de frappe de la stablecoin USR de Resolv. Dans des conditions normales, un utilisateur qui dépose de l’USDC reçoit un montant équivalent d’USR. Cette fois-ci, toutefois, l’attaquant a réussi à frapper environ 80 millions d’unités d’USR, bien au-delà du plafond raisonnable correspondant à son dépôt.
Ce scénario s’est produit parce que l’étape d’approbation de la frappe dépendait d’un service hors chaîne utilisant une clé privée privilégiée pour autoriser le nombre d’unités d’USR à frapper. Or, le contrat intelligent concerné ne définissait aucune limite supérieure à la quantité d’USR pouvant être frappée — il vérifiait uniquement la validité de la signature.
Après avoir frappé des unités d’USR non adossées à toute garantie, l’attaquant les a rapidement converties en leur version « stakée » wstUSR, puis progressivement échangées contre d’autres stablecoins, avant d’en retirer finalement de l’ETH. À la fin de l’attaque, l’attaquant avait empoché environ 25 millions de dollars en ETH. L’afflux soudain sur le marché d’une grande quantité d’USR non garanties a fait chuter le cours de ce jeton d’environ 80 %.
Une fois les conséquences de l’incident clairement identifiées, nous analysons ci-dessous les défauts de conception de l’étape de frappe qui ont permis cette attaque.
Processus normal de frappe des jetons Resolv
Pour comprendre les causes profondes de cette attaque, il est essentiel de connaître le mécanisme de frappe mis en œuvre par Resolv.
Lorsqu’un utilisateur souhaite frapper la pièce native USR de Resolv, il n’interagit pas avec un mécanisme entièrement autonome sur la chaîne, mais suit un processus hors chaîne comportant deux étapes :
requestSwap — l’utilisateur dépose de l’USDC dans le contrat USR Counter et lance une demande de frappe.
completeSwap — un service hors chaîne contrôlé par une clé privée privilégiée, nommée SERVICE_ROLE, examine cette demande et détermine, via un appel de rappel (callback) vers le contrat, le nombre final d’unités d’USR à frapper.
Au niveau du contrat, seule une quantité minimale d’USR à produire est définie ; aucune limite supérieure n’est imposée. Aucune vérification n’est effectuée sur la chaîne pour comparer le montant des garanties déposées et le nombre d’unités d’USR frappées, ni aucun oracle de prix, plafond global ou ratio maximal de frappe n’est intégré. Autrement dit, tout montant signé par cette clé peut être effectivement frappé.
Déroulé détaillé de l’attaque
Étape 1 : Obtention d’un accès à l’environnement AWS KMS de Resolv
L’attaquant a compromis l’infrastructure cloud de Resolv, obtenant ainsi un accès à l’environnement AWS Key Management Service (KMS) utilisé par le protocole, où était stockée sa clé privée de signature privilégiée. Une fois cet environnement KMS sous son contrôle, l’attaquant a pu utiliser la clé de frappe propre à Resolv pour autoriser n’importe quelle opération de frappe souhaitée.
Étape 2 : Frappe des jetons USR
Une fois en possession de la clé de signature, l’attaquant a lancé deux demandes d’échange (swap), chacune soutenue par un dépôt modeste d’USDC, soit un montant total d’environ 100 000 à 200 000 dollars, réparti sur plusieurs transactions. Il a ensuite utilisé la clé SERVICE_ROLE pour appeler la fonction completeSwap, en indiquant volontairement un montant de sortie exagéré, autorisant ainsi la frappe de dizaines de millions d’unités d’USR moyennant un dépôt très limité d’USDC.
Deux transactions principales ont été identifiées sur la chaîne :
- Une transaction de frappe de 50 millions d’unités d’USR
- Une transaction de frappe de 30 millions d’unités d’USR
Ces deux transactions ont donc conjointement abouti à la frappe de 80 millions d’unités d’USR, d’une valeur approximative de 25 millions de dollars.
Étape 3 : Contournement des contraintes de liquidité via wstUSR
L’attaquant a ensuite converti ses unités d’USR en wstUSR. Ce dernier est un jeton dérivé représentant une part dans un pool de staking, dont la valeur n’est pas fixée proportionnellement à celle de l’USR. En transformant ses fonds en wstUSR, l’attaquant a évité d’impacter directement le marché de l’USR, transférant plutôt sa position vers un actif plus substituable, bien que doté d’une liquidité relativement faible.
Étape 4 : Récupération et sortie des fonds
Fort de ses wstUSR, l’attaquant les a ensuite échangés contre des stablecoins, puis contre de l’ETH, en exploitant plusieurs pools de liquidité sur des bourses décentralisées et des ponts interchaînes afin de maximiser le montant retiré et compliquer le traçage des fonds.
Au moment de la rédaction de cet article, l’adresse de l’attaquant détenait encore :
- Environ 11 400 ETH (d’une valeur d’environ 24 millions de dollars)
- Environ 20 millions de wstUSR (d’une valeur d’environ 1,3 million de dollars, calculée au cours post-décrochage)
Impact sur les détenteurs d’USR
Cet incident a eu un impact direct et sévère sur les détenteurs d’USR.
Les 80 millions d’unités d’USR nouvellement frappées, non garanties, ont progressivement afflué vers les pools de liquidité des bourses décentralisées. Avec cette augmentation brutale de l’offre, l’ancrage du cours de l’USR au dollar s’est effondré rapidement. Le jeton est tombé brièvement à 0,20 dollar, soit un repli de 80 %, avant de remonter légèrement dans les heures suivantes, atteignant environ 0,56 dollar.
Après l’incident, Resolv Labs a publié une déclaration suspendant toutes les fonctions du protocole afin d’éviter toute perte supplémentaire et a engagé une enquête sur l’intrusion. Compte tenu du fait que l’attaquant tentait encore de frapper davantage d’USR, l’urgence d’agir rapidement pour empêcher une aggravation des pertes était évidente — soulignant ainsi l’importance extrême d’une capacité de réponse rapide face à de telles attaques.
Une approche sécurisée saine doit reposer sur l’hypothèse « qu’une faille surviendra inévitablement »
Bien que Resolv ait mis en œuvre l’ensemble des mesures de sécurité classiques et subi jusqu’à 18 audits de sécurité, cette attaque constitue, sous certains aspects, une histoire simple : l’attaquant a obtenu une clé, l’a utilisée pour frapper illégalement des actifs, puis les a monétisés avant que les parties concernées ne s’en rendent compte.
Or, à un niveau plus profond, cet incident met en lumière la manière dont les protocoles DeFi héritent des hypothèses de sécurité — et des risques potentiels — associés aux infrastructures hors chaîne dont ils dépendent. Le contrat intelligent sur la chaîne fonctionnait parfaitement conformément à sa conception, tandis que la conception globale du système — ainsi que l’infrastructure hors chaîne compromise — n’atteignait pas le niveau de sécurité requis.
Dans un contexte où les exploitations de vulnérabilités sont souvent réalisées en quelques minutes et où, une fois la perte concrétisée, il est trop tard pour réagir passivement, la surveillance en temps réel et les mécanismes de réponse automatisée ne sont plus des options facultatives : ils constituent une protection indispensable.
Analyse de cas préventif : Hexagate
L’attaque subie par Resolv illustre parfaitement les scénarios que les mécanismes de surveillance en temps réel sur la chaîne sont conçus pour détecter. Si Chainalysis Hexagate avait été déployé, les deux méthodes de détection suivantes auraient pu jouer un rôle efficace :
Solution 1 : Surveillance des événements de frappe anormaux
Grâce à la configuration de systèmes de surveillance tels qu’Hexagate, il est possible de surveiller les appels à la fonction completeSwap, en mettant particulièrement l’accent sur les écarts disproportionnés entre le nombre d’unités d’USR frappées et le montant des garanties déposées.
Un dépôt de 100 000 dollars en USDC autorisant la frappe de 50 millions d’unités d’USR représente un ratio anormal, dépassant largement toute plage d’opération plausible pour un utilisateur légitime. La définition d’une règle d’alerte sur ce modèle d’appel — par exemple, déclenchant une alerte dès lors que le ratio de frappe excède de 1,5 fois la valeur normale — aurait permis d’identifier immédiatement les deux transactions majeures mentionnées ci-dessus.
Le mécanisme personnalisable de surveillance d’Hexagate aurait pu, dès la détection d’un comportement anormal exploitant la logique de frappe de Resolv, déclencher une réponse automatisée.
Solution 2 : Contrôle des événements critiques des contrats via GateSigner et fonctionnalités personnalisées
L’attaquant devait nécessairement exécuter successivement les deux étapes requestSwap et completeSwap, chacune générant un événement sur la chaîne. La combinaison de la fonction GateSigner d’Hexagate avec la surveillance des événements de contrat aurait pu être configurée pour déclencher automatiquement la suspension du contrat dès la détection d’un événement de frappe (Mint) anormal, bloquant ainsi toute entrée sur le marché public des fonds, y compris les 80 millions d’unités d’USR.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Chainalysis
