Device code phishing has escalated from a niche red-team tactic to an industrial-scale criminal operation. Push Security currently tracks more than 25 device-code phishing kits—many capable of bypassing passkey protections—while Barracuda Networks recorded 7 million such attacks in a single four-week period. Attackers are exploiting the OAuth 2.0 device authorization grant, a legitimate authentication flow designed for input-constrained devices like smart TVs and printers, to harvest access tokens at volume, enabling widespread credential theft.
The attack unfolds by deceiving users into authenticating on their own trusted devices. Victims, often contacted via phone, email, or chat, are directed to a genuine identity-provider login page (such as login.microsoftonline.com) and prompted to enter a short, attacker-provided code. Upon successful authentication, frequently involving multi-factor authentication, the attacker receives a valid access token and can impersonate the user. Because the authentication event is genuine, conventional MFA controls fail to block the resulting session.
Security researchers at Push and Barracuda identify a fundamental design mismatch as the core vulnerability. The device-code flow was never intended for the broad array of cloud applications now utilizing it, and many consent screens lack sufficient transparency, obscuring the requesting application's identity. This combination of poor visibility and high success rates has allowed criminal groups to rapidly industrialize the method, requiring minimal technical skill for significant impact.
For organizations, immediate defense hinges on two pillars. First, user education must instill a non-negotiable rule: never enter a third-party code into a login prompt, as legitimate support personnel will never initiate authentication this way. Second, technical hardening is essential, including conditional access policies that restrict device-code grants to approved applications and enhanced monitoring for anomalous patterns within identity providers like Microsoft Entra ID and Google Workspace.
The research explicitly calls on platform vendors to implement native safeguards. Recommended measures include clearer consent screens that prominently display the requesting application's name and purpose, rate-limiting of device-code requests, and specialized anomaly detection tuned to this authentication flow. Without such vendor-side enhancements, the protocol will remain a reliable channel for token theft.
This threat underscores a broader tension in modern identity systems: protocols designed for constrained devices are now embedded in everyday cloud workflows, often without adequate fraud controls. Open-source projects and enterprise teams alike must balance usability against the reality that attackers will weaponize any authentication path lacking strong user-visible context and server-side monitoring.
While major platforms have begun discussing enhanced protections, concrete, out-of-the-box detection capabilities and real-time indicators that organizations can monitor before token issuance remain open questions. Until standardized anomaly detection models emerge and vendors deliver timely updates, the most practical defense combines rigorous user training with stricter policy configuration—a layered approach necessary to counter this industrialized threat.
裝置碼釣魚攻擊已從小眾的紅隊戰術演變為大規模的犯罪操作。安全公司Push Security目前正追蹤超過25種裝置碼釣魚攻擊套件——許多具備繞過Passkey保護的能力，而Barracuda Networks則記錄了在短短四週內發生的700萬次此類攻擊。攻擊者正利用OAuth 2.0裝置授權授予——一種為智能電視和打印機等輸入受限裝置設計的合法認證流程——大規模收割存取權杖，從而導致廣泛的憑證盜竊。
攻擊的過程是透過欺騙用戶，在其自身受信任的裝置上進行認證。受害者通常透過電話、電子郵件或聊天聯繫，被引導至真實的身份提供商登入頁面（例如login.microsoftonline.com），並被要求輸入一個由攻擊者提供的簡短代碼。在成功完成認證後（通常涉及多因素驗證），攻擊者會收到一個有效的存取權杖，並可以冒充該用戶。由於認證事件本身是真實的，傳統的MFA控制機制無法阻止隨後建立的會話。
Push及Barracuda的安全研究人員指出，根本的設計錯配是核心漏洞。裝置碼流程並非為目前眾多使用它的雲端應用程式而設計，且許多同意畫面缺乏足夠的透明度，模糊了請求應用程式的身份。這種低能見度與高成功率的結合，使得犯罪集團能快速將此方法工業化，僅需最少的技術技能即可造成重大影響。
對於組織而言，即時的防禦依賴於兩大支柱。首先，用戶教育必須灌輸一條不可商量的規則：切勿在登入提示中輸入第三方代碼，因為合法的技術支援人員永遠不會以這種方式發起認證。其次，技術強化至關重要，包括限制裝置碼授予僅限於經核准應用程式的條件式存取策略，以及加強對Microsoft Entra ID和Google Workspace等身份異常模式的監控。
這項研究明確呼籲平台供應商實施原生防護。建議措施包括：更清晰的同意畫面，突出顯示請求應用程式的名稱與用途；對裝置碼請求進行速率限制；以及針對此認證流程調校的專門異常檢測。若沒有這些供應商端的增強措施，該協議將繼續成為權杖竊取的可靠管道。
此威脅凸顯了現代身份系統中更廣泛的矛盾：為受限裝置設計的協議如今已被嵌入日常的雲端工作流程中，卻往往缺乏足夠的防詐騙控制。開源項目和企業團隊同樣必須在易用性與一個現實之間取得平衡——攻擊者會將任何缺乏強力可見用戶情境與伺服器端監控的認證路徑武器化。
雖然主要平台已開始討論更強的保護措施，但組織可在權杖發放前監控的、具體且開箱即用的檢測能力及即時指標，仍是懸而未決的問題。在標準化的異常檢測模型出現以及供應商提供及時更新之前，最實用的防禦結合了嚴格的用戶培訓與更嚴格的策略配置——這是一種必須採用的分層方法，以對抗這種工業化威脅。