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.
webauthn-cross-origin-iframe-lure
What this tier means
High-confidence threat indicator — phishing, impersonation, BEC, or scam pattern. Strong contributor to the trash decision.
How Gorganizer detects this
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.
False-positive guard
Every signal in Gorganizer feeds a multi-module score — never a sole verdict. This is a threat-tier signal — it adds a strong contribution to the trash score. The full pipeline still requires convergence across multiple modules + a margin over the safety floor before deletion happens, and Gmail's trash (30-day recovery) is always used — never permanent delete.
About the scoring engine
Gorganizer's scoring engine emits over 1,800 signals across six modules — headers, sender, subject, body, attachments, and structural metadata. Every email is scored by every module independently; the final verdict requires multiple modules to agree and the trash score to beat the safety floor by a margin.
Sacred safety guards — never delete starred emails, replies, calendar invites, receipts/invoices, or attachments — apply unconditionally regardless of any signal.
Ready to clean your inbox?
Gorganizer scans your Gmail with this signal and 1,800+ others, then cleans everything in one click. $4.99 one-time, no subscription.
Get started