Kort samengevat: credential stuffing detectie in-sessie versus na login
- Rate limiting per IP was het handboek van de sector, maar moderne aanvallen verspreiden 50.000 loginpogingen over 50.000 residentiële IP's, dus je logs zien één verzoek per adres en elke alertregel blijft stil.
- Gestolen inloggegevens drijven 39% van de breaches in het Verizon 2026 DBIR; cside's device fingerprint blijft stabiel bij incognito, VPN en cookie-wissen, afgeleid van meer dan 100 browsersignalen, zodat cross-account correlatie de aanvallersinfrastructuur blootlegt die IP-rotatie moest verbergen.
- Voor de volgende fraude-review: vraag of je login-stack afgaat op cross-account device-hergebruik, TLS-fingerprint-mismatch en mechanische form-fill-cadans, of alleen op IP-drempels die aanvallers jaren geleden stopten met triggeren.
Credential stuffing is lastig te betrappen omdat aanvallers loginpogingen met gestolen wachtwoorden nu verspreiden over tienduizenden roterende residentiële IP-adressen, waardoor rate limiting per IP elk adres maar één keer ziet. De signalen die nog werken, zijn de signalen die een aanvaller niet goedkoop kan rouleren: het apparaat achter de verzoeken en hoe de sessie zich gedraagt.
Drie van die signalen onthullen credential stuffing betrouwbaar. Het eerste is correlatie van device fingerprints tussen accounts, waarbij dezelfde device-identifier binnen een kort tijdsbestek opduikt bij loginpogingen op verschillende accounts. Het tweede is een nieuw apparaat op een bekend account, waarbij een geregistreerd account inlogt vanaf een device fingerprint die het nog nooit heeft gebruikt. Het derde is een afwijking in de netwerkcontext, waarbij een VPN- of proxyverbinding opduikt in een sessie die voorheen altijd vanaf een residentieel IP-adres kwam. Alle drie identificeren de infrastructuur en het gedrag van de aanvaller, ongeacht hoeveel IP-adressen hij doorloopt.
Waarom rate limiting per IP tegenwoordig het grootste deel van credential stuffing mist
Rate limiting per IP was een effectieve verdediging tegen credential stuffing toen aanvallen van een klein aantal servers kwamen. Dat tijdperk is voorbij.
Moderne credential stuffing-operaties gebruiken residentiële proxynetwerken die bij elk verzoek van IP-adres wisselen. Een aanvaller die 50,000 loginpogingen uitvoert, verspreidt ze over 50,000 verschillende residentiële IP-adressen. Je rate limiter ziet elk IP precies één keer en onderneemt geen actie, want een enkele loginpoging vanaf een willekeurig IP is niet te onderscheiden van normaal verkeer.
De aanval slaagt. De accounts zijn gecompromitteerd. Het enige bewijs in je serverlogs is een marginaal verhoogd aantal loginpogingen met een geografische spreiding die organisch gebruikersgedrag nabootst.
Detectie vereist een overstap naar signalen die de aanvaller niet goedkoop kan rouleren. Gestolen inloggegevens zijn betrokken bij 39% van alle datalekken (Verizon Data Breach Investigations Report 2026); ze bij de loginlaag tegenhouden voordat er schade is aangericht, betekent dus vertrouwen op signalen die IP-rotatie overleven.
Signaal 1: correlatie van device fingerprints tussen accounts
Een device fingerprint is een stabiele identifier die is afgeleid van browsersignalen: canvas-entropie, kenmerken van fontrendering, WebGL-output, audiocontext, timingpatronen en headless-browservlaggen. Anders dan een IP-adres kan een device fingerprint niet worden veranderd door verbinding te maken met een andere proxy. De browseromgeving van de aanvaller blijft consistent over alle verzoeken.
Wanneer device-ID X binnen een venster van 30 minuten probeert in te loggen op accounts A, B, C, D en E, is dat een credential stuffing-aanval. Elke afzonderlijke poging kan op zichzelf legitiem lijken: correct wachtwoordformaat, kloppende geolocatie, redelijke timing. De correlatie tussen accounts onthult dat één stuk infrastructuur achter alle vijf de pogingen zit.
Dit is het signaal dat detectie per IP volledig mist. De aanvaller rouleert IP's. De device fingerprint blijft hetzelfde.
Om dit te implementeren, log je de device fingerprint bij elke loginpoging en doorzoek je vervolgens de pogingen om device-ID's te vinden die binnen een tijdsvenster op meer dan een drempelaantal verschillende accounts verschijnen. Eén apparaat dat binnen een uur meer dan drie verschillende accounts raakt, is een signaal met hoge zekerheid. Eén apparaat dat binnen dertig minuten tien accounts raakt, is nagenoeg zeker.
Signaal 2: een nieuw apparaat op een bekend account
Een nieuwe, onbekende device fingerprint die probeert in te loggen op een al lang bestaand account is een signaal met hoog risico, zelfs wanneer het juiste wachtwoord wordt ingevoerd. Een account dat altijd vanaf dezelfde device fingerprint heeft ingelogd, draagt een impliciete verwachting: toekomstige logins komen van die fingerprint of van een met een hoge gelijkeniscore.
Wanneer device-ID 456 probeert in te loggen op een account dat twee jaar lang uitsluitend device-ID 123 heeft gebruikt, behandel het dan als hoog risico, ook als het wachtwoord klopt. De kans dat de legitieme gebruiker precies op het moment dat een aanvaller ook zijn wachtwoord heeft, is overgestapt op een volledig nieuwe browseromgeving, is klein.
Het signaal wordt aanzienlijk sterker in combinatie met netwerkcontext. Een nieuw, onbekend apparaat dat probeert in te loggen met een datacenter-VPN actief, op een account dat alleen ooit vanaf residentiële IP's verbinding heeft gemaakt, is de sterkste individuele aanwijzing van een gerichte accountovername via credential stuffing.
Deze detectie vereist een apparaatgeschiedenis per account. Log de device fingerprint bij elke geslaagde authenticatie. Wanneer een nieuwe fingerprint verschijnt op een waardevol of al lang bestaand account, markeer het dan voor step-up-authenticatie of blokkeer het in afwachting van verificatie.
Device fingerprints moeten stabiel blijven in de scenario's die aanvallers gebruiken om hun identiteit te verhullen. De fingerprint van cside houdt met hoge nauwkeurigheid stand bij incognitomodus, VPN-verbindingen en het wissen van cookies, afgeleid van meer dan 100 browsersignalen per sessie. Een aanvaller die cookies wist en via een VPN verbinding maakt, produceert nog steeds dezelfde device fingerprint.
Signaal 3: netwerkcontext plus sessiecadans
Het combineren van VPN- en proxydetectie met een gescripte sessiecadans levert het credential stuffing-oordeel met de hoogste zekerheid op, omdat beide signalen elk afzonderlijk moeilijk te vervalsen zijn en samen nagenoeg doorslaggevend.
Met residentiële proxynetwerken kunnen aanvallers door echte thuis-IP-adressen rouleren om geografische en op IP-reputatie gebaseerde filtering te omzeilen. De verbindingskenmerken van een residentieel proxyverzoek verschillen nog steeds van een echte residentiële verbinding. TLS handshake fingerprint TLS-fingerprinting analyseert de parameters van de TLS-handshake, waaronder de volgorde van cipher suites en de aanwezigheid van extensies, om via een proxy doorgestuurde verbindingen te onderscheiden van directe residentiële verbindingen.
Een account dat drie jaar lang verbinding heeft gemaakt vanaf een echt residentieel IP-adres in het VK en dan plotseling een TLS-fingerprint vertoont die past bij proxy-relay, is een afwijking in de netwerkcontext. Op zichzelf verdient dat aandacht. In combinatie met een gescripte sessiecadans is het nagenoeg zeker bewijs van een geautomatiseerde aanval.
Gescripte credential stuffing produceert loginpogingen met onmenselijk hoge snelheden of met mechanisch gelijkmatige intervallen. Een mens typt zijn inloggegevens met natuurlijke variatie in de tijd tussen toetsaanslagen, pauzes tussen velden en onregelmatige interactie met het formulier. Een script vult velden onmiddellijk of met precies getimede intervallen. cside meet deze cadans als onderdeel van zijn sessie-evaluatie.
Een sessie die TLS-kenmerken vertoont die passen bij een proxy en een mechanische cadans bij het invullen van het formulier, op een account zonder geschiedenis van proxyverbindingen, is met zeer hoge zekerheid een credential stuffing-poging.
Hoe cside deze signalen teruggeeft
cside evalueert elke sessie en geeft een realtime oordeel terug waarvan de waarden rechtstreeks aansluiten op de drie detectiesignalen hierboven.
Het geeft een stabiele device fingerprint-identifier terug. Log die bij elke loginpoging en doorzoek hem vervolgens over pogingen heen om correlatie tussen accounts te vinden (Signaal 1) en toets hem aan de geschiedenis per account om een nieuw, onbekend apparaat te herkennen (Signaal 2).
Het geeft een VPN- en proxyvlag terug, die wordt gezet wanneer de sessie verbinding maakt via een VPN, datacenterproxy of residentiële proxy-relay die is gedetecteerd met TLS handshake fingerprint TLS-fingerprinting. Combineer die met de accountgeschiedenis om afwijkingen in de netwerkcontext te identificeren (Signaal 3).
Het geeft een sessiecadansscore terug die kwantificeert hoe nauw de interactietiming van de sessie overeenkomt met menselijke patronen. Een lage cadansscore samen met een actieve proxyvlag sluit rechtstreeks aan op het derde signaal.
Door deze waarden te combineren, vang je credential stuffing-aanvallen die onzichtbaar zouden zijn voor rate limiting per IP, een botscore alleen of welke aanpak met één enkel signaal dan ook.
Detectie versus preventie
Detectie vertelt je dat er een credential stuffing-aanval gaande is. Preventie voorkomt dat die slaagt.
Zodra je met de drie signalen hierboven een actieve aanval hebt geïdentificeerd, heb je verschillende opties: de device fingerprint blokkeren voor verdere loginpogingen, step-up-authenticatie vereisen voor getroffen accounts, alle sessies ongeldig maken die tijdens het aanvalsvenster zijn opgezet, en getroffen gebruikers waarschuwen om hun wachtwoord opnieuw in te stellen.
De detectiesignalen die hier worden beschreven, zijn de input. Je applicatielogica, fraude-orchestratielaag of WAF bepaalt de reactie.
Voor een complete aanpak om credential stuffing te stoppen zodra het is gedetecteerd, zie de gids van cside over het begrijpen en stoppen van credential stuffing-aanvallen, de pagina over device fingerprinting-oplossingen voor hoe deze signalen in een volledige stack passen, en de use case voor accountovername voor waar ze passen in een ATO-verdediging.
