Phishing wordt slimmer. Niet alleen omdat aanvallers geloofwaardige pagina’s maken, maar ook omdat ze verdediging rond herstelmaatregelen kunnen omzeilen. Een voorbeeld is iAuthFlow V2, een phishingtoolkit waar onderzoekers naar keken op basis van openbare informatie van de verkoper. De kern: passkeys in phishing kunnen zorgen dat een wachtwoordreset niet genoeg is.
Omdat de analyse in grote lijnen is gebaseerd op berichten en demo’s van de aanbieder (en niet op het daadwerkelijk uitvoeren van malware), moeten conclusies met enige voorzichtigheid worden gelezen. Tegelijk laat het scenario zien waar het heen kan: aanvallen die niet stoppen wanneer een gebruiker “standaard” herstelt.
Wat is iAuthFlow V2?
iAuthFlow V2 is volgens de beschikbare beschrijving een geavanceerde phishingtoolkit die “persistent access” kan bieden aan een slachtoffer. Met andere woorden: zelfs als iemand het wachtwoord wijzigt, kan de aanvaller mogelijk opnieuw inloggen via een andere vorm van authenticatie.
De toolkit zou eerder zijn gesignaleerd op een Russische cybercrimecommunity. Op basis van onderzoek van Abnormal wordt de werking vooral verklaard aan de hand van een specifieke module die draait rond passkeys. De toolkit wordt bovendien als commercieel verkocht, met extra onderdelen als los aan te schaffen modules.
De aanval in hoofdlijnen
De phishing start zoals je bij een traditionele aanval zou verwachten. Het doelwit wordt naar een pagina geleid die in de browser draait en waar de gebruiker credentieel-invoer doet. Om de gebruiker te laten slagen, moet het slachtoffer de juiste gegevens invoeren en het verzoek tot authenticatie goedkeuren.
Het verschil zit volgens de analyse in de manier waarop de aanvaller die interactie afhandelt. De aanvaller gebruikt een tweede, verbonden browseromgeving op zijn eigen server. Daardoor lijkt het alsof het slachtoffer met de echte dienst communiceert, terwijl de antwoorden in werkelijkheid via die tweede omgeving worden afgehandeld.
Onderzoekers beschrijven ook dat iAuthFlow V2 een device fingerprint zou toepassen op de browsersessie van het slachtoffer. Vervolgens worden invoer en authenticatiestappen gelogd en doorgestuurd naar die externe omgeving.
Waarom is een wachtwoordreset niet genoeg?
Bij een phishingcompromis geldt voor veel gebruikers een vast herstelpad: wachtwoord wijzigen en actieve sessies intrekken. Dat is ook logisch, omdat een aanvaller vaak afhankelijk is van gestolen token(s) of sessiecookie(s).
Bij iAuthFlow V2 draait het scenario echter om iets anders: de aanvaller zou geen “wachtwoord-afgeleide” toegang nodig hebben. In plaats daarvan wordt een passkey klaar gezet en gekoppeld aan het account. Een passkey is een credential die aan het account is geregistreerd. Als die registratie tot stand komt tijdens het phishingproces, dan blijft die credential bestaan, ook nadat een gebruiker het wachtwoord wijzigt.
Volgens de redenering van Abnormal kan een standaard reactie—zoals wachtwoordreset en sessierevocatie—dus wel de sessies van de aanvaller afsnijden, maar niet per se de nieuw toegevoegde passkey neutraliseren. Daardoor kan de aanvaller bij later inloggen “een andere manier” kiezen en alsnog toegang krijgen.
Hoe past dit in de bredere ontwikkeling van phishing?
Wat dit geval benadrukt, is dat sociale engineering steeds vaker “meebeweegt” met moderne authenticatie. Waar aanvallers vroeger vooral mikten op wachtwoorden, zien we dat ze proberen om het authenticatieproces zelf te sturen—zodat de uitkomst (een extra credential, een goedgekeurde sessie, een nieuwe registratie) voor hen bruikbaar blijft.
Daar komt bij dat passkeys een element zijn dat voor veel organisaties nog relatief nieuw is in beheer en incidentrespons. Als je proces vooral is ingericht op “wachtwoord kwijt = toegang kwijt”, dan kan een credential die niet direct door het wachtwoord wordt gegenereerd, buiten bereik vallen.
Als je meer wilt lezen over hoe phishing en omzeilingstechnieken zich ontwikkelen, sluit dit inhoudelijk aan bij artikelen over geavanceerde phishing-aanpakken, zoals Phishing 3.0: van e-mailscans naar agent-gedreven aanval. Die link helpt je breder te kijken naar de verschuiving van enkel “lokken” naar “automatiseren en doorzetten”.
Wat moet je doen als er phishing is vastgesteld?
Op basis van het iAuthFlow V2-scenario is het advies vooral: herstelacties moeten verder gaan dan alleen het wachtwoord. De precieze stappen hangen af van je identity provider en je beleid, maar het uitgangspunt blijft hetzelfde.
1) Beperk de impact direct
Naast een wachtwoordwijziging is het belangrijk om actieve sessies te beëindigen en eventuele sessiecookies te intrekken. Dit voorkomt vaak dat aanvallers blijven doorwerken op bestaande sessies.
2) Kijk breder dan tokens
Omdat de kern van het probleem in de analyse rond passkeys ligt, moet je incidentrespons ook rekening houden met credentials die tijdens het phishingmoment zijn toegevoegd. Dat betekent: controleer of het account extra authenticatiemethoden heeft gekregen en of er nieuwe registraties zijn ontstaan.
3) Controleer app-wachtwoorden en OAuth-toegang
Bij Gmail geldt volgens openbare informatie dat wachtwoordwijziging doorgaans ook bepaalde toegang afsnijdt, zoals app passwords en OAuth-tokens met relevante scopes. Toch kunnen onderdelen van het toegangspakket onder omstandigheden blijven bestaan voor geautoriseerde apparaten of derde partijen. Daarom is het verstandig om niet te vertrouwen op alleen één knop, maar op een gecontroleerde uitkomst.
Wil je dit koppelen aan concrete security-maatregelen die je kunt inrichten voor sneller herstel in je omgeving? Lees dan ook Wazuh AI: sneller reageren in je SOC. Dat artikel gaat over detectie en responsworkflow, wat goed aansluit bij het idee dat je recovery moet versnellen én verbeteren.
IOC’s en praktische detectie: wat weten we wel?
Abnormal noemt in de analyse ook IOCs en remediatie-advies. Het belangrijkste voor organisaties is om te vertalen naar eigen tooling: wat kun je detecteren op endpoint, browser-gedrag, netwerkverkeer of identity-events?
Omdat de publiek beschikbare informatie niet gelijkstaat aan “we hebben het malwarepakket live gedraaid”, is het verstandig om detection te baseren op meer dan alleen één verdacht domein of één specifieke test. Kijk vooral naar patronen die passen bij phishing die een extra credential probeert toe te voegen: ongebruikelijke authenticatiegolven, onverwachte registratie van authenticatiemethoden en “nieuwe login routes” na herstel.
Belangrijkste takeaways
- Passkeys in phishing is volgens de analyse van iAuthFlow V2 een mechanisme om toegang te behouden na een wachtwoordreset.
- De standaard reactie bij accountcompromis—wachtwoord wijzigen en sessies intrekken—kan onvoldoende zijn als de aanvaller een credential kan registreren.
- Herstel moet daarom ook controleren op nieuwe authenticatiemethoden of wijzigingen in account-credentials.
- Omdat details deels uit openbare posts en demo’s komen, blijft implementatie van checks op basis van je eigen identity-omgeving cruciaal.
Conclusie
iAuthFlow V2 laat zien hoe phishing zich ontwikkelt: niet alleen het verzamelen van inloggegevens staat centraal, maar ook het veiligstellen van toekomstig toegangspad. Juist daarom is de boodschap helder: bij een phishingincident is een wachtwoordreset een begin, geen eindpunt—zeker wanneer passkeys in phishing mogelijk onderdeel zijn van de aanval.
Door je incidentrespons te verbreden met controles op account-credentials, sessies en geautoriseerde authenticatiemethoden, maak je herstel robuuster. Zo verlaag je de kans dat een aanvaller na jouw “standaard” herstel alsnog terugkomt.
