Listing de faux LBTC d'Ionic Money

En février 2025, la plateforme de prêt basée sur Mode Ionic Money — anciennement Midas Capital — a été exploitée pour environ 8,6 millions de dollars (Rekt liste 6,94 M$) via une opération d'ingénierie sociale de plusieurs semaines. Les attaquants ont usurpé l'identité de membres de l'équipe Lombard Finance, conduit des discussions de business development sur « plusieurs semaines » et finalement trompé Ionic en lui faisant lister un faux token LBTC comme collatéral. Ils ont ensuite déposé 250 de leur faux LBTC et emprunté de vrais actifs contre.

Ce qui s'est passé

La chaîne d'attaque s'est déroulée sur une échelle temporelle plus longue que les exploits crypto typiques :

1. Contact initial : Les attaquants ont contacté Ionic Money en se faisant passer pour des représentants de Lombard Finance, proposant de lister LBTC (le produit Bitcoin wrappé de Lombard) comme collatéral sur Ionic.
2. Business development : Les imposteurs ont passé plusieurs semaines à interagir avec l'équipe Ionic — discussions techniques sur le design de LBTC, conversations sur l'adéquation au marché, négociations de paramètres de risque.
3. Préparation du token : Les attaquants ont déployé leur propre faux contrat LBTC, puis mis en place un pool de liquidité Balancer avec 400 000 $ de leur propre liquidité pour fournir une découverte de prix superficielle pour le token.
4. Intégration d'oracle : Ils ont convaincu Ionic d'intégrer un flux de prix oracle API3 pour leur faux LBTC — une étape clé qui a donné à l'actif un « prix de confiance » que les marchés de prêt consommeraient.
5. Approbation du listing : Après plusieurs semaines de théâtre de due diligence, l'équipe Ionic a approuvé l'actif frauduleux comme collatéral sur la plateforme de prêt.

Une fois le faux LBTC live comme collatéral, l'attaque a été mécanique :

6. Mint de 250 faux LBTC depuis leur propre contrat (c'était leur token ; ils pouvaient en minter autant qu'ils voulaient).
7. Dépôt des 250 faux LBTC comme collatéral, l'oracle API3 le rapportant au prix de marché légitime de LBTC.
8. Emprunt de 8,6 M$ d'actifs réels contre le faux collatéral.
9. Départ sans rembourser, laissant Ionic détenir du faux LBTC sans valeur comme seul backing pour les prêts.

Après le vol, les attaquants ont utilisé des ponts cross-chain pour transférer environ 3,5 M$ vers Ethereum, avec 1 204 ETH (~3,2 M$) bridgés directement dans Tornado Cash.

Conséquences

• Ionic a suspendu les marchés de prêt affectés et audité la provenance de chaque actif de collatéral listé.
• L'équipe Lombard Finance a publiquement confirmé l'usurpation et clarifié qu'aucun membre de leur équipe n'avait été impliqué dans le processus de listing Ionic.
• Aucune récupération publique depuis les wallets de l'attaquant.
• Le rythme de l'exploit — semaines de business development avant l'attaque technique — suggère fortement un comportement d'acteur de menace aligné sur un État plutôt qu'une exploitation opportuniste.

Pourquoi c'est important

L'incident d'Ionic Money est l'un des cas 2025 les plus clairs pour comment les opérations d'ingénierie sociale contre les protocoles augmentent en patience et sophistication. L'attaque n'était pas opportuniste. Les attaquants :

• Ont recherché le processus de listing d'Ionic assez exhaustivement pour savoir quelles preuves seraient requises.
• Ont construit une relation de plusieurs semaines avec l'équipe, établissant la confiance avant de l'exploiter.
• Ont construit un artefact crédible — le pool Balancer avec 400 K$ de vraie liquidité et l'intégration oracle API3 — qui ne crierait pas immédiatement « arnaque » à une revue de due diligence normale.

Les leçons structurelles pour les plateformes de prêt DeFi :

1. « Nous avons rencontré leur équipe » n'est pas une validation — les protocoles listant un nouveau collatéral doivent vérifier l'identité de la contrepartie via des canaux indépendants des personnes demandant le listing. Les propres canaux de communication de Lombard, pas le chat Telegram d'Ionic avec quelqu'un prétendant être Lombard.

2. Les vérifications de provenance de token doivent être cryptographiques, pas narratives — vérifier que l'adresse de contrat déployée correspond aux annonces officielles du protocole (signées par leur multi-sig connu ou compte de réseaux sociaux) plutôt que de croire la parole du proposant du listing.

3. L'intégration d'oracle fait partie du risque de listing — ajouter un flux de prix oracle pour un token lui donne une énorme surface d'attaque ; l'étape d'intégration d'oracle devrait être une porte d'approbation séparée et à haute friction qui requiert une vérification indépendante du sous-jacent.

Le calendrier « semaines d'usurpation avant l'attaque » est aussi notable comme une carte de visite d'acteur étatique. Lazarus et des groupes similaires maintiennent du personnel dédié pour ces opérations à combustion lente précisément parce que le coût de patience est bien inférieur au retour attendu sur un exploit réussi. Se défendre contre cela requiert des processus institutionnels qui ne dépendent pas de la capacité des membres d'équipe individuels à repérer des ingénieurs sociaux patients.