Scientia
目錄
前言
於2024年四月，烏克蘭的Cyber Security Situation Center (CSSC)因為國內停電的情形而記錄到這隻新型針對烏克蘭能源公司進行工控攻擊的惡意軟體FrostyGoop/BUSTLEBERM，是目前為止回報第19隻被開發用來針對工控裝置的malware，透過Modbus TCP port攻擊成功後影響了超過600家烏克蘭國內公司的電力供應，如果工控裝置有連網的話這隻malware可以透過攻擊周邊的元件或者外部的系統進去，接著送Modbus指令去讀寫或變更Industrial control system (ICS)裝置的資料，造成能源上的災害。
Operational Technology (OT)的malware隨著世界各地的戰爭越來愈多有了顯著的增加，故本文章就想要透過烏俄戰爭之下產生的這隻FrostyGoop來探討針對能源的攻擊形式樣貌。
分析
初步判斷是俄羅斯的惡意組織發動攻擊造成超過600家公司內停電無法使用暖氣等設備，當地氣溫處於零度以下，而根據一些廠商的報告，攻擊者利用MikroTik router的漏洞進入工控設備系統內，但目前還不確定是否是從外部存取進去的還是有內神通外鬼，但目前確切可以知道的是利用Modbus TCP協定直接對ICS/OT設備進行溝通。
其中Modbus就是關鍵基礎設施內的系統工業元件跟軟體最常使用的協定，攻擊者在了解Modbus協定以及ENCO control設備的情況下能夠送自己建構的指令，只要該系統有支援指令，就能夠讓工控系統沒辦法準確的測量能源數值或者觸發工業元件警報讓系統停擺造成不繼續生產能源，然而在一些資安廠商的報告中是看到攻擊者先攻擊ENCO control設備放進malware，而後再去攻擊任意的設備，其中比較奇特的是在一次攻擊當中超過100萬組Modbus TCP設備在網路上可以存取，總計超過600萬組設備被洩漏出去。
可能是FrostyGoop先針對幾台Modbus TCP設備連線後傳送Modbus指令針對特定的中心ICS裝置又送了一些指令跟參數讓攻擊者可以橫向擴散找到更多的Modbus TCP設備，最終設計了一些分散的JSON config檔案去批次的尋找跟溝通才洩漏出去如此多台，這點就值得我們省思工控系統內有這麼多的元件跟設備該如何進行管理？
惡意樣本分析
新奇的是FrostyGoop是由Go語言寫成的，github上也有直接可以參考go寫成的Modbus實作library，這支malware其中一個特性是會使用JSON檔案儲存輸出或儲存config內容，但原生go的沒有支援json格式，所以攻擊者要自己加進去json格式，用來儲存針對ICS系統的特定格式指令以供malware可以讀取，而FrostyGoop可以支援兩種型態的參數
- 針對Modbus設備暫存器內所有可操作的指令及位址參數集合
- 時間設定檔的參數集合
圖一透過Binary Ninja工具查看暫存器內main:main.TaskList__runtime.structtype_fields
而圖二則顯示FrostyGoop暫存器內的timing configuration
原先go沒有支援，所以FrostyGoop使用的是Goccy’s go-json library，這個library屬於一種有效率的JSON encoder與decoder其支援go語言，同時這個library還支援一組特定的open-source controller “queues”，所以如果在其他疑似變種的樣本上也許可以透過這些動態鏈結進來的library作為一組IoC，如圖三就是用Binary Ninja分析FrostyGoop windows exe檔案有看到引入的資料。
儘管不是每一組找到的樣本都會像是這麼完整的字串，也許為了做混淆他們會特意設計不同的拼湊方法把URL組合起來，但在其他字串上面找到類似的關鍵字我想也是能當作malware偵測的準則。
另外FrostyGoop也實作了debugger規避功能，透過確認Windows的Process Environment Block (PEB) BeingDebugged值，操作這個區塊來讓malware本身不要被windows的malware分析工具抓到，厲害的點在於攻擊者實作替代方案不用呼叫WinAPI的IsDebuggerPresent()就能確認BeingDebugged flag如圖四。
Go-encrypt.exe樣本分析
在一些資安廠商報告當中顯示有一支關聯的叫做go-encrypt.exe檔案，一樣是用go寫成但行為不是FrostyGoop，不過調查一下IoC看到這兩支malware發生的日期其實近乎相同，所以一些報告內是將其關聯起來的，透過terminal查有沒有說明時還真的有寫，並且很直接的就告訴你這支malware是用來作JSON檔案加密及解密的如圖五
如果執行了go-encrypt.exe的-encrypt參數之後會建立兩個新的檔案如圖六
- 一組加密過的JSON檔案
- 一組32-byte的檔案內含解密金鑰”key”
而加密過的JSON檔案內容會長得像圖七
如果用Process Monitor去錄執行go-encrypt.exe的話還會發現它額外產了一組叫”key”的解密檔案，裡面存著32個character的內容如圖八
如果嘗試去decompile go-encrypt.exe的話發現需要造這把key其實是因為加密是使用AES演算法搭配Cipher Feedback (CFB) mode如圖九、圖十
所以我們知道了這支go-encrypt.exe使用AES的CFB mode之後，對於生出來的這把key應該要嘗試有一些調查，我們在圖六執行解碼的時候產出的”key”檔內容回傳了一組10進制資料
- 71 76 90 67 120 104 86 98 85 97 88 54 88 50 75 77 71 78 116 89 74 66 51 50 75 103 70 117 56 100 117 88
嘗試將這組數字串利用不同的方式來解碼成32-byte的內容，把這些10進制的轉成2進制在轉成16進制
def to_hex(key_dec:list)->list:
result = ' '.join('%02x'%i for i in key_dec)
return result轉換完成之後應該會得到一組32-byte的hex字串
- 47 4c 5a 43 78 68 56 62 55 61 58 36 58 32 4b 4d 47 4e 74 59 4a 42 33 32 4b 67 46 75 38 64 75 58
根據Go語言的官方文件來看aes.NewCipher這個feature，一組32 bytes的字串就是用來256-bit AES加密搭配CFB mode，所以可以用CyberChef等轉換工具來確認轉換出來的這個32bytes內容是不是跟key檔案裡轉ASCII值一樣
儘管我們在各項報告當中還無法斷言說出go-encrypt.exe是不是一定使用在FrostyGoop攻擊內，但有兩項猜測指出這項攻擊有利用的跡象
- 可能是使用這支加密及解密JSON檔案，畢竟傳輸加密過的JSON檔案是FrostyGoop功能裡基本需要的
- go-encrypt.exe這支程式的IoC出現實在是跟FrostyGoop樣本發生時間太過於相近，以及task_test.json檔案也差不多時間出現
所以一些資安廠商直接就先表示攻擊者可能有利用到go-encrypt.exe在潛伏階段先隱藏起來目標資訊的JSON檔案以利後續直接進行攻擊。
目標關鍵基礎建設
上面提到的task_test.json其實是根據Dragos針對FrostyGoop最早在2024年四月就發佈情資報告內提及，但如果從VirusTotal搜尋，最早2023年10月10號就能看到有人回報進行分析，持續關注這支奇怪的json檔後連帶發現它關聯著一些Windows執行檔有出現FrostyGoop以及go-encrypt.exe檔案等如圖十二
各家情資團隊嘗試對task_test.json進行分析時看裡面的資料結構以及key-values值就先猜測是不是用來給FrostyGoop執行檔當作設定的內容，Unit42團隊認為json檔案內容在進行一些Modbus操作的讀、寫以及多重寫入功能如圖十三
在一些樣本當中的task_test.json會看到Iplist記錄著應該是目標機器的外部實體IP，透過情資平台或直接搜尋該IP應該都會有一些資訊，例如在某一支樣本內發現某個IP對應的是位於羅馬尼亞境內的ENCO control設備如圖十四
而在一些報告當中就嘗試更大範圍的進行搜尋，光一隻樣本就嘗試對32組IP的ENCO裝置進行連線如圖十五，且都發生在羅馬尼亞亦或是烏克蘭境內的實體IP
說起來ENCO設備溝通走的是TCP port 23的Telnet協定，放在今日的角度來看根本不安全，這個協定根本不做驗證也沒有進行任何加密，簡單就能進行連線，這樣只要ENCO裡的可程式設計邏輯控制器(programmable logic controller, PLC)是放在網路上的，一般使用者都可以隨意的連線並且還會一併提供該設備能夠操作哪些指令如圖十六
而回去觀察task_test.json檔案內的設定就會發現這支裡面針對了一些協定進行連線如圖十七
- TCP port 23 (Telnet)
- 502 (Modbus)
- 1024 (Router WebUI)
- 37777 (ENCO connect port)
既然知道ENCO設備開的是什麼port，便可以嘗試去連線看看有無任何瀏覽器介面可以連線，順便測個流量，走TCP 23 Telnet協定就不指望它會把流量加密起來了，圖十八嘗試用browser登入一台ENCO設備，同時用Wireshark解析網頁連線流量，找到了一組正在服務的web server以及router的名字都清清楚楚的顯示在上面”TP-LINK Wireless Lite N Router WR740N”，連型號都有可說是最危險的等級。
根據MITRE ATT&CK資料庫內顯示WR740N的router不管是version 1或version 2的韌體都存在CVE-2023-33538的漏洞，其CVSS風險等級直達8.8高危害，容易就可以command injection進去，但目前各家廠商也無法斷言說攻擊者在2024年七月是利用這個漏洞達成FrostyGoop攻擊的。
流量分析
但畢竟task_test.json這支檔案的IoC在2023年就出現了，我想是值得持續關注的，所以嘗試分析FrostyGoop的流量，可以挑兩組樣本出來搭配task_test.json當作config檔進行流量測試，目前在VirusTotal可以挑選兩像是
- 5d2e4fd08f81e3b2eb2f3eaae16eb32ae02e760afc36fa17f4649322f6da53fb
- a63ba88ad869085f1625729708ba65e87f5b37d7be9153b3db1a1b0e3fed309c
不過要注意的是task_test.json檔案只有執行code 3的Modbus操作，在Modbus指令中會去讀目前register內的值，所以在FrostyGoop會用到這個設定檔的功能只是為了拿來跟目標機器的TCP port 502溝通拿目前register裡的值是多少，圖十九就顯示報告內利用FrostyGoop樣本跟指定的機器透過Modbus溝通取得的一些register值有53370, 53882, 53760, 54272
而圖二十可以顯示如果攻擊者利用Modbus的code 3撈到特定ENCO設備上的register值，例如攻擊者如果對於Modbus協定熟悉的話可以從53760的位址計算到下一個123區間register位址，讓設備回傳53760-53882位址的值回來，通常內容會是UINT16格式的unsigned integers值，這樣駭客就能夠知道目前這個裝置內正常的值會落在多少，以及如果要讓工控系統報錯應該要測試多少值寫回去
除了code 3的操作之外，透過逆向工程的工具可以看到FrostyGoop裡會有一個叫做taskWorker的function會去選擇要做什麼操作，目前已知的有
- read holding registers (3)
- write (6)
- writeMultiple (6)
這部分還能夠跟JSON config檔案進行合作，如果還包含字數1就代表要讀1組register回來，如果不特別設定1就回傳超過一組回來，圖二十一就利用反編譯工具去看FrostyGoop有選擇的功能
總結
近年針對工業控制系統以及OT設備(e.g. 電廠、石油廠、天然氣工廠等)的關鍵基礎設施網路攻擊事件有持續的上升，要辨識這類情境的網路安全邊界及應對方法越來越繁雜危險，畢竟在OT的環境當中其實包含了IT設備、OT元件、各環節互相溝通的協定通道、控制這些物件的中央控制系統等都存在著資安風險，尤其世界各地越來越多戰爭，諸如烏克蘭、羅馬尼亞、以色列、中國、俄羅斯以及美國等時常在新聞上就會看到相關的事件新聞正在發生當中，畢竟建立這些關鍵基礎建設已經是十或二十年前的事情當時應該還沒有考量到連硬體設備都會常常被打。
過去十年malware演進越來越強，目前還正在經歷著數位轉型的時代，許多工控軟硬體配置都還沒有考量到非常完整的SecDevOps，所以不管從底層kernel到上層關鍵基礎建設必定存在著許多的漏洞，以FrostyGoop為例就屬於近期非常著名的例子，即便目前有許多利用ML/DL/RL的方法要找出malware，隨著不斷的攻防演練讓malware躲避的技術越來越好，而model沒看過的奇妙方法勢必抓不到，還是得靠人力下來逆向調查，而同時間聯網的OT裝置跟IoT設備也持續不斷地連上網路。
目前最直觀的想法是把這些急劇增加的OT設備連上IT網路進行管理視作一套方法，然而這也有可能是替攻擊者開通另一條網路攻擊的方向，畢竟目前還是倚賴早期制定出來的工控系統溝通協定，OT設備的影響不只從ICS那邊顯示還連帶影響到現實世界，何況敵對國家底下的惡意組織針對特定的系統會很熟悉其內部的指令及操作，所以在鑑識時其實不是那麼容易可以區分出是自己的員工在進行系統調整還是外部攻擊者在進行測試。
目前針對這類的安全措施以及修補可能包括像是：
- 啟動即時監控：啟用入侵偵測系統（IDS）和流量分析工具，偵測是否有異常的 Modbus 流量或任何與 FrostyGoop 相關的可疑行為
- 檢查Endpoint Device活動：檢查各類 ICS/OT 裝置，特別是與 FrostyGoop 類似的malware樣本，是否已在endpoint運行。這包括辨識可疑的command操作（如Modbus 讀取寫入）或未經授權的remote login
- 啟用惡意檔案監控：使用 Advanced WildFire 或其他惡意檔案檢測系統來識別是否有 FrostyGoop 或其變種的檔案正在被執行
- 切斷網路連接：立即斷開受影響的設備與其他 ICS/OT 網絡的連接，以防止攻擊的擴散，並避免攻擊者對其他關鍵設備發起進一步的控制
- 隔離受感染設備：將所有可疑的受感染設備隔離，尤其是那些可能被用來發送控制命令的設備（如工作站或現場設備）
- 阻止指令擴散：對 Modbus 等協定進行封鎖或篩選，禁止異常或不明的寫入操作，特別是對關鍵註冊的寫入
- 啟動應急響應計劃：根據預設的應急計劃啟動反應流程，對受影響的系統進行初步檢查，並將安全事件上報給相關的指揮中心
- 清除受感染裝置：進行全面掃描，清除所有 FrostyGoop 相關的惡意程式，並確認所有關鍵設備的韌體和軟體版本是最新的，避免已知的漏洞被攻擊者利用
- 恢復與重建：對受影響的系統進行重建和修復，並透過可靠的備份系統恢復重要的業務操作，確保系統的持續運行
要做到這些除了一些基本的表單可以制定出來檢查，可能還是得持續開發ML/DL/RL工具，找出更好的檢測方法及規則來彌補人力無法顧及的部分，以及Next-Generation防火牆可以制定自定義的規則以及IDS/IPS功能都是對於有經驗的藍隊員工能夠一起搭配的工具。
Indicators of Compromise
如果在EDR/XDR當中發現了一些hash IoC的話可能是跟FrostyGoop有關聯如下
- 5d2e4fd08f81e3b2eb2f3eaae16eb32ae02e760afc36fa17f4649322f6da53fb
- a63ba88ad869085f1625729708ba65e87f5b37d7be9153b3db1a1b0e3fed309c
- 2fd9cb69ef30c0d00a61851b2d96350a9be68c7f1f25a31f896082cfbf39559a
- c64b67c116044708e282d0d1a8caea2360270a7fc679befa5e28d1ca15f6714c
- 91062ed8cc5d92a3235936fb93c1e9181b901ce6fb9d4100cc01167cdc08745f
- a25f91b6133cb4eb3ecb3e0598bbab16b80baa40059e623e387a6b1082d6f575
- 9cf30d82a86a9485f7bbd0786a5de207cf4902691a3efcfc966248cb1e87d5b7
- 06919e6651820eb7f783cea8f5bc78184f3d437bc9c6cde9bfbe1e38e5c73160
這部分就得靠是否有注意到，如果有看到奇怪的網路行為可以將EDR/XDR上的hash value丟上VirusTotal看是不是有問題。
References
[1] DRAGOS, “Impact of FrostyGoop ICS Malware on Connected OT Systems,” 2024. https://hub.dragos.com/report/frostygoop-ics-malware-impacting-operational-technology
[2] UNIT42, “FrostyGoop’s Zoom-In: A Closer Look into the Malware Artifacts, Behaviors and Network Communications,” November, 2024. https://unit42.paloaltonetworks.com/frostygoop-malware-analysis/
[3] Mandiant Advantage, “BUSTLEBERM: OT-Tailored Malware Utility Possibly Used to Disrupt Building Automation Devices in Ukraine,” July, 2024.
[4] United Arab Emirates Cyber Security Council, “FrostyGoop/BUSTLEBERM OT-Centric Malware Threat,” November, 2024.
[5] Nozomi Networks Labs, “Cyberwarfare Targeting OT: Protecting Against FrostyGoop/BUSTLEBERM Malware,” July, 2024. https://www.nozominetworks.com/blog/protecting-against-frostygoop-bustleberm-malware
