{"success":true,"data":{"id":"webauthn-cross-origin-iframe-lure","label":"Fake WebAuthn L3 cross-origin iframe assertion-harvest lure — \"re-enroll your passkey within the embedded iframe\" / \"complete the cross-origin WebAuthn assertion via navigator.credentials.get within 48 hours.\" Sender NOT on the FIDO-canonical allowlist (yubico.com, fidoalliance.org, microsoft.com, microsoftonline.com, azure.com, google.com, workspace.google.com, apple.com, icloud.com, okta.com, auth0.com, duo.com, rsa.com, thalesgroup.com, feitian-tech.com, hypersecu.com, w3.org). Real WebAuthn assertion flow happens within a top-level navigation to the relying-party origin, never within a cross-origin iframe embedded in an attacker page. Fresh 2024+ surface area (WebAuthn L3 spec); distinct from R6 MFA push-fatigue and R8 OIDC-backchannel-logout — this signal is specifically the *cross-origin WebAuthn assertion harvest* pretext, where the attacker iframes the legitimate RP and harvests the resulting publickey-credential assertion. Source: Red-Team R8 multi-agent council S3 (technical-AiTM specialist), Lead consensus C2 extension.","description":"Fake WebAuthn L3 cross-origin iframe assertion-harvest lure targeting passkey-using and FIDO2-using enterprise app users. The phish narrative arrives as: \"Per the new WebAuthn L3 cross-origin iframe primitive, re-enroll your passkey within the embedded iframe sign-in. Click below to call navigator.credentials.get and complete the cross-origin WebAuthn assertion within 24 hours,\" or \"Per WebAuthn Level 3, the relying-party allows cross-origin iframes calling navigator.credentials.get for passkey assertion. Re-authenticate your security key within the embedded iframe within 48 hours, or your account access will be locked.\" When the WebAuthn L3 spec landed (2024+), the cross-origin iframe primitive made it possible for a relying-party origin to opt-in to allowing iframes from third-party origins to call `navigator.credentials.get()` and harvest the resulting publickey-credential assertion. An attacker page with a cross-origin iframe to the legitimate RP (with `allow=\"publickey-credentials-get *\"` permission policy) can prompt the user for a WebAuthn assertion that the user reads as a routine RP sign-in but which the attacker page now possesses and can replay against the RP origin. Real WebAuthn assertion flow happens within a top-level navigation to the relying-party origin (not within a cross-origin iframe) so the user can verify the URL bar; legitimate RPs do not enable the cross-origin iframe permission policy because of exactly this risk. Sender NOT on the FIDO-canonical allowlist (yubico.com, fidoalliance.org, microsoft.com, microsoftonline.com, azure.com, google.com, workspace.google.com, apple.com, icloud.com, okta.com, auth0.com, duo.com, rsa.com, thalesgroup.com, feitian-tech.com, hypersecu.com, w3.org). Fresh 2024+ surface area (WebAuthn L3 spec); distinct from R6 MFA push-fatigue (push-bombing) and R8 OIDC-backchannel-logout (logout_token JWT) — this signal is specifically the *cross-origin WebAuthn assertion harvest* pretext where the attacker iframes the legitimate RP and harvests the resulting publickey-credential. Lead consensus C2 extension (Red-Team R8 multi-agent council): same shape as the auth-protocol-param family — extend canonical-IdP allowlist to WebAuthn cross-origin endpoints. Fires when body references WebAuthn / WebAuthn L3 / WebAuthn Level 3 / passkey / FIDO-2 / navigator.credentials.get / \"navigator credentials get\" / publickey-credential AND \"cross-origin iframe/WebAuthn/assertion/passkey\" / \"embedded iframe\" / \"iframe sign-in/WebAuthn/assertion/credentials\" / \"cross-origin assertion/credentials.get\" AND \"re-enroll(ment) your passkey/WebAuthn/security key/credential\" / \"re-authenticate\" / \"complete the WebAuthn/cross-origin assertion\" / \"sign-in within/via the embedded/cross-origin iframe\" AND within N hours-days / 24-48 hours / action required / \"account will be lock/locked/revoke/locked out\" / \"access will be lock/locked/revoked\" urgency. Excludes the canonical FIDO / passkey vendor domains. Auto-classified as danger via the `-lure` suffix. Source: Red-Team R8 multi-agent council S3 (technical-AiTM specialist), Lead consensus C2 extension.","tier":"danger","category":"phishing","isThin":false}}