從身分開始，而不是事件標籤
商業電子郵件洩露 描述了一種有害的業務場景，而不是一個唯一的電子郵件身份驗證結果。欺騙性請求可能來自冒充網域、受損的供應商郵箱、被濫用的內部帳戶或使用合法發送基礎設施的未經授權的應用程式。調查必須確定所提供的身份、哪個系統對其進行了身份驗證以及接收者認為其代表哪個業務機構。如果沒有這種分離，團隊可以修復錯誤的控制，而潛在的風險仍然存在。
這 IC3 基於雲端的電子郵件諮詢，日期為 2020 年 4 月 6 日，描述了受損的雲端電子郵件帳戶如何支援 BEC，並建議獨立驗證和帳戶保護。這是背景指導，而不是當前事件的證據。 Microsoft 的受損帳戶指南 同樣描述了Microsoft 365中的郵箱濫用和調查。兩個消息來源都沒有證實假設練習中討論的任何帳戶實際上已被洩露。
保留請求並暫停業務操作
第一個操作問題是訊息要求某人做什麼：更改付款詳細資訊、發布資訊、批准存取、更改供應商記錄或採取其他相應操作。用中性語言記錄動作。當請求可疑時，透過組織既定流程暫停執行。避免將調查本身變成未經授權的付款、帳戶變更或披露。分析師可以記錄該請求而不需要遵循它。
將原始訊息和相關業務記錄保存在經批准的限制位置。螢幕截圖可以顯示演示，但不能取代完整的訊息證據。轉發的副本可能會更改上下文並添加標頭；相應地標記它。保留時區的時間表並確定每個物品的收集者。對於共享摘要，請刪除不必要的個人數據，同時保留比較身分所需的差異。請勿將憑證、存取權杖或完整的敏感信件作為常規故障排除材料進行傳播。
建構身份堆疊
列出可見的顯示名稱、解析的寄件者地址、回覆地址、 信封寄件人, DKIM 簽章網域、接收者身分驗證結果和所謂的業務角色。僅當授權調查證據表明其存在時才添加郵箱或應用程式帳戶。這些是單獨的行，不能互換「寄件者」的標籤。驗證訊息的網域可能與接收者推斷其權限的人不同。
RFC 9989 使邊界明確： DMARC 用途 域對齊 並且不驗證網域以外的實體或分析內容。因此，成功的一致結果不能證明發票、新的銀行詳細資料或高階主管的批准。相反，失敗的結果並不能證明 帳號接管。調查應避免從協議結果跳到誰控制某人帳戶的結論。
為每個觀察建立信任邊界
確定哪個接收者產生了身份驗證結果以及記錄是否是透過該接收者的受信任介面或日誌取得的。 RFC 8601 解決信任問題 Authentication-Results 斷言。寄件者可能包含具有誤導性的文本，因此僅存在欄位是不夠的。記錄將斷言視為本地且受信任的基礎。如果不存在該基礎，請將結果標記為未經驗證，而不是將其重複為事實。
應用程式日誌和帳戶審核記錄回答不同的問題。發送日誌可能會顯示提交成功，但無法證明是人為的。郵箱審核可能會顯示規則更改，但無法證明該規則是惡意的。在授權的情況下將按時間、帳戶和訊息標識符進行的觀察結合起來，在連結較弱時保留不確定性。避免將單一異常位置或孤立的錯誤視為妥協的決定性證據。
在選擇控制措施之前比較機制
使用恆等和控制矩陣。對於沒有一致身份驗證的精確網域模擬，請檢查網域策略和傳送路徑。對於顯示名稱或相似網域濫用，請檢查表示、識別和獨立業務驗證。對於可疑的帳戶洩露，請檢查帳戶存取和未經授權的操作。對於被濫用的應用程序，檢查其授權和訊息構造邊界。在同一情況下可能會出現不只一種機制。
微軟的指南列出了潛在的症狀，例如可疑的收件匣規則、轉發以及遺失或刪除的郵件。這些是調查線索，而不是自動判決。其補救措施包括停用受影響的帳戶、撤銷存取權限以及檢查身份驗證裝置、同意的應用程式、角色和轉發器。這些是授權響應者相應的行政行為。本文並未指示助手執行這些操作、授予權限或收集憑證；一旦證據支持假設，它就會確定適當的回應域。
操作比較工作表
每個假設創建一行。包括所聲稱的身份、支持性觀察、觀察來源、相互矛盾的證據、受影響的控制、提議的下一次授權檢查和負責人。新增帶有簡單語言解釋的置信標籤。 「受信任的接收者報告與供應商域一致的DKIM 」比「供應商確認安全」更窄且更有用。 「收件者記住顯示名稱」並不等於經過驗證的供應商地址。
新增單獨的業務驗證行。確定在可疑請求之前建立的聯絡管道、需要確認的確切變更、授權驗證者和記錄的結果。回應應確認或拒絕所要求的業務操作，而不僅僅是聯絡人識別寄件人姓名。請勿使用僅在可疑訊息中提供的電話號碼、連結或替代地址作為獨立驗證。本建議的工作表不是已執行的事件回應記錄。
虛構診斷：發票變更請求
虛構製造商收到更改供應商付款目的地的請求。顯示名稱與客戶經理匹配，可信任接收者證據顯示供應商真實領域的一致身份驗證。收件人認為這排除了 BEC。相反，安全團隊記錄了一個更狹隘的結論：該訊息使用了經過驗證的供應商域路徑。供應商帳戶、整合或授權人員是否發起了變更仍然未知。
使用先前記錄的供應商聯絡方式，企業主將驗證特定提議的變更。授權的供應商回應者將調查他們自己的帳戶和應用程式證據。如果供應商拒絕該請求，則該拒絕支援停止更改，但本身並未識別電子郵件的發送方式。在帳戶或服務證據解決該機制之前，案件將保持開放。整個例子都是虛構的；未獲得付款詳細資訊、供應商帳戶或真實信件。
用正確的證據消除每一個不確定性
合理的結論說明觀察到了什麼、支持什麼機制、仍然不確定什麼以及透過授權改變了哪些控制。不要將來自受影響網域的每封郵件都標記為惡意，聲稱DNS編輯包含帳戶接管，或僅僅因為稍後的郵件經過身份驗證就聲明修復已完成。業務流程驗證、帳戶遏制和郵件身份驗證各自回答了不同的問題。
目錄需要根據可信訊息證據建立經過編輯的身份和控制比較。該證據仍然存在。該草案提供了一種方法和虛構的案例，並非可信的原始訊息材料。獨立的專家審查、當前來源的適用性、生產路線檢查、視覺可及性和所有者發布也都是開放的。發布應等待授權的證據包來證明比較，而不會暴露敏感帳戶資料或暗示發生了未執行的回應操作。