網路資安威脅
三方郵件盡在駭客掌握！揭露一起進階版 B2B 變臉詐騙 (BEC)
Trend Micro™ Managed XDR 協助調查了一起 B2B 變臉詐騙 (BEC) 攻擊，揭露駭客如何利用一台被入侵的伺服器來建立錯綜複雜的聯絡網，在好幾天的時間內讓三家業務合作夥伴慢慢掉入他們編織的陷阱。本文提供此事件的調查洞見以及我們推測的事件發生時間表，並提出一些資安實務建議。
重點摘要：
- 最近我們調查了一起 B2B 變臉詐騙 (BEC) 攻擊，這是一個典型變臉詐騙的進階版，運用了精心設計的手法將多家企業玩弄於指掌之間。
- 事件中的駭客利用一台已遭駭入的電子郵件伺服器來發送詐騙郵件。
- 我們根據蒐集到的詳細資訊，建構出一個推測的事件發生時間表，顯示這起行動橫跨了數日之久。
- 除此之外，我們也找出了攻擊情境中使用到的 MITRE ATT&CK 技巧，以及企業可建置的一些資安控管。
- 同時還提出一些建議來協助企業主動保護自己的系統，防範 B2B 變臉詐騙攻擊所帶來的風險。
當企業遭遇變臉詐騙 (BEC)，只需一封電子郵件就能為企業帶來巨大的財務損失。在這類攻擊當中，駭客可能運用的技巧相當廣泛，從單純到進階都有，並且每一年都在增加。
最近我們在調查中發現了一起非典型變臉詐騙，駭客並非是只單純發送詐騙郵件來誘騙某家企業，而是利用業務合作夥伴之間的互信，耐心地編織出橫跨好幾天的詐騙陷阱。
這起事件主要包含以下幾項元素：
- 三家透過電子郵件進行商務往來的業務合作夥伴 (A、B 和 C)。
- 一台已遭駭客入侵的電子郵件伺服器，駭客用它來發送變臉詐騙郵件。
- 完整掌握了三家業務夥伴之間所有電子郵件對話的駭客。
駭客在這起詐騙當中運用了多種手法，包括駭入多個電子郵件帳號，類似帳號接管 (ATO) 的手法。在分析這整起變臉詐騙時，我們得重複查看多份來自所有當事人的相同電子郵件，可見像這樣的事件分析起來有多麼複雜，因為如果只分析部分 (某一組寄件人/收件人的郵件) 就無法看到所有電子郵件對話的全貌。
請繼續往下閱讀來進一步了解我們所推測出來的事件發生時間表，還有我們對於加強防範這類事件的建議，以及一些能協助您企業偵測及防範這類攻擊的觀念。
事件發生時間表
當 Managed XDR 團隊接到請求來協助調查這起 B2B 變臉詐騙事件時，我們使用 Trend Vision One™ 以及多名使用者所匯出的電子郵件標頭 (包括電子郵件對話的寄件人和收件人) 來分析 Trend Micro Email Sensor 所蒐集到的監測資料，這些資料能幫助我們重建整起事件的重要細節。這起事件大致分成兩個階段，如以下兩張圖片所示：
由於我們只能看到 B 夥伴這邊的事件發生經過，因此駭客一開始應該是在我們看不到的地方潛入並掌控了整個對話。此外，事件中的第三方電子郵件伺服器也屬於另一家正常機構所有，雖然它並非電子郵件對話的一環，但卻被用來發送變臉詐騙郵件。
值得注意的是，駭客似乎能完整看到這三家業務合作夥伴彼此之間的所有電子郵件往來。事實上，在步驟 2 和步驟 3 這段時間，我們有證據顯示駭客之所以再重發一次同一封電子郵件，是因為 B 夥伴的電子郵件系統拒絕了駭客透過已駭入的第三方電子郵件伺服器所發的那封信。
還有一個重要的細節是，駭客大約等了 4.5 小時之後才潛入電子郵件對話當中。所以當天稍晚收到這封電子郵件的 B 夥伴，才會以為是 A 夥伴發現他們自己最初提供的銀行資訊有誤，所以才又重發了一次。而且駭客並非從最初的電子郵件地址發送新的假銀行資訊 (因為這樣可能會引起疑慮)，而是等待對話管道建立。不過，步驟 2 和步驟 3 的電子郵件都含有宣稱來自 A 夥伴的最新匯款指示，要求 B 夥伴將錢匯到詐騙帳號。
在第二階段，駭客已完全潛入對話當中，並且將兩家公司的對話隔開。很重要的是，這個電子郵件對話串中大約有 4 至 6 名收件人，駭客會逐步將收件人的地址替換成他們自己的電子郵件地址。
為了讓一切看起來正常，電子郵件的「寄件人」欄位都是 A 夥伴或 B 夥伴的人員，但「回覆地址」(Reply-To) 卻都是駭客的電子郵件地址，不論是寄給 A 夥伴、B 夥伴或 C 夥伴的電子郵件都一樣。至於電子郵件的內容，駭客會模仿 A 夥伴和 B 夥伴的寫作風格 (寒暄方式、署名及遣詞用字)，通常都盡量簡短。
有幾封變臉詐騙郵件是透過第三方電子郵件伺服器來發送。但該伺服器的組態設定似乎不安全，因而讓這些詐騙郵件能夠通過 Sender Policy Framework (SPF) 認證。至於這是因為第三方電子郵件伺服器的組態設定一開始就錯誤，或是駭客篡改了電子郵件伺服器的組態設定，我們不得而知。
接著，駭客會將 A 夥伴提供的資訊發送給 B 夥伴來確認，但銀行資訊部分已更換成第一階段的假銀行資訊。此時，A 夥伴和 B 夥伴都以為自己是在跟對方通信，但其實他們的通信對象都是駭客。最後，B 夥伴將款項匯入了駭客的銀行帳戶。
從下圖時間表可以看出來，整個騙局計畫得相當嚴密：
| 時間 | 詳細說明 |
| 以下電子郵件對話串發送時間是在週三和週四。 | |
| T+0:00 | A 夥伴發一封電子郵件來向 B 夥伴請款，並將副本 (CC) 寄給 C 夥伴。 |
| T+4:30 | 駭客利用「回覆」方式又將這封信發給了 B 夥伴，並附上新的銀行資訊。 但這並非一封回覆，而是一封新的電子郵件 (從其 Message-ID 及相關的電子郵件標頭就能看出來)，並且是經由已遭駭入的電子郵件伺服器所發送。在保留相同顯示名稱的情況下，郵件中指定的 6 個電子郵件地址有 1 個被換成了駭客的郵件地址。此外，Reply-To (回覆地址) 也被設定成了駭客的郵件地址。 |
| T+11:00 | 駭客又利用「回覆」方式將前述郵件再發了一次，但這次是利用 C 夥伴已被駭入的電子郵件帳號來發送，電子郵件的內容與先前的一樣。 |
| T+15:00 | B 夥伴確認收到了發票，並通知「A 夥伴」(其實是通知到了駭客)，告知他們會審查其提供的資訊，並要求提供公司詳細資訊。實際上，這封回信會傳送到駭客，而真正的 A 夥伴所收到電子郵件當中，6 個原始收件人有 5 個都已經被暗中調包。 |
| 接著經過了週五、週六及週日。 | |
| T+5.02 天 | A 夥伴回覆了正確的公司詳細資訊給「B夥伴」(其實是發給了駭客)。這就是那封 6 個收件人當中有 5 個變成駭客地址的電子郵件。 |
| T+5.17 天 | 駭客假扮「A夥伴」發送一封後續電子郵件給 B 夥伴來提供確認的公司詳細資訊，以及先前 (上週) 要求的最新銀行資訊。 |
| T+5.64 天 | B 夥伴將款項匯入駭客的銀行帳戶。 |
| T+5.66 天 | B 夥伴通知「A 夥伴」(其實是駭客) 款項已經匯出。 |
最後，A 夥伴在第一次送出請款發票後的 12 天左右，請 B 夥伴確認是否已經匯款，此時款項早已全部匯到駭客的帳戶。
還有一點值得注意的是，在這段期間，A 夥伴和 B 夥伴雙方之間仍有其他與這個討論串分開的信件往返。照理說，只要是使用者曾經回覆過某個電子郵件地址，那麼大多數電子郵件用戶端程式的地址自動完成功能就會記住這個地址。所以，駭客才會選擇將某些自動完成的郵件地址換成真正的收件人 (非駭客)，這樣才不會影響到其他對話。
除了最初寄出發票的郵件之外，我們還找到了大約 5 個其他的電子郵件對話串，在這些對話串中，A 夥伴或 B 夥伴的寄件人所發的郵件都會傳送到駭客的電子郵件地址，真正的收件人 (非駭客) 會晚一點收到郵件。但由於 A 夥伴、B 夥伴和 C 夥伴本來就是電子郵件的寄件人或收件人，因此所有人看到的都是電子郵件對話一切正常。
這種詐騙是可以避免的嗎？ 無法完全避免，但可以增加它的困難度。
在我們解決這個問題之前，讓我們先來看看這起事件用到的 MITRE ATT&CK 技巧：
- 由於駭客已經掌握了蒐集受害企業電子郵件的管道 (T1114)，因此當受害企業內部出現這類對話時，駭客馬上就能看到有機可乘。
- 這一點雖然無法在這起事件當中直接證實，但一種常見的方式就是先接管某個有效的網域帳號 (T1078)，然後再運用某種形式的電子郵件轉寄規則 (T1114.003) 就能做到這點。
- 為了容易發送電子郵件，駭客還入侵了某台第三方電子郵件伺服器 (T1584.004)。被駭入的電子郵件伺服器同樣也隸屬於某個正常機構，所以一切看起來都很正常，只不過該機構對其外送電子郵件已無太多掌控能力。
- 駭客會建立一些呼應其登入方式的電子郵件帳號，例如：駭客不會使用user1[@]partnerA.com 這樣的帳號，而是使用 user1[@]free-email-domain.com 這樣帳號。 駭客會基於他們對每家受害機構的了解來預先建立這些帳號 (T1585.002)，他們會針對 A 夥伴、B 夥伴和 C 夥伴的不同使用者建立不同的電子郵件地址，而且這些電子郵件地址的顯示名稱也會仿照真正的使用者。
- 駭客利用了受害機構之間的信任關係 (T1199)，而且整起 B2B 變臉詐騙都高度仰賴這一層關係才能成功。
- 事件最後的結果是一起金融竊盜案 (T1657)，至於被駭客入侵的電子郵件伺服器，則是資源遭到挾持 (T1496)。
資安固然有眾多層面必須考量，但一家企業能夠做的，就是做好自身環境的資安控管。至少，每家企業都能設法不要讓駭客能夠輕易發動 B2B 變臉詐騙。
以下建議適用於大多數曾經遭遇類似攻擊的企業機構：
1. 洽詢您的電子郵件防護廠商，看看能否建置一些額外的電子郵件控管，如：Domain-based Message Authentication, Reporting, and Conformance (DMARC)、DomainKeys Identified Mail (DKIM) 以及 Sender Policy Framework (SPF)
在這起事件中，駭客製作的電子郵件顯然無法通過這些檢驗：
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=softfail (sender ip
is 11.22.33.44) smtp.rcpttodomain=PartnerA.com smtp.mailfrom=PartnerB.com;
dmarc=fail (p=none sp=none pct=100) action=none header.from=PartnerB.com;
dkim=none (message not signed); arc=pass (0 oda=0 ltdi=0 93)
ARC-Authentication-Results: i=1; rspamd-587694846-cqc8b; auth=pass
smtp.auth=spamcontrol26 smtp.mailfrom=finance-person@PartnerB.com
Authentication-Results: spf=softfail (sender IP is xx.yy.aa.bb)
smtp.mailfrom=PartnerB.com; dkim=none (message not signed)
header.d=none;dmarc=fail action=none header.from=PartnerB.com;compauth=other
reason=501
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
PartnerB.com discourages use of xx.yy.aa.bb as permitted sender)
(註：IP 位址和電子郵件網域已遮蔽或移除。)
但由於此處的 DMARC 電子郵件檢驗失敗政策已經被設定為「action=none」(不採取任何行動)，因此就算郵件無法通過檢驗還是會被放行，並寄到 A 夥伴的信箱。假使當初設定了嚴格的 DMARC 政策，此處就能發揮作用，因為這類電子郵件將無法通過檢驗；或者，至少電子郵件會在主旨上被標註為 [SPAM] (垃圾郵件) 或 [Suspicious] (可疑)，並送進垃圾郵件資料夾。
如果要對所有的電子郵件網域都這樣設定，應該先跟企業內的利害關係人討論一下，因為這會影響來自這些網域名稱的電子郵件遞送。不過，針對本案例的 B2B 通訊，雙方可以針對涉及金融交易的電子郵件對話實施這類電子郵件控管。
2. 考慮對電子郵件使用數位簽章，尤其是透過電子郵件進行金融交易的人員
駭客利用已遭駭入的電子郵件伺服器發送的電子郵件，其郵件標頭如下：
Received: by webmail.emailsrvr.tld (Authenticated sender:
compromised-account@compromised.email.server, from: finance-person[@]PartnerB.com) with HTTP
Authentication-Results: spf=pass (sender IP is xx.yy.aa.bb)
smtp.mailfrom=compromised.email.server; dkim=none (message not signed)
header.d=none;dmarc=fail action=none header.from=PartnerB.com;compauth=fail
reason=001
Received-SPF: Pass (protection.outlook.com: domain of compromised.email.server designates
xx.yy.aa.bb as permitted sender) receiver=protection.outlook.com;
client-ip=xx.yy.aa.bb; helo=smtp116.sub.emailsrvr.tld; pr=C
X-Auth-ID: compromised-account@compromised.email.server
Reply-To: finance-person[@]free-email-domain.com
(註：IP 位址和電子郵件網域已遮蔽或移除。)
從上面的電子郵件標頭可以看出這郵件已通過 SPF 認證，即使寄件人並未使用其指定的電子郵件地址，而且回覆地址也不同。
前述的 DMARC 設定在這裡同樣也能發揮作用。另一個可以考慮的作法是使用數位簽章來改善電子郵件對話的機密性和完整性。如此就能驗證電子郵件寄件人的真實性，同時確保電子郵件沒有被人篡改、與原始無異。
如果再搭配一些最佳實務原則，例如啟用多重認證 (MFA) 來保護網路並稽核登入動作，那麼經過數位簽章的電子郵件就很難偽造其來源。
同樣地，如果要對全公司或全面採用這項設定來保護所有電子郵件網域，確實是個不錯的主意，但應該先跟企業內的利害關係人討論過。在 B2B 交易部分，合作夥伴機構之間或許可以強制實施這類電子郵件控管，來確保電子郵件未遭到篡改，並來自數位簽章正確且有效的電子郵件帳號。
3. 針對特定人員實施更嚴格的稽核，尤其是那些須透過電子郵件進行金融交易的人員
在 B2B 變臉詐騙、甚至是一般變臉詐騙當中，最有利可圖的目標就是企業的一些重要人員，所以這些人可能需要更嚴格的監控與警報通知。視您資安工具的功能而定，您可能可以啟用以下警報：
- MFA 被停用。
- 登入平台發生異常事件 (例如 Impossible Travel)。
- 監控是否有可疑的活動，例如暗中建立轉寄規則，因為這是變臉詐騙的早期警訊之一。
企業可向電子郵件服務或資安廠商詢問是否提供變臉詐騙徵兆、帳號接管 (ATO) 之類的監控或類似的服務 (如：身分防護)，並請他們將這些功能列為優先。
4. 針對上述高風險使用者實施特別的教育訓練與流程
由於這類攻擊情境所利用的因素之一，就是兩家或多家公司人員之間的彼此默契和信任，因此這類高風險使用者可能必須接受另一套專門的教育訓練。企業可舉辦網路釣魚教育訓練，並針對高風險使用者實施 B2B 變臉詐騙模擬。如此可讓他們提高警覺，不再單純地相信出現在收件匣中的任何名字，而是會仔細確認透過電子郵件變更匯款帳號的指示。
在本文討論的事件當中，電子郵件討論串上的副本 (CC) 欄位包含了多個合作夥伴人員的電子郵件地址，而這些地址卻被偷換成免費電子郵件服務的地址。雖然我們可以理解使用者很難注意到任何不尋常之處，但留意這些可疑的變更還是有所幫助，尤其當對方透過電子郵件要求轉帳時。
5. 合作夥伴之間應事先約定好一套核對程序
從事件的發生時間表來看，假使第一天就有辦法透過其他管道來確認寄件人的身分，那麼基本上在駭客送出指示的幾分鐘內就能確認其匯款指示的真偽。例如，如果 B 夥伴和 A 夥伴之間已經約定要透過視訊/電話來核對電子郵件交易的真偽，那就能當場再次核對匯款指示。
如同 MITRE 的 M1060 指引所指出，藉由建立安全的頻外通訊管道 (也就是可能遭到入侵的網路之外的替代途徑)，將有助於確保關鍵通訊的永續與安全，一旦遇到網路攻擊，就能降低駭客攔截或篡改機敏資料的風險。今日已經有各種不同形式的頻外通訊管道，如：加密的即時通訊應用程式、安全的電話線路等等。
此外，也透過流程控管來達成這項目的，要求帳號變更之前須事先確認其真實性。例如，在發送電子郵件來索取金融交易指示之前，必須先透過其他方式溝通，不能單憑一封電子郵件。這樣一來，當收到要求變更銀行資訊的電子郵件指示時，就會有所警覺，因為這已經違反了事先約定好的程序。
6. 在高風險人員的電子郵件當中追查是否有違反流程的情況
至少在企業內強制實施這類標準流程並加以監控，請看以下範例：
From: invoicing[@]partner_organizationA.com
To: accounts_payable[@]partner_organizationB.com
Subject: Invoice from <Partner Organization> - reference ticket number
Email characteristics:
- 已設定 SPF 和 DKIM
- 強制啟用 DMARC，並永遠封鎖。
如果雙方預先同意採用這些標準作法，那就能建立一些警報邏輯來處理違反這些標準程序的狀況。對於使用 Trend Email Sensor 的 Trend Vision One 客戶來說，可透過以下邏輯來設定警報規則：
(mailFromAddresses: invoicing[@]partner_organizationA.com OR
mailToAddresses: accounts_payable[@]partner_organizationB.com) AND
(mailMsgSubject:Invoice) AND (mailWantedHeaderValue:dmarc=fail OR
mailWantedHeaderValue:dkim=none) AND (mailDirection:3)
這條追蹤規則可視需求而擴充或修改，但基本上它會找出符合以下條件的郵件：
- 任何內送的郵件、
- 來自 invoicing[@]partner_organizationA.com 或寄到 accounts_payable[@]partner_organizationB.com、
- 含有預先同意的電子郵件主旨、
- 電子郵件特性 (如 SPF、DKIM 或 DMARC) 違反雙方企業的規定。
除此之外，Trend Vision One 客戶還可啟用 Threat Insights 權利來取得更多追蹤查詢。
結論
變臉詐騙一旦得逞，企業將付出慘痛代價。不過，企業現有建置的技術很可能已具備了某些電子郵件防護功能可以協助降低這類攻擊的效果。因此，我們鼓勵企業應謹慎地和電子郵件服務供應商及電子郵件資安廠商一起好好評估自己的網路資安措施，並且要了解正確的商業往來習慣，即使面對值得信賴的業務合作夥伴也是一樣。
例如，建立適當的 DMARC 設定是降低變臉詐騙成功率不可或缺的一項安全機制。不過值得注意的是，雖然這項技術非常有效，但它只是整體資安框架的一環。尤其，DMARC 須建構在 SPF 和 DKIM 的基礎上，而這些同時也是 M3AAWG 等產業團體推薦並獲得 Google 背書的核心最佳實務原則。然而，有心想要建置 DMARC 的企業，卻可能面臨其複雜性的挑戰。在這種情況下，企業必須與電子郵件、訊息及協同作業廠商合作，以確保組態設定與整合的正確性。
此外，導入某些電子郵件規格也有所幫助，例如：BIMI 可在通過 DMARC 驗證的電子郵件上顯示企業的品牌標誌。這有助於收件人分辨來自可信任來源的電子郵件與未經檢驗的資源。
採用 Trend Vision One 的主動式防護
Trend Vision One 是一套能簡化資安作業的企業網路資安平台，藉由整合多種防護功能、強化企業對攻擊面的掌握，以及提供資安風險狀況的全方位可視性，來協助企業更快偵測及攔截威脅。這套雲端式平台，運用了 AI 以及來自全球 2.5 億個感測器與 16 個威脅研究中心的威脅情報，在單一解決方案當中提供了完整的風險洞見、早期威脅偵測，以及自動化風險與威脅回應選項。
Trend Vision One 威脅情報
要隨時掌握新興的威脅，Trend Vision One 客戶可透過 Intelligence Reports 以及 Threat Insights 取得各種情報與威脅洞見。Threat Insights 可幫助客戶在威脅發生之前便提前掌握，並對新興的威脅預先做好準備，提供有關駭客、惡意活動及駭客技巧的完整資訊。善用這些情報，客戶就能主動採取步驟來保護自己的環境、防範風險，並且有效回應威脅。
Trend Vision One Threat Insights 應用程式