Pff.. again an Entra ID security flaw? It’s incredibly how sloppy their single auth solution is..

Safari on Windows? That browser hasn't been supported since 2012...

What if you have conditional access policy requiring phishing resistant auth to be able to login?

It's not clear who this is an attack for.. organizations that have implemented phishing-resistant MFA will already have CA policy to block any sign-ins that don't have the required authentication strength (that same "You can't get there from here" message users in unsupported browsers get). Maybe it's effective if the organization is in the middle of a rollout, where FIDO is enabled but old MFA methods haven't been disabled yet?

EDIT: This is actually called out in the article:

> The attack sequence relies on the existence of an alternative authentication method (usually MFA), besides FIDO, for the targeted user account. But luckily, this tends to be the case with FIDO implementations, as most admins prefer to maintain a practical option for account recovery.

Most orgs will have TAP for account recovery, but that's not really phishable for other reasons.

Since this relies on simulating safari as the broswer, I wonder if a conditional access policy enforcing browser selection would help mitigate this.

While only realistic for a small number of users, I've started enforcing users of privileged tools to go through a wireguard instance before being allowed to access Azure hosted tools that rely on Entra auth. Services I publish then have a ingress whitelist of said wireguard VM.