2022 年到 2023 年間，在我們監控範圍下的許多金融單位，均能觀察到中國駭客組織的攻擊行為，比起往年顯得更加活躍；而藉由相關的調查，我們也發現了其中許多攻擊的成因，都與供應鏈相關的資安問題習習相關。
過往由於供應鏈安全有著各種不同的問題，人們時常會將那些攻擊混為一談，故而難以找到共通點；因此，為了更加系統化地剖析供應鏈資安問題，我們首先依照下表將供應鏈安全問題分為四個類別。
在上圖的分類中，我們根據兩個維度將供應鏈攻擊類型分為四種，第一個維度涉及初始受駭單位，而第二個維度涉及受駭的軟體生命階段。在初始受駭單位的部分，攻擊者除了直接攻擊受害單位，也有許多案例是先打下供應商，再間接攻擊受害單位的；再來，我們進一步將供應商細分為兩個不同角色－－系統開發商和服務提供商。而在另一個維度，我們則以受駭軟體的生命階段作為區分，因為軟體在開發、派發、運行等不同階段中，都有可能遭遇不同的攻擊。
說到最常見的一種供應鏈攻擊，應該屬於供應鏈軟體漏洞。攻擊者透過了解目標使用的軟體系統，針對這些軟體挖掘漏洞，並利用該漏洞在軟體的運行階段直接攻擊受害單位。類似這樣的攻擊型態存在已久，只是直到近期人們才將其放入供應鏈的議題中一併進行探討。
而相對而言，近期較為知名的供應鏈攻擊，如 ShadowHammer 和 SolarWinds，則是涉及在軟體開發階段植入惡意程式的手法，惡意程式伴隨著合法軟體，依正常管道被安裝在使用者機器上。由於惡意程式是經過合法的軟體開發流程，甚至可能被開發公司簽章，大部分資安偵測機制都可能會被繞過，而在使用者安裝後，便可自動植入後門，造成相當廣泛且嚴重的破壞。在這類攻擊之中，所有使用到該軟體的用戶，都會是潛在的受害者。
在我們的分類之中，特別將服務提供商這個角色切分出來，強調中間服務提供商的重要性。以現今的軟體生態系而言，中間服務商在軟體安裝、維護、配置中皆會發揮關鍵作用，並且通常會需要擁有高存取權限、以便存取被服務單位的 IT 系統，這種情況可能會造成新的攻擊表面 (Attack Surface) 產生，並導致一種所謂的跳島攻擊 (Island Hopping Attack)。跳島攻擊的攻擊者首先會先針對服務提供商發動攻勢，取得 VPN、遠端桌面等遠端控制的權限，並透過這些途徑進入目標企業內網。
最後一種攻擊手法，則可以視為跳島攻擊的相反方式，也就是直接偷取受害單位提供給服務商、外包商的資料。前者是軟體系統、控制權限由供應商提供給受害單位，後者則是由受害單位將資料提供給服務供應商、外包商。
這些不同的供應鏈攻擊類型，體現出供應鏈安全並非單一的問題，需要對不同種類的攻擊手法提供不同的處置方式，以提供全面的安全措施和監控。舉例而言，針對前述提及的跳島攻擊，企業需在自家採用較好的威脅獵捕、監控偵測機制，並加強有關外部供應商對內部系統的存取管控。但相同的方式，便無法有效處理外包商外洩資料的潛在威脅，因為該類攻擊的主戰場是在外包商的系統、而非企業內部，因此針對外包商強化事件處理，才是處理這類問題的方式。
在監控許多金融單位的網路攻擊後，前述四種攻擊類別我們基本上都有遭遇過，而本文也繼續依循這樣的分類，來探討與分享幾個攻擊案例。為了確保受害單位的隱私，以下案例內容皆已將過程中的資訊，包含公司名稱、使用者名稱、機器名稱、特定路徑等進行匿名化，僅保留與攻擊相關的資訊。
首先，讓我們一起深入研究第一類的跳島攻擊。在跳島攻擊的相關事件中，最初的受害單位可能是各種受信任的機構，例如向受害公司提供服務的服務提供商、外包商、子公司和海外分支機構等。除此之外，企業的子公司也可能會與其他廠商有服務往來、或者資訊系統的代管橋接等，這也可以算是服務商的一種。 而跳島攻擊這一類的行為，在金融單位可以說是更加突出。
以金融單位集團內子公司作為跳板，攻擊其他公司，是金融單位頻繁遇見的攻擊手法。」
跳島攻擊的攻擊者間接利用了這些受信任的機構，作為他們滲透最終目標的墊腳石。而在這種類型中，我們發現兩起針對金融業的攻擊事件：
在此事件中，受害金融單位在其內部交易系統上偵測到惡意程式的行為，同時該單位的安全運營中心 (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 後門，進行後續的攻擊。
回到這次攻擊事件的起源，是防毒軟體在以下位置偵測到惡意程式：
值得注意的是，分析了偵測到這些惡意程式的端點後，我們發現攻擊是從另一台機器 Server-CARISA 來的，這台端點並不屬於受害者的組織，而是隸屬於同一金融集團下其他公司的機器。而再往後追蹤，這個端點是由一家供應商負責運營的，最後確認威脅來源是來自一個供應商分配到的 VPN IP。因此可以研判，攻擊者先入侵了供應商，利用供應商的 VPN 進到金融集團下公司的機器，接著再往後通向同一集團下的其他公司系統。
最後，讓我們來看這個案件中主要的後門程式 Bifrose：
以下是這次 Bifrose 程式運作的流程與架構：
Bifrose 起初透過啟動服務並執行 ServiceMain 函數來啟動，然後通過變異的 RC4 算法解密 payload。需要注意的是，不僅 payload 是加密的，加載器內部的配置資訊也是加密的，這種加密機制使得分析和檢測 Bifrose 變得更加困難。
經過解密後，Bifrose 便會在記憶體內將解密後的內容以 DLL 的方式執行。具體來說，會經過以下步驟：
這個過程中 Bifrose 所有的操作都是在記憶體進行，不會在檔案系統留下明顯的痕跡和記錄，加深了分析上的難度。
而在完成基本的執行後，Bifrose 會將機器相關的資訊回傳到 C2，包含 victim ID、computer name、username、version number、process id、language 等。
Bifrose 連接到 C2 伺服器後，攻擊者可以進行以下操作：
最後，在此附上本次事件的 TTP 與 IoCs 供各位讀者參考。
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 事件有興趣的讀者點擊詳閱。
回到本文，關於此事件我們想要強調的重點是，其主要的兩個資安問題都與供應鏈相關：
緊接著，我們來介紹第二種供應鏈攻擊。這種攻擊手法被歸類為供應商軟體漏洞，當這些供應商的軟體在特定行業中被廣泛採用，攻擊者可以相對輕鬆地利用漏洞來對多個受害者造成威脅。
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) 清單供參考。
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 列表。
最後，我們想來分析這些攻擊發生背後的原因，並藉此探討金融單位常遇到的困難。
雖然一般而言，人們常會認為金融單位因為有較高標準的資安規範、以及較多的資安預算，應該已將資安做得相當嚴謹，但實務上，仍會面對幾個困難的問題：
金融產業獨特的供應鏈問題，源自於許多金融公司事實上都是作為金融控股集團的其中一部分，在這種結構中，屬於同一金融控股集團的不同公司，可能有不同程度的資安規範、側重不同的資安防護。而在這些集團中，銀行通常遵守最嚴格的安全要求，並更常接受全面的安全稽核；相比之下，證券等公司則往往面對較少的安全稽核要求。舉例而言，銀行因更高標準的資安規範會對遠程桌面協議 (RDP) 日誌進行例行稽核，但同一金融控股集團中的證券公司，卻有可能不會對 RDP 活動進行任何稽核或監督。這種安全機制和稽核要求的差異，展現出了金融行業供應鏈結構帶來的獨特挑戰。
事實上，金融公司的資訊安全能力往往取決於合規要求。在許多情況下，金融機構會將其安全措施與其所受合規法規相一致，若是法規未包含的資安機制，金融單位便不傾向且難以立即部署。
法規的制定也會因金融公司的類型不同，而去設置不同的標準。不同的金融機構，如銀行和證券經紀商，可能面臨不同的監管義務，因此展現出不同程度的資訊安全強度；但在同一集團內，常會為了業務整合需求、IT 資源利用統合，將 IT 基礎建設橋接起來，造成我們在這幾次案例中所看到，特殊模式的跳島攻擊。