MFA 疲勞攻擊是設法令用戶批准一個並非自己發起的真實多重認證要求。在這種推送疲勞攻擊中，攻擊者反覆觸發推送通知，夾雜來電或訊息，或等受害者因誤觸、厭煩，或以為是一般登入的一部分而批准。

關鍵前提是攻擊者能到達 MFA 驗證一步。他們可能已知道或重設了密碼、持有有效的第一因素，或正在操作即時的登入流程。反覆出現的提示不是隨機垃圾訊息，可能代表有人正試圖完成認證。CISA 建議以數字配對緩解推送轟炸攻擊，因為它比單純的「批准」按鈕需要更多情境資訊。［1］

關鍵要點

除非你發起了該次登入並能對上其情境，否則切勿批准 MFA 要求。

拒絕一次提示有用，但反覆出現提示代表你應保護並上報帳戶。

數字配對能減少誤批，但不能令每次登入或社交工程要求都變得可信。

誤批准後按可能的帳戶入侵處理：撤銷工作階段、重設 MFA 驗證方式並調查活動。

MFA 疲勞攻擊（MFA 轟炸）怎樣運作？

攻擊者先取得或猜出足以通過第一步認證的資料。在其他外洩中暴露的重用密碼，可被用於憑證填充攻擊；釣魚頁面可能即時截取密碼；操控支援熱線或濫用復原流程，也能讓攻擊者接近 MFA 驗證環節。

接着，攻擊者提交登入嘗試。以推送為本的系統會向已登記的裝置發出真實通知。一次要求可能很快被拒絕，於是攻擊者在不便的時間或密集地重複發起。他們可能冒充 IT 部門來電，聲稱提示是保安更新的一部分，或要受害者批准一次要求「好讓通知停下來」。

如果受害者批准，服務供應商可能完成攻擊者的登入。之後會發生甚麼視乎帳戶和控制措施：攻擊者可能建立工作階段、登記另一個驗證因素、存取電郵或檔案、更改復原設定、建立應用程式授權，或轉攻其他服務。MFA 疲勞指的是這種施壓誘使批准的手法；它並非所有 MFA 繞過、工作階段被盜、SIM 卡騎劫或一次性驗證碼被盜的統稱。

Push、TOTP、number matching 與 passkey 有何區別？

不同認證方式要求用戶作不同決定。一般推送提示只問是否批准。時間型一次性密碼（TOTP）要求把短時變化的代號輸入用戶正在查看的登入流程。數字配對（number matching）在登入頁顯示一個數字，要求在驗證器中輸入或選擇相應數字。通行密鑰（passkey）使用與提出要求的網站綁定的密碼學認證，並需要本機用戶驗證或在場確認。

方式	用戶操作	針對疲勞攻擊的優點	重要限制
批准／拒絕推送	點選批准或拒絕	操作簡單，但容易在缺乏情境下批准	反覆推送和社交工程可利用習慣
TOTP	在進行中的登入流程輸入變動代號	沒有可隨手批准的意外按鈕	即時釣魚代理可索取並轉交代號
數字配對	配對登入頁顯示的數字	把提示與可見的互動連繫起來，減少盲目批准	來電者仍可操控正在查看攻擊者所發起流程的用戶
Passkey/FIDO2	使用綁定網站的憑證並作本機驗證	抵禦憑證重放及許多釣魚代理	登記、復原、裝置覆蓋和後備方式仍然重要

Microsoft 的數字配對流程在登入時顯示數字，要求用戶在 Authenticator 輸入該數字才能完成批准。［2］這迫使用戶多作一次比對，令來歷不明的推送更難被接受，但用戶仍須確認登入是自己發起的。若受害者按犯罪分子的指示操作，電話另一端的人照樣能展示或讀出數字。

通行密鑰和 FIDO2 安全密鑰追求更強的特性：憑證在密碼學上與合法網站相連，因此不是釣魚頁面可直接收集的可重用代號。Microsoft 把通行密鑰和 FIDO2 方案納入其抗釣魚 MFA 方向，同時指出部署和平台方面的考慮。［3］抗釣魚不等於不會出事；復原途徑、舊有驗證方式、惡意軟件和已授權工作階段被濫用，仍需相應控制。

收到意外 MFA 要求應如何處理？

不要批准，也不要輸入別人提供的數字。如驗證器提供拒絕或舉報選項，就使用它。關閉並非你有意開啟的登入頁面。然後透過官方 App 或書籤獨立檢查帳戶。

一次偶然的通知，可能來自你自己延遲的工作階段、第二部裝置或服務重試。把時間、地點、應用程式和裝置資料與你當時所做的事對照。對不上的話，就當作可疑處理。多次要求、在異常時間出現的要求，或同時有「IT 支援」來電，都代表情況更緊急。

情況	可能的暴露	即時行動
自己登入時出現一次提示	可能正常	批准前比對應用程式、數字、地點和裝置
沒有登入卻出現一次提示	攻擊已到達 MFA 環節	拒絕或舉報；查看近期活動並保護密碼
反覆出現提示或伴隨來電	正在進行的施壓攻擊	停止回應；獨立聯絡支援或資訊保安團隊
誤批准了提示	可能已成功登入	立即開始帳戶復原和事故審查

個人帳戶方面，若第一因素可能已被知悉（尤其是重用的密碼），請在可信裝置上更改密碼，並檢查近期登入和復原方式。工作帳戶方面，請透過已知號碼或內部入口網站聯絡資訊保安團隊或支援熱線，提供提示出現的時間、顯示的地點、應用程式及來電者資料。不要撥打可疑訊息提供的號碼。

誤批准 MFA 後怎樣復原？

在有證據證明並非如此之前，假設該次批准可能替別人完成了認證。透過服務供應商的官方保安頁面撤銷陌生工作階段或登出其他裝置。密碼可能外洩的話，就更改密碼。檢查已登記的 MFA 方式、通行密鑰、安全密鑰、電話號碼、復原電郵、受信任裝置和應用程式連接，移除任何無法核實的項目。

然後檢查該身份背後的資源：電郵轉寄和規則、寄件備份、雲端檔案分享、帳戶委派、付款設定、開發者權杖和近期變更。攻擊者可能使用新建立的工作階段，不再觸發 MFA 提示。有人登入了我的帳戶中的復原次序可助你整理這些檢查。

暴露程度	處理優先次序	應保留的證據
拒絕了所有提示	保護第一因素並上報嘗試	時間、應用程式名稱、地點、來電或訊息細節
已批准，暫未發現活動	撤銷工作階段，重設 MFA 驗證方式	在逾期前保存登入和稽核紀錄
已批准，並發現帳戶變更	還原復原及 MFA 設定，控制受影響的服務	變更前後的設定、新增因素、規則、授權、IP 或裝置資料
涉及敏感工作、金錢或受規管資料	交由負責團隊處理並按事故程序行事	供應商紀錄、交易紀錄、資料存取範圍、往來通訊

不要指望再來一次推送能「取消」第一次。在資訊保安團隊能使用證據之前，不要刪除它。如涉及金融帳戶或付款，請透過可信途徑聯絡機構。如攻擊者說服支援熱線更改了驗證因素，請告知應變人員，讓他們檢查復原流程，而不只是密碼。

機構如何降低 MFA 疲勞風險？

以數字配對取代缺乏情境的批准／拒絕提示，可行時改用抗釣魚方式。停用薄弱及閒置的後備方式。審慎應用速率限制、按風險的控制、不可能的行程和陌生裝置訊號，並就反覆拒絕或提示激增發出警報。無止境重發提示的控制，反而可能放大攻擊。

為用戶提供在驗證器內舉報意外要求的明顯入口，以及另一條聯絡支援人員的可信途徑。支援人員絕不應要求用戶批准來歷不明的提示或透露一次性驗證碼。支援熱線的身份核實和重設驗證因素流程也需保護，因為登入變難時，攻擊者可能轉向復原途徑。

監察整個認證過程：密碼驗證、MFA 挑戰、批准和拒絕、驗證因素登記、工作階段建立、OAuth 授權和敏感活動。關聯分析比單純計算提示次數更重要。多次失敗後出現一次批准和一部新裝置，比一次孤立的重試更有意義。

最後，維持一條經測試的復原途徑。轉用通行密鑰或硬件密鑰的機構，應規劃登記、遺失、更換、無障礙、出行、離線使用和緊急存取，而不是靜悄悄讓所有人退回可被釣魚的方式。較全面的網絡安全指南介紹了仍然必需的密碼、裝置和復原層。

常見問題

意外 MFA 提示能證明密碼已洩露嗎？

不能絕對證明，但可能代表有人已到達 MFA 環節。請保護帳戶並查看活動，而不是認定通知無害。

應拒絕還是忽略提示？

App 支援的話，拒絕並舉報，然後獨立檢查帳戶。只忽略反覆出現的要求而不保護帳戶，第一因素的問題仍未解決。

Number matching 能阻止所有疲勞攻擊嗎？

不能。它把提示與顯示的數字連繫，減少盲目和意外的批准。社交工程仍可操控用戶，其他帳戶復原途徑也可能仍然暴露。

TOTP 不怕釣魚嗎？

不是。TOTP 避免了意外的批准按鈕，但即時釣魚網站可索取代號，並在逾時前轉交。

Passkey 與 push MFA 相同嗎？

不同。通行密鑰使用與網站綁定的密碼學憑證及本機裝置驗證；推送 MFA 則是要已登記的 App 批准另一次獨立的認證嘗試。

登入時出現提示，應如何處理？

比對服務、裝置、地點、時間和數字。情境與你發起的登入不符，就拒絕。

改密碼會結束已批准的工作階段嗎？

未必。除了更改已暴露的密碼，也要撤銷陌生工作階段，並檢查驗證因素和復原設定的變更。

為甚麼拒絕後仍要上報？

機構可把你的報告與登入嘗試關聯，保護其他被針對的用戶，封鎖攻擊基建，並在有人批准之前發現攻擊活動。

本文提供一般保安教育。認證選項和撤銷行為因服務供應商而異；請遵從受影響帳戶最新的復原指示和機構的事故程序。

來源

CISA — Implement Number Matching in MFA Applications — https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf
Microsoft Learn — How number matching works in MFA push notifications for Authenticator — https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match
Microsoft Learn — Phishing-resistant MFA — https://learn.microsoft.com/en-us/security/zero-trust/sfi/phishing-resistant-mfa

Sources checked 2026 年 8 月 28 日。

甚麼是 MFA 疲勞攻擊？反覆收到驗證要求時如何應對