Reverse Engineering een Account Checker: Hoe cybercriminelen gestolen credentials valideren

Credential stuffing is een van de meest voorkomende aanvalsmethoden van 2026. Cybercriminelen gebruiken databases met gelekte gebruikersnamen en wachtwoorden om toegang te krijgen tot accounts bij populaire diensten. Maar hoe weten ze welke credentials nog geldig zijn? Daarvoor gebruiken ze geautomatiseerde "checker tools".

Wij analyseerden zo'n tool om te zien welke bekende aanvalstechnieken in de praktijk worden toegepast. In dit artikel delen we onze bevindingen en, belangrijker nog, hoe je jouw organisatie ertegen beschermt.

Wat is een Account Checker?

Een account checker is software die automatisch probeert in te loggen bij online diensten met lijsten van gestolen credentials. Deze tools worden dagelijks ingezet om:

• Accounts te valideren: Welke e-mail/wachtwoord-combinaties werken nog?
• Account details te extraheren: Welk abonnement heeft deze gebruiker? Zijn er betaalgegevens opgeslagen?
• Waarde te bepalen: Premium accounts leveren aanzienlijk meer op de zwarte markt.

De tool die wij analyseerden richtte zich specifiek op streamingdiensten, maar de onderliggende technieken worden breed toegepast in vrijwel elke sector.

De Anatomie van de Tool

Bij het reverse engineeren van de checker ontdekten we een architectuur die opviel door een mix van slimme applicatielogica en een verrassend gebrek aan operationele veiligheid (OpSec). De tool leunde op vier belangrijke pijlers:

• Multi-threading met SemaphoreSlim: De applicatie, geschreven in C#, gebruikt SemaphoreSlim om concurrent requests te beheren. Dit is een lichtgewicht synchronisatiemechanisme dat perfect geschikt is voor I/O-intensieve operaties, zoals HTTP-verzoeken. Hierdoor kan de tool honderden accounts razendsnel tegelijk valideren, zonder threads te verspillen of het eigen systeem te laten crashen.
• GraphQL als Target: Alle validatieverzoeken gaan direct naar een GraphQL-endpoint in plaats van een traditioneel REST- of web-endpoint. Dit is een zeer tactische keuze: GraphQL-endpoints retourneren vaak sterk gestructureerde data en zeer gedetailleerde foutmeldingen. Een typische response zegt niet simpelweg "Login failed", maar verraadt exact waarom (bijv. verkeerd wachtwoord versus account bestaat niet). Dit maakt het sorteren van gestolen data veel efficiënter.
• Header-based Fingerprinting: Om beveiligingssystemen te misleiden, gebruikt elk request identieke, zorgvuldig gekozen headers om een legitieme client na te bootsen. De User-Agent, Accept-Language en specifieke applicatie-versies zijn statisch en exact overgenomen van de officiële apps.
• De Fatale Fout (Geen Proxy-rotatie): Wat deze specifieke aanval opmerkelijk maakte, was het netwerkgedrag. Er werden in dit geval geen proxy's gebruikt. Ondanks de geavanceerde technieken om op applicatieniveau als een legitieme app te lijken, kwamen alle duizenden requests vanaf exact hetzelfde IP-adres. Dit maakte de aanval uiteindelijk zeer kwetsbaar voor eenvoudige detectie en toch kon alles doorheen.

Eenvoud als Kracht

Wat tijdens de analyse direct opviel, was de eenvoud van de implementatie. Geen complexe obfuscatie, geen geavanceerde anti-debugging technieken en geen custom protocol-implementaties. Gewoon doeltreffende C#-code. Dit toont aan dat aanvallers geen diepgaande malwarekennis nodig hebben om effectieve tools te bouwen; standaard programmeerpatronen, een GraphQL client library en basiskennis van concurrency zijn al genoeg.

API Misbruik Patronen: De Kern van het Probleem

Het interessantste aspect was hoe de tool legitieme API's misbruikt. De code bevatte geen complexe exploits of zero-days, maar vertrouwde simpelweg op het slim bespelen van openbare interfaces.

Patroon 1: Endpoint Shopping

De tool probeert niet in te loggen via de normale webinterface. In plaats daarvan zoekt (en gebruikt) het mobiele API-endpoints die:

• Minder rate limiting hebben: Mobiele apps moeten bij een slechte verbinding soepel blijven werken, waardoor de limieten vaak ruimer zijn ingesteld.
• Eenvoudigere authenticatie vereisen: Vaak ontbreken CAPTCHA's of complexe multi-factor authenticatie (MFA) flows.
• Meer informatie teruggeven: API-responses bevatten soms extra metadata over de gebruiker die de webinterface niet direct toont.

Patroon 2: Session Recycling

In plaats van voor elke check een nieuwe, verdachte sessie te starten, hergebruikt de tool sessies op een manier:

1. Start een sessie met valide device ID.
2. Gebruik dat actieve sessietoken om tientallen andere credential-sets te testen.
3. Roteert niet, als het geen sessie kan maken dan stopt het, dan moet de gebruiker IP veranderen.

Dit gedrag lijkt in de logs op een normale gebruiker die door een app navigeert, terwijl het in werkelijkheid een geautomatiseerde validatiemachine is.

Patroon 3: Timing Randomization

De tool imiteert menselijk gedrag om te voorkomen dat het opvalt in logbestanden door:

• Variabele vertragingen tussen requests (bijv. willekeurig 2 tot 8 seconden in plaats van exact 5).
• Pauzes na mislukte inlogpogingen (alsof de gebruiker nadenkt of het wachtwoord opnieuw intypt).
• Ingebouwde "idle" periodes waarin niets gebeurt.

Patroon 4: Client Spoofing (Response Mimicry)

De tool doet er alles aan om qua dataverkeer niet te onderscheiden te zijn van de officiële software. Zelfs de specifieke applicatie-headers worden minutieus nagemaakt in de code. In het geval van de geanalyseerde streaming-checker zagen we bijvoorbeeld hoe de tool zich voordeed als een legitieme Disney+ webclient via de volgende C#-implementatie:

req.Headers.Add("x-bamsdk-client-id", "disney-svod-3d9324fc");
req.Headers.Add("x-bamsdk-platform", "javascript/windows/chrome");
req.Headers.Add("x-bamsdk-platform-id", "browser");
req.Headers.Add("x-bamsdk-version", "35.2");

Door deze specifieke BAM SDK (de onderliggende streamingtechnologie van o.a. Disney) headers exact te injecteren, accepteert de API het verzoek klakkeloos als afkomstig van een normale Chrome-browser op een Windows-machine. De makers van deze tools analyseren regelmatig webverkeer en updates van officiële apps om hun "fingerprint" actueel en geloofwaardig te houden.

Hoe Bescherm Je Jouw Organisatie?

De technieken van deze checker zijn uiterst effectief, maar niet onverslaanbaar—zeker niet als aanvallers fouten maken zoals het niet roteren van IP-adressen. Hier zijn concrete maatregelen om je te wapenen tegen dergelijke tools:

1. Gedragsanalyse boven (uitsluitend) Rate Limiting Hoewel het gebrek aan proxy's deze specifieke tool kwetsbaar maakte voor traditionele rate limiting (bijv. "max 5 logins per minuut per IP"), gebruiken de meeste geavanceerde tools wél proxy's. Focus daarom op gedrag:

• Login velocity: Hoeveel unieke accounts proberen in te loggen vanaf verschillende IP's binnen een specifiek tijdsvenster?
• Credential reuse: Zien we hetzelfde e-mailadres bij meerdere van onze diensten binnen korte tijd pogen in te loggen?
• Device fingerprinting: Blijven de unieke "device IDs" wel consistent, of wisselt het IP constant bij hetzelfde apparaat?

2. Multi-Factor Authenticatie als Standaard MFA vernietigt het verdienmodel van credential stuffing. Zelfs als een e-mail en wachtwoord geldig blijken via een checker, strandt de aanvaller bij de tweede factor. Maak MFA verplicht voor nieuwe accounts en stimuleer adoptie bij bestaande gebruikers met incentives, zoals extra functionaliteiten of opslagruimte.

3. Breached Password Protection Controleer tijdens de registratie en bij wachtwoordwijzigingen of het gekozen wachtwoord voorkomt in bekende datalekken. Gebruik hiervoor diensten met veilige API's (zoals HaveIBeenPwned). Dwing de gebruiker een ander wachtwoord te kiezen als het gelekt is, zelfs als het technisch voldoet aan je lengte- en complexiteitseisen.

4. Anomaliedetectie op API-niveau Monitor niet alleen je webomgeving, maar specifiek je API's (en dan met name de GraphQL en mobiele/SDK endpoints):

• Endpoint usage patterns: Wordt een specifiek endpoint plotseling intensief aangeroepen met identieke SDK-versies?
• Error rate spikes: Zien we een golf van 401 Unauthorized responses en specifieke GraphQL error payloads?
• Version skew: Blijft een abnormaal groot aantal clients plotseling vasthouden aan exact versie 35.2 (de hardcoded versie in de checker tool), terwijl de rest van je legitieme gebruikers de web-update al heeft ontvangen?

5. Proactieve Gebruikersnotificatie Betrek je gebruikers bij de beveiliging door notificaties te sturen bij:

• Meerdere mislukte inlogpogingen achter elkaar.
• Een succesvolle login vanaf een onbekend apparaat of een afwijkende geografische locatie.
• Gelijktijdige logins vanaf locaties die onmogelijk tegelijk bereisd kunnen zijn.

Conclusie

Onze analyse van deze checker bevestigt dat moderne cyberaanvallen lang niet altijd technisch hoogstaand of buitengewoon complex hoeven te zijn. Ze teren op de menselijke gewoonte van wachtwoordhergebruik, het blootleggen van de juiste data via GraphQL, en de aanname dat correcte HTTP-headers (zoals een BAM SDK payload) gelijkstaan aan een legitieme gebruiker.

De belangrijkste inzichten om mee te nemen:

1. API's zijn vaak de zwakste schakel: Mobiele en GraphQL-endpoints ontsnappen te vaak aan de strenge security scrutiny die web-omgevingen wel krijgen.
2. Detectie vergt context: Eén enkel verzoek met perfect gespoofte headers ziet er volkomen legitiem uit; pas als je naar het grotere netwerk- of gedragspatroon kijkt, verraadt de aanval zich.
3. Security is een productbeslissing: Gebruikerservaring en veiligheid sluiten elkaar niet uit, mits intelligent geïmplementeerd.