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.
tatersolid · 14h ago
Basically all other identity providers are also vulnerable to phishers which strip out webautn calls in the payload when acting as a proxy to the real IdP.
Basically you must disable all other phishable forms of MFA fallback if you want phishing-resistant FIDO2/passkeys. Conditional access policies in Entra can do this selectively or org-wide. If you don’t do this you’re relying on “end user training and wariness” again as phishing protection.
parliament32 · 13h ago
Yes, exactly. But there is little point of going through the pain and effort of rolling out phishing-resistant MFA if you're going to leave non-phishing-resistant methods available / as a fallback...
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.
lousken · 15h ago
What if you have conditional access policy requiring phishing resistant auth to be able to login?
parliament32 · 13h ago
Then the attack won't work, because this depends on you (for some reason) having both FIDO and non-phishing-resistant MFA methods available at the same time.
Loudergood · 15h ago
Safari on Windows? That browser hasn't been supported since 2012...
moi2388 · 15h ago
Pff.. again an Entra ID security flaw? It’s incredibly how sloppy their single auth solution is..
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.
Basically you must disable all other phishable forms of MFA fallback if you want phishing-resistant FIDO2/passkeys. Conditional access policies in Entra can do this selectively or org-wide. If you don’t do this you’re relying on “end user training and wariness” again as phishing protection.
https://taptrap.click/
No comments yet
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.