AI wordt steeds vaker ingezet bij beveiligstests, maar de impact zit pas echt wanneer zo’n test ook door alle beschermlagen heen kan. Bij een geautoriseerde beoordeling van een grote verzekeraar vond een AI pentesting agent een OTP-bypass in productie. De “attack” zelf bleek relatief eenvoudig; het lastige deel was het aantonen binnen de echte webcontext van een live systeem met een groot aantal gebruikers.
In dit artikel lees je wat er precies misging bij de one-time passcode (OTP), waarom dit soort fouten extra gevaarlijk zijn, en welke lessen je organisatie direct kunt toepassen op je eigen authenticatie- en 2FA-stromen.
Wat was er aan de hand met de OTP?
Een OTP (one-time passcode) is bedoeld om te bewijzen dat een gebruiker is wie hij zegt te zijn. Dat werkt alleen als de ontvangen code gekoppeld is aan het juiste account. In de casus van de verzekeraar zat het fundamentele probleem in het loginproces: één aanvraag liet bepalen waar de verificatiecode naartoe ging.
De AI-agent logde in via de live website en stuurde een loginverzoek waarmee de bezorgroute van de OTP werd aangepast. In normale omstandigheden gaat de code via tekst naar het telefoonnummer dat bij het account hoort. Maar het systeem accepteerde ook een andere route, bijvoorbeeld via e-mail, en gebruikte daarbij het adres dat in de aanvraag werd opgegeven.
Daar zat de kernfout: het serverdeel controleerde niet voldoende of het adres dat voor bezorging werd opgegeven daadwerkelijk bij het gekozen account hoorde.
Waarom deze fout als “bypass” voelt
De essentie van een OTP-bypass in productie is dat de beveiliging niet langer “bindt” aan de identiteit die je wilt verifiëren. In plaats daarvan wordt de OTP alleen nog gezien als een code die ergens is afgeleverd, zonder hard bewijs dat die afleverlocatie hoort bij het doelaccount.
De AI-agent maakte het werkend door exact te controleren welke velden de OTP-bezorging stuurden. Toen de code aankwam op de inbox waar de tester controle over had, voldeed de gebruiker-aanvraag aan de verificatiestap en ging de login door. Daarna stopte de AI-test om verdere acties te voorkomen, omdat de succesvolle login al voldoende bewijs was.
Dit sluit aan bij een basischeck uit test- en beveiligingsrichtlijnen: vraag je af of OTP’s echt zijn gekoppeld aan het juiste gebruikersaccount. Als die koppeling ontbreekt, kan een aanvaller met de juiste gegevens mogelijk toegang krijgen tot accounts die niet van hem zijn.
Van vermoeden naar bewijs: het moeilijke deel
Volgens de beschrijving begon de AI-agent met verkenning. De agent onderzocht JavaScript en de API-aanroepen achter de websitepagina’s. Op basis daarvan kwam naar voren welke elementen leken te sturen waar de OTP heen ging.
Belangrijk is dat zo’n bevinding in eerste instantie nog geen eindresultaat is. Systemeigen logica kan bijvoorbeeld wijzigingen weigeren of later in de flow toch blokkeren. Daarom bouwde de agent een gerichte test rond de geïdentificeerde waarden en liet die uitvoeren via de echte live loginflow.
Pas toen de login daadwerkelijk slaagde binnen de productiesite, werd het een bevestigde bypass. De “aanval” was dus niet het probleem—de bewijsvoering binnen de volledige workflow was dat wél.
Waarom webcontext zo bepalend is
Veel geautomatiseerde tests stoppen bij de loginpoort. Maar in moderne webapplicaties speelt het grootste deel van de relevantie zich af achter meerdere stappen: het ophalen van tokens, het afhandelen van 2FA, het verwerken van statusinformatie en het doorlopen van de juiste flow met de juiste sessies.
In deze case kon de AI-agent die context wél gebruiken. Het platform achter de agent had al eerder uitgebreid productiewebsites gescand en beschikte daardoor over ervaring met hoe login- en verificatiestromen in het wild lopen. Met die aanpak start de agent niet “vanaf nul”, maar met kennis van hoe de website zich gedraagt tijdens echte gebruikersroutes.
In de praktijk betekent dit dat de agent door geauthenticeerde stappen navigeert, inclusief het moment waarop OTP’s en 2FA worden verwerkt. Daarmee ontstaat er een realistischer test van wat gebruikers daadwerkelijk meemaken.
Gevalideerde findings versus “coverage”
Een bevestigde kwetsbaarheid zegt iets over wat er misging, maar niet automatisch over hoe breed de testen waren. Daarom is het volgens de beschrijving van de testaanpak belangrijk om niet alleen te vinden wat faalt, maar ook te registreren welke onderdelen zijn getest.
De agentische aanpak draaide daarom meerdere aanvalspaden naast elkaar binnen dezelfde tests. De organisatie achter de agent combineert een open onderzoek met een gestructureerd plan: endpoints die werden ontdekt, worden vervolgens getest tegen passende aanvalscategorieën.
Daarnaast werd elke verdachte bevinding opnieuw gereproduceerd door een aparte validatie-actie met dezelfde payload en context. Het resultaat is een soort “bewijs- en registratierapport” waarin staat welke tests zijn uitgevoerd, welke uitkomsten zijn vastgelegd en welke onderdelen mogelijk uitgesloten waren.
Waarom “we hebben gepentest” niet hetzelfde is als veilig
De verzekeraar gaf aan dat er ongeveer zes maanden eerder een pentest had plaatsgevonden. Er werd daarbij ook een exploiteerbare loginfout vastgesteld. Tegelijk is onduidelijk wanneer de zwakte precies in productie is gekomen.
De belangrijkste les is niet dat menselijke pentesters tekortschieten. Het probleem zit vaker in het karakter van point-in-time testing: een testmoment verandert de code niet, en de planning is niet flexibel. Websites veranderen voortdurend met releases, terwijl pentestmomenten vaak in tijdvakken zijn vastgelegd.
Dat maakt het lastiger om een aanvaller bij te benen die met geautomatiseerde methoden kwetsbaarheden sneller kan opsporen. Agentic testing kan volgens de beschrijving gerichter en vaker herhalen, zolang de juiste toegang en afbakening aanwezig zijn—met een output waar reviewers bewijsbaar naar kunnen kijken.
Praktische aandachtspunten voor je eigen OTP- en 2FA-flow
Als je wilt voorkomen dat een OTP-bypass opnieuw voorkomt, begin dan niet bij “extra controles achteraf”, maar bij de basisbinding tussen code en gebruiker.
- Check de account-koppeling: controleer server-side dat de bezorglocatie (kanaal en adres) hoort bij het beoogde account.
- Werk met vaste, herleidbare brongegevens: laat het loginverzoek niet vrij kiezen waar het de OTP naartoe stuurt; gebruik accountgegevens die je server betrouwbaar kan herleiden.
- Test de hele flow: valideer niet alleen het moment van OTP-invoer, maar ook alle stappen daaraan voorafgaand (API-calls, sessies, statusovergangen).
- Herhaal tests bij wijzigingen: automatisering of agentic aanpak kan helpen om veranderingen sneller te toetsen dan een periodiek testvenster.
Wil je meer context over hoe beveiliging rond webflows en identity-instellingen vaak samenkomt met exploitketens? Lees dan ook Microsoft Patch Tuesday 1.413 fixes: wat je moet doen, omdat het laat zien hoe snel veranderende componenten (en ketens) de aandacht verdienen. Het onderwerp is anders, maar de les over doorlopende risico’s en tijdige opvolging is vergelijkbaar.
Conclusie: OTP is sterk, maar alleen met juiste binding
De casus toont aan dat OTP’s niet automatisch veilig zijn. Een OTP-bypass in productie ontstond omdat het systeem de bezorggegevens accepteerde zonder te verifiëren of die gegevens bij het juiste account hoorden. De AI-agent kon dat overtuigend aantonen door de test uit te voeren binnen de echte live webcontext—waardoor een theoretische zwakte een bewezen bypass werd.
Voor organisaties betekent dit: borg de koppeling tussen OTP en gebruiker op server-side, test de volledige flow en kies een aanpak die met releases mee kan bewegen. Alleen dan blijft 2FA meer dan een extra stap in de interface.
Bron: https://thehackernews.com/2026/10/an-ai-agent-found-critical-otp-bypass.html
