Hoe komen ze daar nu bij? Ik begreep dat ze in de mail zelfs naar dossier nummers verwezen. Dit is dan geen standaard phishing mail, maar een actie waar voortgeborduurd wordt op gegevens uit reeds bestaande mail.

Het is niet zo moeilijk om met een RNG (fake) dossiernummers te genereren.
Maar wel jammer dat er geen logging is op gelezen emails.

Als ze MFA tokens hebben weten te stelen, kunnen ze bij alles wat via SSO is aangesloten...

Alle sessies intrekken iig.
Tevens begrijp ik niet dat ze het e.e.a niet kunnen uitsluiten.
Unfied Audit Logging zie je precies wat er wel of niet gebeurd is.

Wanneer MFA goed is ingericht dan is token maar beperkt geldig.

Echter is MFA via mail adres of SMS eigenlijk iets wat af te raden is. Het liefst kan je beter een Authenticator hebben voor je token. Liefst nog op een ander device.

E-mail als recovery is ook iets wat ik nooit zou aanraden zonder token. Helaas kan het soms niet anders. Er blijft altijd een zwak punt ergens.

Dat helpt niet tegen dit soort aanvallen (die steeds vaker plaatsvinden naarmate meer mensen zwakke MFA gebruiken, https://security.nl/posting/859561).

Maar ga vooral door met Haarlemmerolie promoten.

Enkel wanneer je in je voorwaardelijke toegang beleid werkt met sign-in frequency. Een (PRT) token is langer geldig dan je je zou denken. Deze is namelijk standaard 14 dagen geldig en wordt automatisch verlengd wanneer de gebruiker actief is op het apparaat.

https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token

melden dat tokens voor MFA onderschept zijn is leuk maar welke methode wordt er gebruikt? SMS, emails als 2FA een app? iets meer info is toch wel vereist als je zo iets schrijft.

MFA tokens zijn niet kort geldig
Zie: https://learn.microsoft.com/nl-nl/entra/identity-platform/configurable-token-lifetimes

Daarnaast is er software zoals het programma Evilginx die in staat is om usernaam/paswword en token te onderscheppen.
Dit is natuur even simpel gesteld.

Het is allemaal niet zo simpel en niks is veilig zolang mensen zich niet bewust zijn van hun handelen.
Alees valt of staat met bewust zijn.

Ik denk dat het wat onduidelijk omschreven is. Ik vermoed dat namelijk dat het gaat om een token, inclusief MFA claim. De aanvaller kan dus hierdoor alles wat ontsloten is via SSO en/of een MFA requirement heeft omzeilen, tenzij er een sign-in frequency is ingesteld, of bijv. een authentication strength wordt vereist.

https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token#when-does-a-prt-get-an-mfa-claim

Uit het artikel:
Het is via een phishing-link onderschept. Wat daar onderschept kan worden is niet een hardware- of software-token maar een response die door/met dat token gegenereerd is. Ik denk dat simpelweg het woord token door een voorlichter of zo het voor iets anders heeft gebruikt dan voor een hardware- of software-token (zoals een X509-certificaat).

Aan de ene kant zie je dat niet-specialisten in allerlei vakgebieden specialistisch jargon verkeerd gebruiken omdat ze niet helemaal gesnapt hebben waarvoor het gebruikt wordt. Anderzijds hebben specialisten er een handje van om alledaagse woorden van specialistische betekenissen te voorzien, en in de IT gebeurt dat op grote schaal.

Het woord token stamt uiteindelijk uit het proto-Germaans, wat je in de tijd tussen 500 voor en 200 na Christus moet plaatsen. Op de Engelstalige Wikipedia heeft het woord token 26 betekenissen, waaronder een aantal waarbij het token zelf wordt doorgegeven aan anderen. Bij ons is hetzelfde proto-Germaanse woord tot teken geëvolueerd, wat maar met een paar van die 26 Engelse betekenissen overeenkomt; we zouden teken nu eerder naar sign vertalen.

Misverstanden zijn niet zo verwonderlijk, en ook bepaald niet zeldzaam. Wees er verdacht op.

Dit is wat ik ervan begrijp (please correct me if I'm wrong).

Een "evil proxy" kan de door de inlogger ingevoerde gegevens "onderscheppen" in de zin van kopiëren en doorsturen (plan B), maar dat hoeft niet: ongezien doorsturen kan ook (plan A).

Plan A: account tijdelijk misbruiken (totdat het slachtoffer in elk geval uit deze sessie wordt uitgelogd). De AitM (Attacker in the Middle) stuurt alle inloggegevens, nl. user-ID (meestal een e-mailadres), het wachtwoord en een MFA code, door naar de echte server (zonder hier zelf in geïnteresseerd te zijn). Als de inloggegevens correct zijn, retourneert de server een token zoals een session-cookie of een JWT. De AitM kopieert dat token voor eigen gebruik en kiest ervoor om dat token juist wél of juist niet tevens door te sturen naar het slachtoffer.

Plan B: Account overnemen (totdat het geblokkeerd wordt). Een MFA code (door de inlogger ontvangen via SMS of door een Authenticator app gegenereerd) is slechts korte tijd geldig. Dat kan genoeg zijn als de aanvaller het account wil overnemen (*) indien daarvoor opnieuw een MFA code vereist is.

(*) Door het user-ID en de MFA instellingen te wijzigen, en desgewenst het wachtwoord.

Een slimmere server zal een wachttijd inbouwen waardoor er een andere MFA code vereist is. Een slimmere AitM zal daarom met de eerste set gegevens inloggen, maar richting de echte inlogger bijv. liegen dat de MFA code incorrect was en deze het over 30 seconden nogmaals moet proberen. Met die tweede set gegevens kan het account dan worden overgenomen.

En vervolgens met het gestolen MFA token een nieuwe MFA optie registeren.......

Mooi. Zo word er misschien wat terugverdiend van die belachelijke cybersecurity-wedstrijd waar je voor een paar dubbeltjes aan mee moest doen, terwijl je bijdrage 10.000 tot 100.000+ euro waard is.