前言
自從我接觸到 Passkey 之後，就強烈感受到「這才是理應存在的認證樣貌」，此後也一直積極推廣 Passkey。
在這樣的過程中，我得知有一種即使使用 Passkey 仍可能遭受攻擊的方法，也就是「濫用裝置代碼流程的釣魚攻擊」，因此大為震驚。
作為推動無密碼認證的一方，光說「用了 Passkey 就安全」是不夠的。我認為必須理解還殘留哪些風險，並連同對策一起傳達，因此開始調查這個機制。
查過之後發現，雖然這種攻擊手法是近年才受到關注，但裝置代碼流程本身的風險其實早就被指出。反過來說，也可以認為是隨著 MFA 與 Passkey 的普及，傳統密碼攻擊變得困難，攻擊者才轉而鎖定其他路徑。
Passkey 是非常強大的認證方式，但也正因如此，更必須正確理解它的限制與周邊風險。本文想整理什麼是裝置代碼流程、為什麼會被拿來做攻擊，以及在 Microsoft Entra ID 中可以採取哪些對策。
本文介紹的主要對策
- 在登入記錄中確認裝置代碼流程的使用狀況
- 掌握使用者與應用程式的使用情況
- 透過條件式存取封鎖裝置代碼流程
- 封鎖後從登入記錄確認影響範圍
- 向使用者周知裝置代碼流程的風險
- 不只保護 Passkey，也要保護整體驗證流程
Entra ID / Passkey 相關文章系列介紹
以下的收藏清單整理了我撰寫的 Entra ID 與 Passkey 相關文章，歡迎參考：
https://qiita.com/carol0226/stocks/3670cb8678daed11b191
[9/9 Avanade Tech Japan LT]
（活動 URL）https://avanadejapantech.connpass.com/event/403423/
我臨時在 Avanade 先生的 Connpass 研討會上進行了飛入式簡報。
Qiita 的投影片模式幫了大忙。
[LT影片] 即使有 Passkey 也會受害的裝置代碼流程攻擊是什麼？～ 解說 Entra ID 的防禦與驗證方法 by @carol0226
什麼是裝置代碼流程？
裝置代碼流程是一種即使沒有鍵盤或瀏覽器的裝置，也能進行認證的機制。
最容易理解的例子，就是在智慧型電視、Fire TV Stick、Apple TV 等裝置上登入 Netflix 之類的影音串流服務。
用電視遙控器輸入長密碼很麻煩，因此可以先在電視上顯示 QR Code，再用智慧型手機掃描，並在手機端完成驗證，如此一來電視端也會自動登入。
Microsoft Entra ID 的裝置代碼流程基本概念也是一樣。它會在與欲進行認證的裝置不同的另一台裝置上完成驗證，並透過共享結果來實現登入。
原本這是非常方便的機制，但若遭到濫用，也可能被用於釣魚攻擊。
※這張圖片不是實際照片的截圖，而是由生成式 AI 製作的示意圖。
Netflix 官方：在家中電視登入 Netflix 的步驟
https://help.netflix.com/ja/node/311830241325668
（摘錄如下）
理解裝置代碼流程遭濫用的例子
本文以 Netflix 為例，但多數影音訂閱服務都採用類似機制。
你有沒有過這樣的經驗？
你是 Netflix 訂閱者，而且人在公司。
你的孩子（或家人）跟你說，家裡電視的登入已經失效，看不到 Netflix……
你機警地說：「那把電視上顯示的代碼告訴我吧」，然後完成裝置代碼流程驗證。
接著家人回你：「啊，認證成功了。現在可以看 Netflix 了！」
但其實，如果你的孩子不是在家，而是在朋友家聯絡你呢……
那就會變成在不是你家、而是別人的家裡，卻能用你的訂閱看 Netflix。
這就是為了幫助理解裝置代碼流程濫用所舉的例子。
另外，裝置代碼流程絕對不是什麼特殊的認證方式。
由於 Azure PowerShell、Microsoft Graph PowerShell 等管理工具也能使用，因此某些組織可能已將它納入日常作業流程中。
因此，不能單純想成「很危險，封鎖掉就好」，而是應該先確認自家組織是否真的有使用實績。
實際使用 Azure 的人，可能在不知不覺間就曾用過裝置代碼流程。
如果你長期使用 Azure，或許曾在登入 Azure PowerShell 時看過如下訊息：
其實這就是裝置代碼流程。
在早期的 Azure PowerShell，以及目前仍可使用的某些驗證方式中，都是透過這套機制來完成認證。
也就是說，裝置代碼流程並不是特殊的認證方式，而是許多 Azure 工程師平常就一直在使用的機制。
公開資訊：Azure PowerShell -UseDeviceAuthentication
https://learn.microsoft.com/ja-jp/powershell/module/az.accounts/connect-azaccount?view=azps-16.3.0&wt.mc_id=MVP_407731#-usedeviceauthentication
這是什麼樣的風險？
如下列文章所示，裝置代碼流程的濫用，也已在利用飯店 Wi-Fi 認證畫面（Captive Portal）的攻擊情境中被確認。
為什麼危險？
例如，假設你人在出差飯店，準備連上 Wi-Fi。
使用者原本以為自己是在依照飯店的認證畫面操作，但過程中卻可能出現 Microsoft 的登入畫面。
這裡顯示的 Microsoft 登入畫面並不是假的，而是真正由 Microsoft 提供的正式畫面。
因此，使用者可能不會起疑，而直接用 Passkey 或 MFA 完成認證。
結果，使用者的認證會完成攻擊者側客戶端所發起的裝置授權請求。
也就是說，這種攻擊不是竊取密碼或 Passkey 的攻擊。
使用者是在正式的 Microsoft 網站上進行認證，Passkey 與 MFA 也都正常運作。即便如此，只要使用者完成認證，攻擊者端所啟動的裝置代碼流程就會被核准，攻擊者的客戶端就可能取得權杖。
因此，即使 Passkey 沒有被破解，攻擊者仍可能取得可冒用使用者身分存取 Microsoft 365 或 Azure 的權杖。
攻擊流程
- 攻擊者先做好準備
攻擊者事先啟動裝置代碼流程，取得驗證代碼。 - 誘導使用者
利用偽造的 Wi-Fi 認證畫面或釣魚郵件，引導使用者前往 Microsoft 的裝置登入畫面，並輸入攻擊者取得的驗證代碼。 - 使用者進行正式認證
使用者看到的是正版 Microsoft 登入畫面，接著用 Passkey 或 MFA 照常完成認證。 - 攻擊者取得權杖
認證結果不是綁定在使用者自己身上，而是綁定到攻擊者所發起的裝置代碼流程工作階段。因此，攻擊者端客戶端有可能取得被允許範圍內的存取權杖。 - 進一步濫用
若受害者是具有管理權限的使用者，且取得的權杖包含管理操作所需權限，就可能導致權限變更等嚴重影響。
在 Entra ID 中該如何防範？
如前所述，裝置代碼流程雖然便利，但也可能被攻擊者濫用。
因此 Microsoft 建議透過條件式存取（Conditional Access）來限制或封鎖裝置代碼流程本身。
Microsoft Learn 上也公開了以下文件。
公開資訊：使用條件式存取原則封鎖驗證流程
https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/policy-block-authentication-flows?wt.mc_id=MVP_407731
不過，如前一章所說，裝置代碼流程可能已被 Azure PowerShell、Microsoft Graph PowerShell 等工具使用，若直接無條件封鎖，可能會導致組織內業務中斷。
因此，對於組織租戶，不應一開始就直接封鎖，而是要先確認：
- 目前是否有在使用
- 哪些使用者有在使用
- 是否真的可以放心封鎖
確認完再套用，這一點非常重要。
實際試試裝置代碼流程
裝置代碼流程是 Azure PowerShell 認證的其中一種方式，屬於正規認證；但在這裡，我會一邊說明流程，一邊標出在被濫用時的立場。請帶著這個立場來看。
立場：攻擊者角色
先產生裝置代碼流程。
Connect-AzAccount -UseDeviceAuthentication
說明
從 Azure PowerShell 啟動裝置代碼流程後，會顯示驗證代碼。接著從瀏覽器前往 https://microsoft.com/device，輸入這組代碼完成認證。
這是正規流程。
※故意改成從執行 Connect-AzAccount 的那台電腦以外的裝置（例如手機）操作，應該就能看出這是跨裝置完成驗證。
將上面產生的 URL 與代碼送給攻擊對象。
※假設是以欺騙當事人的方式，誘導他點開網址並輸入代碼。
釣魚郵件範例
若收到這類郵件，正確做法是
- 不要回應自己沒有主動發起的裝置驗證
- 不要輕易把郵件或聊天中收到的代碼輸入到頁面
- 不要只因為是 Microsoft 正規畫面就視為安全
- 要確認畫面上顯示的應用程式名稱與認證目的
- 若有可疑，應取消並聯絡組織的窗口
立場：標的使用者角色
假裝自己相信了攻擊者寄來的郵件，點擊連結並輸入郵件中提供的代碼。
※此時，輸入的代碼會把使用者的認證操作綁定到攻擊者已啟動的裝置授權請求。也就是說，等於是你在幫攻擊者的工作階段完成認證。
（認證畫面）
會開啟正式的認證畫面。
在這裡，輸入電子郵件地址後，透過 MFA 進行驗證，或選擇登入選項。
接著進行 Passkey 認證。
※不一定要用 Passkey，也可以用 MFA 測試。
（認證成功畫面：操作認證的一方）
正常來說，這時應該覺得不對勁並按下取消，還來得及。
但這裡假設因為太相信對方，而按下了 繼續。
登入成功了。
此時，攻擊者就可能已經能夠存取。
立場：攻擊者角色
（認證成功畫面：Azure PowerShell 端）
攻擊者角色也已成功登入。
在攻擊者的裝置上，就能透過 Azure PowerShell 以該已認證使用者所擁有的權限範圍存取資源。
這裡因為沒有做條件式存取控制，所以透過裝置代碼流程的認證會正常完成。接下來來確認登入記錄。
在登入記錄中確認使用狀況
在 Microsoft Entra 管理中心顯示登入記錄。
選擇允許的時間範圍：最近 1 個月。
按下新增篩選條件，選擇原始傳輸方式，再選擇裝置代碼流程，然後按下套用。
接著就會顯示如下所示，透過裝置代碼流程完成驗證的記錄。
確認前一章測試時的時間、使用者、應用程式與結果是否一致。若還有其他記錄出現，則要從詳細資訊判斷是正當業務使用，還是可疑嘗試。
點擊記錄列即可查看詳細資訊。
若記錄中有本文測試之外的項目，請確認以下事項：
- 是誰在使用
- 是哪個應用程式在使用
- 現在是否仍有使用實績
- 是否可以封鎖
透過條件式存取封鎖裝置代碼流程
以下是公開資訊中所解說的條件式存取原則設定範例。
公開資訊：使用條件式存取原則封鎖驗證流程
https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/policy-block-authentication-flows?wt.mc_id=MVP_407731
如下所示，在 條件 的設定中選擇驗證流程。
如果是第一次使用條件式存取，請參考我的以下文章。
安全性預設值群組與條件式存取的首次使用
https://qiita.com/carol0226/items/51a70a561b78af567972
在要排除的特定使用者欄位中，請指定下方文章中說明的 Break glass 帳號。
緊急存取管理帳號（Break glass）入門：從基本架構到非典型額外配置完整說明
https://qiita.com/carol0226/items/bbd69bdc907a48f0e67f
封鎖前想確認的使用情境（2026/9/10 20:00 補充）
我從看過我文章的 MVP @Shokolate 那裡得到了建議。
具體來說，如下方文件所述，若是沒有輸入裝置的裝置，例如會議設備，就需要使用裝置代碼流程。因此，若組織有這類設備在運作，應該要做排除處理。
公開資訊：條件式存取：驗證流程（裝置代碼流程）
https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-authentication-flows?wt.mc_id=MVP_407731
不過在這份公開資訊中，也再次強調了以下內容：
只在必要時允許裝置代碼流程。 Microsoft 建議盡可能封鎖裝置代碼流程。
實際驗證是否能封鎖
在啟用條件式存取原則的狀態下，嘗試透過裝置代碼流程進行認證。
這次同樣使用 Azure PowerShell 的 UseDeviceAuthentication 來驗證。
Connect-AzAccount -UseDeviceAuthentication
照前面相同方式執行裝置代碼流程認證後，結果如下圖所示，已被封鎖。
確認封鎖後的登入記錄
再次查看登入記錄，可以找到失敗的記錄。
選取該列，在顯示的詳細畫面中選擇 條件式存取 分頁。
這樣就能確認剛剛建立的條件式存取規則已經將其封鎖。
另外，按下右側的 ...，還可以查看詳細資訊。
可以確認是因為條件式存取而被封鎖的理由。
總結
這次調查之後，我再次認識到 Passkey 本身的堅固性，以及保護整體驗證流程的重要性。
這次攻擊所濫用的不是 Passkey 本身，而是認證周邊機制中的裝置代碼流程。
使用者是在 Microsoft 正規的登入畫面完成認證，並沒有洩漏 Passkey 的秘密資訊，也沒有破壞 Passkey 的密碼學機制。
更有意思的是，攻擊者不是正面突破 Passkey，而是選擇濫用裝置代碼流程這種認證周邊機制。
反過來說，這也顯示出相較於密碼與傳統 MFA，直接突破 Passkey 本身已經變得更困難。但這並不代表可以放心。當認證方式變強時，也必須注意攻擊者可能會轉而鎖定認證周邊流程與使用者操作。
正因為是推廣 Passkey 的立場，更應該理解它的優勢、限制與周邊風險，並結合條件式存取控制、登入記錄監視等適當對策一起導入。
這次案例可以說不是「Passkey 被破解」，而是「使用 Passkey 前後的驗證流程被濫用」的情況。
而且，我們也確認了這種攻擊可以透過 Microsoft Entra ID 的條件式存取來加以控制。
建議先從登入記錄確認實際使用情況，在評估自家組織的影響後，再考慮適當的控制方式。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
