Samenvatting: credential harvesting
- Harvesting versus stuffing: harvesting is hoe aanvallers geldige inloggegevens bemachtigen. Stuffing is wat daarna komt. Andere signalen, andere detectiestack.
- De blinde vlek van MFA: standaard-MFA stopt de vier dominante technieken niet: phishingpagina's, AiTM-proxy's à la Evilginx, gecompromitteerde externe scripts en infostealer-malware.
- Je eigen loginpagina: je slechtst verdedigde oppervlak is je eigen loginpagina. Een gecompromitteerd extern script leest het formulier terwijl je gebruiker typt, en servercontroles zien het nooit.
Weinig tijd? Bekijk cside's detectie van accountovername. Die dekt alles hieronder in één implementatie.
Credential harvesting is geen credential stuffing (en dat verschil telt)
Stel dat een fraudeleverancier zegt dat hij «aanvallen op inloggegevens stopt». Vraag dan welke helft: harvesting of stuffing. Kan hij dat niet helder beantwoorden, dan verkoopt hij je ratelimiting vermomd als dreigingsplatform.
Harvesting zit bovenaan de trechter. Aanvallers verzamelen geldige inloggegevens. Stuffing zit onderaan. Aanvallers proberen die inloggegevens op doelsites. Eén harvestingoperatie voedt duizenden stuffingcampagnes. Eén gestolen inloggegeven kan bij elke webwinkel op internet worden getest.
De detectiesignalen verschillen:
- Harvesting verschijnt op JOUW site als verdachte scriptactiviteit op de loginpagina, of als data-exfiltratie naar een onbekend extern domein.
- Stuffing verschijnt op JOUW site als massale inlogpogingen, IP-snelheid en verspreide, trage patronen.
Ratelimiting stopt stuffing. Aan harvesting raakt het niet. Als je enige verdediging tegen aanvallen op inloggegevens een ratelimit op /api/login is, vang je de tweede helft van de aanval en laat je de eerste helft ongehinderd doorgaan.
Vier harvestingtechnieken uit 2026 die je MFA niet stopt
1. Phishingpagina's (nog altijd de belangrijkste aanvalsvector)
Aanvallers registreren een gelijkend domein (zie ons artikel over homoglief-aanvallen voor de truc met Cyrillische tekens), klonen de HTML van je login en sturen verkeer via sms of e-mail. De gebruiker typt zijn wachtwoord op een pagina die identiek is aan de jouwe. Het inloggegeven gaat naar de aanvaller.
Standaard-MFA verlaagt de waarde van het gestolen wachtwoord, maar niet tot nul. Hergebruikt de gebruiker dat wachtwoord elders (ongeveer 65 % doet dat, blijkt uit elk onderzoek naar hergebruik), dan heeft de aanvaller net toegang gekregen tot diens mail, bank of SaaS-omgeving.
2. Adversary in the middle à la Evilginx (AiTM)
Evilginx is een opensource phishingframework dat een reverse proxy draait tussen het slachtoffer en de echte loginpagina. Het slachtoffer typt zijn wachtwoord. Evilginx stuurt het door naar de echte site. De echte site geeft de MFA-prompt terug. Het slachtoffer lost de MFA op. Evilginx stuurt dat door. De echte site geeft de sessiecookie terug. Evilginx steelt de sessiecookie.
Dit verslaat MFA via TOTP, sms-OTP en pushmelding. Het verslaat geen passkeys of FIDO2-hardwaresleutels, want die binden zich cryptografisch aan het origin-domein en weigeren te authenticeren voor een geproxyde site.
Zit je gebruikersbestand in 2026 niet op phishingbestendige MFA, dan zijn aanvallen van de Evilginx-klasse spotgoedkoop voor aanvallers. Het framework is opensource, de phishingsjablonen zijn massagoed en de opbrengst is het omzeilen van elke MFA-implementatie die geen FIDO2 is.
3. Gecompromitteerd extern script op je eigen loginpagina
Dit is degene die de meeste verdedigingen missen. Je loginpagina is schoon. Je servercode is schoon. Je certificaten zijn geldig.
Maar je loginpagina laadt scripts. Google Tag Manager. Een chatwidget. Analytics. A/B-tests. Elk daarvan, of elk van hun transitieve afhankelijkheden, kan door de eigenaar worden bijgewerkt zonder dat jij het hoort. Raakt er één gecompromitteerd, hetzij door een supplychain-aanval als Polyfill[.]io (ruim 490.000 getroffen sites in 2024), hetzij door een gewijzigde regel in de tagmanager, dan draait dat script voortaan in dezelfde JavaScript-context als je loginformulier.
Het kan de formuliervelden uitlezen. Het kan een listener aan het submit-event hangen. Het kan de inloggegevens naar een door de aanvaller beheerd domein sturen nog voordat je login-endpoint het verzoek ziet.
Je WAF ziet dit niet. Je serverlogs zien dit niet. Je SIEM ziet dit niet. De enige plek waar de exfiltratie zichtbaar is, is binnen de browsersessie van de bezoeker, op het moment dat het gebeurt.
4. Infostealer-malware op het apparaat van de gebruiker
Infostealers als RedLine, Raccoon en LummaC2 halen opgeslagen wachtwoorden uit browsers, cookies uit lokale sessieopslag en MFA-tokens uit authenticatie-apps. Eenmaal geïnstalleerd op het apparaat van een slachtoffer draaien ze continu en sturen ze de verzamelde inloggegevens naar de infrastructuur van de aanvaller.
Deze aanval kun je niet vanaf jouw kant van de lijn stoppen. Wat je WEL kunt doen, is het gebruik verderop detecteren: een authenticatie die slaagt vanaf een apparaatvingerafdruk of geografische herkomst die niet strookt met de historie van het account.
De dataset die aanvallers in 2026 echt gebruiken
RockYou2024 is het referentiecorpus. Gepubliceerd medio 2024 bevat het ongeveer 10 miljard unieke wachtwoorden in platte tekst. Een samenvoeging van elke noemenswaardige eerdere lekcompilatie, ontdubbeld en genormaliseerd. Elke eerdere compilatie (Collections #1 tot en met #5, Pwned Passwords van Have I Been Pwned, de diverse «COMB»-lekken) is er een deelverzameling van.
Aanvallers gooien geen 10 miljard inloggegevens tegen je login aan. Dat zou elke ratelimit laten afgaan. Wat ze doen, is:
- Filteren op inloggegevens die bij jouw domein horen (via de metadata van het bronlek)
- Filteren op inloggegevens uit de laatste 24 maanden (grotere kans dat ze nog geldig zijn)
- Filteren op wachtwoorden die basale sterkteheuristieken doorstaan (aanvallers gaan ervan uit dat de gebruiker een «echt» wachtwoord hergebruikte, geen
password123) - De gefilterde deelverzameling in trage, verspreide batches testen vanaf residentiële IP's
Daarom helpt IP-reputatie je niet bij het vangen van moderne credential stuffing. Het IP is dat van een residentiële provider. De snelheid per IP is 2 à 3 pogingen per uur. Alleen correlatie over accounts heen vangt dit.
Wat credential harvesting daadwerkelijk detecteert
Vier signaalbronnen, op volgorde van rendement.
1. Monitoring van je loginpagina binnen de sessie
De enige verdediging die techniek nummer drie (gecompromitteerd extern script) vangt, is kijken wat scripts werkelijk uit het loginformulier lezen in de browsersessie van een echte gebruiker. Dat is wat het client-side beveiligingsplatform van cside doet. Een first-party sensor observeert DOM-uitlezingen, toegang tot formuliervelden en uitgaand netwerkverkeer in elke echte sessie, en markeert elk script dat de velden met inloggegevens aanraakt zonder op de toegestane lijst te staan.
Dit bouw je niet zelf als eenmalige exercitie. Je hebt continue observatie over elke echte sessie nodig, want de aanvaller activeert de exfiltratie maar bij een deel van de bezoekers (gerichte regio, gerichte browser, gericht accounttype) om detectiescanners te ontlopen.
2. Apparaatintelligentie bij het inloggen
Bereken bij het login-endpoint een apparaatvingerafdruk op basis van browserattributen, TLS- of JA-vingerafdruk en gedragscadans. Vergelijk die met de apparaathistorie van het account. Een nieuw apparaat uit een nieuwe regio dat probeert te authenticeren is een sterk signaal dat er iets mis is, of dat nu van een AiTM à la Evilginx komt of van een verse infostealer-buit.
Onze introductie in apparaatintelligentie loopt de signaalstack door. Kort gezegd: meer dan 40 browserattributen samengevoegd tot een stabiele apparaat-ID die het wissen van cookies en privévensters overleeft.
3. Have I Been Pwned-controle bij het inloggen (of beter, bij registratie)
Have I Been Pwned publiceert een range-lookup-API waarmee je kunt controleren of een wachtwoord in een bekend lekcorpus voorkomt zonder het echte wachtwoord te versturen (via een SHA-1-prefix met k-anonimiteit). Dit hoort een stap te zijn in elke loginstroom boven een bepaalde risicoscore.
Authenticeert een gebruiker met een wachtwoord dat in RockYou2024 voorkomt, behandel dat dan als prima facie bewijs van harvesting. Forceer een wachtwoordreset en schaal bij de volgende login op naar phishingbestendige MFA.
4. Correlatie over accounts heen
Het betrouwbaarste signaal is dat hetzelfde apparaat, dezelfde vingerafdruk of hetzelfde gedragspatroon binnen een kort tijdsbestek probeert te authenticeren op meerdere accounts van je platform. Ratelimiting per account mist dit. Ratelimiting per IP mist het ook, want residentiële proxy's wisselen elke 30 seconden. Alleen correlatie van apparaatsignalen vangt het.
Waar MFA nog wel helpt (en waar niet)
Phishingbestendige MFA (WebAuthn, FIDO2-hardwaresleutels, passkeys) stopt de phishingpagina en de Evilginx-gevallen daadwerkelijk. Zit je gebruikersbestand er eind 2026 niet op, dan houd je een anachronisme in stand.
Maar phishingbestendige MFA helpt niet tegen:
- Een gecompromitteerd extern script op je eigen loginpagina (het script leest het wachtwoordveld ongeacht het MFA-type)
- Infostealer-malware op het apparaat van de gebruiker (de malware exfiltreert de passkey-seed of de sessiecookie ná authenticatie)
- Correlatie-aanvallen over accounts heen (het inloggegeven is al geldig; MFA bij de eerste login is niet het knelpunt)
Gelaagde detectie (MFA plus monitoring binnen de sessie plus apparaatintelligentie plus HIBP-controle) is wat de vier gaten dicht. Geen enkele losse maatregel doet dat.
Wat we zeggen tegen wie vraagt of cside «weer een MFA-leverancier» is
Dat zijn we niet. MFA is wat er gebeurt op je login-endpoint. cside is wat er gebeurt in de browsersessie, in de zeven seconden tussen het typen van het wachtwoord en het indrukken van verzenden. Wij zien de scripts die het formulier uitlezen. Wij zien de uitgaande netwerkaanroepen. Wij zien de exfiltratiepogingen die je serverlogs nooit bereiken.
Stopt je verdediging bij het login-endpoint, dan zie je techniek nummer drie niet. Dat geldt voor ruwweg 90 % van de e-commerce-, fintech- en SaaS-logins in 2026. Los dat op en je dicht het grootste onderbelichte gat in de aanvalsketen op inloggegevens.
Gerelateerde artikelen
- Credential stuffing: zo detecteer en stop je het bij de login
- Wat is device fingerprinting: de definitieve gids voor 2026
- Fraudepreventie bij accountovername: de complete gids voor 2026
- Hoe Polyfill[.]io 490.000 sites compromitteerde (supplychain-aanval via de browser)
- Homoglief-aanvallen: het аpple.com-probleem
