Le 22 mars 2026, le protocole Revolv a subi une attaque ayant entraîné une perte d'environ 26,8 millions de dollars. Cette attaque résultait d'une compromission de l'infrastructure cloud du projet, permettant à l'attaquant d'accéder au système de gestion des clés (KMS) d'AWS. GetBlock AML Research propose une analyse détaillée de cette attaque contre le projet Revolv.
Revolv utilise un modèle hybride : les utilisateurs déposent des garanties (par exemple, en USDC ), après quoi un système externe vérifie le dépôt et autorise la libération du jeton interne USR. L’attaquant a initialement effectué plusieurs petits dépôts réels (environ 100 000 à 200 000 USDC ).
Puis, grâce à un accès privilégié compromis (un « rôle de service »), il a appelé la fonction completeSwap() et a artificiellement gonflé le montant de jetons USR à recevoir. Il a ainsi perçu 80 millions d'USR en deux transactions. Cette surémission de jetons a entraîné une chute brutale de leur prix, de 1 $ à 0,03 $, après quoi d'autres plateformes ont suspendu leurs opérations sur cet actif.
Comment Revolv a été piraté et comment AWS KMS a été accédé
Pour protéger ses clés, Revolv a utilisé AWS KMS, un système de gestion de clés cryptographiques basé sur le cloud.
Pourquoi utiliser AWS KMS et comment fonctionne la gestion des clés ?
Tout d'abord, il s'agit de sécurité à grande échelle : si une plateforme compte des milliers d'utilisateurs, il est impossible de stocker les clés sur des appareils physiques distincts ; les solutions cloud permettent une gestion centralisée.
Deuxièmement, le contrôle d'accès : seuls certains services ou employés peuvent utiliser les clés, et les actions peuvent être restreintes et auditées. L'audit et la conformité sont également importants : chaque utilisation de clé est enregistrée, ce qui est essentiel pour les entreprises réglementées.
De plus, le système assure la sauvegarde et la restauration des clés et permet la signature automatique des transactions sans intervention manuelle. Ce système contenait une clé qui a permis à l'attaquant d'accéder au rôle de service. Cela lui a permis de :
- signer des transactions pour l'émission d'un nombre quelconque de jetons (le contrat limitait le minimum, mais pas le maximum),
- créer des signatures que le système considérait comme légitimes,
- Émettre des dizaines de millions de jetons avec des dépôts réels minimaux en utilisant la fonction completeSwap().
Comment l'attaque et la libération des jetons USR ont eu lieu
| L'attaquant s'adresse |
| 0x04A288a7789DD6Ade935361a4fB1Ec5db513caEd |
| 0x8ED8cF0C1c531C1b20848E78f1CB32fa5B99b81C |
| 0x6Db6006c38468CDc0fD7d1c251018b1B696232Ed |
| 0xb945eC1be1f42777F3AA7D683562800B4CDD3890 |
| 0x9FeeEAEc113E6d2DCD5ac997d5358eee41836e5f |
| Adresses concernées |
| 0xa27a69Ae180e202fDe5D38189a3F24Fe24E55861 (contrat USR) |
| 0x15CAd41e6BdCaDc7121ce65080489C92CF6de398 (portefeuille de service) |
Chronologie de l'attaque contre Revolv
- 22 mars 2026, 1 h 50 min 59 s : L’attaquant a d’abord créé une demande d’échange, déposant environ 100 000 USDC . Transaction : 0x590b5c66df27b7f34cde721ca1b5f973ae047ffda370610491f694dade732c89
- Le 22 mars 2026 à 02:21:35, grâce à un accès compromis, il a exécuté cette requête via la fonction completeSwap() et a reçu 50 millions de rials américains (moins des frais d'environ 50 000). Transaction : 0xfe37f25efd67d0a4da4afe48509b258df48757b97810b28ce4c649658dc33743
Environ deux heures plus tard, il a répété le même schéma : soumettre une nouvelle demande et la confirmer, recevant 30 millions de dollars US. Transaction : 0x41b6b9376d174165cbd54ba576c8f6675ff966f17609a7b80d27d8652db1f18f.
Vulnérabilité du système de gestion des clés
La cause principale de l'incident est une compromission du système AWS KMS, au cours de laquelle l'attaquant a obtenu l'accès à la clé privée d'un portefeuille de service. Ce portefeuille (0x15CAd41e6BdCaDc7121ce65080489C92CF6de398) bénéficiait auparavant de privilèges spéciaux (un « rôle de service ») lui permettant d'effectuer des opérations critiques.
Où les fonds ont-ils été retirés après l'attaque ?
L'un des portefeuilles de l'attaquant (0x04A288a7789DD6Ade935361a4fB1Ec5db513caEd) a reçu 80 millions d'USR.
Diagramme de flux des fonds volés. Visualisation : Certik
Au 27 mars :
- À une adresse (0x04A288a7789DD6Ade935361a4fB1Ec5db513caEd), il reste environ 20,4 millions de wstUSR (~1,26 million de dollars).
- d'autre part (0x8ed8cf0c1c531c1b20848e78f1cb32fa5b99b81c) – 11 408 $ETH (~24,78 millions de dollars)
- Une autre adresse (0x9FeeEAEc113E6d2DCD5ac997d5358eee41836e5f) détient 12 millions de wstUSR (~742 000 $) et 25,93 $ETH (~56 000 $).