Hackers hebben ongeveer een dozijn websites van DeFi-protocollen gekaapt en ongeveer $138.000 afgetapt van gebruikers die met de gecompromitteerde front ends interactie hadden. Alle getroffen websites deelden één gemeenschappelijk detail: hun domein was geregistreerd via Name.com. Het incident is een directe herinnering dat het vertrouwensoppervlak van een DeFi-protocol ver beyond de smart contracts reikt, tot aan de webinfrastructuur die de gebruikersinterface bedient.

Wat bekend is over de DeFi-websitekapingen

Volgens berichtgeving van The Block op 31 oktober 2026 kregen aanvallenden de controle over ongeveer twaalf DeFi-websites en leidden zij gebruikers naar kwaadaardige flows, waarbij in totaal circa $138.000 werd gestolen.

De bevestigde feiten blijven beperkt: ongeveer twaalf DeFi-websites waren getroffen, allemaal geregistreerd via Name.com, en er werd circa $138.000 aan gebruikersmiddelen gestolen. De specifiek gerichte protocollen, de precieze aanvalsvector en het aantal individuele slachtoffers zijn in de beschikbare berichtgeving niet bevestigd. Een gedeelde registratie alone bewijst geen oorzakelijk verband, en Name.com is niet bevestigd als het directe faalpunt.

Wat onbevestigd blijft

Volgens onbevestigde berichten zou de gedeelde Name.com-registratie kunnen wijzen op een credential-compromittering of accountovername op registrar-niveau, waarmee aanvallenden DNS-records konden wijzigen en domeinverkeer konden omleiden zonder de onderliggende smart contracts aan te raken. Het incident kan evenzeer gecompromitteerde registrar-accounts, social engineering of een geheel andere vector hebben betrokken.

Het onderscheid is belangrijk voor zowel getroffen gebruikers als protocolteams: als er met DNS-records is geknoeid, kunnen de on-chain smart contracts zelf onaangetast zijn, wat betekent dat de treasuries en liquiditeitspools van het protocol intact kunnen blijven, terwijl gebruikers die met de vervalste front ends interactie hadden de verliezen droegen.

Front-endkapingen via domeininfrastructuur hebben precedent in de sector: in 2022 leidden aanvallenden de DNS van Curve Finance om naar een kwaadaardige kloon van de interface nadat ze een account bij een domeinprovider hadden gecompromitteerd, een veel aangehaald voorval dat registrar- en DNS-controles op de beveiligingschecklists van DeFi-teams zette. Precedent is echter geen bewijs — of de gedeelde Name.com-registratie in dit geval centraal dan wel toevallig was, kan alleen worden vastgesteld door de eigen incidentonderzoeken van de getroffen teams.

Hoe een gekaapte DeFi-website gebruikers in gevaar brengt

Een compromittering van de web-front-end verschilt structureel van een smart contract-exploit. Wanneer aanvallenden een domein controleren, kunnen ze een visueel identieke kopie van de legitieme interface tonen terwijl ze in stilte endpoints voor walletverbindingen, contractadressen of transaction calldata vervangen. Een gebruiker die lijkt te tekenen voor een routinegoedkeuring, kan in werkelijkheid een drainer-contract autoriseren om het volledige tokensaldo leeg te trekken.

Wat gebruikers moeten verifiëren voordat ze een transactie ondertekenen

Voordat gebruikers een wallet verbinden of een transactie ondertekenen op een DeFi-interface, moeten ze onafhankelijk het contractadres waarmee wordt geïnteracteerde verifiëren tegen de officiële documentatie van het protocol, niet alleen de URL in de browser. Het Secure Transaction Verification and Authorization (STVA) framework behandelt de specifieke stappen voor het inspecteren van calldata vóór goedkeuring. Een domein dat correct resolveert en een geldig SSL-certificaat toont, garandeert niet dat de front end niet op DNS- of hostingniveau is gemanipuleerd.

Phishingbestendige hardware wallets kunnen transactiedetails op het apparaatscherm tonen, onafhankelijk van de browser, waardoor gebruikers een tweede verificatielaag krijgen. Toch kan een vastberaden aanvaller die de front end beheert, misleidende transactiebeschrijvingen vervaardigen. De enige betrouwbare bescherming is het verifiëren van het bestemmingscontractadres tegen de canonieke on-chain implementatie van het protocol, afkomstig uit de officiële GitHub-repository of governance-documentatie in plaats van de verbonden dApp-interface.

Tokengoedkeuringen die aan een gecompromitteerd contract zijn verleend, blijven on-chain bestaan totdat ze expliciet worden ingetrokken. Elke gebruiker die tijdens de periode dat deze sites onder controle van aanvallenden stonden een wallet verbond en een transactie ondertekende, moet openstaande goedkeuringen als potentieel kwaadaardig beschouwen. Tools voor het beheer van goedkeuringen maken het mogelijk om permissies voor ERC-20-tokens te auditen en in te trekken, maar pas nadat onafhankelijk is bevestigd welke contractadressen moeten worden ingetrokken en op welk netwerk moet worden gewerkt.

Wat gebruikers en DeFi-teams nu moeten doen

Acties voor gebruikers

Gebruikers die met een van de getroffen DeFi-websites interactie hadden, moeten eerst vermijden wallets te verbinden of nieuwe transacties te ondertekenen totdat het betreffende protocol publiekelijk bevestigt dat de front end is hersteld en geverifieerd. Officiële communicatie moet afkomstig zijn van de geverifieerde sociale accounts en governancefora van het protocol, niet van links in directe berichten of communitychatberichten, die een veelvoorkomende secundaire aanvalsvector zijn na een front-endcompromittering. Omdat de beschikbare berichtgeving de getroffen protocollen niet heeft genoemd, moeten gebruikers van elke DeFi-front-end letten op directe aankondigingen van de protocollen die ze gebruiken, in plaats van aan te nemen dat zij niet zijn getroffen.

Voor gebruikers die tijdens het incident wel transacties hebben ondertekend, geldt dat het intrekken van goedkeuringen pas raadzaam is nadat het juiste kwaadaardige contractadres is bevestigd via een geverifieerde, onafhankelijke bron. Het intrekken van het verkeerde contract verspilt gas en geeft vals vertrouwen. Protocollen zoals Aave V4 publiceren canonieke contractregisters die als referentiepunt kunnen dienen om legitieme protocolcontracten te onderscheiden van door aanvallenden ingezette drainers.

Reactie van protocolteams

Getroffen teams moeten dit behandelen als een actief incident totdat de volledige aanvalsketen is bevestigd. Onmiddellijke prioriteiten zijn onder meer het auditen van toegangslogboeken van registrar-accounts, het roteren van alle credentials die aan Name.com-accounts zijn gekoppeld, het verifiëren van de huidige DNS-records tegen bekende goede snapshots en het controleren van HTTPS-certificaattransparantielogboeken op ongeautoriseerde certificaten die tijdens de aanvalsperiode zijn uitgegeven.

Teams moeten ook alle incidentbewijzen bewaren voordat ze wijzigingen aanbrengen, aangezien forensische gegevens over de aanvalsperiode — waaronder DNS-wijzigingslogboeken en elke communicatie met de registrar — nodig zullen zijn om precies vast te stellen wat en wanneer is gecompromitteerd. Het publiceren van een helder, van tijdstempels voorzien incidentrapport zodra de aanvalsvector is bevestigd, in plaats van speculatieve communicatie tijdens het onderzoek, is de standaard die getroffen gemeenschappen mogen verwachten.

De beveiliging van registrar-accounts, waaronder het afdwingen van tweefactorauthenticatie en registrar-niveau domeinvergrendeling, is een basisverhardingsmaatregel die ongeautoriseerde DNS-wijzigingen voorkomt, zelfs wanneer aanvalscredentials geldig zijn. Domeinvergrendeling voorkomt overdrachten en DNS-wijzigingen zonder expliciete bevestiging van de registrar, waardoor het een zinvolle controle is voor elk protocol waarvan de website een gebruikersgericht vertrouwensoppervlak vormt voor transacties met echte middelen.

De bredere les

Het gerapporteerde verlies van $138.000 verspreid over ongeveer een dozijn protocollen is bescheiden vergeleken met de totale DeFi TVL op Ethereum. Maar de structurele kwetsbaarheid die het blootlegt — namelijk dat een web2-registrar-account de zwakke schakel kan worden in de beveiligingsstack van een protocol — geldt voor elk DeFi-project dat afhankelijk is van een centraal geregistreerd domein om zijn gebruikersinterface te tonen. Front-endbeveiliging, waaronder DNS-monitoring, verharding van registrar-accounts en gebruikersrichtlijnen over onafhankelijke contractverificatie, verdient dezelfde operationele nauwkeurigheid als smart contract-audits.