DEBULL 濫用 Microsoft 裝置驗證碼，MFA 點解都未必擋得住

一組驗證碼，點解可以變成帳號接管

iThome 報道，ZeroBEC 揭露一套名叫 DEBULL 嘅工具，近排用嚟針對 Microsoft 365 做 device code phishing。呢類釣魚最陰濕嘅位，重點放喺 token：佢唔叫你喺假 Microsoft 頁面打密碼，而係引你去真 Microsoft 登入頁，輸入攻擊者預先開出嚟嗰組裝置驗證碼。你見到係正牌頁面，MFA 又照彈，心理防線自然低咗，完成登入之後，攻擊者嗰邊就攞到可用 token。

圖片：ZeroBEC

Device code flow 本身係正常功能

Microsoft 呢個 OAuth device code flow，原意係畀電視、printer、CLI 工具呢啲唔方便打字或者冇完整 browser 嘅裝置登入。正常流程係裝置顯示一組 user code，用戶用手機或電腦開 Microsoft 指定頁面，打 code、登入、授權，然後原本嗰部裝置攞到 access token 同 refresh token。設計本身合理，問題係釣魚信可以將「我要你幫另一部裝置登入」包裝成「開共享文件」或者「入 Teams 會議」。

MFA 冇廢，但佢擋唔晒呢個場景

呢度要講清楚：MFA 冇失去價值，針對撞密碼、撞舊密碼、普通假登入頁，MFA 仍然係基本防線。但 device code phishing 嘅麻煩位，係用戶自己喺真 Microsoft 流程完成第二重驗證，身份平台見到嘅係一個成功授權，而唔係密碼外洩。Microsoft 官方亦提過，攻擊者攞到 token 之後可以讀電郵、查 Graph 資料，部分 access token 可能仍有短時間窗口；所以淨係改密碼未必夠，要 revoke session / refresh token，同時暫時停用可疑帳號。

DEBULL 值得驚嘅位係包裝好咗

ZeroBEC 原文講到，DEBULL 似係可重用嘅 PhaaS 工具層，前面可以換 Teams、共享資料夾、Excel/Box 文件之類 lure，後面就維持同一套 token broker 同 post-auth 流程。ZeroBEC 亦見到疑似 GraphSpy 或衍生工作流嘅痕跡，iThome 報道就指出手法同 Microsoft 2025 年披露嘅 Storm-2372 device code phishing 好相似。重點係，呢招由高門檻情報操作，開始變成有面板、有模板、有部署流程嘅商品化工具。

對用 Microsoft 365 嘅公司，風險唔止係一個 mailbox

香港好多公司、學校、NGO、會計同法律 firm 都靠 Microsoft 365 做日常協作，一個帳號出事，受影響唔止 Outlook。Teams 對話、OneDrive、SharePoint 文件、財務往來、客戶資料，都可能俾人用 Graph API 或正常 app session 慢慢翻。BEC 最煩就係攻擊者可以用真同事 mailbox 發信，語氣、thread、附件脈絡都似真，收款資料一改，財務同 admin 好易中招。

公司 IT 第一件事：管住 device code flow

Microsoft Learn 而家好直接，建議盡量 block device code flow，只喺有清楚紀錄同已加固嘅用途放行，例如會議室裝置、舊工具或某啲 CLI。實務上唔好即刻亂封，先用 Conditional Access report-only 同 sign-in log 睇清楚邊啲 app、邊啲人真係用緊，之後用 Authentication flows 條件去封，break-glass account 同必要 service account 要分開處理。冇人講得出業務用途嘅 device code flow，就唔應該長期開住。

偵測要睇 sequence，唔好淨係睇單點

ZeroBEC 呢單點解有代表性，就係單一訊號未必好嚇人：郵件可能有正常 sender path，登入頁係 Microsoft，IP 地理位置又可以扮到幾合理。SOC 應該串起幾樣嘢睇：可疑共享文件或 Teams lure 之後，有冇 device code / Microsoft Authentication Broker 登入；同一 session 有冇由另一個 IP 轉去 OfficeHome 或 Outlook；Entra 有冇突然多咗陌生裝置；OAuth app consent、Graph API 讀取、Inbox rule、forwarding 有冇異常。ZeroBEC 原文有 IoC 同 hunting 線索，公司安全隊可以直接拎返去對 SIEM，普通用戶就唔使逐個 domain 記。

普通人點避：唔好幫陌生裝置登入

最貼地嘅判斷係：除非係你自己啟動嘅流程，例如登入新電視、printer、開發工具或者公司明確要求嘅裝置，否則唔好因為一封郵件、一個 Teams link、一份付款文件，去 Microsoft 頁面輸入裝置驗證碼。見到登入畫面要睇清楚 app 名、要求嘅權限同發信人；已經輸入過可疑 code，就即刻搵 IT，唔好只係改密碼就算。公司防線做得好，device code flow 係可以管得住；最怕係成間公司冇人知道自己開住呢條路。

參考來源

• iThome — 惡意工具DEBULL濫用Microsoft裝置驗證碼流程，攻擊者可藉此接管受害者Microsoft 365帳號 — original report
• DEBULL: Storm-2372-Style Microsoft Device-Code Phishing With GraphSpy Post-Exploitation — ZeroBEC 原始研究，提供 DEBULL 攻擊流程、PhaaS 判斷、GraphSpy 痕跡同 IoC。
• Microsoft identity platform and the OAuth 2.0 device authorization grant flow — Microsoft 官方說明 device code flow 正常用途、token response 同 code 期限。
• Block authentication flows with Conditional Access policy — Microsoft 官方建議，示範點樣用 Conditional Access 限制或封鎖 device code flow。
• Authentication flows as a condition in Conditional Access policy — Microsoft 官方解釋 device code flow 風險、sign-in logs 同 original transfer method。
• Storm-2372 conducts device code phishing campaign — Microsoft Threat Intelligence 2025 年 Storm-2372 分析，補充同類手法、MFA 旁路場景同防守建議。
• Respond to a compromised cloud email account — Microsoft 官方事故處理指引，核對 revoke session、停用帳號、查 forwarding / inbox rules。
• Access granted: Phishing with device code authorization for account takeover — Proofpoint 背景研究，補充 device code phishing 由情報圈走向犯罪工具化嘅趨勢。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。