MFA fatigue en push bombing: wanneer de goedkeuringsprompt zelf de aanval wordt
Multifactorauthenticatie werkt het best als de tweede factor om iets doordachts vraagt. Een pushprompt om goed te keuren vraagt veel minder: één tik. MFA-fatigue-aanvallen — ook push bombing genoemd — misbruiken precies dat gat. Een aanvaller die al over een geldig wachtwoord beschikt, herhaalt keer op keer de inlogpogingen en overstelpt de telefoon van het slachtoffer met goedkeuringsverzoeken tot er één wordt geaccepteerd: uit reflex, uit ergernis of in de overtuiging dat goedkeuren de prompts eindelijk tot stoppen brengt.
Hoe een push-bombing-aanval verloopt
Het patroon is in alle gedocumenteerde gevallen gelijk. De aanvaller begint met elders gestolen inloggegevens — in bulk verkochte infostealer-logs zijn een veelvoorkomende bron — en controleert of het wachtwoord nog werkt. Daarna herhaalt hij de inlogpogingen, waardoor pushmeldingen op het geregistreerde apparaat van het slachtoffer verschijnen. Elke prompt ziet er identiek uit aan een legitieme, en jaren van onschuldige dagelijkse goedkeuringen hebben veel gebruikers getraind om bijna gedachteloos goed te keuren. Campagnes voegen vaak een tweede laag toe: een telefoongesprek of bericht van iemand die zich voordoet als IT-support, met de instructie de prompts te accepteren zodat ze stoppen. Vanuit de gebruiker bekeken is dit verwarrend by design. De prompt doet alsof de gebruiker zelf het inloggen startte, maar niets aan de melding bewijst wie dat deed. In theorie is de prompt een beveiligingscontrole; in de praktijk is het een bericht op uw scherm dat iedereen met uw wachtwoord kan genereren — en opnieuw genereren — tot vermoeidheid de rest doet. Zo'n prompt behandelen als niet-vertrouwde invoer is precies de mentale omslag die deze aanvallen omzeilen.Uber, september 2022: het standaardvoorbeeld
Het meest geciteerde voorbeeld blijft de inbraak bij Uber in september 2022. Zoals TechCrunch berichtte, schreef Uber de inbraak toe aan een hacker die tot Lapsus$ wordt gerekend en meldde dat het wachtwoord van een externe opdrachtnemer mogelijk op een darkweb-marktplaats was gekocht — volgens de berichten afkomstig uit logs van de RedLine-infostealer. Het wachtwoord alleen voldeed niet, want het account vroeg om een tweede factor. De aanvaller loste ruim een uur lang pushprompts uit, nam daarna contact op met de opdrachtnemer via WhatsApp alsof hij bij de IT van Uber werkte, en zei dat de meldingen zouden stoppen zodra hij ze accepteerde. De uitkomst vatte de aanvaller later in één zin samen tegen TechCrunch:And well, he accepted and I added my device.Met die goedkeuring registreerde de aanvaller zijn eigen apparaat voor de MFA en kwam hij via de VPN het interne netwerk van Uber binnen. Zoals BleepingComputer documenteerde, breidde de toegang zich snel uit: op de Slack van Uber verscheen een bericht dat de inbraak aankondigde, en de aanvaller bereikte cloudconsoles, het Windows-domein en de HackerOne-tickets van het bedrijf, waar hij volgens de berichten privérapporten over kwetsbaarheden downloadde voordat de toegang werd afgesneden. Op een netwerkshare legde een PowerShell-script beheerdersreferenties van Ubers PAM-platform bloot. TechCrunch meldde dat number matching, voor zover bekend, niet actief was waar het er toe deed.
Cisco: dezelfde hendel, anders gebruikt
Het incidentresponsteam van Cisco, Talos, documenteerde datzelfde jaar een parallel geval. Op 24 mei 2022 kreeg Cisco lucht van een compromittering die begon bij het persoonlijke Google-account van een medewerker, waarin zakelijke referenties uit Chrome waren gesynchroniseerd. De aanvaller combineerde vishing-gesprekken onder de gedaante van een vertrouwde supportorganisatie met herhaalde MFA-pushverzoeken tot er één werd geaccepteerd, met VPN-toegang als gevolg. Talos achtte het matig tot sterk waarschijnlijk dat de actor een initial access broker was, gelieerd aan UNC2447, Lapsus$ en de operators van de Yanluowang-ransomware, en beschreef de activiteit als pre-ransomware: eerst toegang, later geld. Twee incidenten, dezelfde deur: de pushprompt, onder druk goedgekeurd.Number matching en de trap van mitigaties
De mitigaties zijn goed begrepen. De richtlijn van CISA is ondubbelzinnig: "phishing-resistente MFA is de standaard waar alle industrieleiders naar moeten streven, maar elke MFA is beter dan geen MFA". De instantie noemt FIDO/WebAuthn de enige breed beschikbare phishing-resistente optie en beveelt, waar dat niet haalbaar is, "number-matching-MFA aan om mobiele pushbombardementen te blokkeren". Microsoft heeft number matching inmiddels de standaard gemaakt voor zijn Authenticator-pushmeldingen: het inlogscherm toont een getal en goedkeuren vereist dat getal in de app intikken. Een prompt zonder context heeft geen getal om in te tikken — precies daarom verslaat de techniek de blinde goedkeuring.- Behandel elke onverwachte prompt als niet-vertrouwde invoer: weiger, rapporteer en wijzig het wachtwoord dat ermee werd getest.
- Geef de voorkeur aan factoren die een bewuste handeling vragen — authenticatorcodes of hardwarekeys — boven pushgoedkeuring met één tik.
- Synchroniseer zakelijke of waardevolle referenties nooit naar een persoonlijk browserprofiel; de aanvaller bij Cisco kwam precies daarbinnen.
- Reserveer hardwaresecuritykeys voor de belangrijkste accounts; volgens TechCrunch hielden ze bij Cloudflare een vergelijkbare aanval tegen.