針對SolarWinds供應鏈攻擊簡介
最近FireEye披露的UNC2452駭客組織入侵SolarWinds的供應鏈攻擊讓安全從業人員印象深刻。一是影響規模大，SolarWinds官方稱受影響的客戶數量可能有18000家。二是攻擊者留下的後門程式-SUNBURST，十分隱蔽和具有迷惑性，分析認為攻擊者對SolarWinds Orion產品理解程度很深。
有證據表明，早在2019年10月，UNC2452駭客組織就一直在研究透過新增空類來插入程式碼的能力。因此將惡意程式碼插入原始SolarWinds.Orion.Core.BusinessLayer.dll的時間可能很早，甚至可能是在軟體構建編譯之前。這就導致SolarWinds官方無意間對包含4000行惡意程式碼的DLL進行了數字簽名，這樣容易讓惡意程式碼提升許可權，並且很難被人發現。感染的Origin軟體第一個版本是2019.4.5200.9083，在此幾個月的時間內，使用者透過下載受到感染的產品版本被感染。目前原始dll檔案中沒有發現存在動態拓展、也不存在橫向移動等後滲透階段的相關能力支援。
Sunburst後門總體流程總體流程圖：
Sunburst後門總體流程可以簡單地概括為以下幾個階段：
(1)SolarWinds.BusinessLayerHost.exe載入SolarWinds.Orion.Core.BusinessLayer.dll，並執行其中的惡意程式碼。
(2)程式碼透過9層環境檢查，來判斷當前環境上下文是否安全，是否應該繼續執行。
(3)如果檢查透過，嘗試使用DGA演算法生成的域名傳送DNS上線通知，並檢查DNS解析結果是否滿足自身執行要求。
(4)DNS上線通知成功，則會嘗試使用兩種User-Agent和3種代理模式，與C2伺服器建立起HTTP控制通道。
(5)SUNBURST後門本身能處理的控制指令並不多，攻擊者可以下載自定義的Payload，例如Cobalt Strike beacon，即TEARDROP進行進一步操作。
Sunburst後門的程式碼都在SolarWinds.Orion.Core.BusinessLayer.dll這個檔案中，這是個C#編寫的.NET assembly，可以直接反編譯檢視原始碼，分析其執行邏輯。主要涉及的三項技術為程式碼執行（Execution）、環境檢測（Discovery）和C2通訊（Command and Control）。
TTPs提取與分析1 程式碼執行/Execution1.1 紅隊視角
無論是紅隊後滲透還是真實APT攻擊，第一步要在受害者的機器上執行起來控制程式（agent/implant/artifact）。Windows系統上的程式碼執行的方法有很多，也可以從多種角度進行分類和總結。這裡作者將之分為以下三類：
(1)BYOB: Bring Your Own Binary，就是把後門、工具、武器編譯成exe檔案，上傳到目標主機上並執行。這也是最直接的執行方式。缺點是需要不斷的編譯和上傳、要處理殺軟和EDR的靜態檢測等等。
(2)LotL: Living off the Land，可以理解為就地取材，利用Windows系統和應用程式來載入執行惡意程式碼，典型的案例就是利用powershell的攻擊。這種方式利用白名單程式來載入，會有一定規避檢查的優點，但會產生明顯的父子程序關係和程序引數，容易被獵捕。
(3)BYOL: Bring Your Own Land，這也是FireEye提出的一種方法，在使用前兩種方法建立了基本的程式碼執行能力後，在記憶體中載入並執行Windows的PE檔案、.NET assembly檔案。優點是跳過了靜態檔案查殺，不會明顯產生程序間呼叫關係和程序呼叫引數，缺點是需要自己開發記憶體載入執行的程式碼，很多常規的命令需要自己重新實現。
1.2 Surburst實際攻擊技巧
本次供應鏈攻擊的Sunburst後門存在於SolarWinds.Orion.Core.BusinessLayer.dll檔案中，它的執行需要SolarWinds.BusinessLayerHost.exe這個合法的程序來載入，可以理解為是一種變形的Living off the Land執行方法。類似於DLL劫持，但相比於常規的DLL劫持，這類修改原始DLL的供應鏈攻擊後門顯得更加隱蔽。往往有以下特點：
(1)修改原有的DLL，不會產生多餘的DLL檔案落地
(2)程式載入DLL執行，不會產生子程序和程序引數
(3)供應商的信任程序不在常規程序檢測名單，已知Windows lolbins檢測規則無效
本次的DLL後門，可以看到作者很注重隱蔽(OpSec)，程式碼中透露著檢測對抗的思想，其隱蔽技巧表現為：
(1)DLL合法的數字簽名，很大程度上規避了靜態檔案查殺:
(2)程式碼透過建立新執行緒,執行SolarWinds.Orion.Core.BusinessLayer.dll.OrionImprovementBusinessLayer庫目錄下的Initialize函式開始惡意動作。DLL入口函式呼叫棧較深，透過6層的呼叫才開始執行程式碼，動態跟蹤需要花費更多精力:
(3)程式碼使用自定義hash演算法，常量字串都進行hash處理，避免敏感字串在傳輸流量和本地檔案掃描時發現。實際使用的地方有9處，下圖是程序名檢測部分:
2 環境檢測/Discovery2.1 紅隊視角
紅隊技術傳統技術往往高度關注程序列表檢測、驅動列表檢測的技巧：
2.1.1 程序檢測
對於殺軟和安全軟體的檢測，我們通常使用taskllist /v和tasklist /svc來檢查程序和服務，可以認為這是一種手工判斷+LotL的方法。這裡推薦兩款自動化的檢測指令碼和工具，大家可以根據自己的需求進行改造，結合記憶體載入實現BYOL的方式來檢查安全軟體。
(1)ProcessColor.cna，一款Cobalt Strike的外掛指令碼，可以幫助我們標記出常見的安全軟體、監控軟體、分析軟體。
(2)Seatbelt的InterestingProcesses命令，C#開發的多功能資訊蒐集工具，可單獨使用，可結合其他程式實現記憶體載入。
2.1.2 驅動檢測
既然程序和服務都檢測了，那麼檢測這些驅動有什麼意義嗎？
在常規的情況下，檢查程序和服務名稱就可以瞭解當前系統的安全軟體執行情況，但是一些高階系統管理員會修改程序和服務的名稱，我們就沒辦法判斷了。Sunburst後門在環境檢測中還檢查了系統驅動，這些驅動大部分都是殺軟和EDR產品使用的。這一點是值得紅隊人員借鑑的，下面以sysmon為例進行說明。
圖中左側為常規的sysmon安裝，我們可以在程序和服務中找到sysmon。右側只是簡單地把sysmon進行重新命名，安裝之後我們在程序和服務的名字中已經找不到sysmon了，只能找到修改後的名稱。這個時候檢視驅動就很必要了，因為sysmon預設安裝的驅動路徑和名字並沒有改變，如下圖：
即使管理員在安裝sysmon的時候將預設的驅動名稱也改了，但是每個驅動都有一個唯一的altitude，要修i改這個成本就很高了。sysmon的altitude是385201，如下圖，可以對比上圖，這個是不變的：
2.2 Sunburst實現的機制
SolarWinds.Orion.Core.BusinessLayer.dll中的惡意程式碼對於執行環境的檢查十分嚴格，一共有9層檢測機制，只有當所有檢測條件都透過時，其才會執行上線操作。
序號
檢測機制
1
透過雜湊判斷當前載入惡意DLL的程序名字是solarwinds.businesslayerhost.exe
2
惡意DLL的最後寫入時間比當前時間至少提前12到14天，說明其會潛伏半個月左右才會執行
3
檢查硬編碼的命名管道583da945-62af-10e8-4902-a8f205c72b2e，避免多程序重複執行
4
檢查惡意複用的配置選項ReportWatcherRetry，ReportStatus項不能為3，即Truncate退出狀態
5
檢查當前裝置所在域，域名中不能包含雜湊值校驗的黑名單patternHashes中的一些字串；域名不能匹配到正則表示式“(?i)([^a-z]|^)(test)([^a-z]|$)”，該表達示主要用來檢查當前域名是不是測試用的域名；"(?i)(solarwinds)"，猜測該表示式主要用來檢測是否處於sloarwinds公司辦公環境
6
檢查第一個非迴環啟用網絡卡，不在IP黑名單中
7
檢測程序Hash黑名單(含137個程序)，確保當前環境中沒有安全相關軟體和服務程式，如：Windbg、 Autoruns、 Wireshark，並嘗試關閉服務名單中的服務
8
檢查當前環境中是否存在13個安全軟體的驅動程式，如：groundling32.sys
9
主機解析“api.solarwinds.com”為指令的IP地址
3 C2通訊/Command and Control程式碼執行起來，檢測環境上下文是安全的，最後的一步就是和C2伺服器進行通訊了。Sunburst後門透過自定義的DGA演算法生成C2域名，透過自定義DNS通道進行上線通知，透過自定義HTTP通道進行指令下發與資料回傳。
3.1 紅隊視角
對於紅隊來說，最常規的出網協議是HTTP[S]和DNS協議，但是大多數情況是手動判斷目標的網路環境後來選擇C2通訊的方式。雖然能夠修改和自定義C2通訊協議，無疑是規避流量檢測的好方法，但是相對的成本會比較高，需要同時兼顧客戶端和服務端，還需要保證通訊質量。簡易的做法是利用後滲透框架自身的配置來修改C2流量特徵，比如Cobalt Strike、Empire、Covenant等工具都支援Malleable C2 profile的配置。
Sunburst後門這種使用DNS和HTTP協議結合的方式，讓作者想起了Sliver C2這款工具的DNS Canary功能。雖然DNS Canary不是用來進行C2通訊的，但是提供了一種紅隊監測藍隊是否分析了自己implant的思路。
Sliver C2生成的implant預設會使用符號混淆來避免殺軟查殺，不會出現敏感字串。但是當使用--canary/-c引數時，會將指定的DNS域名以常量字串的形式嵌入implant中。並生成一個獨一無二的DNS域名，如果藍隊人員分析我們的implant，發現這個域名，只要逆行了DNS解析，我們的C2伺服器就會收到DNS查詢請求，這說明我們的行動已經被發現。
如下圖，紅隊人員在建立implant的時候，設定DNS canary為mews.cs.local，在生成的implant中，嵌入了mqrrzkj.news.cs.local.和kvn3g0-.news.cs.local兩個域名。
當藍隊分析樣本，嘗試解析域名時，C2伺服器就會收到告警。
告警資訊如下：
3.2 Sunburst後門在該階段的亮點
(1)很具有迷惑性的DnsRecords程式碼，用常規的變數名錶達其他實際意義。
(2)對DGA生成的域名解析的IP地址，進行白名單、黑名單、等待名單的判斷，確定網路解析環境是否安全才會繼續執行。
(3)HTTP協議的一種User-Agent會採用SolarWinds產品的User-Agent，更加接近真實可信的流量。
(4)出網會檢測代理設定，透過無代理、系統代理和SolarWinds本身配置的代理三種方式是嘗試出網，連線C2伺服器。
(5)高度迷惑性的C2伺服器響應。
(6)高度迷惑性的DGA演算法。
上述動作的具體表現為：
(1)具有高度迷惑性的DNS上線請求：惡意程式碼傳送DNS請求並將返回的CNAME資訊將儲存至DnsRecords物件。
DNS查詢如果請求失敗，則設定隨機7-9小時的休眠時間（程式碼如下圖），進行休眠後再進行下一次嘗試。
如請求成功，則首先判斷是否存在CNAME資訊，如不存在，則處理IP的最後兩個位元組，修改DnsRecords物件對應的欄位：
length欄位，此欄位用於儲存控制階段應用的代理型別；
_type欄位，此欄位決定控制階段使用的url以及對返回資料的解碼方式；
A欄位，此欄位決定DNS請求查詢階段每次DNS請求之間的延時。
(2)對DGA生成的域名解析的IP地址，進行白名單、黑名單、等待名單的判斷：檢測到IP處於任一黑名單，將導致狀態更改為Truncate，從而導致後續操作全部終止，並作標記此後不再嘗試。IP黑名單列表：
IP地址
子網掩碼
AddressFamilyEx型別
10.0.0.0
255.0.0.0
Atm內網IP黑名單
172.16.0.0
255.240.0.0
Atm內網IP黑名單
192.168.0.0
255.255.0.0
Atm內網IP黑名單
224.0.0.0
240.0.0.0
Atm內網IP黑名單
fc00::
fe00::
Atm內網IP黑名單
fec0::
ffc0::
Atm內網IP黑名單
ff00::
ff00::
Atm內網IP黑名單
41.84.159.0
255.255.255.0
Ipx外網黑名單
74.114.24.0
255.255.248.0
Ipx外網黑名
154.118.140.0
255.255.255.0
Ipx外網黑名單
217.163.7.0
255.255.255.0
Ipx外網黑名單
20.140.0.0
255.254.0.0
ImpLink等待名單
96.31.172.0
255.255.255.0
ImpLink等待名單
131.228.12.0
255.255.252.0
ImpLink等待名單
144.86.226.0
255.255.255.0
ImpLink等待名
8.18.144.0
255.255.254.0
NetBios白名單
18.130.0.0
255.255.0.0
NetBios白名單
71.152.53.0
255.255.255.0
NetBios白名單
99.79.0.0
255.255.0.0
NetBios白名單
87.238.80.0
255.255.248.0
NetBios白名單
199.201.117.0
255.255.255.0
NetBios白名單
184.72.0.0
255.254.0.0
NetBios白名單
上述表格中Atm代表內網IP黑名單，ImpLink代表外網IP黑名單，Ipx代表等待名單，NetBios代表白名單。如果返回的IP處於任一黑名單，則惡意程式碼退出並且設定標記永不再上線。
在進行程序、服務、驅動狀態檢查通過後，然後還會解析官方域名“api.solarwinds.com”判斷是否為指定IP地址，如檢驗透過則進入後續的感染邏輯，整個邏輯可以用下圖表示：
(3)高度迷惑性的User-Agent：當惡意程式碼從C2域名的CNAME DNS響應中成功檢索到域，將產生一個新的執行執行緒，呼叫HttpHelper.Initialize方法來與C2伺服器通訊。
HttpHelper的建構函式會處理由DNS請求查詢階段決定的請求型別與代理型別，兩種User-Agent，在正常情況下，第一種會用於Windows檢查證書吊銷列表。
第二種用於SolarWinds本身的通訊過程，將偽裝為SolarWinds正常請求連結或靜態資源。
(4)高度迷惑性的代理配置：出網代理主要分為三類，無代理、系統代理和紅色箭頭標明的SolarWinds本身配置的代理，從這點也可以看出駭客組織對於SolarWins的瞭解的確十分深入。
最後組成了一個JSON文字，在其中添加了前面描述的userID，sessionID和一組其他不相關的資料欄位。然後它將此JSON文件傳送到C2伺服器。
(5)高度迷惑性的C2伺服器響應：如果C2通訊成功，C2伺服器將回復編碼壓縮後的資料，該資料中包含後門要執行的命令。C2伺服器可能還會回覆有關要報告的其他C2地址的資訊：
實際的伺服器控制執行程式碼在Job.ExecuteEngine函式中。以下是駭客C2伺服器對遠端受害主機控制命令的型別和功能：
命令
值
詳細描述
空閒
0
無
退出
1
結束當前程序
設定延遲時間
2
設定主事件迴圈執行的延遲時間
收集系統資訊
3
解析本地系統資訊，包括主機名、使用者名稱、作業系統版本、MAC地址、IP地址、DHCP配置和域資訊
上傳系統資訊
4
向指定的URL傳送HTTP請求，並把系統資訊以特殊格式傳送到C2伺服器
啟動新任務
5
根據檔案路徑和引數啟動新程序
列舉程序資訊
6
獲取程序列表，並根據引數決定是否獲取父程序ID、使用者名稱、域名
結束任務
7
根據PID結束指定程序
列舉檔案資訊
8
根據檔案路徑列舉檔案和目錄
寫入檔案
9
根據檔案路徑和Base64編碼字串，將Base64解密字串的內容以追加模式寫入檔案，寫入後延遲1-2秒
判斷檔案是否存在
10
判斷檔案路徑是否存在
11
獲取檔案雜湊
12
獲取檔案的MD5雜湊資訊
讀登錄檔值
13
讀取登錄檔值
設定登錄檔值
14
設定登錄檔值
15
獲取登錄檔子項和值
16
獲取登錄檔路徑下的子項和值名稱的列表
重啟
17
嘗試使系統重啟
(6)高度迷惑性的DGA演算法：
如果樣本透過上述階段，則樣本將在while迴圈中透過DGA演算法開始生成域。樣本會延遲域生成之間的隨機間隔；此時間間隔可以是1到3分鐘，30到120分鐘或在錯誤條件下最長420到540分鐘（9小時）範圍內的任意隨機值。
總共用四種方法來生成url，分別為GetCurrentString，GetPreviousString，GetNextStringEx和GetNextString函式。
下圖是四種方法的呼叫條件，以及會組成的URL的第一段格式如上圖。這裡需要了解一個變數和兩個演算法，才能對DGA的演算法生成過程更加了解。一個變數是GUID,兩個加密演算法即CryptoHelper.Base64Encode和CryptoHelper.Base64Decode。
其中GetCurrentString/GetPreviousString可以認為是第一階段DGA，包含可以完整解析的域名，GetNextStringEx/GetNextString可以認為是第二階段DGA，包含了有效的伺服器時間戳等資訊。
不管哪種生成方式，在OrionImprovementBusinessLayer.GetOrCreateUserID中，HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography的 MachineGuid值和第一個網路介面卡的物理地址MAC組成了UID，並透過計算UID的MD5雜湊，再用ComputeHash類的方法將 MD5 雜湊值作為16位元組的陣列返回，異或之後最終輸出64位雜湊值這樣得到目標GUID。GUID透過CreateSecureString函式進行加密，CreateSecureString函式中使用了CryptoHelper.Base64Encode演算法加密。所以整個加密過程全是CryptoHelper.Base64Encode函式和CryptoHelper.Base64Decode函式實現的，研究的重點就是CryptoHelper.Base64Encode函式和CryptoHelper.Base64Decode函式。然而這兩個函式都並不是名稱表示的常見的Base64編解碼函式。
CryptoHelper.Base64Decode其實是自定義的加密演算法。
CryptoHelper.Base64Encode其實是自定義對映表的Base32演算法。
下圖是GetCurrentString/GetPreviousString函式加密方式中以CryptoHelper.Base64Decode加密域名的方式生成的URL。藍色的表示會隨機變化，黑色表示固定不變。紫色00帶有下劃線代表是此種加密方式的標誌位。
一、前15個位元組是GUID被加密過後的編碼0fn7oe4cegrf933
二、中間一個位元組是透過CreatString生成的“c”
三、後面的mudofi75f4tjvh則是AD域被編碼後的字串。
因為這裡十六個位元組過後有“00”開頭的標誌，所以可以斷定應該呼叫OrionImprovementBusinessLayer.CryptoHelper.Base64Decode對應的解碼演算法。解碼後可以得到域名稱：WASHO。
下圖就是透過GetNextStringEx和GetNextString函式加密的方式生成的URL。對照上圖其實如果沒有“00”標誌，這種URL形式和GetCurrentString/GetPreviousString函式加密方式中以CryptoHelper.Base64Encode加密域名的方式是很像的，所以這種直接使用CryptoHelper.Base64Encode對應的解碼演算法即可，最終得到spsd.sk.ca域名。
安全研究員@bambenek在其Github上公佈了1722個疑似與此次攻擊事件相關的DGA域名:
透過上述DGA域名格式解析，我們僅提取最有價值的以“.”分隔的第一段看起來雜亂無序的編碼嘗試進行逆向解密，如下是解密結果的部分展示，可以發現此次駭客攻擊目標的組織數量巨大，包括多數大型美國政府和企業的常見域名。
因為GUID是透過MD5計算出來的，所以要想還原MAC地址是不可能的，但這並不代表GUID就沒有價值。FireEye在其GitHub上釋出的DNS請求內部包含以下加密的GUID：
我們在解密出的文件中搜索發現同樣的規律：
r1q6arhpujcf6jb6ervisu10odohu0it.appsync-api.us-west-2.avsvmcloud.comdomain name part GUID (0x2956497EB4DD0BF9) offset 0 = central.pima.g0oni12r13ficnkqb2w.appsync-api.us-west-2.avsvmcloud.comdomain name part GUID (0x2956497EB4DD0BF9) offset 35 = ovr8stkst71ebqgj66ervisu10bdohu0gt.appsync-api.us-west-2.avsvmcloud.comdomain name part GUID (0x683D2C991E01711D) offset 0 = central.pima.gulfmcf44qd58t9e82w.appsync-api.us-west-2.avsvmcloud.comdomain name part GUID (0x683D2C991E01711D) offset 35 = ov617stsr6ntep0auho2v60be2h.appsync-api.us-east-2.avsvmcloud.comdomain name part GUID (0x92EB3D64B8A03CB) offset 35 = ions.com由此可見相同GUID可以作為域名長度過長時進行分割的子串，逆向拼接即可形成完整的域名。
總結本文從紅隊的視角分析了Sunburst後門中的TTPs，其後門實現邏輯可以看出攻擊者把安全隱蔽(OpSec)放在了第一位，雖然其中很多技術是惡意軟體本身的技巧，但是涉及的一些思想和TTPs對紅隊建設仍有很大參考價值，也透露出現階段紅隊技巧和第一梯隊APT組織實戰攻擊技巧的差距。紅隊行動首先就要制定策略，是隱蔽優先還是速度優先。但是無論哪種策略，OpSec始終是紅隊人員的必修課。