用Claude辨識商務郵件釣魚攻擊

簡而言之： Claude可以像一名受過訓練的分析師那樣讀一封可疑郵件——驗證結果、寄件者歷史、文字本身，以及連結真正指向哪裡——並在幾秒內給出帶推理過程的結構化判定。最合適的落點是一個「可疑郵件通報」信箱，專門分派員工標記出來的郵件。它是郵件安全閘道的補充，絕不是替代品：沒有沙箱、沒有隔離區，也沒有投遞後的收回能力。

大多數中小企業對付釣魚郵件其實只有一道防線：Microsoft 365或Google Workspace預設過濾掉的那些，加上剛好在讀這封信的人的判斷力。這套組合對付大量垃圾郵件和已知惡意網域是有效的。但對真正會造成損失的那類郵件，它就明顯吃力了——一封簡短、合理、不帶任何附件或惡意連結的郵件，來自收件者認識的人，要求做一件聽起來很像週二日常的事。本文講的是一件用Claude API花一個下午就能搭出來、而且確實有用的窄事情，以及它做不到的那一大堆事情。

到底什麼能繞過標準垃圾郵件過濾

商業郵件詐騙（BEC）根本沒有可偵測的東西。 沒有附件、沒有惡意連結、沒有畸形標頭——只有一段文字。「你在位子上嗎？截止時間之前需要你處理一筆供應商付款。」一個為查找惡意程式而調校的過濾器什麼也查不到，因為那裡除了意圖之外什麼都沒有。

顯示名稱偽造能通過身分驗證。 SPF、DKIM和DMARC驗證的是寄件網域，不是郵件用戶端裡顯示的那個人名。攻擊者用一個自己合法擁有的網域寄信，三項檢查全部通過，照樣可以把貴公司財務總監的全名放進寄件者欄。而在手機上，網域往往根本不會顯示。

被入侵的合法帳號能通過全部檢查。 當真實供應商的信箱被接管，郵件就是從真實網域寄出的，通過驗證，而且常常出現在一條真實的既有對話裡。以信譽為基礎的過濾在結構上對此是盲的——因為那份信譽是真的。

仿冒網域是現註冊、只用一次的。 一個48小時前註冊的網域還沒有壞名聲，因為它根本還沒有任何名聲。等它進了黑名單，這一波攻擊早就結束了。

對話劫持借用的是你自己的脈絡。 攻擊者把真實對話複製過來後在其中回覆，引用著真實的早前訊息。所有本來會讓收件者放心的東西——主旨列、下面的歷史紀錄、熟悉的名字——都是攻擊本身提供的。

這五種情況的共同點是：訊號在脈絡層面，而不在技術層面。語言模型並不是一個更好的垃圾郵件過濾器，但它確實擅長這五種情況所需要的那種判斷。

AI釣魚檢查實際是怎麼運作的

該餵給模型什麼——標頭、寄件者歷史、內文和連結落點

判定的品質，完全取決於你在呼叫API之前組裝了什麼證據，而這些證據裡有很大一部分應該用確定性程式碼採集，而不是交給模型去評判。自己解析Authentication-Results標頭，把SPF、DKIM、DMARC的結果當作客觀事實傳進去。取出真正的From網域，用程式碼把它與你的通訊錄和往來歷史比對——「這個顯示名稱符合一位內部主管，但這個網域從來沒寄過信給我們」，這條事實比任何篇幅的文風分析都值錢。

把每個連結都解析開。取href而不是錨點文字，在不執行任何內容的前提下跟隨轉址，把最終落點連同可註冊網域、以及（如果你有查詢能力）它的註冊年齡一起傳進去。把純文字內文、主旨、收件者的職務角色，以及這封信是否回覆了一條信箱裡真實存在的對話，都給模型。然後要求結構化輸出——一份JSON判定，包含風險等級、發現的具體指標、明確檢查過但不存在的指標，以及一段非技術同事讀得懂的說明。要明確指示它：無法確定的一律標為未知，不要猜；一個自信的錯誤判定比一處誠實的空缺糟糕得多。

兩種做法：通報信箱分派機器人 vs 串接式閘道

這件事有兩種形態，而其中只有一種適合自己動手做。串接版本坐在郵件流裡，投遞前檢查所有郵件，並執行攔截或隔離。自己搭這個，意味著你要為全公司的郵件投遞負責——每一次逾時、限流、模型故障和誤判，都會變成遺失或延誤的業務郵件，而你還得再搭出緩衝佇列、容錯移轉，以及凌晨兩點放行隔離郵件的辦法。那是一個產品，不是一個腳本，而且成熟的產品早就有了。

分派版本坐在郵件流旁邊。員工轉寄或通報一封可疑郵件，機器人分析後給出答覆。什麼都不攔截，什麼都不延誤，最糟的失效模式無非是回覆慢了點。而且它針對的恰恰是那些已經繞過其他一切防線的郵件，殘餘風險正好就在那兒。從這裡開始，而且除非有特定理由，就留在這裡。

一套可落地的做法：可疑郵件通報信箱分派流程

給員工一個明確動作。 一個共用信箱，例如phishing@yourcompany.com，如果用得上再加上Outlook或Gmail內建的通報按鈕，以及一條指令：覺得不對勁就通報，你會收到答覆。通報必須比自己拿主意更省事。

要拿到原件，而不是轉寄件。 一般轉寄會毀掉你需要的標頭。請員工以附件形式通報，或使用平台自帶的通報機制，或透過Microsoft Graph、Gmail API依訊息ID把郵件取出，確保原始原始碼完整。

先做豐富化，再去提問。 把確定性檢查跑一遍——驗證結果、對照寄件歷史做首次聯絡判斷、連結解析、網域年齡、顯示名稱是否與通訊錄項目撞名——然後交給Claude一份結構化的證據包，而不是一大坨文字。

幾分鐘內用白話回覆通報人。 「這極可能是一次付款改道詐騙。顯示名稱與貴公司財務總監一致，但網域yourc0mpany-finance.com是9天前註冊的，此前從未與我們聯絡過。請勿回覆。IT已收到通知。」正是這樣的回覆，會讓員工願意通報下一封。

依嚴重程度分流，高風險端必須留人。 低風險判定可以帶著說明自行結案。任何評為高風險的，都應當直接呼叫IT，而模型在那裡的職責是分派與蒐證，不是拍板。

全量留痕，每週檢討。 把證據包、判定結果，以及事後證實的真相都存下來。每週花二十分鐘檢視分歧，對提示詞的改進速度會超過任何前期設計，而且它能給你一個真實的誤判率和漏判率，而不是一種感覺。

把已確認的攻擊回灌進你的控制措施。 一個確認的惡意網域應當進入租戶層級封鎖清單；如果還有其他人被當成目標，就該觸發一次跨信箱搜尋。分析的價值取決於你拿它做了什麼。

AI輔助分派 vs 託管郵件安全閘道

辨識BEC與社交工程文字 — AI分派在這裡確實強，而這也正是閘道歷史上最薄弱的缺口。現代閘道已經加入自己的AI冒充偵測，所以這是一項正在收窄的優勢，而不是永久優勢。
投遞前攔截 — 只有閘道做得到。分派機器人是在郵件已經躺進收件匣之後才作答的，這表示風險窗口等於員工決定通報所花的時間。
附件與惡意連結 — 閘道完勝。在沙箱裡引爆一個檔案、把URL改寫成點擊時再檢查一次，這些是工程能力，不是推理能力。模型讀一個檔名，學不到這個檔案會做什麼。
投遞後清除 — 只有閘道或郵件平台能伸進每一個信箱，把一封事後被判定為惡意的郵件抽走。你用API搭出來的東西做不到這件事。
向非技術使用者說明判定 — AI分派明顯勝出。閘道產出的是隔離通知；模型產出的是收件者真能看懂的一段話，這對員工資安意識的價值超過大多數教育訓練模組。
成本與投入 — 分派機器人是幾天的整合工作，每次分析花幾分錢。託管閘道是一筆持續訂閱和一段供應商關係。兩者定價方式不同，是因為它們根本不是同一種控制措施。
失效時會發生什麼 — 分派機器人壞了，只是沉默且惱人。自建的串接式過濾器壞了，全公司郵件停擺。這種不對稱，正是選擇分派形態的全部理由。

為什麼它是補充而不是替代

沒有沙箱。 模型無法在隔離環境裡打開附件、看它究竟做了什麼。如果答案需要引爆才能得到，那這個答案就拿不到。

沒有收回能力。 當一封郵件在投遞一小時後被確認為惡意，把它從四十個信箱裡刪掉是平台的功能。你的機器人可以建議這麼做，但執行不了。

沒有佇列。 你的整合掛掉時，既沒有任何保護，也沒有任何緩衝。閘道生來就是要能扣住郵件的；腳本不是。

模型自己也會被社交工程。 藏在郵件內文裡的提示詞注入——寫給分析系統而不是寫給人看的指令——是針對這套設計真實且顯而易見的攻擊。把郵件內容當作不可信輸入，與你的指令明確隔離，絕不讓模型輸出自行觸發動作，並且要假定遲早有人會來試。

一個自信的漏判比沒有工具更糟。 如果員工學會了「機器人說沒問題」，他們就會停止仔細閱讀。要讓不確定性在回覆裡看得見，絕不能讓低風險判定讀起來像一張免責保證書。

把這件事做對：郵件資料治理、API金鑰，以及何時該讓IT介入

被通報的郵件是企業裡最敏感的資料之一。一封釣魚通報常常連帶著一張真實發票、一份真實合約或一段真實對話，把它轉給第三方API是一個帶有合約與法遵分量的處理決策——取決於你的人員和資料所在地，可能落在香港《個人資料（私隱）條例》、新加坡PDPA或中國《個人信息保護法》之下。有意識地決定哪些內容會離開租戶、是否採用零保留的API條款，並且在客戶的資安問卷問到之前，就先把答案寫下來。

把憑證權限收窄。信箱整合需要的是對一個共用信箱的讀取權限，而不是全組織範圍的郵件讀取權限；而Microsoft Graph裡的應用程式權限預設就是寬的——請用應用程式存取原則把它限定到那一個信箱。把Anthropic API金鑰放進密鑰管理系統而不是自動化流程的設定檔裡，按計畫輪替，並對費用異常告警：一張意料之外的帳單，往往是某個環節在無限迴圈或被濫用的第一個可見訊號。

這正是託管夥伴體現價值的地方。Brocent的託管郵件安全服務涵蓋這套流程旁邊的閘道層——AI輔助的冒充與BEC偵測、附件沙箱，以及任何自研腳本都做不到的投遞後處置。我們的AI+支援服務負責建置與調校分派整合本身，託管IT支援則在上線後接管憑證、監控與事件回應。如果你的短板在員工行為而不是工具，我們那篇談亞洲釣魚演練專案的指南涵蓋的是同一個問題的訓練那一側。Brocent自2007年在北京創立以來一直在亞洲提供託管IT與資安服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

AI能取代我們的郵件安全閘道嗎？

不能，而且值得把原因說直白。閘道在投遞前攔截、在沙箱裡引爆附件、改寫URL使其在點擊時再次檢查，並且能在事後把一封郵件從所有信箱中移除。以API為基礎的分析器一樣都做不到。它是在一套體系之上疊加了脈絡判斷力——它不會變成那套體系。

把可疑郵件轉給AI，本身會不會帶來風險？

它帶來的是一個你必須有意識回答的資料處理問題。這些內容往往很敏感，而且正在離開你的租戶。核對服務商的資料保留與訓練條款，把這個決定記錄下來；如果你受PDPO、PDPA或《個人信息保護法》約束，請確認這次傳輸被你用於其他雲端處理的那個法遵依據所涵蓋。

漏判該怎麼處理？

預設它一定會發生，並把回覆設計成「低風險判定永遠讀不出保證書的味道」。給每一次分析連同結果一起留痕，每週檢視分歧，把漏判率當成一個真實數字來追蹤。如果員工把「看起來沒問題」當成可以點擊的許可，那這個工具是讓情況變糟了，而不是變好。

附件和惡意連結怎麼辦？

這是最清楚的一條邊界。模型能讀到的是檔名和連結的可見文字，而這幾乎說明不了什麼。請在分析之前用程式碼解析連結落點，把附件檢查交給有真正沙箱的閘道。絕不要讓模型對附件的評估，頂替對它的實際掃描。

一封郵件能攻擊正在讀它的AI嗎？

能——提示詞注入就是針對這套設計那個顯而易見的攻擊。攻擊者可以在內文裡寫下針對你的分析器的指令。請把不可信內容明確定界，絕不讓模型輸出在沒有人工或確定性規則介入的情況下觸發動作，並在信任它之前先用注入嘗試測試自己的提示詞。

它應該盯哪個信箱？

一個共用通報信箱，而且只盯這一個。這樣權限範圍小、資料足跡小，而且瞄準的正是那些已經越過其他所有控制措施的郵件——那恰恰是額外判斷力最值得花錢的地方。

從哪裡開始

先做唯讀版本：取出被通報的郵件，跑一遍確定性豐富化，拿到判定，然後把它發到一個團隊之外無人可見的IT私有頻道。用真實通報跑兩週，並給每一條評分。這兩週裡你對自身釣魚風險曝險的了解，會超過任何一份廠商報告，而且你會知道這些回覆是否好到可以發給員工。到那時再打開自動回覆。如果你更希望把閘道、分派層和事件流程當成一整件事來建置，歡迎與我們聯絡。