先記結論：自稱 IT 的電話叫你「立刻更新通行金鑰」時，危險不在 Passkey 私鑰被拷走，而在你把一次有效登入交給了對方。中間人截的是工作階段；裝置碼流程裡，登入頁甚至可以是微軟真網域。改密碼只覆蓋口令這一層，擋不住已經登記的陌生驗證器。能當場核對的是：來電路由、網址列主機名稱、安全性資訊頁有沒有多出裝置，而不是「我已經用了 Passkey」。
一句話先回答搜尋意圖
通行金鑰（Passkey）按 WebAuthn 設計，私鑰留在本機或同步鑰匙圈，並綁定依賴方的來源網站。假登入頁拿不到這塊私鑰，這是「抗網釣」這句話能成立的範圍。它不能成立的範圍是：你被催著走完一次登入，工作階段權杖落到對方手裡；或者你在真網域上輸入別人給你的裝置碼，把權杖核發給對方控制的應用程式。
這篇文章給已經開了通行金鑰、仍會被電話或簡訊催「更新」的人，以及要給同事解釋「為什麼 Passkey 不是免責金牌」的開發者和維運。它不代替微軟的事故通報，也不寫成「怎麼關掉通行金鑰」。你要帶走的是：話術覆蓋哪一層、工作階段和裝置碼各偷哪一層、改密碼為什麼不夠，以及掛掉電話之後能在本機核對什麼。
微軟這次揭露拆開了哪幾層
2026 年 9 月 9 日，微軟安全研究發布英文通報。他們追蹤的是一組仍在進行的雲端身分入侵：異常登入之後，出現對方新增的驗證方法、大量 Microsoft Graph 存取、SharePoint 與 OneDrive 下載，以及透過 REST API 收集郵件。通報寫明，這類活動從 2026 年 5 月起被觀察到。
開頭不是一封精緻的釣魚信，而是打到私人門號的電話或簡訊，也就是台灣常說的語音網釣。來電自稱公司 IT 服務台，製造緊迫感：通行金鑰、多重要素驗證或單一登入必須立刻更新，否則帳號會中斷。連結常常另用簡訊發到同一支私人手機。微軟寫得很乾脆：儘管話術圍著 Passkey 轉，登記通行金鑰常常不是真正目標。藉口的作用是把人帶進兩條技術路徑——中間人（AiTM）網釣，或裝置碼授權。
中間人路徑截的是憑證和工作階段權杖。裝置碼路徑裡，受害人被說服在微軟自己的驗證頁輸入一串碼，權杖發給對方控制的用戶端，不必再偷瀏覽器 Cookie。兩條路都可能讓後續存取不再碰一次 MFA。若連結開在未納入 Defender 的私人手機上，端點側可能幾乎沒有痕跡；調查時，當事人對電話或簡訊的回憶，常常是解釋「入侵從哪開始」最早、有時也是唯一的證據。
基礎建設也按「看起來眼熟」來搭。通報列出的主題網域包括 passkeyhelpdesk.com、setupmypasskey.com、add-passkey.com、secure-passkey.com，以及把公司名嵌進子網域的形態，例如 contoso.add-passkey.com。同一家公司名還可以出現在 integratedsso.com 這類 SSO 主題網域下。網域註冊後數小時就能用，給攔截窗口很短。部分案例裡，對方還會用已經淪陷的同事帳號，在 Teams 裡發同一套「更新通行金鑰」訊息，把內部信任疊到電話之外。
微軟把初始存取活動關聯到包括 Storm-3121、Storm-3032 在內的多組操作方。Storm-3121 的後續常接到 ShinyHunters 與 Falcon 勒贖；Storm-3032 被描述為從 BlackFile 分裂、現在打 Helix 旗號的一撥人。這只說明生態，不證明你接到的每一通「IT 電話」都來自同一集團。能寫進交接說明的，是話術加兩條技術路徑，不是某個集團名字。
通行金鑰擋得住假站，擋不住交出去的工作階段
把「抗網釣」讀成「再也不會被騙」，是把憑證層和工作階段層焊成了一句。通行金鑰在登記時綁定網站來源。假網域就算做成和微軟登入頁一樣，通常也拿不到你為 login.microsoftonline.com 存下的私鑰。這是 Passkey 相對密碼複用的真實優勢，不必否定。
微軟調查裡的一條時間線，把「優勢停在哪」寫清楚了。T+0 分，未受管理環境存取 OfficeHome，回傳錯誤 50074，要求二次驗證；T+1 分，MFA 完成（通報寫明是中間人加上非抗網釣 MFA），隨後 50140 中斷「保持登入」；同一分鐘驗證成功，工作階段建立。接下來大約一小時內，同一工作階段開啟 My Apps、個人資料、核准管理、安全性資訊，再經 Graph 列舉 SharePoint 與 Outlook。工作階段在，對方就不必再碰你的通行金鑰。
所以「我已經用了 Passkey」只能支援很窄的結論：假站很難直接匯出這塊私鑰。它不能支援：你不會被催著在仿冒頁上再走一遍密碼或簡訊碼；中間人拿不到這次登入換來的權杖；安全性資訊頁不會多出對方的驗證器。後幾句要另找證據：看你點開的主機名稱是不是官方登入網域，以及登入之後安全性資訊有沒有陌生裝置。
不要用真實工作帳號去「試探」來電裡的連結或裝置碼。準備一句可丟棄的說法就夠：掛斷，改走公司書面公布的 IT 管道回撥。核對的是來電路由和網址列，不是把一次有效登入再送給對方。
裝置碼為什麼能在真網域上得手
中間人至少還要搭一張像登入頁的站。裝置碼（裝置代碼流程）把這層也拆掉了。官方流程本來就是：一個用戶端顯示短碼，你在瀏覽器開啟微軟的裝置登入頁，輸入這串碼，等於批准「那個用戶端」代表你存取資源。頁是真的，憑證是真的，網址列也經得起「是不是微軟」。被騙的點換成了：這串碼是誰產生的、批准會落到誰的應用程式。
通報裡的第二條攻擊序列就是這樣：通行金鑰話術之後走裝置碼，受害人在合法驗證頁輸入對方提供的碼，權杖發給對方控制的用戶端。之後對方重放這枚權杖，列舉目錄和檔案，不再需要再偷 Cookie，也不再需要再過一次 MFA。對習慣檢查「鎖頭和網域」的人，這比假站更難當場拆穿——你檢查的那一層是綠的。
因此，「網址列是微軟」只能支援：你沒有把口令打進 add-passkey.com 這種仿冒主機。它不能支援：這個碼屬於你自己的筆電；批准之後權杖只會留在你的瀏覽器。別人電話、簡訊或即時訊息裡念給你的碼，預設要按「對方的用戶端」處理，而不是按「官方頁面所以安全」處理。
改密碼為什麼蓋不住已經登記的驗證器
得手之後，對方第一件事往往不是繼續翻檔案，而是把自己的驗證方法寫進你的身分。通報寫的是：新手機號碼、驗證器應用程式，或軟體一次性口令。2026 年 9 月 4 日的一條真實稽核範例裡，新增紀錄的裝置名是 NO_DEVICE，裝置標記是 SoftwareTokenActivated，雜湊函式欄位為 hmacsha1。這不是「又設了一個密碼」，而是以後的二次驗證可以由對方完成。
微軟給確認淪陷帳號的處置順序是連在一起的：撤銷活動工作階段和重新整理權杖、重設憑證、刪除對方登記的驗證方法、拿掉對方加的信箱規則，並要求用抗網釣方式重新登記。只改密碼、不看安全性資訊頁，等於留下一把對方已經配好的鑰匙。第三條調查序列還顯示，對方可以隔幾天再用稍早登記的 PhoneAppOTP 登入，然後用 Node.js 自動化走 Graph——口令對了、二次驗證也「過了」，過的是他們自己的因素。
本地 密碼檢測 對照的是公開高頻弱密碼名單，待測密碼不上傳，也不是全網撞庫。它能告訴你這串口令是不是太常見，不能告訴你安全性資訊頁有沒有多出 NO_DEVICE，也不能證明剛才那通電話是假的。弱密碼和工作階段劫持不是同一欄資料，不要互相代替。
| 你看見的說法 | 能支援的結論 | 不能支援的結論 |
|---|---|---|
| 我已經登記了通行金鑰 | 假站很難直接匯出這塊私鑰 | 再也不會被催著交出一次有效登入 |
| 網址列是微軟官方網域 | 你沒有把口令打進仿冒主機 | 裝置碼批准的一定是你自己的用戶端 |
| 電話自稱本公司 IT，還報得出部門名 | 對方做了公開資訊偵察 | 來電走的是公司核實過的回撥管道 |
| 我改掉了密碼 | 口令這一層已輪換 | 陌生驗證器和未撤銷的工作階段都失效了 |
| 簡訊連結開在私人手機，電腦沒中毒 | 這台工作電腦的端點紀錄可能是空的 | 雲端身分沒有建立過對方的工作階段 |
| 同事在 Teams 裡也催我更新 Passkey | 訊息來自一個已登入的內部帳號 | 這個帳號此刻一定仍由本人控制 |
掛掉電話之後，當場能核對哪幾層
口號不能當證據。下面只核對應由你控制的事：來電是不是走既有管道、即將點開的主機名稱、安全性資訊頁有沒有多出裝置。不要用正式帳號去開啟來電裡的連結做實驗。
- 掛斷。用公司書面公布的 IT 工單、內部入口網站或回撥號碼聯絡，不要回撥剛才那通來電，也不要點簡訊裡的連結。微軟建議給員工一條核實過的管道，用來回報主動找上門的驗證要求。
- 若你已經點開連結：只看網址列主機名稱。公司名出現在子網域、後綴卻是
add-passkey.com、setupmypasskey.com或secure-passkey.com，這不是微軟登入網域。不要在這一頁輸入口令、簡訊碼或通行金鑰確認。 - 若有人要你「在官網輸入一串碼」：先問這串碼是哪個應用程式、哪台裝置產生的。別人念給你的碼，按對方用戶端處理。官方裝置碼頁是真的，批准對象仍可能是對方的應用程式。
- 登入公司帳號後，開啟安全性資訊 / My Sign-Ins，逐條看驗證方法。多出來的手機號碼、驗證器、軟體權杖，尤其是裝置名不像你自己手機的，按管理員流程撤銷工作階段並刪除，不要只改密碼。
- 必須把一次性短秘密交給已經核實過的同事時，改走密文通道。開啟 閱後即焚，寫入一句可丟棄的金絲雀，例如
canary-fp-20260921-passkey-lure。開啟開發者工具的 Network，勾選 Preserve log。產生後搜這句金絲雀：POST /secrets的請求體裡應只有密文、過期時間和閱讀次數，不應出現原文，也不應出現井號後的金鑰。連結形態是s.html?id={id}#{key}；RFC 9110 規定請求目標 URI 不含 fragment。
前四步處理的是身分被接管的通道。第五步處理的是另一件常見誤操作：把「IT 要的碼」或臨時口令截圖傳進聊天。圖床和相簿會留下像素和可能的 OCR，上一篇已經寫過。焚鏈只上傳密文，金鑰留在 # 後面。兩條通道不要混用——不要先截進聊天，再把完整焚鏈 URL 貼回同一張圖。
完整連結和密文不要走同一條管道。電話裡報出來的裝置碼、聊天裡的截圖、焚鏈的 s.html?id=…#… 整串，是三種不同的外洩面。把鑰匙和鎖寫在同一條訊息裡，井號後的保護對「能看見這條訊息的人」已經沒了。
三種把「我有 Passkey」讀過頭的情況
第一，把抗網釣當成抗社交工程。通行金鑰綁定來源網站，針對的是假登入頁直接拿走私鑰。電話、簡訊、內部聊天可以繞開這一層，把你帶到中間人或裝置碼。微軟自己的緩解清單裡，和「強制抗網釣 MFA」並列的，是針對語音與郵件網釣做訓練，以及攔截不必要的裝置碼流程。
第二，把「頁面是官方的」當成「批准對象是我的」。裝置碼頁可以是真網域。你檢查鎖頭圖示，檢查不到權杖核發給誰。判斷依據是碼的來源：自己裝置跳出的，和電話裡念的，不是同一件事。
第三，把改密碼當成收尾。口令、工作階段、對方登記的驗證器、信箱轉寄規則，分屬不同開關。通報要求它們一併處理。本地產生一組新口令，只能覆蓋「還在用密碼的服務」這一層：開啟 密碼產生器 即可，長度 6–128 字元、預設 16 字元，低於 8 字元會提示安全性較低，計算在瀏覽器完成，不上傳。它代替不了撤銷工作階段，也代替不了刪掉陌生驗證方法。
常見問題
我已經登記了通行金鑰，還會被這通電話騙到嗎？
會，而且常常不是因為 Passkey 被偷走。話術用通行金鑰當藉口，真正要的是中間人截到的工作階段，或你在微軟真網域上為對方應用程式輸入的裝置碼。通行金鑰綁定來源網站，擋得住假登入頁直接拿走私鑰，擋不住你主動授權對方的用戶端。
網址列看起來像微軟官網，是不是就可以輸入裝置碼？
裝置碼流程的登入頁本來就可以是官方網域。危險不在「是不是假站」，而在「這個碼是誰發給你的、授權會落到誰的應用程式」。別人電話或簡訊裡念給你的碼，授權的是對方控制的用戶端，不是你自己的瀏覽器工作階段。
改掉密碼之後，這通電話還算結束了嗎？
不夠。微軟寫明對方會在得手後登記自己的手機號碼、驗證器或軟體權杖。只改密碼、不撤銷工作階段、不刪陌生驗證方法，對方仍可能透過自己登記的第二因素再進來。安全性資訊頁上多出來的裝置，要按官方處置步驟拿掉。
同事在聊天裡要一次性口令，能不能截圖傳過去？
不要把有效口令或裝置碼截進聊天相簿。短文字應在目前分頁用 AES-256-GCM 加密後走 閱後即焚，金鑰放在連結的 # 後面，形態是 s.html?id={id}#{key}。建立和閱讀都開啟即用，無需帳號。先確認對方身分走的是你們公司既有的核實管道，而不是剛才那通自稱 IT 的來電。超過 32 KB 的材料改走 檔案加密盒，單檔案不超過 5 GB，輸出 .lock / .enc。
把短秘密改走開啟即用的通道
若你希望用一個把計算邊界寫清楚的頁面來練習「還口令、不截圖」，開啟 FastPwd 的 閱後即焚 即可，無需註冊。寫入上面那句金絲雀，閱讀次數留 1，產生後按上面的核對步驟對照 Network：請求體裡應只有密文，不應出現原文或井號後的金鑰。必須把短口令交給已經核實過的同事時，才走這條通道，不要先截圖，更不要把裝置碼回給陌生來電。
聊天紀錄或工單正文裡如果還疊著手機號碼、身分證字號，先在 隱私清洗 裡做規則遮蔽，再決定要不要送出。清洗在本機完成，原文不作為業務資料上傳，也不寫入 analytics。還在用口令的網站，用密碼產生器本地產生唯一口令，不要複用被電話催過的那一串。密碼檢測只回答「是不是公開高頻弱密碼」，不回答「剛才那通電話是不是假的」。
下次再接到「立刻更新通行金鑰」的電話，記住三件事。第一，話術裡的 Passkey 常常只是藉口，對方要的是工作階段或裝置碼授權。第二，真網域擋不住你把權杖核發給別人的應用程式。第三，收尾看安全性資訊頁和工作階段撤銷，不是只改密碼。能寫進交接說明的，只能是這三句，不能是「我開了通行金鑰，所以不用管來電」。
延伸閱讀
把口令截進圖床之後，登入雜湊擋不住 OCR 明文和 Image ID，見 把密碼截進圖床之後，OCR 明文和 Image ID 為什麼比雜湊更危險。閱後即焚燒掉的是伺服器上的密文，證明不了接收方沒截圖，見 閱後即焚能證明伺服器刪了密文，為什麼證明不了對方沒截圖。URL 井號後面為什麼不進 HTTP，見 URL 的井號後面為什麼適合放金鑰，以及什麼時候會失效。