De recente Binance-heist van naar schatting $6,34 miljard toont hoe snel een aanval kan escaleren wanneer social engineering, malware en interne tooling samenkomen. Volgens Binance bereikte de campagne uiteindelijk de wallet signing-keten, waardoor aanvallers ongeautoriseerde transacties konden uitvoeren vanuit hot wallets.
Een belangrijk element in het verhaal is dat de indringers niet alleen medewerkers-werkstations wisten te besmetten, maar ook een interne AI-tool misbruikt hebben om controle te krijgen binnen het wallet-ecosysteem. De aanval verliep daarbij niet als één incident, maar als een zorgvuldig opgebouwde reeks stappen over maanden.
Van nep sollicitatie naar gecompromitteerde werkstations
Binance beschrijft dat de inbraak in meerdere fases plaatsvond. Het begon in juni, toen een Wallet DevOps engineer tijdens het zoeken naar een populaire AI-coding tool een tampered Homebrew-installatie downloadde via een zoekopdracht.
Hoewel het beveiligingsteam van Binance de verdachte activiteit detecteerde, het betreffende apparaat verving en credentials resette, had de aanvaller volgens Binance al voldoende informatie opgedaan: inzicht in taken en de personen die met de wallet-infrastructuur werkten.
Nep recruiters en een “coding assignment”
In september werd een tweede engineer benaderd door iemand die zich voordeed als project director. De “sollicitatie”-route liep via twee gesprekken: een eerste met een valse HR-afdeling en een tweede met een zogenaamd CEO-profiel van een bedrijf dat niet zou bestaan.
Tijdens het eerste contact gebruikte de impostor een socialmediakanaal met persoonlijke foto’s en video’s om vertrouwen op te bouwen. Het tweede gesprek liep via een chatapp en eindigde met een verzoek om een coding “assignment” te downloaden op het werkapparaat.
Dat assignment bleek een kwaadwillige code repository te bevatten die opstartte zodra de engineer het op zijn computer installeerde. Binance zegt ook dat een 0-day malware-component op dat moment niet werd gedetecteerd door endpointbeveiliging.
Hoe de AI-tool misbruikt werd in de aanval
Op 20 oktober schakelden de aanvallers door naar de volgende stap: zij maakten gebruik van de besmette machines en een interne AI-tool om controle te krijgen over het systeem van de eerste engineer en ook dat van een derde wallet engineer.
Binance licht volgens het incidentrapport niet volledig toe hoe precies die AI-tool is ingezet. Wel benadrukt de uitwerking van de campagne dat het misbruik niet los stond van de besmettingen, maar er functioneel op voortbouwde.
Daarmee past de aanval in een breder patroon dat je vaker ziet: eerst toegang via mensen en endpoints, daarna pas het escaleren naar interne systemen en processen.
Van toegang tot wallet signing en onrechtmatige transacties
De eerste engineer zou een token hebben gehad waarmee container deployments mogelijk waren. Uiteindelijk logden de aanvallers op de derde engineer in, zetten ze een container op met credentials die uit de eerste machine waren verkregen en startten ze de aanval met een malicious script.
Binance stelt dat de aanvallers vervolgens ongeautoriseerde toegang misbruikten tot een interne wallet signing-service. Daardoor konden zij activa verplaatsen uit hot wallets, waaronder XRP, SOL, OP en BTC.
Ethereum EIP-7702 en “delegation” die doorliep
Volgens Binance werd ook een Ethereum-mechanisme misbruikt, namelijk EIP-7702. Dit gaf een contract onder controle van de aanvallers gedeeltelijke uitvoeringstoestemming over een hot wallet.
Belangrijk detail: stoppen met withdrawals alleen bleek niet voldoende om alle ongeautoriseerde verplaatsingen te stoppen. Binance legt uit dat de EIP-7702 autorisaties al op de blockchain stonden en dus onafhankelijk opereerden van Binance’ normale withdrawal-infrastructuur.
Waarom MPC dit niet meteen kon terugdraaien
De hot wallet was volgens Binance beveiligd met multi-party computation (MPC). Dat betekent in de praktijk dat Binance niet één enkele sleutel had waarmee het de delegatie direct kon annuleren.
De laatste ongeautoriseerde overdracht zou hebben plaatsgevonden om 23:56 UTC. Kort daarna, rond na middernacht, werd de delegatie vervolgens uitgezet.
Na de incidentfase zegt Binance de wallet-systemen en de AI-tool opnieuw opgebouwd te hebben, apparaten vervangen, en ook de betrokken credentials en tokens retired (buiten gebruik gesteld).
Attributie, ontkenning en aanvullende ontwikkelingen
De FBI koppelt de diefstal aan TraderTraitor, een Noord-Koreaanse state-sponsored hackinggroep. Noord-Korea wijst dit van de hand en noemt het een politieke verdraaiing richting de DPRK.
Los van de discussie over attributie, kwamen er ook operationele meldingen naar buiten. Binance zegt dat het in het lopende jaar 57 vermoedelijke Noord-Korea-linkte dreigingen heeft gedetecteerd en geblokkeerd.
Reserves, hervatte withdrawals en laundering-snelheid
Binance voltooide daarnaast een zero-knowledge proof voor een reservesnapshot van 31 oktober. Daarmee kunnen houders van 10 grote tokens verifiëren dat hun balances ten minste 1:1 gedekt zijn. Co-CEO Richard Teng stelt dat 98% van de impacted tokens is aangevuld.
Verder zegt Teng dat withdrawals “broadly” zijn hervat, met gefaseerde heropening vanaf 1 november.
Voor het witwassen (laundering) melden partijen zoals Elliptic dat het gestolen geld via ongeveer 12.000 wallets op 11 blockchains is gegaan binnen minder dan vier dagen, met automatisering, maar zonder aanwijzingen dat AI-agenten beslissingen namen. Op 3 november zou nog ongeveer $3,18 miljard in theft-linked adressen hebben gezeten.
Ook Chainalysis vermeldt dat een noodstop bij THORChain door een andere technische kwestie de laundering tijdelijk vertraagde.
Wat betekent dit voor je eigen security-aanpak?
Dit incident laat zien dat grote financiële schade vaak niet begint bij een “mystieke” exploit, maar bij een samenloop van fouten: vertrouwen op nepkanalen, onvoldoende weerstand tegen supply chain-achtige manipulatie en het te laat blokkeren van toegangspaden naar interne services.
Als je organisatie werkt met interne tooling of gevoelige signing-processen, zijn er drie praktische lessen die je kunt toepassen:
- Bescherm de toegang tot ontwikkel- en infrastructuurtools. Denk aan strictere verificatie bij downloads en installatiepaden (zoals pakketten), en zorg dat detectie niet alleen op malware draait maar ook op afwijkende workflows.
- Maak social engineering minder effectief. Nep HR- en directieprofielen werken alleen als medewerkers niet worden “gehardeerd” op het veilig afhandelen van downloads, opdrachten en werkinstallaties.
- Beperk impact van geautoriseerde tokens en delegated rights. Ook als je withdrawals kunt pauzeren, kunnen blockchain-autorisaties blijven werken. Ontwerp daarom controlemogelijkheden die verder gaan dan alleen de front-end withdrawalflow.
Wil je dit breder trekken naar realistische dreigingen, dan is het relevant om ook te lezen hoe social engineering en AI-misbruik samenkomen, bijvoorbeeld in DarkBlinders: cloud-aanvallen via social engineering.
En als je kijkt naar waarom incidenten soms moeilijk te stoppen zijn zodra toestemmingen zijn vastgelegd, kan exposure prioritization helpen om sneller te bepalen waar je als eerste moet ingrijpen—ook in complexe omgevingen.
Conclusie: AI-tool misbruikt als schakel in een langer aanvalstraject
De Binance-casus draait niet om één enkele fout, maar om een maandenlange campagne met verschillende ingangen: een gemanipuleerde installatie, nep sollicitaties en uiteindelijk besmette werkstations die doorgingen naar interne systemen. De kern daarvan is dat een AI-tool misbruikt werd als onderdeel van de escalatie richting wallet signing en ongeautoriseerde transacties.
Hoewel Binance veel stappen heeft genomen—systemen herbouwen, credentials en tokens intrekken en withdrawals gefaseerd hervatten—maakt dit incident duidelijk dat organisaties met kritieke financiële processen extra aandacht moeten besteden aan mensgerichte aanvallen, het beperken van token- en delegatie-impact, en het beveiligen van interne tooling tegen misbruik.
