Ionic Money Fake-LBTC-Listing

Im Februar 2025 wurde die Mode-basierte Lending-Plattform Ionic Money — vormals Midas Capital — um rund 8,6 Millionen $ (Rekt listet 6,94 Mio. $) durch eine mehrwöchige Social-Engineering-Operation exploitet. Angreifer gaben sich als Lombard Finance-Teammitglieder aus, führten „mehrere Wochen" lang Business-Development-Gespräche und brachten Ionic schließlich dazu, einen Fake-LBTC-Token als Collateral zu listen. Sie deponierten dann 250 ihrer Fake-LBTC und liehen reale Assets dagegen.

Was geschah

Die Angriffskette lief auf einer Zeitskala länger als typische Krypto-Exploits:

1. Erstkontakt: Angreifer wandten sich an Ionic Money und gaben sich als Lombard-Finance-Vertreter aus, die vorschlugen, LBTC (Lombards Wrapped-Bitcoin-Produkt) als Collateral auf Ionic zu listen.
2. Business Development: Die Imitatoren verbrachten mehrere Wochen mit dem Ionic-Team — technische Diskussionen über LBTCs Design, Market-Fit-Gespräche, Risk-Parameter-Verhandlungen.
3. Token-Vorbereitung: Die Angreifer deployten ihren eigenen Fake-LBTC-Contract, richteten dann einen Balancer-Liquiditätspool mit 400.000 $ ihrer eigenen Liquidität ein, um oberflächliche Price-Discovery für den Token zu liefern.
4. Orakel-Integration: Sie überzeugten Ionic, einen API3-Orakel-Preisfeed für ihren Fake-LBTC zu integrieren — ein Schlüsselschritt, der dem Asset einen „vertrauenswürdigen Preis" gab, den die Lending-Märkte konsumieren würden.
5. Listing-Genehmigung: Nach mehreren Wochen Due-Diligence-Theater genehmigte das Ionic-Team das betrügerische Asset als Collateral auf der Lending-Plattform.

Sobald das Fake-LBTC als Collateral live war, war der Angriff mechanisch:

6. 250 Fake-LBTC aus dem eigenen Contract minten (es war ihr Token; sie konnten so viel minten, wie sie wollten).
7. Die 250 Fake-LBTC als Collateral deponieren, wobei das API3-Orakel sie zum legitimen LBTC-Marktpreis meldete.
8. 8,6 Mio. $ in echten Assets gegen das Fake-Collateral leihen.
9. Davongehen, ohne zurückzuzahlen, und Ionic mit wertlosem Fake-LBTC als einziger Deckung für die Kredite zurücklassen.

Nach dem Diebstahl nutzten die Angreifer Cross-Chain-Bridges, um rund 3,5 Mio. $ auf Ethereum zu transferieren, mit 1.204 ETH (rund 3,2 Mio. $) direkt in Tornado Cash gebridgt.

Folgen

• Ionic pausierte betroffene Lending-Märkte und auditierte die Herkunft jedes gelisteten Collateral-Assets.
• Das Lombard-Finance-Team bestätigte die Impersonation öffentlich und stellte klar, dass keines ihrer Teammitglieder am Ionic-Listing-Prozess beteiligt war.
• Keine öffentliche Wiederherstellung aus den Wallets des Angreifers.
• Das Tempo des Exploits — Wochen von Business Development vor dem technischen Angriff — deutet stark auf staatsnahes Bedrohungsakteurs-Verhalten statt opportunistischer Ausnutzung hin.

Warum es wichtig ist

Der Ionic-Money-Vorfall ist einer der klarsten 2025-Fälle dafür, wie Social-Engineering-Operationen gegen Protokolle in Geduld und Raffinesse zunehmen. Der Angriff war nicht opportunistisch. Die Angreifer:

• Recherchierten Ionics Listing-Prozess gründlich genug, um zu wissen, welche Beweise erforderlich wären.
• Bauten eine mehrwöchige Beziehung zum Team auf, etablierten Vertrauen, bevor sie es ausnutzten.
• Konstruierten ein glaubwürdiges Artefakt — den Balancer-Pool mit echten 400K $ Liquidität und der API3-Orakel-Integration —, das einer normalen Due-Diligence-Prüfung nicht sofort als „Scam" auffallen würde.

Die strukturellen Lektionen für DeFi-Lending-Plattformen:

1. „Wir haben ihr Team getroffen" ist keine Validierung — Protokolle, die neue Collateral listen, müssen die Identität der Gegenpartei über Kanäle unabhängig von den Personen verifizieren, die das Listing beantragen. Lombards eigene Kommunikationskanäle, nicht Ionics Telegram-Chat mit jemandem, der behauptet, Lombard zu sein.

2. Token-Provenance-Checks müssen kryptographisch sein, nicht narrativ — verifizieren, dass die deployte Contract-Adresse den offiziellen Ankündigungen des Protokolls entspricht (signiert von ihrer bekannten Multi-Sig oder ihrem Social-Media-Account), statt dem Wort des Listing-Antragstellers zu vertrauen.

3. Orakel-Integration ist Teil des Listing-Risikos — einen Orakel-Preisfeed für einen Token hinzuzufügen gibt ihm eine enorme Angriffsfläche; der Orakel-Integrationsschritt sollte ein separates, hochreibungs-Approval-Gate sein, das unabhängige Verifikation des Underlying erfordert.

Die „Wochen der Impersonation vor dem Angriff"-Zeitlinie ist auch als Staats-Akteur-Visitenkarte bemerkenswert. Lazarus und ähnliche Gruppen unterhalten dediziertes Personal für diese Slow-Burn-Operationen — gerade weil die Geduldskosten viel niedriger sind als der erwartete Ertrag eines erfolgreichen Exploits. Die Verteidigung dagegen erfordert institutionelle Prozesse, die nicht von der Fähigkeit einzelner Teammitglieder abhängen, geduldige Social Engineers zu erkennen.