Bij meervoudige authenticatie draait het om één simpele belofte: een one-time passcode (OTP) bewijst wie je bent, mits die code naar de juiste gebruiker en het juiste account is gekoppeld. In een recent beschreven geval lukte dat niet. Een AI pentesting-agent ontdekte een OTP-bypass via code-drempels op een productiewebsite van een grote verzekeraar—en de moeilijkste stap bleek niet het “aanvalsgedeelte”, maar het aantonen van de impact binnen de echte gebruikersflow.
De bevinding laat zien hoe kwetsbaar OTP-verificatie kan zijn wanneer een backend niet streng genoeg controleert of de bestemming van de verificatiecode overeenkomt met het account waarvoor je probeert in te loggen.
Wat er misging met de OTP-verificatie
De technische kern van het probleem was helder: bij het inlogproces kon de aanvraag beïnvloeden waar de OTP naartoe werd gestuurd. Normaal gesproken hoort een OTP naar een kanaal te gaan dat al aan het betreffende account is gekoppeld, bijvoorbeeld naar het telefoonnummer of e-mailadres dat bij dat account hoort.
In dit geval zat de zwakte in het verzoek dat de OTP opriep. Dat verzoek bevatte velden waarmee de server kon bepalen:
- via welk kanaal de code werd verzonden (bijvoorbeeld sms of e-mail), en
- naar welk adres de code moest worden gestuurd.
Het gevolg was dat de server de adreskeuze niet controleerde tegen de gegevens die aan de gebruiker/account waren gekoppeld.
Waarom dit een OTP-bypass kan worden
OTP’s leveren pas echte beveiligingswaarde op als ze “aan de juiste identiteit” hangen. Als de koppeling tussen code en account ontbreekt, ontstaat een logisch gat: je kunt een verificatiecode laten sturen naar een bestemming die jij kunt controleren, terwijl je je toegang probeert te verschaffen tot een ander account.
De beschreven situatie komt neer op het volgende scenario: iemand met de benodigde klantidentifiers kan een loginactie uitvoeren, de verzendbestemming aanpassen, en vervolgens de OTP ontvangen op een plek die niet aan het doelaccount gebonden is. Zodra de code binnenkomt, kan de login doorlopen.
Belangrijk is dat dit soort fouten niet “gevoel” moeten worden, maar toetsbaar gemaakt moeten worden in de echte flow. Alleen dan weet je of het systeem later alsnog blokkeert—bijvoorbeeld in latere checks of rate-limiting.
Van verdacht veld naar bewezen bypass
De ontdekking begon niet bij een willekeurige aanval, maar bij analyse. De AI pentesting-agent onderzocht de site door naar JavaScript en API-aanroepen te kijken. Daaruit kwamen aanwijzingen naar voren dat specifieke waarden in het OTP-verzoek bepaalden hoe de code werd afgeleverd.
Op basis van zulke signalen kun je een hypothese vormen. Maar een “vinding” is het pas wanneer je kunt aantonen dat het werkt tegen een live gebruikersstroom: dat wil zeggen dat het systeem niet alleen een poging ziet, maar ook daadwerkelijk de login laat slagen.
Daarom zette de agent een gerichte test op—met precies die waarden—en voerde die uit binnen het echte loginproces. Daarmee werd de bypass bevestigd in de productiesituatie.
Deze manier van werken sluit aan bij de manier waarop moderne testing niet alleen naar losse endpoints kijkt, maar naar het totaal van schermen, API’s en verificatiestappen. Het is vergelijkbaar met hoe Zero Trust en Identity-benaderingen juist focussen op consistente controles op identiteit door de hele keten.
Waarom “inloggen kunnen” de echte drempel is
Veel geautomatiseerde tests stoppen letterlijk bij het loginhek. Ze kunnen kwetsbaarheden misschien signaleren, maar ze kunnen niet beoordelen wat er gebeurt nadat een gebruiker is ingelogd of nadat een OTP daadwerkelijk is ontvangen en gevalideerd.
In dit geval draaide het werk om web context: de agent moest door een multi-step workflow kunnen navigeren zoals echte klanten dat doen, inclusief stappen rondom eenmalige verificatiecodes.
De beschreven organisatie had die context al eerder opgebouwd door langdurig productiewebsites te scannen en ze te volgen tot en met de verificatiestappen. Daardoor kon de agent niet “op een lege URL” starten, maar vanuit een bestaande, herbruikbare workflow-kennis: het systeem wist hoe de gebruiker door de flow heen gaat.
Waarom één finding niet genoeg is
Een bevestigde zwakte zegt nog niet alles over de dekkingsgraad van een test. Zelfs als één OTP-test slaagt, blijft de vraag: is dezelfde categorie aanval ook getest op andere relevante onderdelen van het systeem?
In de aanpak die hier beschreven wordt, werd het OTP-probleem niet als geïsoleerde “single issue” behandeld. Er liep een breder plan waarbij de agentic aanpak automatisch meerdere attack-categorieën koppelt aan de ontdekte onderdelen. Daarnaast wordt er een aparte validatie uitgevoerd die de bevinding reproduceert met dezelfde context en payload.
Het resultaat is niet alleen een melding, maar ook documentatie over wat er is getest en met welke uitkomsten—plus eventuele uitsluitingen.
Waarom eerder pentesten niet automatisch betekent dat het veilig is
Volgens de beschrijving had de verzekeraar eerder (ongeveer zes maanden daarvoor) een pentest laten uitvoeren. Die beoordeling zou al een exploiteerbare loginfout hebben gevonden. Toch blijft onduidelijk wanneer precies de zwakte is ontstaan of veranderd.
Dat is niet per se een tekortkoming van menselijke testers. Het wijst vooral op een bekende realiteit: pentests zijn momentopnames. Websites wijzigen door releases, updates en configuratiewijzigingen. Als je testmomenten niet meebewegen met die veranderingen, kan een aanvalstechniek sneller dan de volgende testwindow resultaat opleveren.
Agentic testing probeert dit gat te dichten door gerichte controles vaker en herhaalbaar uit te voeren—mits de agent de juiste toegang heeft en binnen duidelijke grenzen opereert. Dat maakt het makkelijker om bewijs te verzamelen dat reviewers kunnen verifiëren.
Wil je een vergelijkbare dynamiek zien bij andere security-disciplines, dan kan ook een kijkje in maatregelen tegen grootschalige phishing helpen om te begrijpen hoe snelle schaalbaarheid en herhaling in securitytesten relevant blijven.
Praktische aandachtspunten voor je eigen OTP-flows
Als je wilt voorkomen dat een OTP-bypass via code-drempels kan ontstaan, is de rode draad: bind verificatiecode-logica aan het juiste account.
1) Koppel bestemming aan accountdata
Controleer server-side of het kanaal en het adres dat in het OTP-verzoek wordt gebruikt, overeenkomen met wat geregistreerd staat voor het betreffende account. Laat de keuze niet alleen afhangen van waarden die uit de client komen.
2) Valideer op het moment van verzending én bij acceptatie
Het systeem moet niet alleen “later” corrigeren. Als een OTP naar een onjuist adres gaat en dat wordt toch geaccepteerd, is het beveiligingsmodel al gebroken.
3) Test echte workflows, niet alleen losse endpoints
Een loginflow is doorgaans opgebouwd uit meerdere stappen, met guardrails, validaties en soms aanvullende checks. Test daarom end-to-end: van aanvraag tot ontvangst tot verificatie.
4) Herhaal testen bij wijzigingen
Omdat applicaties doorlopend veranderen, is frequent testen belangrijk. Vooral voor kritieke identiteitsstromen zoals inloggen, wachtwoordherstel en accountverificatie.
Conclusie: OTP-beveiliging vraagt om harde koppelingen
De beschreven casus toont dat een OTP niet automatisch veilig is zodra het systeem “OTP” gebruikt. Wanneer een loginverzoek kan bepalen waar de verificatiecode heen gaat, zonder dat de server die bestemming echt aan het doelaccount koppelt, ontstaat het risico op een OTP-bypass via code-drempels.
De boodschap voor organisaties is duidelijk: zorg voor strikte server-side validatie van kanaal en adres, test de volledige gebruikersworkflow, en herhaal assessments zodra je applicatie wijzigt. Zo voorkom je dat een kwetsbaarheid pas zichtbaar wordt nadat kwaadwillenden dezelfde logica hebben ontdekt.
Bron: https://thehackernews.com/2026/10/an-ai-agent-found-critical-otp-bypass.html
2 reacties