Phishingbestendige MFA is een tweede factor die zelf controleert met welk webadres hij praat, zodat een tussenliggende phishingpagina technisch niet werkt. Codes uit een app, sms en pushmeldingen doen dat niet: die kun je doorgeven, en de moderne phishingaanval jaagt precies daarop. Niet op je wachtwoord, maar op je sessie.
Kort samengevat
- De moderne phishingaanval steelt je sessiecookie, niet je wachtwoord, en loopt daarmee langs codes en pushmeldingen heen.
- Alleen phishingbestendige MFA (hardware-sleutels, domeingebonden passkeys) sluit die route af.
- Testers vragen vooraf welke MFA je gebruikt, omdat het bepaalt hoe diep een phishingtest kan gaan.
- Begin bij de accounts met de meeste rechten, verkort sessies, en zoek vooral de uitzonderingen.
In vrijwel elk scopegesprek over een phishingtest komt hetzelfde moment langs. De vraag is: hoe diep kan die test gaan? Het antwoord hangt op één ding: welke vorm van multifactor-authenticatie er in gebruik is. Niet óf er MFA is; bijna iedereen heeft dat inmiddels. Maar welke. Dat onderscheid bepaalt of een phishingaanval op je Microsoft 365-omgeving struikelt bij de tweede stap of doorloopt tot aan je documenten.
Waarom draait de aanval niet meer om je wachtwoord?
Het mentale model bij veel mensen is nog: iemand steelt je wachtwoord, probeert in te loggen en strandt bij de code op je telefoon. Zo werkt het niet meer. Wat er gebeurt:
- Je krijgt een mail die je naar een inlogpagina stuurt die niet van Microsoft is, maar die alles wat jij invult in real time doorgeeft aan de echte pagina.
- Je typt je wachtwoord: wordt doorgegeven. Microsoft vraagt om je tweede factor: die vraag krijg jij te zien.
- Jij keurt de melding goed of typt de code over. Ook dat wordt doorgegeven.
- Microsoft ziet een geslaagde login met correcte tweede factor en geeft een sessiecookie af. Die cookie vangt de tussenliggende pagina af.
Vanaf dat moment heeft de aanvaller jouw sessie. Hij hoeft je wachtwoord niet, hij hoeft je tweede factor niet meer. Je wachtwoord wijzigen helpt niet: de sessie blijft geldig tot hij verloopt.
Welke MFA is phishingbestendig en welke niet?
De scheidslijn loopt niet tussen “sterk” en “zwak”, maar tussen vormen die je kunt doorgeven en vormen die dat niet kunnen.
- Niet bestand: codes per sms, codes uit een authenticator-app, pushmeldingen die je goedkeurt. Allemaal gegevens die jij kunt overtypen of goedkeuren, en dus gegevens die een tussenpersoon kan doorgeven.
- Wel bestand: hardware-sleutels en passkeys die gebonden zijn aan het adres van de website. De sleutel controleert zelf met welk domein hij praat. Staat er een andere domeinnaam, dan werkt hij niet. Geen kwestie van oplettendheid; het werkt technisch niet. Dit is phishingbestendige MFA.
- Er tussenin: getalsvergelijking in plaats van simpele goedkeuring. Het verhoogt de drempel, maar sluit de route niet af.
Wat betekent dit voor je phishingtest?
Hierom vragen testers vooraf welke MFA je gebruikt. Draai je op app-codes of pushmeldingen, dan loopt de test het hele pad: mail, inlogpagina, sessiecookie, en vervolgens laten zien waar die sessie toegang toe geeft. Confronterend, en daarom overtuigend richting een directie die twijfelt of de investering nodig is.
Draai je al op phishingbestendige MFA, dan stopt de test daar, en dat is de uitkomst die je wilt. De test verschuift dan naar de vraag of er ergens nog een uitzondering bestaat: een systeem dat buiten de sleutel om werkt, een oud account, een dienstaccount, een uitzonderingsregel die ooit tijdelijk was. Die uitzonderingen zijn in de praktijk het echte probleem. Een organisatie met “overal MFA” blijkt bij nader inzien vaak twee of drie plekken te hebben waar dat niet geldt.
De volgorde die werkt
Overstappen op phishingbestendige MFA hoeft niet in één beweging.
- Breng in kaart welke vorm van MFA waar geldt. Inclusief de uitzonderingen. Juist de uitzonderingen.
- Begin bij de accounts met de meeste rechten. Beheerders, directie, financiën. Grootste winst, kleinste groep.
- Verkort je sessieduur. Zolang je nog niet overal phishingbestendig bent, beperkt dit hoelang een gestolen sessie bruikbaar blijft.
- Zet voorwaardelijke toegang in. Aanmelden vanaf een onbekende locatie of onbeheerd apparaat mag om extra bevestiging vragen, of gewoon niet mogen.
- Rol daarna breder uit. Met de ervaring van stap twee weet je waar het in jouw organisatie schuurt.
Test het daarna. Een phishingsimulatie tegen de nieuwe opstelling laat zien of de uitzonderingen er echt uit zijn. Wil je weten hoe ver een phishingaanval in jouw omgeving komt? Dat is een van de modules in een scopegesprek, en de uitkomst is vaak het argument waarmee je de rest van je plan gefinancierd krijgt.
BOEM voert pentesten uit met EHGI, het bedrijf achter de EHGN-community van 2.500+ ethische hackers, waaronder specialisten van Politie, Defensie en DIVD. Welke tester bij jouw omgeving past, bepalen we in het scopegesprek.
Veelgestelde vragen
Wat is phishingbestendige MFA?
Een tweede factor die zelf controleert met welk webadres hij praat, zoals een hardware-sleutel of een passkey gebonden aan het domein. Staat er een andere domeinnaam dan waarvoor hij is geregistreerd, dan werkt hij niet. Dat blokkeert een tussenliggende phishingpagina technisch, niet op oplettendheid.
Waarom houdt een authenticator-app of sms-code phishing niet tegen?
Omdat het gegevens zijn die jij kunt overtypen of goedkeuren, en dus gegevens die een tussenpersoon in real time kan doorgeven aan de echte inlogpagina. De aanvaller krijgt vervolgens de sessiecookie, en heeft je tweede factor niet meer nodig.
Helpt mijn wachtwoord wijzigen na een phishingaanval?
Niet tegen deze aanval. De aanvaller heeft je sessie, niet je wachtwoord. Die sessie blijft geldig tot hij verloopt. Sessies intrekken en de sessieduur verkorten helpt wel.
Waar begin ik met overstappen op phishingbestendige MFA?
Breng eerst in kaart welke MFA-vorm waar geldt, inclusief uitzonderingen. Begin bij accounts met de meeste rechten (beheerders, directie, financiën), verkort de sessieduur, zet voorwaardelijke toegang in en rol daarna breder uit.
