De beveiligingsindustrie heeft jarenlang ingezet op sterkere authenticatiemethoden, zoals langere wachtwoorden, tweefactorauthenticatie en hardwaretokens. Aanvallers hebben hierop gereageerd door de authenticatiefase te omzeilen met zogenaamde adversary-in-the-middle (AiTM) phishingaanvallen. Deze aanvallen stelen geen inloggegevens, maar onderscheppen in real time het sessietoken dat wordt uitgegeven na een succesvolle login. De authenticatie zelf is dus echt, maar de aanvaller kopieert het resultaat en kan daarmee toegang krijgen.

Hoewel het versterken van authenticatie, bijvoorbeeld met phishingbestendige methoden zoals FIDO2 en passkeys, de blootstelling aan AiTM-aanvallen op het authenticatieniveau vermindert, richt dit zich slechts op het voorkomen van diefstal van credentials. De echte kwetsbaarheid ligt bij de sessietokens die na succesvolle authenticatie worden uitgegeven. Deze tokens zijn zogenaamde bearer tokens: wie ze bezit, wordt geacht geauthenticeerd te zijn. Er is geen cryptografische koppeling tussen het token en het apparaat dat het heeft gegenereerd, noch een automatische beëindiging van de sessie bij locatie- of apparaatwisselingen. Hierdoor kan een aanvaller een gestolen sessietoken vanaf een andere locatie hergebruiken en wordt dit door de identiteitprovider als legitiem geaccepteerd.

Een belangrijke maatregel om dit risico te beperken is het binden van sessies aan beheerde en conforme apparaten. Toegangsbeleid, zoals Microsoft Entra Conditional Access, kan vereisen dat het apparaat dat een sessietoken presenteert, is ingeschreven en voldoet aan compliance-eisen. Dit maakt het voor een aanvaller veel moeilijker om een gestolen token op een onbeheerd apparaat te gebruiken, omdat de sessie dan wordt beëindigd. Hoewel deze controle niet onfeilbaar is, sluit het de eenvoudigste aanvalsvector uit: het hergebruiken van een token op een willekeurig ander apparaat.

Daarnaast is het monitoren van afwijkingen na succesvolle authenticatie cruciaal. AiTM-aanvallen veroorzaken geen mislukte inlogpogingen, maar succesvolle. Traditionele monitoring die zich richt op mislukte pogingen mist deze aanvallen daarom. Het is noodzakelijk om te letten op ongewone sessieactiviteit en afwijkingen in gebruikersgedrag na inloggen. Microsoft’s eigen incident response teams hebben dit patroon gedocumenteerd en benadrukken het belang van dergelijke monitoring.