Als je hiermee een MFA bypass attack bedoeld (testen is niet echt mogelijk) dan zou je dat zelf moeten inrichten om dit te repliceren. Maar misschien begrijp ik het verkeerd en zal je even wat uitleg moeten geven.

Om zo'n MFA bypass attack te voorkomen kan je dit via een FIDO2 authenticatie met bijvoorbeeld een Yubikey, al moet die wel net door de specifieke website ondersteund worden en dit zijn er helaas nog niet heel veel die dit ondersteunen.

Door veel MFA requests te genereren .

Hoe - dat zal er heel erg vanaf hangen hoe de MFA koppeling werkt , of je dat makkelijk (of uberhaupt) kunt injecteren .

Maar uiteindelijk komt er vanuit een authenticatie systeem , na een valide password - ergens een API call dat leidt tot een MFA request voor dat account .

*in principe* - zou die call ook gemaakt kunnen worden zonder dat er een username/password langs gekomen is - maar dat vergt waarschijnlijk een stuk uitzoekwerk en progammeren om automatisch mfa requests te maken voor een bepaalde user.
Als je het platform in eigen beheer hebt zou dat moeten kunnen , met het nodige uitzoek werk. Bij een third party (Office 365 oid) betwijfel ik of je zo zou kunnen testen .

Ik heb het nooit geprobeerd/geimplementeerd, dus kan je niet helpen met het ene of andere MFA platform.

Ik denk dat als je snapt hoe de techniek en de kwetsbaarheden werken je al daarmee al meteen een paar belangrijke aanwijzingen hebt voor het testen ervan, en dat je dan veel en veel gerichtere vragen kan stellen dan je nu doet. Wat je nu vraagt is zo breed en algemeen dat ik me afvraag of je er meer van weet dan de paar termen die je gebruikt.

In de titel van je post noem je MFA fatigue (de q moet een g zijn). Dat is in wezen een doodsimpele aanval. Als je snapt wat daar gebeurt dan zie ik eigenlijk niet in hoe je daar geen test voor zou kunnen bedenken.

Ik krijg met andere woorden sterk de indruk dat je je vraag stelt nog voordat je zelfs maar begonnen bent je zelf in het onderwerp te verdiepen en zelf na te denken. Begin daar eens mee, zou ik zeggen. En als je wel al het nodige gedaan hebt, laat dat dan blijken door specifieker te zijn en gerichtere vragen te stellen. Betere vragen leveren betere antwoorden op, en het is veel leuker om iemand die duidelijk zelf energie in iets steekt met een antwoord verder te helpen dan iemand die er zelf geen fluit voor lijkt te doen.

hi,

ja net als hoe het nu werkt met het versturen van spam mails via de azure security site. dan kan je dus een spam mail uitkiezen en die versturen naar al je gebruikers.

ik zou zoiets ook graag willen zien om bij iedereen op zijn telefoon een mfa request te genereren. kijken hoeveel mensen hem accepteren. en daarna een stukje awareness creeren hierover.

Dan volstaat naar mijn weten een normale phising test. Die hacks zijn gewoon alternatieve links waarbij de gebruiker zijn/haar gegevens moet submitten, vervolgens via de proxy configuratie wordt dan de MFA sessie token onderschept via een man in the middle attack.

In aanvulling op mijn 14:17

Als het mijn project was zou ik

1) kijken (cq noemen) welke smaak MFA gebruikt wordt in je omgeving
2) daarover gaan zitten lezen hoe je die MFA implementeert voor een (nieuwe) service . Er zal vast een devkit/api/manual zijn voor "how to add <MFA> to your website " .
3) En dan in je te testen omgeving een development systeem bouwen wat die MFA requests stuurt - voor je installed base.

Waarschijnlijk heb je ook een of andere api key of andere koppeling nodig waarmee het MFA systeem aan jouw service gekoppeld is.

Ik betwijfel heel sterk of een externe service bestaat van het type "enter email, enter phone to send an MFA push to this person" .

Zucht .
Nee, dat is niet het mechanisme van MFA fatigue.

MFA fatigue slaat (vooral) op de MFA variant waarbij je alleen maar op "OK" hoeft te drukken in de MFA app om je (valide username/pw login) te autoriseren.

Wat bij gebruikers te weinig tussen de oren zit is dat je zo'n MFA popup op je telefoon *ALLEEN MAAR* krijgt bij een login -door jou - op de betreffende service.

Een aanvaller die (reeds) een valide login namens de gebruiker kan doen - blijft dat proberen, net zolang tot de gebruiker gek wordt van al die autorisatie pings en dan maar een keer op "OK" drukt om te zien of het dan stopt . Yep, het stopt dan ...

TS hier wil dus z'n userbase (ook) gaan bombarderen met autorisatie pogingen om ze te leren toch niet op OK te drukken.

https://www.tenfold-security.com/en/mfa-fatigue/

Je weet dat die zwakte er is in het systeem, je weet dat mensen de zwakte hebben om als ze geïrriteerd raken uit irritatie dingen gaan doen die ze beter kunnen laten. In plaats van dat inzicht te gebruiken ga je "awareness creëren". Zucht.

Ik weet iets veel beters om je energie in te steken. Vraag je eens af of het mogelijk is om die irritatie te voorkomen. Is het bijvoorbeeld mogelijk om te voorkomen dat mensen gespamd worden met veel te veel van die verzoeken om een login te bevestigen? Bijvoorbeeld door als drie opeenvolgende van die berichten niet tot een login hebben geleid de vierde en volgende niet meer te sturen en daar pas weer mee te beginnen als de betreffende gebruiker de helpdesk heeft gebeld om te melden dat inloggen niet meer gaat. Qua awareness kan je mensen dan erop wijzen dat het zo werkt, zodat ze bij onverwachte bevestigingsverzoeken a) weten dat ze er hooguit drie krijgen (dat scheelt al direct in de irritatie), en b) weten dat ze binnenkort een telefoontje naar de helpdesk zullen moeten plegen.

Als je systeem zo werkt dat iemand door "Oké" op zijn telefoon te geven een ander kan laten inloggen, dan zou ik ook gaan uitkijken naar een systeem dat die kwetsbaarheid niet heeft.

Als je MFA device of app nou gewoon een code displayed die je op het login scherm in moet tikken (in een 2e password veld bijvoorbeeld) dan is er niks aan de hand als men je MFA requests stuurt, want je hebt dan niks om ze in te tikken.

Eindelijk iemand die mij begrijpt! :) nu nog een manier hoe :)

jij gaat dus omdat het irritant is maar gewoon het hele principe wegnemen. lijkt me niet logisch?

Helaas - zie (ook) mijn postings van 1 nov 14:17 / 17:21

Ik denk niet dat er de een of andere service of tool reeds voor bestaat.

Trouwens - ook al zou er een test service bestaan - je hebt hopelijk wel bedacht dat zomaar een externe service gebruiken waar je (telefoonnummers ? emails? ) van je gebruikers bestand naar upload Geen Goed Idee is ?

Op zich - degenen die gereageerd hebben dat een andere stijl MFA uberhaupt beter is hebben natuurlijk geen ongelijk .
Daarop pushen is zeker (ook) aan te bevelen.

Als je dienst met deze MFA in-house is - kun je denk ik het beste gaan shoppen bij de developer/senior beheerders die 'm ingericht hebben en de MFA koppeling gemaakt hebben.

Wel een goede uitdaging voor een security engineer om eens _echt_ te snappen hoe de integratie van het authenticatie systeem met een MFA service gedaan is .

Ik lees niet dat hij zegt om zonder MFA te gaan werken, maar om het MFA systeem aan te passen zodat de gebruiker geen flood van requests kan krijgen . (die de gebruiker dan allemaal moet negeren , want daar hangt de hele veiligheid van af).

Moet je voorstellen - de gebruiker wordt geflood vol met MFA request (vanwege hacker logins) - gebruiker gaat óók zelf inloggen , en moet dan tussen de flood door z'n eigen login wel approven. Dat is toch echt een disaster waiting to happen.

Dan is er best wat te zeggen voor een (ander) MFA systeem waarbij het niet simpelweg "druk OK" is .
Of dus - zoals voorgesteld - een threshold dat bij drie of vijf logins zonder dat de MFA "OK" gedrukt wordt - de login bevroren wordt zodat verdere MFA requests niet meer gestuurd worden.
Want de flood van requests hang toch (zoals ik het probleem lees) samen met het feit dat de hacker (reeds) valide login/password heeft, en daarmee telkens aan het inloggen is, net zo lang totdat het slachtoffer het zat is en op OK drukt.

Het feit _dat_ er MFA requests geflood worden is een indicatie van een behoorlijk security probleem - en als je dat automatisch altijd kunt detecteren heeft dat de voorkeur boven uitleggen dat gebruikers moeten oppassen en de helpdesk bellen .

Je laatste defensie dan bouwen op "ik heb de gebruikers aware gemaakt dat ze gewoon niet op OK moeten drukken " is wat dunnetjes.
Awareness is prima , en testen ervan ook - maar als je de keuze hebt om een reële aanvalsvector uit te sluiten - vooral doen.

Misschien heb je de keuze niet - het zal mensen hier teleurstellen, maar in veel organisaties is "security" niet "God in het IT universum", maar gewoon ook een IT discipline die het beste moet zijn te maken van wat er staat aan services.
Maar goed - pushen voor een structurele fix is inderdaad iets dat je niet moet nalaten.

Aanvankelijk dacht ik dat "Number Matching" in de Microsoft Authenticator app zo werkte, maar het is andersom - en dat is verstandiger. Want als de app een getal zou tonen dat de inlogger op de website moet invoeren, zou een aanvaller het getal (wat de echte gebruiker ziet in diens app) kunnen blijven gokken tot dat toevallig een keer klopt (met nog meer push-berichten als gevolg).

Het is echter zo dat als de echte gebruiker of een aanvaller probeert in te loggen, de website een getal van 2 cijfers toont. De echte gebruiker krijgt een melding uit de MS Authenticator app op diens smartphone, en moet in de app die twee cijfers invoeren om in te kunnen loggen.

Als het niet de echte gebruiker is die inlogt, weet die echte gebruiker niet wat er op het inlogscherm staat. Je kunt natuurlijk niet helemaal uitsluiten dat de echte gebruiker de pings zó zat wordt dat deze random getallen in de app gaat invullen om er vanaf te komen (of dat de aanvaller op de een of andere manier in contact kan komen met de echte gebruiker en hem of haar met een smoes overhaalt om het juiste getal in te voeren), maar de kans daarop lijkt mij kleiner dan zonder "number matching".

Ik weet niet precies hoe het werkt, maar ik hoop dat de inlogpagina op de website het random getal van twee cijfers ook toont als de aanvaller een onjuist wachtwoord probeert (en dat er dan geen ping naar de MS Authenticator app wordt gestuurd - met onnodige MFA-fatigue als gevolg). Immers, als het random getal alleen zou worden getoond als het wachtwoord klopt (bij een gegeven user-ID), weet de aanvaller het zodra hij of zij het juiste wachtwoord heeft geprobeerd.

Als het zo geïmplementeerd is (wat ik verwacht), moeten gebruikers beseffen dat hun wachtwoord geraden is als MS Authenticator hen pingt. Als iedereen te vertrouwen zou zijn, zouden we geen wachtwoorden en MFA-ellende nodig hebben. Security Awareness is dus ook dat inloggen, net zoals het met een sleutel openen van jouw voordeur, in de eerste plaats bedoeld is om kwaadwillenden buiten te houden.

Helaas is MS Authenticator met number matching geen veilige oplossing: het biedt geen bescherming tegen phishing met valse (proxy/AitM) websites. Als password spraying + MFA fatigue niet meer werkt, zullen cybercriminelen hun werkwijze aanpassen. Ik verwacht dan ook dat het aantal aanvallen met fake websites, fake popups (browser in browser) en client-side attacks zal toenemen, en daar helpt MS Authenticator niet tegen.

Heb hier wel een artikel gevonden met de voordelen van MFA: https://onlineguardian.nl/het-belang-van-multi-factor-authenticatie-en-hoe-je-het-effectief-kunt-implementeren/