Tien jaar geleden was het advies simpel: zet multifactorauthenticatie aan en het grootste risico is weg. Dat advies was toen juist. Vandaag is het onvolledig. Aanvallers hebben zich aangepast aan een wereld waarin bijna iedereen MFA heeft, en de technieken die ze daarvoor gebruiken zijn goedkoop, gestandaardiseerd en te huur. Wie nog denkt in termen van "we hebben MFA, dus we zijn veilig", heeft een beeld van zijn beveiliging dat niet meer klopt met de praktijk.
Het onderliggende principe is steeds hetzelfde: de aanvaller probeert MFA niet te kraken, maar er omheen te lopen. Hij laat de gebruiker de MFA zelf keurig afronden, en pikt daarna het resultaat in. Vier varianten zien we in vrijwel elk incident terug.
1. Adversary-in-the-middle: de echte inlogpagina, via een omweg
De gebruiker klikt op een link naar wat eruitziet als SharePoint of OneDrive. De pagina is echt, in die zin dat alles wat de gebruiker intypt live wordt doorgestuurd naar Microsoft. Wachtwoord, sms-code, pushmelding: het werkt allemaal gewoon. Alleen zit er een proxy van de aanvaller tussen, en die vangt het sessietoken op dat Microsoft na een geslaagde login uitgeeft. Met dat token is de aanvaller ingelogd zonder wachtwoord en zonder MFA, en een wachtwoordreset helpt niet: de sessie blijft geldig.
Dit is inmiddels de meest voorkomende methode in zakelijke accountovernames. De kits die het mogelijk maken worden per maand verhuurd, inclusief ondersteuning.
2. Device code phishing: een legitieme inlog, voor het verkeerde apparaat
Microsoft heeft een inlogmethode voor apparaten zonder toetsenbord, zoals printers en vergaderschermen: je krijgt een korte code en voert die in op een gewone inlogpagina. De aanvaller start zo'n inlog op zijn eigen apparaat, stuurt de code naar de gebruiker met een plausibel verhaal ("verifieer je account"), en de gebruiker keurt op een echte Microsoft-pagina de sessie van de aanvaller goed. Geen namaakpagina, geen malware, wel volledige toegang.
3. Consent-misbruik: toestemming die een wachtwoordreset overleeft
Een gebruiker krijgt de vraag of een app toegang mag tot zijn mailbox. Hij klikt op "Accepteren". Vanaf dat moment heeft de aanvaller via die app een eigen, langlopend token, los van het wachtwoord van de gebruiker. Wachtwoord veranderd? Maakt niet uit. MFA opnieuw ingesteld? Maakt niet uit. Zolang de app-toestemming bestaat, blijft de toegang bestaan. In incidentonderzoek is dit de klassieke manier waarop aanvallers "persistentie" bouwen na een eerste inbraak.
4. Een eigen MFA-apparaat registreren
Wie eenmaal een wachtwoord heeft, bijvoorbeeld uit een infostealer of een eerder datalek, probeert een eigen telefoon als MFA-methode te registreren. Als de registratie niet extra beschermd is, of als de servicedesk op een overtuigend telefoontje een reset doet, is het gelukt: de aanvaller haalt vanaf dan zelf de MFA-drempel.
Wat wél werkt
De rode draad: alles wat de gebruiker "gewoon goed doet" moet ook goed blijven als hij wordt misleid. Dat vraagt om een aantal specifieke keuzes, niet om nog een awarenesstraining.
- Phishing-resistant MFA. Passkeys en FIDO2-sleutels werken alleen op het domein waarvoor ze zijn aangemaakt. Een proxy-pagina kan er niets mee. Begin bij beheerders en andere risicogroepen, en breid uit.
- Conditional Access die de sessie beperkt. Een gestolen token is minder waard als het alleen werkt vanaf een beheerd, compliant apparaat, met een korte levensduur en met continue evaluatie bij risicosignalen.
- Gebruikers mogen geen apps zelf toestemming geven. Admin-goedkeuring voor app-toestemmingen, en een periodieke controle van welke apps welke rechten hebben. Dit is een instelling, geen project.
- Device code-inlog uit, tenzij aantoonbaar nodig. Waar het moet blijven: alleen onder Conditional Access, met alarmering op afwijkend gebruik.
- Registratie en herstel van MFA beschermen. Sterke herverificatie bij het toevoegen van een methode, een servicedeskproces dat niet op een goed verhaal te kraken is, en een alarm bij elke nieuwe MFA-registratie.
- Snel kunnen intrekken. Sessies, tokens en app-toestemmingen in één keer kunnen revoken hoort in elk incidentdraaiboek. Wie dat niet geoefend heeft, doet het onder druk fout.
Deze maatregelen vallen samen met wat wij "identity-first" noemen: niet de vraag of iemand is ingelogd, maar of die inlog nog te vertrouwen is. Wil je weten hoe jouw omgeving hierop scoort? De Digital Defense Review bekijkt precies deze paden, vanuit het perspectief van een aanvaller die al een wachtwoord heeft.