Direct naar de inhoud
Beveiligingsnieuws

Snowflake-incident: schuldpleidooi en lessen voor MFA

Snowflake incident

In de Verenigde Staten is een belangrijke zaak rond het Snowflake incident verder in de juridische fase beland. Connor Riley Moucka (26) pleitte in een federale rechtbank in Seattle schuldig aan meerdere aanklachten, waaronder computermisbruik en oplichting. Daarmee komt er ook meer duidelijkheid over hoe de aanvallen in 2024 konden landen bij klanten van het SaaS-platform.

Volgens de aanklagers en onderzoeksinformatie ging het niet om een doorbraak via een technische kwetsbaarheid in het platform zelf. De kern van het verhaal is eenvoudiger (en daardoor ook gevaarlijker): oude wachtwoorden die nooit zijn vervangen en accounts waar multi-factor authenticatie (MFA) was uitgeschakeld.

Wat verklaart het Snowflake incident in grote lijnen?

De zaak draait om inbraken in klantaccounts in 2024. De aanvallen bereikten volgens de beschikbare informatie minstens 165 organisaties en werden gekoppeld aan gegevens van ten minste 100 miljoen personen. Dat betekent: niet alleen losstaande accounts, maar een schaal die de impact van één zwakke schakel ver overstijgt.

Moucka wordt bovendien genoemd als iemand die persoonlijk opbrengsten vergaarde via afpersing en verkoop van data. Het Openbaar Ministerie beschrijft bedragen die samenlopen met een fors totaal aan opbrengsten, met een verplicht minimumstraf op een van de identiteitsgerelateerde tellingen.

Schuldvraag: geen platformfout, maar gestolen credentials

De belangrijkste les uit het Snowflake incident is dat de aanvallers geen exploit of platform-gebrek nodig hadden. Wat “de deur opende” waren wachtwoorden die al jaren eerder waren verzameld door infostealer-malware. Die data bleef vervolgens bruikbaar doordat de betrokken credentials nooit werden geroteerd.

Daar bovenop stond dat MFA in de getroffen accounts uit was gezet. Met andere woorden: zelfs als de inloggegevens al eerder waren buitgemaakt, zorgde het ontbreken van een tweede factor ervoor dat aanvallers de accounts konden misbruiken.

Waarom oude wachtwoorden zo hard kunnen werken

Veel organisaties denken bij accountbeveiliging aan “eenmalige” maatregelen: stel MFA in, pas wachtwoorden aan en klaar. Maar het Snowflake incident laat zien dat het niet genoeg is om beveiliging te hebben—je moet ook zorgen dat die beveiliging door de tijd heen blijft kloppen.

In de onderzoeksbeschrijving wordt benadrukt dat een groot deel van de gebruikte accounts eerder al blootgesteld was aan credential-diefstal. Bovendien waren sommige wachtwoorden afkomstig uit campagnes die teruggingen tot in 2020 en daarna nog geldig bleven.

Extra druk: her-afpersing met gevoelige gegevens

Naast de initiële inbraak beschrijven de vervolgende instanties een tweede fase: re-extortion. Daarbij zouden slachtoffers opnieuw zijn benaderd met dreigementen over verdere openbaarmaking van gestolen informatie.

De onderbouwing ging onder meer over informatie die gekoppeld kon worden aan personen met een overheidsfunctie en aan directe familieleden. Het doel van deze aanpak werd in de aankondigingen neergezet als “berekend en roofzuchtig”, wat onderstreept dat de aanvallen niet alleen technisch waren, maar ook strategisch.

Welke data kwam naar buiten?

Het is niet alleen “toegang” die schade veroorzaakt. In deze zaak wordt ook genoemd wat er precies is geëxporteerd of buitgemaakt. Daarbij ging het om gegevens die variëren van administratieve en identiteitsgerelateerde records tot communicatie- en dossierinformatie.

Onder andere worden genoemd: niet-content communicatiehistorie (zoals bel- en tekstgegevens), loonadministratiegegevens, registratie-informatie en documenten zoals paspoort- en identiteitsnummers.

Een concreet voorbeeld dat eerder door een telecomprovider is bevestigd, gaat over bel- en tekstrecords van (bijna) alle mobiele klanten binnen een bepaalde periode. Zulke details laten zien hoe breed “records” kunnen zijn wanneer toegang tot een klantomgeving eenmaal mogelijk is.

Hoe kon het incident zo breed landen?

Onderzoeksrapporten die samen met de betrokken partijen zijn opgesteld, geven aan dat de campagne niet steunt op een uitzonderlijk nieuw of geavanceerd instrument. De effectiviteit zat volgens die beschrijving vooral in de beschikbaarheid van gestolen inloggegevens en het feit dat wachtwoorden niet werden geroteerd.

Ook wordt in de beschikbare informatie een rol genoemd van het ontbreken van netwerk-allow lists in de gecompromitteerde omgevingen. Dat maakt de “beweging” na inlog makkelijker: er is minder afscherming op basis van netwerkregels, waardoor een aanvaller met geldige credentials vaker meer kan doen dan je zou verwachten.

Aantal getroffen organisaties: waarom cijfers kunnen verschuiven

In communicatie over incidenten lopen aantallen soms uiteen. Bij het Snowflake incident wordt dat extra zichtbaar doordat “het aantal” in verschillende fasen anders wordt gebruikt.

Eerst begon het cijfer als een notificatie- of waarschuwingsmaat: het aantal organisaties dat mogelijk blootgesteld was. In juridische stukken en later in opvolging werd dat doorvertaald naar het aantal klanten dat daadwerkelijk is gecompromitteerd.

Daarbij komen ook verschillen voor tussen “in de body” genoemde aantallen en verklaringen in statements. Het belangrijkste voor organisaties is dus niet om te discussiëren over exacte ronde getallen, maar om te kijken naar de patronen: oude credentials, MFA uit en onvoldoende credential hygiene.

Wat kunnen organisaties leren: wachtwoordrotatie en MFA op orde

De zaak rond het Snowflake incident maakt één punt heel zichtbaar: beveiliging faalt vaak niet door één grote technische misser, maar door een combinatie van factoren die je in de praktijk kunt voorkomen.

  • Rotatie van wachtwoorden: als er ook maar een kans bestaat op credential exposure, vervang wachtwoorden dan snel en grondig.
  • MFA standaard aan: zorg dat MFA structureel ingeschakeld is voor alle relevante gebruikers en service-accounts—niet alleen “voor nieuwe accounts”.
  • Controleer of MFA echt actief is: let niet alleen op het instellen, maar ook op het handhaven en valideren van beleid.
  • Beperk wat accounts mogen: implementatie van netwerk- en toegangsbeperkingen (zoals allow lists) kan lateraal bewegen beperken.
  • Inventariseer welke gegevens en rollen geraakt kunnen worden: wanneer records gevoelig zijn, moet je ook weten waar die liggen en wie er toegang toe heeft.

Een praktische link met andere incidentlessen

Veel aanvallen die voortbouwen op gestolen inloggegevens laten vergelijkbare patronen zien: er ontbreekt een stevige tweede laag of wachtwoorden blijven te lang geldig. Als je verdieping zoekt in hoe credential-gerichte aanvallen ontstaan en welke zwaktes daarbij vaak terugkomen, dan is dit een interessante aanvulling: Passkey-hijack door malware: zo werkt het.

Daarnaast is het zinvol om te kijken naar hoe aanvallers zoeken naar aangrijpingspunten in authenticatieflows en configuraties. Dat thema sluit aan op beveiligingsvragen rond moderne identity- en access-inrichtingen, zeker wanneer incidenten laten zien dat “geen exploit nodig” soms gewoon betekent: de juiste accountgegevens waren al beschikbaar.

Snowflake en het uitrollen van strengere MFA

In de beschikbare informatie staat ook dat Snowflake MFA gefaseerd verder aanscherpt. Voor menselijke gebruikers die na oktober 2024 zijn aangemaakt, wordt MFA door default afgedwongen, maar wachtwoord-only aanmeldingen verdwijnen niet meteen voor alle bestaande accounts.

De documentatie die is gecheckt in de berichtgeving beschrijft een laatste uitrolfase tussen augustus en oktober 2026, account voor account. Pas daarna zouden wachtwoorden als enige factor worden geblokkeerd voor alle resterende menselijke en servicegebruikers. Uitzonderingen worden genoemd voor onder meer test- of reader-accounts.

Voor klanten is dit relevant omdat het aangeeft dat “beleid” pas echt impact heeft wanneer het volledig is uitgerold en wanneer uitzonderingen helder zijn. Een gefaseerde aanpak kan handig zijn om migratieproblemen te beperken, maar het verlengt ook de periode waarin risico blijft bestaan bij configuraties die niet meebewegen.

Waarom deze zaak ook breder gaat dan één platform

Het Snowflake incident is groot door de schaal, maar de oorzaak is generiek: infostealers verzamelen credentials, vervolgens worden die maanden of jaren later misbruikt, en de schade wordt versneld door het ontbreken van moderne authenticatiemaatregelen.

Dat betekent dat de kernmaatregelen—credential hygiene, MFA die echt overal geldt en toegangsbeperkingen—niet alleen voor één leverancier gelden. Ze zijn universeel voor organisaties die werken met SaaS-omgevingen, dataplatformen en omgevingen waar een gecompromitteerd account snel kan leiden tot datalekken.

Conclusie: MFA én rotatie zijn geen “eenmalige” acties

Het schuldpleidooi in de zaak rond het Snowflake incident maakt duidelijk hoe groot de gevolgen kunnen zijn wanneer oude wachtwoorden lang geldig blijven en MFA niet is ingeschakeld. Er was geen doorbraak nodig in het platform; de aanvallers konden profiteren van al eerder verzamelde inloggegevens.

Wie dit incident als signaal gebruikt, doet er goed aan om wachtwoordrotatie en MFA-beleid te zien als doorlopende processen. Combineer dat met beperkingen in toegangs- en netwerkregels, zodat een gecompromitteerd account minder schade kan aanrichten—ook als credential exposure ooit eenmaal is gebeurd.

Bron: https://thehackernews.com/2026/08/snowflake-hacker-pleads-guilty-over.html