Credential stuffing-aanvallen gebruiken geautomatiseerde processen om lijsten met gestolen combinaties van gebruikersnamen en wachtwoorden te testen en zo ongeoorloofde toegang te krijgen tot websites en apps. Deze aanvallen kunnen miljoenen dollars aan schade veroorzaken. Deze tactiek slaagt deels omdat, hoewel gebruikers misschien worden gevraagd om een complexer wachtwoord te maken, wachtwoordcomplexiteitsbeleid geen rekening kan houden met mensen die dezelfde inloggegevens gebruiken op verschillende websites of diensten.

Hieronder gaan we dieper in op wat credential stuffing is, hoe het verschilt van brute force en password spraying, welke soorten fraude kunnen volgen op een succesvolle overname, en hoe je credential stuffing kunt stoppen door een gelaagde verdediging op te zetten.

Hoogtepunten

• Credential stuffing maakt misbruik van het hergebruik van wachtwoorden op verschillende accounts. Sterke wachtwoordbeleidsregels zijn op zichzelf niet effectief als verdediging tegen dit soort aanvallen.

• Software-as-a-service (SaaS) en kunstmatige intelligentie (AI)-platforms lopen risico op credential stuffing-aanvallen, waaronder account-overnames, misbruik van applicatieprogrammeerinterfaces (API's) en het misbruiken van gratis abonnementen.

• Effectieve verdediging vereist gelaagde botdetectie, screening op gecompromitteerde inloggegevens en gedeelde signalen tussen inlog-, aanmeldings- en API-eindpunten.

Wat is credential stuffing?

Credential stuffing is een cyberaanval waarbij criminelen gebruikersnaam- en wachtwoordcombinaties gebruiken die zijn gelekt bij eerdere datalekken en deze automatisch testen bij andere diensten. Dit werkt omdat het hergebruiken van wachtwoorden veel voorkomt. Studies tonen consequent aan dat veel mensen dezelfde inloggegevens voor meerdere accounts gebruiken, waarbij 72% van Gen Z aangeeft dat ze wachtwoorden hergebruiken.

Hoe werkt credential stuffing?

Aanvallers die credential stuffing gebruiken, halen lijsten met inloggegevens, ook wel “combo-lijsten” genoemd, uit databases met gelekte gegevens op criminele forums en darknet-marktplaatsen. Sommige van deze lijsten bevatten honderden miljoenen geverifieerde combinaties van gebruikersnamen en wachtwoorden. Ze laden deze lijsten in software die miljoenen inlogverzoeken kan versturen, CAPTCHA's (Completely Automated Public Turing tests to tell Computers and Humans Apart) kan verwerken, via proxy-IP-adressen kan rouleren en succes- of foutmeldingen kan analyseren.

Om simpele regels voor het beperken van het aantal verzoeken te omzeilen, versturen aanvallers deze inlogverzoeken vanaf duizenden verschillende adressen, vaak residentiële proxy's die lijken op legitiem gebruikersverkeer. Als een inlogpoging slaagt, markeert de tool dit. De aanvaller heeft nu een geverifieerd, werkend account en kan opgeslagen betaalmethoden, persoonlijke gegevens, API-toegang of accounttegoed eruit halen.

Waarin verschilt credential stuffing van brute force en password spraying?

Credential stuffing, brute force-aanvallen en password spraying zijn verwant, maar verschillen qua opzet. De juiste tegenmaatregel voor de ene houdt de andere niet per se tegen.

Hier volgt een overzicht:

• Brute force: een brute force-aanval probeert systematisch elke mogelijke wachtwoordcombinatie uit op een specifiek account. Het is rekenintensief, traag en grotendeels onpraktisch tegen webgebaseerde inlog-endpoints met een beleid voor accountvergrendeling.

• Password spraying: bij een password spraying-aanval worden één of enkele veelvoorkomende wachtwoorden (bijv. Password1!, Welcome2024) op een groot aantal accounts geprobeerd. Het is bedoeld om onder de blokkeringsdrempels per account te blijven en tegelijkertijd misbruik te maken van zwakke wachtwoordkeuzes. Wachtwoordbeleid kan voorkomen dat gebruikers deze veelvoorkomende wachtwoorden überhaupt gebruiken en is een nuttige tegenmaatregel.

• Credential stuffing: soms beschouwd als een subcategorie van brute force-aanvallen, voeren credential stuffing-aanvallen legitieme combinaties van gebruikersnamen en wachtwoorden in op onbeveiligde inlogpagina’s en nemen ze de controle over van alle accounts waar ze toegang toe krijgen. Standaard wachtwoordbeleidsregels helpen niet veel tegen credential stuffing, omdat ze niet kunnen voorkomen dat klanten wachtwoorden hergebruiken voor verschillende accounts.

Wat zijn de vroege waarschuwingssignalen van een credential stuffing-aanval?

Credential stuffing-aanvallen komen zelden voor als één dramatische piek. Ze zijn vaker zichtbaar als een langzame opeenstapeling van signalen.

Let op het volgende:

• Verhoogde percentages mislukte inlogpogingen bij alle accounts: een brute force-aanval leidt tot veel mislukkingen bij één account. Credential stuffing vertoont een gemiddeld percentage mislukkingen, verspreid over duizenden accounts tegelijk. Als je standaardpercentage mislukte inlogpogingen 2%–5% is en dit plotseling over de hele linie stijgt naar 15%–20%, dan is dat een reden voor onmiddellijk onderzoek.

• Een plotselinge toestroom van nieuwe IP-adressen: residentiële proxynetwerken genereren verzoeken vanaf adressen die er op reputatielijsten schoon uitzien. Maar een golf van IP-adressen die nog nooit eerder op je platform zijn geweest, is een belangrijk signaal in combinatie met inlogactiviteit.

• Ongebruikelijke geografische spreiding: inloggen die geclusterd zijn in regio’s die niet overeenkomen met de historische toegangspatronen van een account, kunnen wijzen op geautomatiseerde toegang.

• Consistente user-agent-strings in veel verzoeken: legitieme gebruikersgroepen vertonen enorme variatie in browser-vingerafdrukken. Bij credential stuffing-aanvallen komt dezelfde user-agent-string vaak voor in duizenden verzoeken, wat een patroon is dat de aandacht verdient.

• Een hoge verhouding tussen pogingen en successen: normale gebruikers falen een of twee keer, en slagen daarna of resetten hun account. Credential stuffing-tools slagen zelden, maar genereren veel pogingen per sessie.

• Onverklaarbare pieken in het volume bij het inlog-eindpunt: zelfs met IP-rotatie ziet het eindpunt zelf meer totale verzoeken tijdens credential stuffing-aanvallen. Een enorme toename zonder bijbehorende marketingactie of productlancering is een waarschuwingssignaal.

Waarom is credential stuffing gevaarlijk voor SaaS- en AI-platforms?

Aanvallers die credential stuffing gebruiken, controleren of inloggegevens werken om zo een verzameling toegangsgegevens op te bouwen. Zodra ze binnen zijn, kunnen ze nog meer schade aanrichten.

Als je een SaaS of AI-platform beheert, is dit wat je moet weten:

• Account-overname en gegevensdiefstal: zodra ze toegang hebben tot een klantaccount, kunnen aanvallers persoonlijke gegevens, betalingsgegevens, privébestanden of communicatie buitmaken. Als je platform gevoelige gegevens van een onderneming verwerkt, kan één gecompromitteerd account leiden tot blootstelling die verder reikt dan het oorspronkelijke doelwit van de aanvaller.

• Onmiddellijke inkomsten genereren met het account: aanvallers kunnen een gehackt account meteen leeghalen. Het account kan worden leeggehaald of gebruikt voor frauduleuze aankopen, of de inloggegevens kunnen worden doorverkocht op criminele forums.

• Fraude via opgeslagen betaalmethoden: accounts met opgeslagen betaalmethoden zijn zeer gewilde doelwitten. Aanvallers kunnen aankopen doen, tegoeden overmaken of uitbetalingen omleiden, wat directe financiële risico’s met zich meebrengt voor zowel het platform als de gebruikers.

• Fraude met nieuwe accounts: nadat ze hebben vastgesteld dat je platform toegankelijke waarde heeft, beginnen aanvallers vaak met het aanmaken van meer frauduleuze accounts. Gratis proefperiodes, aanmeldbonussen en API-toegang gekoppeld aan nieuwe accounts zijn allemaal doelwitten.

• Misbruik van gratis proefversies en het ‘farmen’ van gratis staffels: credential stuffing kan uitmonden in andere vormen van fraude. Aanvallers kunnen toegang tot gratis staffels op veel accounts afwisselen om gebruikslimieten te omzeilen. Dit is een groot financieel probleem voor AI-platforms, omdat het weggeven van API-aanroepen en inferentiekredieten het platform direct geld kost.

• API-misbruik: accounts op AI-platforms hebben doorgaans API-toegang en gebruiksquota. Aanvallers die accounts overnemen, kunnen die quota opgebruiken, toegang doorverkopen of de rekenkracht voor hun eigen doeleinden gebruiken. Dit alles zorgt voor infrastructuurkosten voor het platform.

• Ondersteuningslast: klanten van wie de accounts zijn gehackt, hebben veel ondersteuning nodig. Het resetten van wachtwoorden, fraudegeschillen en workflows voor accountherstel kosten tijd, geld en andere middelen.

• Reputatieschade: gebruikers van wie de accounts op jouw platform zijn gehackt, geven misschien jouw platform de schuld, ongeacht waar hun inloggegevens oorspronkelijk zijn gelekt.

Hoe kunnen platforms credential stuffing-aanvallen bestrijden zonder de inlogervaring te schaden?

Het voorkomen van credential stuffing-aanvallen is gebaseerd op meerdere verdedigingslagen, zodat elke laag de kosten van een aanval verhoogt. Hier zijn enkele van je opties.

Genuanceerde rate limiting

Als je algemene rate limiting per IP instelt, kunnen aanvallers dit omzeilen door middel van proxy-rotatie. Effectievere benaderingen beperken de snelheid per account (bijv. hoeveel mislukte pogingen heeft dit specifieke account in de afgelopen 10 minuten gehad?), apparaatvingerafdruk of gedragspatroon. Een combinatie is nog beter.

Botdetectie en verkeersanalyse

Implementeer een botmanagementoplossing die gedragssignalen analyseert (bijv. muisbewegingspatronen, toetsaanslagtiming, verzoekcadans, JavaScript-uitdagingsreacties). Tools zoals Cloudflare Bot Management of Akamai Bot Manager beoordelen het verkeer nog voordat het je authenticatielogica bereikt.

Screening op gecompromitteerde inloggegevens

Met het k-anonymity-model kunnen gebruikers controleren of hun wachtwoord is gecompromitteerd zonder het volledige wachtwoord te delen. Diensten zoals de Pwned Passwords-tool gebruiken dit om te controleren of het wachtwoord van een gebruiker voorkomt in bekende datasets van datalekken.

Voorwaardelijke meervoudige authenticatie (MFA)

Vraag niet bij elke aanmelding om MFA, maar bewaar de MFA-prompts voor afwijkende signalen. Als er een aanmeldingspoging komt vanaf een nieuw apparaat, uit een nieuw land of na een lange periode van inactiviteit van het account, is dat een goed moment om een tweede factor te vragen. Zo blijft de ervaring efficiënt voor regelmatige gebruikers, terwijl je mogelijke credential stuffing-scenario’s kunt opsporen.

Verplichte MFA voor belangrijke acties

Zelfs als je geen MFA vereist bij het inloggen, is het raadzaam om dit wel te doen voordat een gebruiker zijn e-mailadres kan wijzigen, een nieuwe betaalmethode kan toevoegen of toegang krijgt tot API-sleutels. Dit beperkt de schade als er toch een overname plaatsvindt.

Hoe Stripe Radar kan helpen

Stripe Radar gebruikt AI-modellen om fraude op te sporen en te voorkomen, getraind op basis van gegevens uit het wereldwijde netwerk van Stripe. Het werkt deze modellen steeds bij op basis van de nieuwste fraudetrends, zodat je onderneming beschermd blijft terwijl fraude zich ontwikkelt.

Stripe biedt ook Radar for Fraud Teams, waarmee gebruikers regels op maat kunnen toevoegen voor specifieke fraude scenario's voor hun bedrijf en toegang krijgen tot geavanceerde fraude- inzichten.
Radar kan je onderneming helpen met:

• Fraudeverliezen voorkomen: Stripe verwerkt jaarlijks meer dan $ 1 biljoen aan betalingen. Deze schaalgrootte stelt Radar in staat om fraude nauwkeurig op te sporen en te voorkomen, waardoor je geld bespaart.

• Omzet verhogen: de AI-modellen van Radar zijn getraind op basis van echte chargebackgegevens, klantinformatie, browsegegevens en meer. Hierdoor kan Radar risicovolle transacties identificeren en valse positieven verminderen, waardoor je omzet stijgt.

• Tijd besparen: Radar is ingebouwd in Stripe en hoeft niet te worden geconfigureerd. Je kunt ook je frauderesultaten monitoren, regels opstellen en meer op één platform, waardoor de efficiëntie toeneemt.

Lees meer over Stripe Radar of ga vandaag nog aan de slag.