Hacker haben rund ein Dutzend Websites von DeFi-Protokellen gekapert und etwa 138.000 US-Dollar von Nutzern abgeschöpft, die mit den kompromittierten Frontends interagierten. Alle betroffenen Seiten hatten eines gemeinsam: Ihre Domain war über Name.com registriert. Der Vorfall erinnert unmittelbar daran, dass die Vertrauensfläche eines DeFi-Protokolls weit über seine Smart Contracts hinaus bis zur Web-Infrastruktur reicht, die seine Benutzeroberfläche bereitstellt.

Was über die DeFi-Website-Hijacks bekannt ist

Laut Berichten von The Block vom 31. Oktober 2026 erlangten Angreifer die Kontrolle über rund zwölf DeFi-Websites und leiteten Nutzer in bösartige Abläufe um, die zu gestohlenen Mitteln von approximately 138.000 US-Dollar führten.

Die bestätigten Fakten bleiben begrenzt: Ungefähr zwölf DeFi-Websites waren betroffen, sämtlich über Name.com registriert, und es wurden etwa 138.000 US-Dollar an Nutzergeldern gestohlen. Die konkret betroffenen Protokolle, der genaue Angriffsweg und die Zahl der einzelnen Opfer sind in den verfügbaren Berichten nicht bestätigt. Die gemeinsame Registrierung allein belegt keine Kausalität, und Name.com ist nicht als direkte Schwachstelle bestätigt.

Was unbestätigt bleibt

Nach unbelegten Berichten könnte die gemeinsame Name.com-Registrierung auf eine Kompromittierung von Zugangsdaten oder eine Kontoübernahme auf Registrar-Ebene hindeuten, die es Angreifern ermöglicht hätte, DNS-Einträge zu ändern und den Domain-Traffic umzuleiten, ohne die zugrunde liegenden Smart Contracts anzufassen. Der Vorfall könnte ebenso durch kompromittierte Registrar-Konten, Social Engineering oder einen völlig anderen Weg erfolgt sein.

Dieser Unterschied ist für betroffene Nutzer wie Protokollteams relevant: Wurden die DNS-Einträge manipuliert, können die On-Chain-Smart Contracts selbst unberührt sein – das heißt, die Treasuries und Liquiditätspools des Protokolls können intakt bleiben, während Nutzer, die mit den gefälschten Frontends interagierten, die Verluste trugen.

Frontend-Hijacks über Domain-Infrastruktur haben in der Branche bereits Präzedenzfälle: Im Jahr 2022 leiteten Angreifer nach der Kompromittierung eines Domain-Provider-Kontos den DNS von Curve Finance auf einen bösartigen Klon der Schnittstelle um – ein viel zitiertes Ereignis, das Registrar- und DNS-Kontrollen auf die Sicherheitschecklisten der DeFi-Teams brachte. Ein Präzedenzfall ist jedoch kein Beweis: Ob die gemeinsame Name.com-Registrierung in diesem Fall zentral oder zufällig war, kann nur durch die eigenen Untersuchungsergebnisse der betroffenen Teams geklärt werden.

Wie ein gekaperter DeFi-Website Nutzer gefährdet

Eine Kompromittierung des Web-Frontends unterscheidet sich strukturell von einem Smart-Contract-Exploit. Kontrollieren Angreifer eine Domain, können sie eine optisch identische Kopie der legitimen Benutzeroberfläche ausliefern und dabei stillschweigend Wallet-Verbindungsendpunkte, Contract-Adressen oder Transaktions-Calldata austauschen. Ein Nutzer, der eine scheinbar routinemäßige Genehmigung signiert, autorisiert in Wirklichkeit möglicherweise einen Drainer-Contract, der seinen gesamten Token-Bestand abräumt.

Was Nutzer vor jeder Transaktionssignatur prüfen sollten

Bevor Nutzer eine Wallet verbinden oder eine Transaktion auf einer DeFi-Oberfläche signieren, sollten sie die interagierende Contract-Adresse unabhängig anhand der offiziellen Dokumentation des Protokolls überprüfen – nicht nur anhand der URL im Browser. Das Secure Transaction Verification and Authorization (STVA) framework beschreibt die konkreten Schritte zur Prüfung der Calldata vor der Genehmigung. Eine Domain, die korrekt auflöst und ein gültiges SSL-Zertifikat anzeigt, garantiert nicht, dass das Frontend nicht auf DNS- oder Hosting-Ebene manipuliert wurde.

Phishing-resistente Hardware-Wallets können Transaktionsdetails unabhängig vom Browser auf dem Gerätebildschirm anzeigen und bieten Nutzern so eine zweite Verifikationsebene. Dennoch kann ein entschlossener Angreifer, der das Frontend kontrolliert, irreführende Transaktionsbeschreibungen erzeugen. Der einzige verlässliche Schutz besteht darin, die Ziel-Contract-Adresse mit der kanonischen On-Chain-Bereitstellung des Protokolls abzugleichen, die aus dem offiziellen GitHub-Repository oder der Governance-Dokumentation stammt – nicht aus der verbundenen dApp-Oberfläche.

Token-Genehmigungen, die einem kompromittierten Contract gewährt wurden, bleiben on-chain bestehen, bis sie explizit widerrufen werden. Jeder Nutzer, der während des Zeitraums, in dem die Websites unter Angreiferkontrolle standen, eine Wallet verband und eine Transaktion signierte, sollte bestehende Genehmigungen als potenziell bösartig betrachten. Approval-Management-Tools ermöglichen es Nutzern, Berechtigungen über ERC-20-Token hinweg zu prüfen und zu widerrufen – jedoch erst, nachdem die richtigen zu widerrufenden Contract-Adressen und das richtige Netzwerk unabhängig bestätigt wurden.

Was Nutzer und DeFi-Teams jetzt tun sollten

Maßnahmen für Nutzer

Nutzer, die mit einer der betroffenen DeFi-Websites interagiert haben, sollten zunächst keine Wallets verbinden oder neue Transaktionen signieren, bis das jeweilige Protokoll öffentlich bestätigt, dass das Frontend wiederhergestellt und verifiziert wurde. Offizielle Mitteilungen sollten von den verifizierten Social-Media-Konten und Governance-Foren des Protokolls stammen – nicht aus Links in Direktnachrichten oder Community-Chats, die nach einer Frontend-Kompromittierung einen häufigen sekundären Angriffsweg darstellen. Da die verfügbaren Berichte die betroffenen Protokolle nicht nennen, sollten Nutzer jedes DeFi-Frontends auf direkte Ankündigungen der von ihnen genutzten Protokolle achten, statt anzunehmen, sie seien nicht betroffen.

Für Nutzer, die während des Vorfalls Transaktionen signiert haben, ist der Widerruf von Genehmigungen erst ratsam, nachdem die korrekte bösartige Contract-Adresse aus einer verifizierten, unabhängigen Quelle bestätigt wurde. Der Widerruf des falschen Contracts verschwendet Gas und vermittelt falsche Sicherheit. Protokolle wie Aave V4 veröffentlichen kanonische Contract-Register, die als Referenz dienen können, um legitime Protokoll-Contracts von von Angreifern eingesetz Drainern zu unterscheiden.

Reaktion der Protokollteams

Betroffene Teams sollten dies als laufenden Vorfall behandeln, bis die vollständige Angriffskette bestätigt ist. Zu den sofortigen Prioritäten gehören die Prüfung der Zugriffsprotokolle der Domain-Registrar-Konten, der Wechsel aller mit Name.com-Konten verbundenen Zugangsdaten, der Abgleich der aktuellen DNS-Einträge mit als vertrauenswürdig bekannten Schnappschüssen sowie die Kontrolle der HTTPS-Zertifikatstransparenzprotokolle auf nicht autorisierte Zertifikate, die während des Angriffszeitraums ausgestellt wurden.

Teams sollten außerdem alle Beweismittel sichern, bevor sie Änderungen vornehmen, da forensische Daten zum Angriffszeitraum – einschließlich DNS-Änderungsprotokollen und jeglicher Kommunikation mit dem Registrar – benötigt werden, um genau festzustellen, was wann kompromittiert wurde. Einen klaren, mit Zeitstempel versehenen Vorfallbericht zu veröffentlichen, sobald der Angriffsweg bestätigt ist – statt während der Untersuchung spekulative Mitteilungen herauszugeben – ist der Standard, den die betroffenen Communities erwarten werden.

Die Sicherheit von Domain-Registrar-Konten, einschließlich der Durchsetzung der Zwei-Faktor-Authentifizierung und von Domain-Sperren auf Registrar-Ebene, ist eine grundlegende Härtungsmaßnahme, die unbefugte DNS-Änderungen verhindert, selbst wenn Angreifer über gültige Zugangsdaten verfügen. Eine Domain-Sperre verhindert Übertragungen und DNS-Änderungen ohne ausdrückliche Bestätigung durch den Registrar und ist damit eine wirksame Kontrolle für jedes Protokoll, dessen Website eine nutzerseitige Vertrauensfläche für Transaktionen mit echtem Geldvermögen darstellt.

Die breitere Lehre

Der gemeldete Verlust von 138.000 US-Dollar über rund ein Dutzend Protokolle hinweg ist bescheiden im Vergleich zum gesamten DeFi-TVL auf Ethereum. Doch die strukturelle Schwachstelle, die er offenlegt – nämlich dass ein Web2-Registrar-Konto zum schwächsten Glied im Sicherheitsstack eines Protokolls werden kann –, betrifft jedes DeFi-Projekt, das sich für seine Benutzeroberfläche auf eine zentral registrierte Domain verlässt. Frontend-Sicherheit, einschließlich DNS-Monitoring, Härtung von Registrar-Konten und Nutzerhinweisen zur unabhängigen Verifikation von Contracts, verdient dieselbe operative Sorgfalt wie Smart-Contract-Audits.