Bei einem ausgeklügelten Angriff auf das Aevo-Rebrand Ribbon Finance wurden 2,7 Millionen Dollar von einem altentracabgezogen und auf fünfzehn verschiedene Wallet-Adressen verteilt, von denen einige bereits zu größeren Konten zusammengeführt wurden.
Laut mehreren Blockchain-Ermittlern der sozialen Plattform X erfolgte der Angriff nur sechs Tage, nachdem die Plattform ihre Oracle-Infrastruktur und die Verfahren zur Optionserstellung aktualisiert hatte. Die Angreifer nutzten eine geschicktetrac, um Hunderte von Ethereum Token und andere digitale Vermögenswerte zutrac.
Der alte Vertragtrac@ribbonfinance wurde um insgesamt 2,7 Millionen Dollar aufgebraucht.
Exploit-trac: 0x3c212A044760DE5a529B3Ba59363ddeCcc2210bE
Diebstahladressen:
0x354ad0816de79E72452C14001F564e5fDf9a355e
0x2Cfea8EfAb822778E4e109E8f9BCdc3e9E22CCC9… pic.twitter.com/sXKDYoL4RS— Specter (@SpecterAnalyst) 12. Dezember 2025
In einem Thread, in dem der Exploit erläutert wird, sagte Web3-Sicherheitsanalyst Liyi Zhou, dass ein böswilliger VertragtracAAVE Opyn/Ribbon-Orakel-Stack durch Missbrauch von Preisfeed-Proxys manipulierte und beliebige Ablaufpreise für wstETH, AAVELINK und WBTC zu einem gemeinsamen Ablaufzeitpunkt in das gemeinsame Orakel eingab.
„Der Angreifer platzierte große Short-Positionen im oToken-Bereich gegen den MarginPool von Ribbon Finance, der diese gefälschten Verfallspreise in seiner Abwicklungspipeline verwendete und Hunderte von WETH und wstETH, Tausende von USDC und mehrere WBTC über Redeem- und RedeemTo-Transaktionen an Diebstahladressen übertrug“, erklärte Zhou.
Die Oracle-Preisanpassung von Ribbon Finance wies Schwächen auf.
Sechs Tage vor dem Angriff aktualisierte das Team von Ribbon Finance den Oracle Pricer, um 18 Dezimalstellen für stETH, PAXG, LINK und AAVE. Andere Assets, darunter USDC, wurden jedoch weiterhin mit acht Dezimalstellen angezeigt. Laut Zhou trug diese Diskrepanz in der Dezimalgenauigkeit zu der Sicherheitslücke bei, die am Freitag ausgenutzt wurde.
Der jüngste @ribbonfinance scheint auf einen Konfigurationsfehler in Oracle zurückzuführen zu sein.
Vor sechs Tagen haben die Betreiber den Oracle-Preisrechner aktualisiert, der für stETH, PAXG, LINK und AAVEPreise mit 18 Dezimalstellen verwendet. Andere Assets wie USDC werden jedoch weiterhin mit 8 Dezimalstellen bewertet.
Die Erstellung von OToken ist keine… pic.twitter.com/4cpZUNTNun
– Weilin (William) Li (@hklst4r) 13. Dezember 2025
Laut einem pseudonymen Entwickler, der unter dem Benutzernamen Weilin auf X auftritt, war die Erstellung von oTokens an sich nicht illegal, da jeder zugrunde liegende Token auf eine Whitelist gesetzt werden muss, bevor er als Sicherheit oder Strike-Asset verwendet werden kann – ein Verfahren, das der Angreifer buchstabengetreu befolgt hat.
Die böswillige Aktivität begann mit der Erstellung schlecht strukturierter Optionsprodukte. Ein Produkt bestand aus einer stETH-Call-Option mit einem Ausübungspreis von 3.800 USDC, die mit WETH besichert war und am 12. Dezember verfallen sollte. Der Angreifer erstellte daraufhin mehrere oTokens für diese Optionen, die später ausgenutzt wurden, um das Protokoll zu plündern.
Der Angriff umfasste wiederholte Interaktionen mit dem Proxy-Admin-tracunter 0x9D7b…8ae6B76. Einige Funktionen, wie z. B. transferOwnership und setImplementation, wurden verwendet, um die Preisfeed-Proxys über Delegatenaufrufe zu manipulieren. Der Angreifer rief eine Implementierung des Oracles auf, um die Verfallspreise von Vermögenswerten zum gleichen Zeitpunkt festzulegen und so ExpiryPriceUpdated-Ereignisse auszulösen, die die betrügerischen Bewertungen bestätigten.
Durch die manipulierten Preise erkannte das System stETH als weit über dem Ausübungspreis liegend und verbrannte 225 oTokens, was 22,468662541163160869 WETH einbrachte. Insgesamttracder Hacker auf diese Weise etwa 900 ETH.
Das Sicherheitsunternehmen Spectre von Web3 entdeckte die ersten Überweisungen an eine Wallet-Adresse unter 0x354ad…9a355e. Von dort wurde das Geld auf 14 weitere Konten verteilt, von denen viele jeweils etwa 100,1 ETH enthielten. Ein Teil der gestohlenen Gelder ist bereits in sogenannte „TC“-Pools (Treasury Consolidation Pools) geflossen, die Blockchain-Zhou als solche bezeichnete.
Entwickler DeFi Kreditprotokolls: Die Opyn dApp wurde nicht kompromittiert.
Laut Anton Cheng, dem Entwickler von Monarch DeFi , wurde die von Coinbase unterstützte dezentrale Anwendung Opyn nicht kompromittiert, wie in Diskussionen auf Crypto Twitter gemunkelt wurde.
Da ich möglicherweise dafür verantwortlich bin, habe ich mir den Ribbon-Hack angesehen. Folgendes habe ich bisher herausgefunden:
1. @opyn_ wurde nicht gehackt; es handelt sich um einen Fork von @ribbonfinance_.
2. Der Hack wurde hauptsächlich durch einen aktualisierten Oracle-Code ausgelöst, der es jedem ermöglichte, Preise für neue Assets festzulegen.Das hier, wenn… https://t.co/AcF2p495OM pic.twitter.com/BH2rAvNPmP
— Anton Cheng (@antonttc) 13. Dezember 2025
Cheng erklärte, der Hack von Ribbon Finance sei durch einen aktualisierten Oracle-Code ermöglicht worden, der es unbeabsichtigt jedem Nutzer erlaubte, Preise für neu hinzugefügte Assets festzulegen. Er führte aus, der Angriff habe mit einer vorbereitenden Transaktion begonnen, um die Bühne zu bereiten, indem schlecht strukturierte oTokens mit legitimen Sicherheiten und Basiswerten generiert wurden. Weiterhin erklärte er, die gefälschten Token hätten es dem Hacker ermöglicht, bekannte Basiswerte wie AAVE auszuwählen, um keine Aufmerksamkeit zu erregen und nicht entdeckt zu werden.
Der Hacker richtete daraufhin drei „Unterkonten“ ein, auf denen jeweils nur minimale Sicherheiten hinterlegt wurden, um alle drei Optionen zu prägen. Alle Unterkonten waren gekennzeichnet , was bedeutet, dass sie vollständig besichert waren. Da es jedoch kein Auszahlungslimit für die einzelnen Konten oder oToken gab, konnte der Täter ungehindert Vermögenswerte abziehen.
Gemäß Opyns Gamma-Systemen muss der Basiswert bei Call-Optionen der Sicherheit und bei Put-Optionen dem Ausübungspreis entsprechen, um die Verkäufer vollständig abzusichern. Sollte ein Orakel kompromittiert werden, sind ausschließlich die Verkäufer des betreffenden Produkts betroffen.
Doch in diesem Fall reichte die Kombination aus der Erstellung neuer oToken und dem manipulierten Orakel aus, um diese Schutzmechanismen zu umgehen.
