Der Angreifer zielte auf den ResupplyPair-Vertrag ab, der die manipulierte Rate verwendet, nur Stunden nach dessen Bereitstellung. Die Ursache war ein Fehler bei der Wechselkursmanipulation, ausgelöst durch einen klassischen ERC4626 „First Donation“-Vault-Angriff, der zu einem „Division durch großen Wert“-Szenario führte, das den Wechselkurs auf null kollabieren ließ. Diese manipulierte Rate wurde verwendet, um den LTV des Kreditnehmers in der _isSolvent()-Prüfung zu berechnen. Da ltv = 0 ist, wenn exchangeRate = 0, umging der Angreifer die Solvenzprüfung und lieh sich 10 Millionen reUSD mit nur 1 Wei an Sicherheiten.

Der Exploit bezog sich auf einen Smart Contract für eine unveröffentlichte Leverage-Funktion, der zu Testzwecken bereitgestellt wurde. Er zielte auf einen peripheren Vertrag ab, der fillQuote verwendete, um silo.borrow() aufzurufen, wobei Parameter manipuliert wurden, um eine Test-Wallet des Silo Core Teams ins Visier zu nehmen.

Die Hacken-Brücke wurde ausgenutzt. Ein privater Schlüssel, der mit einem Konto mit Prägerechten verbunden war, wurde offengelegt, was es Angreifern ermöglichte, riesige Mengen an HAI-Token zu prägen und diese dann schnell an dezentralen Börsen zu verkaufen. Der private Schlüssel war mit Prägerollen in den Netzwerken Ethereum und BNB Chain verbunden. Die Angreifer konnten rund 900 Millionen HAI-Token prägen.

Nobitex, Irans größte Kryptowährungsbörse, war das Ziel eines bedeutenden Cyberangriffs, der von der pro-israelischen Hackergruppe Gonjeshke Darande, auch bekannt als Predatory Sparrow, beansprucht wurde. Die Gruppe behauptete, dass Nobitex Irans militärische Aktivitäten unterstützte und Nutzern half, internationale Sanktionen zu umgehen, und stellte die Aktion als symbolische Botschaft im Zusammenhang mit den eskalierenden Spannungen zwischen Israel und Iran dar. Der Hack umfasste den Diebstahl von Kryptowährungen aus den Hot Wallets von Nobitex über mehrere Ethereum Virtual Machine (EVM)- und Tron-kompatible Blockchains hinweg. Die Hackergruppe scheint die Krypto-Assets verbrannt zu haben, wodurch sie effektiv zerstört wurden, anstatt sie für eigene Gewinne zu entwenden.

Der Angreifer nutzte eine kritische Integer-Underflow-Schwachstelle in der Funktion BankrollNetworkStack.sell() aus, um die Dividendenzählung zu manipulieren und Gelder von Benutzern abzuziehen, die zuvor mit dem Vertrag interagiert oder diesen genehmigt hatten.

Die Schwachstelle resultierte aus dem Versäumnis, die öffentlich zugängliche Basis-mint()-Funktion, die vom OpenZeppelin ERC4626Upgradeable-Standard geerbt wurde, zu überschreiben oder einzuschränken, was Angreifern ermöglichte, 9701 mpETH ohne Bereitstellung von ETH zu prägen.

Der Exploit entstand durch eine Schwachstelle in der Verifizierungslogik der Self-Listing-Funktion. Der Angreifer nutzte eine kritische Schwachstelle in der Verifizierungslogik der create2-Funktion aus, indem er auf eine fehlgeschlagene Transaktion verwies, wodurch ein bösartiger Token Prüfungen umgehen und Gelder aus Liquiditätspools transferieren konnte.

Der Angreifer führte einen Supply-Chain-Angriff durch, um private Schlüssel zu exfiltrieren. Die geleakten Schlüssel wurden dann verwendet, um Gelder von Bridge-Smart-Contracts freizuschalten. Der Supply-Chain-Angriff zielte auf den Validator-Code ab; der bösartige Code wurde zur Build-Zeit in das Docker-Image eingeschleust.

Ein Mendi-to-Malda Migrationsvertrag wurde ausgenutzt. Der Vertrag erlaubte es, die Mendi Comptroller-Adresse dynamisch zu übergeben, anstatt sie fest zu kodieren. Der Angreifer nutzte eine Funktion, die ausschließlich dazu gedacht war, Mendi-Protokollnutzern die direkte Migration zu Malda zu ermöglichen. Der Angreifer implementierte einen gefälschten Mendi Comptroller-Vertrag, wodurch er eine betrügerische Malda-Position erstellen und Gelder dagegen abheben konnte.

Das Kernproblem hinter dem Exploit liegt in zwei kritischen Schwachstellen des Cork-Protokolls. Erstens erlaubte der Konfigurationsvertrag des Protokolls (CorkConfig) Benutzern, Märkte mit beliebigen Einlösungsvermögenswerten (RA) zu erstellen, was es dem Angreifer ermöglichte, DS als RA zu bestimmen. Zweitens fehlte der beforeSwap-Funktion des CorkHook-Vertrags eine ordnungsgemäße Zugriffskontrolle und Eingabevalidierung, wodurch jeder sie mit benutzerdefinierten Hook-Daten für CorkCall-Operationen aufrufen konnte. Durch die Ausnutzung dieser Schwachstellen erstellte der Angreifer einen bösartigen Markt, der DS als RA verwendete, und nutzte gültige DS-Token von einem legitimen Markt, um sie auf diesem gefälschten Markt einzuzahlen. Im Gegenzug erhielten sie sowohl DS- als auch CT-Token. Aufgrund des Fehlens von Beschränkungen für RA-Typen und einer unzureichenden Validierung des Aufrufers und der Eingabedaten konnte der Angreifer die Liquidität manipulieren und unautorisierte Einlösungen durchführen, wodurch der ursprüngliche Markt geleert wurde. Diese Manipulation ermöglichte es ihnen, eine große Menge an Derivaten zu erwerben, die sie schließlich für 3.761 wstETH einlösten. Die grundlegende Ursache des Exploits liegt im Versagen des Protokolls, vom Benutzer bereitgestellte Daten streng zu validieren und ordnungsgemäße Beschränkungen für die Markterstellung durchzusetzen.

Der Angreifer nutzte eine situative Schwachstelle im Einzahlungspfad des usUSDS++-Vaults aus, einem Beta-Vault, der auf dem Sky-Protokoll basiert. Die Schwachstelle konzentrierte sich auf den „Unwrap“-Prozess, bei dem USD0++ während Einzahlungen in USD0 umgewandelt wird. Durch Manipulation der Einzahlungsroute des Vaults, insbesondere der gedeckelten und begrenzten Konvertierung von USD0++ zu USD0, führte der Angreifer eine Arbitrage-Strategie aus und erzielte einen Gewinn von etwa 42.800 US-Dollar. Der Vault wurde in den letzten Monaten vier Sicherheitsaudits unterzogen. Der Exploit war nicht auf fehlerhafte Logik zurückzuführen. Stattdessen nutzte er einen Verhaltens-Grenzfall im System aus.

Das Fehlen einer Validierung der Chainlink-Oracle-Preisfeeds ermöglichte es dem Angreifer, eine alte, aber immer noch kryptografisch gültige Preissignatur zu verwenden, um eine Position zu eröffnen. Der Angreifer verwendete einen erheblich veralteten ETH-Preis von etwa 1.816 $, während der tatsächliche Marktpreis näher bei 2.520 $ lag. Die Differenz der Vermögenspreise wurde als Gewinn entnommen.

Ein Fehler in der Methode zur Überprüfung von Ganzzahlüberläufen ermöglichte es einem Angreifer, ungesicherte SUI zu prägen.

Ein fehlerhafter und veralteter Smart Contract wurde vor dem Angriff immer noch als Orakel für den Token-Preis verwendet. Der Angreifer nutzte die Spende, um die Schwachstelle im Code auszunutzen und den Preis von dGLP künstlich in die Höhe zu treiben. Anschließend nutzte der Angreifer das überbewertete dGLP als Sicherheit für die Kreditaufnahme.

Die Angriffssequenz beruhte auf umfangreichen administrativen Berechtigungen. Eine Administratorrolle wurde der Adresse eines Angreifers vom Zunami Protocol Deployer Wallet gewährt. Später führte der Angreifer den Exploit aus, indem er direkt die Funktion withdrawStuckToken() in Zunamis Strategie aufrief, eine Funktion, die für Notabhebungen konzipiert ist. Dieser einzige Aufruf ermöglichte es dem Angreifer, 296.456 LP-Token, die die Sicherheiten für zunUSD und zunETH darstellen, direkt auf seine Adresse zu übertragen.

Der ungeprüfte Smart Contract enthielt einen einfachen logischen Fehler, der es dem Angreifer ermöglichte, die gesamte Liquidität abzuziehen. Die Grundursache war die Überschreitung des 1e18-Multiplikators in der Einzahlungsbewertungsfunktion.

Der Vorfall wurde auf einen Entwickler zurückgeführt, der unwissentlich vom Team eingestellt wurde und sich als verdeckter IT-Mitarbeiter der DVRK herausstellte. Diese Person/dieses Team verschaffte sich unrechtmäßig Zugang zu den administrativen Schlüsseln des Projekts und führte eine Reihe nicht autorisierter Transaktionen aus. Der Angreifer hatte eine modifizierte Version der AToken- und VariableDebtToken-Verträge bereitgestellt. In dieser Version wurde der Zugriffssteuerungsmodifikator „onlyPool“ so geändert, dass nicht nur der Pool-Vertrag, sondern auch jede Adresse mit der Pool-Admin-Rolle Funktionen ausführen konnte, die ursprünglich eingeschränkt waren. Der Angreifer nutzte die kompromittierte Bereitsteller-Wallet, um das Leeren aller Pools zu initiieren.

Der Angreifer nutzte fehlerhaften Protokollcode aus und erstellte einen Liquiditätspool abseits des aktuellen Preises, wodurch er erhebliche Gebühren durch Wash-Swaps generierte. Diese Gebühren wurden dann verwendet, um die Bewertung der Sicherheiten zu erhöhen, wobei fehlerhafte Smart-Contract-Mathematik ausgenutzt wurde. Anschließend lieh der Angreifer Geld gegen diese überbewerteten Sicherheiten. Spätere Reinvestitionen reduzierten jedoch den Wert der Sicherheiten, was zu einer unterbesicherten Schuld führte. Diese Schuld wurde dann ohne Liquidation restrukturiert, wodurch der Angreifer die illegalen Gelder behalten konnte.

Loopscale wurde Ziel eines Angriffs, der die Preislogik des Protokolls für von RateX ausgegebene Token ausnutzte. Durch das Spoofing der RateX PT-Marktprogramme konnte der Angreifer eine Reihe von unterbesicherten Darlehen aufnehmen. Der ausgenutzte Codepfad wurde im Rahmen einer neuen Integration mit RateX bereitgestellt und hatte noch keine formelle Prüfung durch Dritte durchlaufen.

Während eines internen Updates des tETH-Orakels wurde eine Diskrepanz in der Dezimalpräzision zwischen den Orakelkomponenten eingeführt. Diese Inkonsistenz führte zu falschen Preisausgaben für tETH. Ein anonymer Liquidator führte Liquidationen in dem Zeitraum durch, in dem der falsche tETH-Preis live war.

Die Oxya Origin Deployer-Wallet scheint kompromittiert worden zu sein, was dazu führte, dass das Eigentum am $OXYZ-Token an eine verdächtige Adresse (0x2a00d9941ab583072bcf01ec2e644679e4579272) übertragen wurde. Der Angreifer prägte 9 Milliarden $OXYZ, tauschte 45.000 $ und überbrückte die Gelder über Stargate.

Eine Schwachstelle in der overPaper-Funktion des BTCMapp Smart Contracts ermöglichte es einem Angreifer, 1.311 ETH zu entnehmen, was 2.228.700 US-Dollar entspricht.

Der Angreifer manipulierte den Preis des $NUMA-Tokens, während er gleichzeitig große Short- und Long-Positionen eröffnete, hinterlegte Sicherheiten durch Selbstliquidation entfernte und das System über den Vault verließ.

Der bösartige Entwickler hatte Code in den Staking-Smart-Contract eingeschleust, der es ihm ermöglichte, eine Notentleerung des Liquiditätspools durchzuführen, wodurch Token im Wert von rund 490 ETH gestohlen wurden.

Die Schwachstelle entstand im TrustedForwarder-Vertrag, der OpenZeppelins MinimalForwarderUpgradeable erbte, aber die Execute-Methode nicht überschrieb. Infolgedessen blieb die Methode erlaubnislos und Missbrauch ausgesetzt. Der Angreifer nutzte dieses Versäumnis aus, indem er die ursprüngliche Execute-Funktion direkt von MinimalForwarderUpgradeable aufrief. In einer einzigen Transaktion eröffnete der Angreifer eine Position zu einem künstlich niedrigen Preis und schloss sie dann zu einem höheren Preis, wodurch er durch diesen Exploit einen illegitimen Gewinn erzielte.

Der Angreifer nutzte ein kompromittiertes Admin-Konto, um die verbleibenden, nicht beanspruchten Token von den ZK-Token-Merkle-Distributoren zu prägen, die für den ZKsync Airdrop vom 17. Juni 2024 verwendet wurden. Der Hacker erlangte erfolgreich die Kontrolle über 111.881.122 ZK-Token.

Die privaten Schlüssel wurden kompromittiert. Der Angreifer nutzte diese Schlüssel dann, um eine Funktion im Vertrag durch eine bösartige zu ersetzen, was ihm den Abzug von Geldern ermöglichte.