{"success":true,"data":{"id":"dpop-token-replay-window-lure","label":"Fake RFC 9449 DPoP token replay-window lure — \"refresh your DPoP token within the 300-second iat clock-skew window via our proxy\" / \"re-submit the proof-of-possession JWT via our DPoP refresh endpoint within 5 minutes.\" Sender NOT on the canonical IdP / IETF allowlist (okta.com, auth0.com, microsoft.com, microsoftonline.com, azure.com, login.microsoftonline.com, google.com, accounts.google.com, workspace.google.com, amazon.com, amazonaws.com, awsapps.com, onelogin.com, pingidentity.com, forgerock.com, jumpcloud.com, duo.com, cisco.com, idaptive.com, cyberark.com, sailpoint.com, oneidentity.com, ietf.org, rfc-editor.org). Real DPoP proof refresh happens client-side in the user's app (DPoP proofs are bound to TLS-channel-id and never cross application boundaries) — never via inbound email demanding submission to a third-party proxy. Distinct from R7 PAR / device-code / passkey auth-protocol-param family — this signal is specifically the *DPoP `iat`-window replay* primitive (RFC 9449 Demonstrating Proof of Possession; the `iat` 5-minute clock-skew window enables replay if an attacker captures the proof-of-possession JWT). Source: Red-Team R8 multi-agent council S3 (technical-AiTM specialist).","description":"Fake RFC 9449 DPoP (Demonstrating Proof of Possession) `iat` clock-skew replay-window lure targeting OAuth 2.1 / DPoP-using enterprise app users. The phish narrative arrives as: \"Per RFC 9449, your DPoP proof-of-possession token must be refreshed within the 300-second iat clock-skew window. Click below to refresh your DPoP token via our proxy within 5 minutes, or the API session will be revoked. Action required,\" or \"Your OAuth 2.1 DPoP JWT proof-of-possession is approaching the 5-minute iat replay window. Re-submit the proof-of-possession via our DPoP refresh endpoint within 300 seconds, or the resource server will reject your access token. Mandatory.\" DPoP (RFC 9449, published Sep 2023) binds OAuth access tokens to a public key the client proves possession of via a per-request JWT proof; the proof carries an `iat` claim, and resource servers accept proofs only within a clock-skew window (typically 60-300 seconds). An attacker that captures the DPoP proof-JWT during the `iat` window can replay it against the resource server unless the server enforces the `jti` nonce + key-binding properly. The phish lure tricks the user into submitting their DPoP proof-of-possession JWT to an attacker proxy that captures + replays the proof against the legitimate API. Real DPoP proof refresh happens client-side in the user's app (DPoP proofs are bound to TLS-channel-id and never cross application boundaries) — never via inbound email demanding submission to a third-party proxy. Sender NOT on the canonical IdP / IETF allowlist (okta.com, auth0.com, microsoft.com, microsoftonline.com, azure.com, login.microsoftonline.com, google.com, accounts.google.com, workspace.google.com, amazon.com, amazonaws.com, awsapps.com, onelogin.com, pingidentity.com, forgerock.com, jumpcloud.com, duo.com, cisco.com, idaptive.com, cyberark.com, sailpoint.com, oneidentity.com, ietf.org, rfc-editor.org). Distinct from R7 PAR / device-code / passkey auth-protocol-param family — this signal is specifically the *DPoP `iat`-window replay* primitive (RFC 9449). Fires when body references DPoP / d-pop / \"proof of possession\" / RFC 9449 / \"dpop proof/jwt/token/header\" / \"jwt proof of possession\" AND iat / \"iat (claim/window/skew)\" / \"clock skew (window)\" / 300-second / \"5 minute(s) iat/window/skew/clock\" / \"replay (window/attack)\" / \"300 second(s)\" AND \"refresh (your) DPoP/proof/jwt\" / \"re-submit (the) DPoP/proof/jwt\" / \"via (our/the) proxy/DPoP refresh endpoint\" / \"submit (the) DPoP/proof via\" / \"click below/here to refresh/re-submit/submit\" AND within N minutes-hours-days / action required / mandatory / \"API session revoked\" / \"access token rejected/revoked\" urgency. Excludes the canonical IdP / IETF / RFC-editor domains. Auto-classified as danger via the `-lure` suffix. Source: Red-Team R8 multi-agent council S3 (technical-AiTM specialist).","tier":"danger","category":"other","isThin":false}}