De Bitget aanval draait om iets wat bij veel organisaties als “extern risico” wordt gezien: een kwetsbaarheid in een derdepartij beveiligingsproduct dat de crypto-exchange gebruikte. Volgens Bitget kreeg de aanvaller via dit lek toegang tot interne omgevingen, waarna vervolgens valse opdrachten werden ingediend om geld van de walletinfrastructuur over te hevelen.
Wat het incident extra zorgwekkend maakt, is dat de aanvaller daarbij gebruikmaakte van legitieme interne inloggegevens en administratieve handelingen wist na te bootsen. Tegelijkertijd stelt Bitget dat klantbalansen niet zijn aangetast en dat er geen private keys zijn gecompromitteerd.
Hoe de Bitget aanval volgens Bitget begon
Bitget meldt dat de aanvaller binnenkwam door een fout in een beveiligingsoplossing van een leverancier. Met die toegang kon de aanvaller hoogwaardige interne credentials verkrijgen. Daarna heeft de aanvaller ze gebruikt om op 24 september frauduleuze opnameopdrachten (“withdrawal commands”) te versturen naar het walletsysteem van Bitget.
Belangrijk detail: Bitget werkt, zoals veel beurzen, met een mix van wallettypes. Een groot deel van klantgelden staat offline in cold wallets, terwijl hot en warm wallets worden gebruikt voor verwerking van opnames. Volgens Bitget kwamen de gestolen fondsen uit de hot en warm segmenten; de cold wallets bleven buiten schot.
Valse opdrachten als legitieme administratieve handeling
Bitget beschrijft dat een kritisch backendonderdeel in de walletinfrastructuur was gecompromitteerd. Daarmee kon de aanvaller onder andere transactiegegevens spoof’en en vervolgens de goedkeuringsflow voor opnames activeren. Bitget gaf eerder niet aan hoe de aanvaller precies binnenkwam, maar koppelt de oorsprong nu aan het derdepartijlek.
Volgens CEO Gracy Chen kregen aanvallers toegang tot een intern managementsysteem. Vanuit daar konden ze frauduleuze opnameopdrachten invoegen in backendservices die normaal gesproken dergelijke acties als “toegestaan” verwerken. Chen noemde daarbij ook dat de activiteit werd gemaskeerd als routinematige administratie en dat sporen werden verwijderd tijdens de uitvoering.
Tijdlijn: eerst testen, dan grotere opnames
Op 24 september zette de aanvaller eerst een rustige test. Bitget meldt dat er om 18:31 UTC twee kleine overboekingen werden gedaan. Die bleven onder een risico-drempel, waardoor ze geen alarm veroorzaakten.
Ongeveer 30 minuten later startten de grotere transacties. De walletsysteemlaag voerde de opnames uit en volgens Bitget werden daarbij de risicocontroles omzeild. Het kernpatroon: beginnen met laag profiel om detectie te ontwijken, waarna de echte impact volgt zodra de omgeving “vertrouwd” lijkt.
Wat er (volgens Bitget) niet is gebeurd
Bitget zegt dat geen private keys zijn gecompromitteerd. De exchange baseert die conclusie op de uitkomst van het onderzoek tot dan toe.
Ook stelt Bitget dat klantenbalansen niet zijn beïnvloed. Het verlies zou worden gedekt via het Protection Fund, een reservering die is bedoeld voor security-incidenten.
Responsmaatregelen: isoleren, credentials intrekken en monitoring opschalen
Nadat het incident was vastgesteld, heeft Bitget volgens haar beschrijving verschillende stappen gezet:
- De leverancier is geïnformeerd.
- Aangetaste systemen zijn geïsoleerd.
- Interne credentials zijn ingetrokken en opnieuw uitgegeven.
- Functies die met het probleem samenhangen zijn tijdelijk uitgeschakeld terwijl de kwetsbaarheid wordt aangepakt.
Daarnaast heeft Bitget het interne toegangsmodel aangescherpt, onafhankelijke controles voor opnames toegevoegd en extra monitoring ingericht op ongebruikelijke activiteiten.
Zijn er fixes beschikbaar voor het derdepartijlek?
In de berichtgeving rond het incident noemt Bitget de betreffende leverancier niet in dit stadium. Ook geeft de exchange niet met zekerheid aan of de vendor al een patch of definitieve oplossing heeft uitgebracht.
Volgens Bitget verwacht men een formeel incidentrapport later in de week te publiceren, zodat ook duidelijker wordt welke maatregelen precies effectief waren en hoe de oorzaak definitief wordt afgesloten.
Praktisch gevolg voor gebruikers: geen actie nodig
Op het moment van de update heeft Bitget de Bitcoin-opnames weer geopend. Voor andere assets geldt dat opnames later gefaseerd worden hervat, met een planning richting 2 oktober.
Bitget benadrukt dat gebruikers geen actie hoeven te ondernemen. Dat is vooral bedoeld om verwarring te voorkomen in tijden waarin klanten vaak geneigd zijn zelf stappen te zetten.
Communicatie met het ecosysteem: herstelnavigatie en adresmonitoring
Voor het herstelproces publiceerde Bitget de kernadressen die de gestolen fondsen ontvingen, inclusief een live tracking dashboard. Ook is er een oproep gedaan aan andere spelers in het netwerk—zoals exchanges, stablecoin-uitgevers, bridges en custodians—om die adressen actief te volgen en bevindingen via een recoveryportaal terug te koppelen.
TRM Labs adviseerde daarnaast om incoming deposits niet alleen te beoordelen op directe herkomst. In plaats daarvan adviseert TRM om ook te kijken naar routes via intermediaire wallets, omdat opbrengsten via bridges en cross-chain swap-diensten vaker indirect binnenkomen.
Waarom een derdepartijlek zo hard kan binnenkomen
De Bitget aanval laat zien hoe kwetsbaar organisaties kunnen zijn wanneer veiligheidstools of monitoringproducten niet volledig “air-gapped” zijn van kritieke processen. Als een externe beveiligingscomponent toegang krijgt tot interne managementstromen, kan een lek binnen die keten direct de kernprocessen bereiken—zoals autorisatie en goedkeuring van transacties.
Daarom is het niet genoeg om alleen te kijken naar kwetsbaarheden in eigen applicaties. Je wilt ook helder hebben welke privileges derdepartijproducten krijgen, hoe snel credentials kunnen worden ingetrokken en hoe goed interne controles falen of juist helpen wanneer iets misgaat.
Wil je meer lezen over dit type risico rond toegang en besturing? Dan past dit artikel goed als vervolg: Governance voor AI-agents: minder toegang, meer controle. Hoewel het thema daar op AI-agents ligt, sluiten de principes rond controle en beperking van toegang inhoudelijk aan op wat hier zichtbaar wordt: misbruik wordt beperkter wanneer autorisaties strakker zijn ingericht.
Wat je als organisatie kunt meenemen
Los van de details van deze specifieke exchange zijn er meerdere lessen die breed toepasbaar zijn op security governance en incidentresponscapaciteit:
- Controleer derdepartijtoegang: weet welke interne systemen externe componenten mogen benaderen.
- Beperk privileges: minimaliseer de impact van gestolen of misbruikte credentials.
- Voer onafhankelijke checks uit op kritieke acties zoals opnames en goedkeuringen.
- Monitor afwijkingen, zeker rond “testachtige” transacties die drempels niet raken.
- Herroep snel: zorg dat intrekken en opnieuw uitgeven van credentials operationeel en voorspelbaar is.
Wie bovendien geïnteresseerd is in hoe incidentafhandeling wordt verbeterd door betere zichtbaarheid, kan ook dit gerelateerde onderwerp bekijken: Focus: stateful SOC en AI in incidentafhandeling. Dat richt zich op SOC-workflows, maar de onderliggende behoefte—sneller detecteren, beter analyseren en consequenter handelen—komt in dit soort scenario’s altijd terug.
Conclusie
De Bitget aanval laat zien hoe een kwetsbaarheid in een derdepartij beveiligingsproduct kan uitgroeien tot grote financiële schade. Door interne credentials te verkrijgen en die te gebruiken om frauduleuze withdrawal-opdrachten door backendservices te laten verwerken, wist de aanvaller controles te omzeilen en geld uit hot en warm wallets te halen.
Tegelijkertijd benadrukt Bitget dat klantensaldi niet werden geraakt, dat private keys niet zijn gecompromitteerd en dat verdere hervatting van opnames gefaseerd plaatsvindt. Voor andere organisaties is dit vooral een waarschuwing om ook de veiligheidsketen buiten de eigen codebase serieus te nemen: controle op rechten, onafhankelijk toezicht en een respons die snel kan schakelen zodra een leverancier of component een zwakke schakel blijkt.
Bron: https://thehackernews.com/2026/09/bitget-says-attacker-exploited-third.html
