揭秘針對臺灣金融單位的供應鏈攻擊手法
2022 年到 2023 年間，在我們監控範圍下的許多金融單位，均能觀察到中國駭客組織的攻擊行為，比起往年顯得更加活躍；而藉由相關的調查，我們也發現了其中許多攻擊的成因，都與供應鏈相關的資安問題習習相關。
過往由於供應鏈安全有著各種不同的問題，人們時常會將那些攻擊混為一談，故而難以找到共通點；因此，為了更加系統化地剖析供應鏈資安問題，我們首先依照下表將供應鏈安全問題分為四個類別。
在上圖的分類中，我們根據兩個維度將供應鏈攻擊類型分為四種，第一個維度涉及初始受駭單位，而第二個維度涉及受駭的軟體生命階段。在初始受駭單位的部分，攻擊者除了直接攻擊受害單位，也有許多案例是先打下供應商，再間接攻擊受害單位的；再來，我們進一步將供應商細分為兩個不同角色－－系統開發商和服務提供商。而在另一個維度，我們則以受駭軟體的生命階段作為區分，因為軟體在開發、派發、運行等不同階段中，都有可能遭遇不同的攻擊。
說到最常見的一種供應鏈攻擊，應該屬於供應鏈軟體漏洞。攻擊者透過了解目標使用的軟體系統，針對這些軟體挖掘漏洞，並利用該漏洞在軟體的運行階段直接攻擊受害單位。類似這樣的攻擊型態存在已久，只是直到近期人們才將其放入供應鏈的議題中一併進行探討。
而相對而言，近期較為知名的供應鏈攻擊，如 ShadowHammer 和 SolarWinds，則是涉及在軟體開發階段植入惡意程式的手法，惡意程式伴隨著合法軟體，依正常管道被安裝在使用者機器上。由於惡意程式是經過合法的軟體開發流程，甚至可能被開發公司簽章，大部分資安偵測機制都可能會被繞過，而在使用者安裝後，便可自動植入後門，造成相當廣泛且嚴重的破壞。在這類攻擊之中，所有使用到該軟體的用戶，都會是潛在的受害者。
在我們的分類之中，特別將服務提供商這個角色切分出來，強調中間服務提供商的重要性。以現今的軟體生態系而言，中間服務商在軟體安裝、維護、配置中皆會發揮關鍵作用，並且通常會需要擁有高存取權限、以便存取被服務單位的 IT 系統，這種情況可能會造成新的攻擊表面 (Attack Surface) 產生，並導致一種所謂的跳島攻擊 (Island Hopping Attack)。跳島攻擊的攻擊者首先會先針對服務提供商發動攻勢，取得 VPN、遠端桌面等遠端控制的權限，並透過這些途徑進入目標企業內網。
最後一種攻擊手法，則可以視為跳島攻擊的相反方式，也就是直接偷取受害單位提供給服務商、外包商的資料。前者是軟體系統、控制權限由供應商提供給受害單位，後者則是由受害單位將資料提供給服務供應商、外包商。
這些不同的供應鏈攻擊類型，體現出供應鏈安全並非單一的問題，需要對不同種類的攻擊手法提供不同的處置方式，以提供全面的安全措施和監控。舉例而言，針對前述提及的跳島攻擊，企業需在自家採用較好的威脅獵捕、監控偵測機制，並加強有關外部供應商對內部系統的存取管控。但相同的方式，便無法有效處理外包商外洩資料的潛在威脅，因為該類攻擊的主戰場是在外包商的系統、而非企業內部，因此針對外包商強化事件處理，才是處理這類問題的方式。
供應鏈攻擊案例探討
在監控許多金融單位的網路攻擊後，前述四種攻擊類別我們基本上都有遭遇過，而本文也繼續依循這樣的分類，來探討與分享幾個攻擊案例。為了確保受害單位的隱私，以下案例內容皆已將過程中的資訊，包含公司名稱、使用者名稱、機器名稱、特定路徑等進行匿名化，僅保留與攻擊相關的資訊。
Type 1：跳島攻擊
Island Hopping Attack
首先，讓我們一起深入研究第一類的跳島攻擊。在跳島攻擊的相關事件中，最初的受害單位可能是各種受信任的機構，例如向受害公司提供服務的服務提供商、外包商、子公司和海外分支機構等。除此之外，企業的子公司也可能會與其他廠商有服務往來、或者資訊系統的代管橋接等，這也可以算是服務商的一種。 而跳島攻擊這一類的行為，在金融單位可以說是更加突出。
以金融單位集團內子公司作為跳板，攻擊其他公司，是金融單位頻繁遇見的攻擊手法。」
跳島攻擊的攻擊者間接利用了這些受信任的機構，作為他們滲透最終目標的墊腳石。而在這種類型中，我們發現兩起針對金融業的攻擊事件：
- Bifrose is Back
- Operation Cache Panda
Case #1: Bifrose is Back
在此事件中，受害金融單位在其內部交易系統上偵測到惡意程式的行為，同時該單位的安全運營中心 (Security Operation Center, SOC) 還發現了大量登錄失敗的紀錄。因此該單位尋求奧義的服務，開啟了事件應變調查，藉以尋找事件根因。
攻擊者利用原本提供給供應商的 VPN 存取由供應商所管理的機器，從而進入到內網發動攻擊。攻擊者在該機器上執行惡意程式，並對同一集團內的另一家金融公司發動攻擊。 以下，我們整理了此攻擊事件中的 Cyber Kill Chain 和戰術、技術與程序 (Tactic, Techniques, and Procedures. TTP)。
此事件涉及三個主要攻擊途徑。首先，讓我們深入研究前兩條攻擊途徑。Server CARISA 嘗試暴力登錄帳戶 Admin 和 Administrator，最後成功地使用 Administrator 帳戶訪問了 Server SOON-2，此處攻擊者應該已取得管理員權限，可以在內網中進行橫向移動。
Server-SOON-2 對這次攻擊是個重要的端點，攻擊者利用遠程桌面協議 (Remote Desktop Protocol, RDP) 和 PsExec 進行橫向移動，並且傳播惡意軟體。
在 Server-SOON-2 上，本地管理員通過 RDP 登錄後執行了可疑的執行檔 ntxn264.exe，從而植入一個惡意的 DLL 文件 uNPXtssucPrx.dll 作為後門。這個後門 DLL 被註冊為一個持續性的服務，確保它在系統重新啟動後會自動被執行，而這個 DLL 經我們研究後確認為 Bifrose 後門，進行後續的攻擊。
回到這次攻擊事件的起源，是防毒軟體在以下位置偵測到惡意程式：
- C:\[Vendor_Name]\svchost.exe
- C:\Windows\System32\wwautoaepupdate.dll
值得注意的是，分析了偵測到這些惡意程式的端點後，我們發現攻擊是從另一台機器 Server-CARISA 來的，這台端點並不屬於受害者的組織，而是隸屬於同一金融集團下其他公司的機器。而再往後追蹤，這個端點是由一家供應商負責運營的，最後確認威脅來源是來自一個供應商分配到的 VPN IP。因此可以研判，攻擊者先入侵了供應商，利用供應商的 VPN 進到金融集團下公司的機器，接著再往後通向同一集團下的其他公司系統。
最後，讓我們來看這個案件中主要的後門程式 Bifrose：
以下是這次 Bifrose 程式運作的流程與架構：
- 載入經過加密的 Payload
- 解析 PE 格式並跳到程式起始點執行
- 檢查自身程序名稱
- 連線到 C2 回傳基本機器資訊
- 後續的控制指令
Bifrose 起初透過啟動服務並執行 ServiceMain 函數來啟動，然後通過變異的 RC4 算法解密 payload。需要注意的是，不僅 payload 是加密的，加載器內部的配置資訊也是加密的，這種加密機制使得分析和檢測 Bifrose 變得更加困難。
經過解密後，Bifrose 便會在記憶體內將解密後的內容以 DLL 的方式執行。具體來說，會經過以下步驟：
- Bifrose 解析載荷作為 DLL 文件的 PE 標頭
- Bifrose 將載荷中的各個 section 拷貝到記憶體內，以便後續執行
- 解析載荷中 Import Table 中的函式庫
- 執行 LoadLibrary 並進行重定位操作，確保解密後的 DLL 能夠在適當的記憶體位置上運行
- 最終，Bifrose 將控制權轉交給 DLL 的入口點，使得載荷得以在記憶體中執行
這個過程中 Bifrose 所有的操作都是在記憶體進行，不會在檔案系統留下明顯的痕跡和記錄，加深了分析上的難度。
而在完成基本的執行後，Bifrose 會將機器相關的資訊回傳到 C2，包含 victim ID、computer name、username、version number、process id、language 等。
- Victim ID：default_zz, set by threat actor
- Computer Name：GetComputerNameA
- User Name：GetUserNameA
- Version Number：2120.1
- Process ID：GetCurrentProcessId
- Language：GetLocaleInfoA
Bifrose 連接到 C2 伺服器後，攻擊者可以進行以下操作：
最後，在此附上本次事件的 TTP 與 IoCs 供各位讀者參考。
Case #2: Operation Cache Panda
Operation Cache Panda 在我們之前的部落格文章中也有介紹過，由於此事件相當重要，這邊我們還是再次簡短介紹這個事件，若想進一步了解相關的詳情，可以點擊下方文章閱讀。
深度剖析針對臺灣金融業的 Operation Cache Panda 組織型供應鏈攻擊
2021 年 11 月 25 日，大量的不正常交易行為，導致許多證券交易業者不得不暫停其交易，來處理系統上所檢測到的可疑活動。當時的初步調查顯示，這些攻擊可能與密碼管理不當和潛在的憑據填充相關，而在這次事件後，許多機構的安全意識提高，部分金融單位選擇加強自身的資安能量，像是採用託管式端點偵測與回應 (Managed Detection and Response, MDR) 等服務，以長期持續地監控其系統安全。
此次事件後，其中一受害單位向奧義尋求協助、要求進行資安事件應變 (事件回應 (Incident Response, IR)，並進一步釐清事件成因等。在執行 IR 的過程中，我們發現到在 2021 年 11 月左右，該單位已有遭受 APT 攻擊的軌跡，這凸顯了金融行業持續存在的安全威脅；此外，我們也在 2022 年 2 月檢測到了新的可疑活動，表明攻擊仍在持續發生。正因如此，我們認爲這一事件並非一起單純的 Credential Stuffing 攻擊，而很有可能是與 APT 攻擊相關，特別是與 TA410 相關聯。
前述文章中，有針對此事件的詳細攻擊手法剖析等，歡迎對 Operation Cache Panda 事件有興趣的讀者點擊詳閱。
回到本文，關於此事件我們想要強調的重點是，其主要的兩個資安問題都與供應鏈相關：
- 攻擊者針對一個金融單位常用的軟體系統的漏洞進行攻擊
- 攻擊者利用供應商的 VPN 作為跳板進行橫向移動
Type 2 供應商軟體漏洞
Vulnerability in Supplier’s Software
緊接著，我們來介紹第二種供應鏈攻擊。這種攻擊手法被歸類為供應商軟體漏洞，當這些供應商的軟體在特定行業中被廣泛採用，攻擊者可以相對輕鬆地利用漏洞來對多個受害者造成威脅。
Case #3: Credit Card Leak in Bank
2022 年 4 月，某銀行發現了一起異常的信用卡資料外洩事件，並懷疑是網路攻擊的結果。該銀行請奧義協助，進行對信用卡資料外洩的調查分析，因此，我們開始針對信用卡申請流程進行全面檢查，以及立即對可能被入侵的重要伺服器展開調查。
總結來說，這起事件中的供應鏈問題，可以追溯到信用卡管理系統存在的網頁應用程式漏洞，並且是由他們自己的供應商開發的。其中，我們注意到攻擊者相當快速地利用漏洞，並沒有探測系統漏洞的痕跡，便直接利用 exploit 進行攻擊；此外，該特定系統並未被廣泛應用在其他公司。因此，我們推測攻擊者可能已經從其他管道挖掘到漏洞，才讓他們能夠如此迅速地發動攻擊。
而後，我們針對信用卡申請流程展開進一步調查，很快地發現到有幾個端點已經被入侵。其中有個關鍵端點，此處我們暫時先將其稱為 Credit Card AP；Credit Card AP 負責處理所有與新信用卡申請相關的請求。
緊接著，這些申請請求將導到另外兩個端點進行驗證。如果所有驗證過程都成功，最後的信用卡資訊將被存到資料庫伺服器中，在此架構中，Credit Card AP 和資料庫伺服器是最關鍵的兩個端點，它們是管理信用卡應用程式並確保相關資料安全的重中之重，同時也是攻擊者鎖定的目標。
接下來，我們來看看這整起事件的詳細案情以及 TTP。
起初，攻擊者利用了網頁應用程式中的漏洞，在初期存取後便開始進行橫向移動，進入到 Credit Card AP 伺服器；隨後，他們繼續向資料庫伺服器和其他端點進行橫向移動，這種進展方式表明了攻擊者有明確的目標，並專注於瞄準資料庫伺服器和 Credit Card AP 兩個重要的伺服器。
在初始階段，一個值得注意的問題是配置錯誤。受駭組織內的 IT 人員告訴我們，測試系統應該只能從內網被存取，然而，在檢查網頁日誌時，我們發現到一些 Public IP 曾嘗試連接到這台伺服器。為了驗證這一點，我們進行了測試，並且成功地與測試伺服器建立了連接，進而確認到一項配置上的錯誤。此外，測試伺服器通常都使用弱密碼，這點也常會被攻擊者利用，需要格外加以留意。
除了配置錯誤問題外，該伺服器還存在任意文件上傳的漏洞。該漏洞允許他們上傳一個名為 “1.aspx” 的 webshell，是一個基於 .NET 具有動態程式碼加載功能的 webshell。
我們發現的 webshell 是一種叫 behinder webshell 的變種版本，使得攻擊者能以不易察覺的程式碼，控制被入侵的伺服器。behinder 是中國威脅組織常用的 webshell 框架，這隻樣本的發現，也增加了這次攻擊或許來自中國的可能性。在植入 webshell 之後，攻擊者利用 pystinger 和 proxy.aspx 建立了隧道 (tunnel)，將內網和命令與控制 (Command & Control, C2) 伺服器連接起來。
除此之外，我們還在 CCAP 伺服器上識別出了一些可疑的活動。在這台伺服器上，我們發現一個名為 ts_windows_amd64.exe 的惡意程式，它是用 Golang 開發的，具有 FTP、Samba、Netcat (nc) 和 Windows Management Instrumentation (WMI) 等偵察功能。另外，我們也發現了 PrintSpoofer 等用於提升權限的工具。
我們也在幾個端點上發現了混淆過後的 Cobalt Strike，以及另一個名為 hoshinoGen 的工具，它可以生成繞過防病毒軟體檢測的 shellcode 的能力，也是中國駭客社群中常用的工具。
最終，攻擊者成功地進入了資料庫伺服器，並使用 SQL操作軟體與資料庫進行互動。因此，合理地推斷這條路徑可能是導致信用卡資料泄露的潛在途徑。
以下有該事件 MITRE ATT＆CK 框架的摘要，並提供威脅指標 (Indicators of Compromise, IoC) 清單供參考。
Case #4: Source Code Stolen
2022 年 8 月初，某銀行單位因內部監控到一些可疑行為，開始進行深入的事件調查。此事件與之前的幾個案例類似，圍繞著交易平台存在的漏洞，且該漏洞成為了攻擊進入點。此事件的交易平台，是由臺灣的一家主要供應商開發的，故而影響到臺灣境內眾多金融單位。
接下來，我們將深入探討這一事件中攻擊手法與流程，下圖是本次攻擊的 Storyline。
在這個攻擊中，最初的入侵是利用 SQL Injection 漏洞來入侵一個面向公眾的伺服器，隨後，這台受到入侵的伺服器被用作立足點，使攻擊者進一步滲透其他內部 Web 伺服器。在此之後，攻擊者更利用了 scheduled tasks 和 psexec 在網路內進行橫向移動。
根據我們的執行事件，程序樹顯示以 SQL Server 為核心生成了大量的命令行程序，而類似這樣的狀況，由 SQL 相關程序創建 CMD 程序，是 SQLi 攻擊常見的模式。我們在追查這個案件的過程中，還識別出了一個額外的 webshell，它起源於 tomcat 程序創建了一個CMD 程序，來執行惡意指令。
在這次案件中，攻擊者使用了兩個隧道工具。第一項是一個開源工具 NPS，第二個則是 X.DLL。以下整理出我們所看到的命令列指令：
該案件還有一個值得關注的攻擊手法，是利用到了憑證提取。攻擊者透過名為 avdump 的合法工具來取得 LSASS 程序記憶體，目的是從這個記憶體轉儲中提取密碼，另外，他們也使用到 Mimikatz 來收集密碼。在這次攻擊中，利用防毒軟體的附加工具來轉儲程序記憶體，是整體攻擊中的一個特點。
而在此攻擊的後滲透操作中，研究團隊發現攻擊者使用 7-Zip 壓縮了一個特別的目錄，在與受害者的討論中，他們確認了目錄的內容，並推測部分原始碼已遭到竊取。
最後，以下為本案例 MITRE ATT&CK 框架的摘要，以及可供參考的 IoC 列表。
金融單位的資安態勢分析
最後，我們想來分析這些攻擊發生背後的原因，並藉此探討金融單位常遇到的困難。
雖然一般而言，人們常會認為金融單位因為有較高標準的資安規範、以及較多的資安預算，應該已將資安做得相當嚴謹，但實務上，仍會面對幾個困難的問題：
- 需高效能的服務交易
金融業的股票交易和運營需要大量的計算能力，這項需求通常會使得同樣也需求高效能的的安全機制難以實施。因此，金融單位有可能僅在非關鍵端點上部署端點偵測 (Endpoint Detection and Response, EDR)，但真正重要關鍵的端點，卻因效能考量而並為部署，因此無法具備完整威脅可視性、造成防禦網不夠全面。 - 供應商多元性不足
金融軟體市場嚴重被少數幾家主要供應商所壟斷，由於商務原因，這些供應商可能不會優先考慮安全功能。而從供應鏈漏洞這個持續存在的問題，便更能看出供應商過於集中所造成的隱憂。
金融產業獨特的供應鏈問題，源自於許多金融公司事實上都是作為金融控股集團的其中一部分，在這種結構中，屬於同一金融控股集團的不同公司，可能有不同程度的資安規範、側重不同的資安防護。而在這些集團中，銀行通常遵守最嚴格的安全要求，並更常接受全面的安全稽核；相比之下，證券等公司則往往面對較少的安全稽核要求。舉例而言，銀行因更高標準的資安規範會對遠程桌面協議 (RDP) 日誌進行例行稽核，但同一金融控股集團中的證券公司，卻有可能不會對 RDP 活動進行任何稽核或監督。這種安全機制和稽核要求的差異，展現出了金融行業供應鏈結構帶來的獨特挑戰。
事實上，金融公司的資訊安全能力往往取決於合規要求。在許多情況下，金融機構會將其安全措施與其所受合規法規相一致，若是法規未包含的資安機制，金融單位便不傾向且難以立即部署。
法規的制定也會因金融公司的類型不同，而去設置不同的標準。不同的金融機構，如銀行和證券經紀商，可能面臨不同的監管義務，因此展現出不同程度的資訊安全強度；但在同一集團內，常會為了業務整合需求、IT 資源利用統合，將 IT 基礎建設橋接起來，造成我們在這幾次案例中所看到，特殊模式的跳島攻擊。
結論
- 在我們的研究中，將供應鏈攻擊依其初始受駭單位與受駭的軟體生命階段，分成四種不同的攻擊手法 — — 供應鏈軟體漏洞、軟體植入惡意程式、跳島攻擊、供應商資料外洩。而這四種不同形式的攻擊，需要不同的資安機制來應對。
- 在供應鏈攻擊領域，由於金融機構應集團內的 IT 系統高度耦合，但安全能力不一致，形成了特殊的供應鏈問題。
- 過去兩年，我們發現四起針對金融業供應鏈的攻擊事件，並在本文中探討了這四個事件的案情，攻擊者使用的 TTP 及 IoC。以快速的調查拼湊出攻擊事件的完整故事後，我們期望藉由揭露這些攻擊手法，使人們更全面地了解金融資安的格局，進而有效強化單位資安防護的部署。
Writer: CK Chen
關於 CyCraft
奧義智慧科技（CyCraft Technology）是一家專注於 AI 自動化技術的資安科技公司，成立於2017年。總部設於台灣，在日本和新加坡均設有子公司。為亞太地區的政府機關、警政國防、銀行和高科技製造產業提供專業資安服務。獲得華威國際集團（The CID Group）和淡馬錫控股旗下蘭亭投資（Pavilion Capital）的強力支持，並獲得國際頂尖研究機構 Gartner、IDC、Frost & Sullivan 的多項認可，以及海內外大獎的多次肯定。同時也是多個跨國資安組織和台灣資安社群的成員和合作夥伴，長年致力於資安產業的發展。
訂閱奧義智慧電子報