自定義 NGLite
NGLite 是一個用 Go 語言（特別是 Go 1.13 版）編寫的開源后門。它可以從公共 GitHub 存儲庫下載。NGLite 是一種后門木馬，只能運(yùn)行通過其 C2 通道接收到的命令。雖然這些函數(shù)是后門的標(biāo)準(zhǔn)函數(shù)，但 NGLite 使用一種新穎的 C2 通道，該通道利用基于合法 NKN 的去中心化網(wǎng)絡(luò)在后門和攻擊者之間進(jìn)行通信。
NKN聲稱，他們的去中心化網(wǎng)絡(luò)使用一個公共區(qū)塊鏈，可以支持?jǐn)?shù)百萬個對等點(diǎn)之間的通信，每個對等點(diǎn)都由一個唯一的NKN地址標(biāo)識，而不是典型的網(wǎng)絡(luò)標(biāo)識符，如IP地址。因此，NGLite工具在其C2通道中通信的直接IP地址只是分散網(wǎng)絡(luò)中的一個點(diǎn)，不太可能代表攻擊者的網(wǎng)絡(luò)位置，這種設(shè)計給NGLite C2通信信道的檢測和防御帶來了困難。
幸運(yùn)的是，將 NKN 用作 C2 通道的情況非常罕見。研究人員總共只看到 13 個示例與 NKN 通信，其中9 個 NGLite 示例和 4 個與名為 Surge 的開源實用程序相關(guān)，該實用程序使用 NKN 進(jìn)行文件共享。VirusTotal 掃描了九個已知 NGLite 示例中的八個。四個未被檢測到，三個被一種防病毒軟件檢測到，其余的示例被五個檢測到。如上一節(jié)所述，dropper 創(chuàng)建注冊表項并執(zhí)行保存在以下路徑中的NGLite后門的自定義變體（SHA256: 805b92787ca7833eef5e61e2df1310e4b6544955e812e60b5f834f904623fd9f）：
C:\Windows\system32\ME_ADAudit.exe
基于 Go 的后門中的數(shù)據(jù)結(jié)構(gòu)包含以下路徑，用于在開發(fā)人員系統(tǒng)上存儲此自定義 NGLite 變體的主要源代碼：
/mnt/hgfs/CrossC2-2.2/src/ng.com/lprey/main.go
基于此路徑，可以推測該攻擊者使用 CrossC2 構(gòu)建跨平臺 Cobalt Strike C2 有效載荷。然而，研究人員沒有理由相信這個有效載荷實際上是基于 CrossC2 的，因為有效載荷是公開可用的 NGLite 后門的定制版本。
攻擊者可能將 CrossC2 字符串包含在路徑中作為誤導(dǎo)，希望使攻擊分析人員誤以為他們正在提供 Cobalt Strike 有效載荷。研究人員已經(jīng)看到以下 NGLite 示例使用可追溯到 8 月 11 日的相同源代碼路徑，這表明該攻擊者已經(jīng)使用該工具好幾個月了：
此活動中使用的自定義 NGLite 示例檢查 g 或組值的命令行參數(shù)。如果此開關(guān)不存在，則載荷將使用默認(rèn)字符串 7aa7ad1bfa9da581a7a04489896279517eef9357b81e406e3aee1a66101fe824 作為其種子標(biāo)識符。
有效載荷將創(chuàng)建它所指的攻擊對象id，它是通過將系統(tǒng)網(wǎng)絡(luò)接口卡 （NIC） 的 MAC 地址和 IPv4 地址連接起來生成的，用連字符 （-） 將兩者分開。這個攻擊對象標(biāo)識符將用于 C2 通信。
NGLite 有效載荷將使用 NKN 去中心化網(wǎng)絡(luò)進(jìn)行 C2 通信。詳見下面示例中的NKN客戶端配置：
嵌入式 NKN 客戶端配置
該示例首先通過 TCP/30003 訪問 seed.nkn[.]org，特別是使用 HTTP POST 請求，結(jié)構(gòu)如下：
原始NKN HTTP POST
它還將發(fā)送以 monitor_03 作為攻擊對象 id 的 HTTP POST 請求，如下所示：
包含“prey id”的 HTTP Post
seed.nkn[.]org 服務(wù)器使用結(jié)構(gòu)如下的 JSON 中的 [prey id （MAC-IPv4）] 響應(yīng)此請求：
這表明有效載荷將通過 TCP/30003 與 66.115.12.89 處的對等端通信。然后，seed.nkn[.]org 服務(wù)器使用以下內(nèi)容響應(yīng) monitor_03 請求，這表明有效載荷將通過 TCP/30003 與 54.204.73.156 通信：
從seed.nkn[.]org 獲得響應(yīng)后，有效載荷將向JSON 中addr 字段中提供的IP 地址和TCP 端口發(fā)出HTTP GET 請求。這些HTTP請求如下所示，但需要注意，這些系統(tǒng)不是由攻擊者控制的；相反，它們只是最終會返回actor內(nèi)容的對等鏈中的第一個對等：
NKN 對等互連
最終，自定義 NGLite 客戶端和服務(wù)器之間的網(wǎng)絡(luò)通信使用具有以下密鑰的 AES 進(jìn)行加密：
WHATswrongwithUu
自定義 NGLite 示例將首先向 C2 發(fā)送一個初始信標(biāo)，該信標(biāo)包含 whoami 命令的結(jié)果并連接字符串 #windows，如下所示：
[username]#windows
發(fā)送初始信標(biāo)后，NGLite 示例將運(yùn)行一個名為 Preylistener 的子函數(shù)，該函數(shù)創(chuàng)建一個偵聽入站請求的服務(wù)器。該示例還將偵聽入站通信，并嘗試使用默認(rèn)的 AES 密鑰 1234567890987654 對其進(jìn)行解密。它將通過 Go 方法 os/exec.Command 將解密的內(nèi)容作為命令運(yùn)行，然后使用相同的 AES 密鑰對結(jié)果進(jìn)行加密并發(fā)送回請求者。
后漏洞利用階段活動
攻擊網(wǎng)絡(luò)得手后，攻擊者迅速從最初的立足點(diǎn)轉(zhuǎn)移到目標(biāo)網(wǎng)絡(luò)上的其他系統(tǒng)，通過其 NGLite 載荷和 Godzilla webshell 運(yùn)行命令。在獲得對初始服務(wù)器的訪問權(quán)限后，攻擊者將會集中精力從本地域控制器收集和竊取敏感信息，例如 Active Directory 數(shù)據(jù)庫文件 （ntds.dit） 和注冊表中的 SYSTEM 配置單元。不久之后，研究人員觀察到攻擊者安裝了 KdcSponge 憑證竊取程序，我們將在下面詳細(xì)討論這個問題。接下來，攻擊者將會竊取憑據(jù)、維護(hù)訪問權(quán)限以及從受害者網(wǎng)絡(luò)收集敏感文件。
KdcSponge憑證竊取程序
在分析過程中，Unit 42 發(fā)現(xiàn)的日志表明攻擊者使用 PwDump 和內(nèi)置的comsvcs.dl來創(chuàng)建了一個迷你的lasss .exe進(jìn)程轉(zhuǎn)儲文件；然而，當(dāng)攻擊者希望從域控制器竊取憑據(jù)時，他們就會安裝KdcSponge憑證竊取程序。
KdcSponge 的目的是在LSASS進(jìn)程中掛鉤API函數(shù)，以便從通過Kerberos服務(wù)（“KDC服務(wù)”）進(jìn)行身份驗證的入站嘗試中竊取憑證。KdcSponge將捕獲系統(tǒng)上的一個文件的域名、用戶名和密碼，然后攻擊者將通過現(xiàn)有的服務(wù)器訪問權(quán)限手動竊取該文件。
研究人員總共發(fā)現(xiàn)了兩個 KdcSponge 示例，并將它們被命名為 user64.dll。他們有以下 SHA256 哈希值：
3c90df0e02cc9b1cf1a86f9d7e6f777366c5748bd3cf4070b49460b48
b4d4090b4162f039172dcb85ca4b85c99dd77beb70743ffd2e6f9e0ba78531945577665
為了啟動 KdcSponge 憑據(jù)竊取程序，攻擊者將運(yùn)行以下命令來加載和執(zhí)行惡意模塊：
regsvr32 /s user64.dll
首次執(zhí)行時，regsvr32 應(yīng)用程序運(yùn)行 user64.dll 導(dǎo)出的 DllRegisterServer 函數(shù)。DllRegisterServer 函數(shù)解析 sfc_os.dll 中的 SetSfcFileException 函數(shù)，并嘗試禁用 c:\windows\system32\kdcsvc.dll 文件上的 Windows 文件保護(hù) （WFP）。然后它嘗試通過以下方式將自己注入正在運(yùn)行的 lsass.exe 進(jìn)程：
使用 OpenProcess 打開 lsass.exe 進(jìn)程；
使用VirtualAllocEx分配遠(yuǎn)程進(jìn)程中的內(nèi)存；
使用WriteProcessMemory將字符串user64.dll寫入分配的內(nèi)存；
以user64.dll 為參數(shù)，使用RtlCreateUserThread 在lsass.exe 進(jìn)程中調(diào)用LoadLibraryA；
現(xiàn)在user64.dll正在lsass.exe進(jìn)程中運(yùn)行，它將通過創(chuàng)建以下注冊表項來通過系統(tǒng)重啟建立持久性：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\KDC Service : regsvr32 /s user64.dll
這樣，示例將通過嘗試獲取以下模塊之一的句柄來檢查以確保系統(tǒng)正在運(yùn)行 Kerberos 服務(wù)：
kdcsvc.dll
kdccli.dll
Kdcsvs.dll
KdcSponge 嘗試使用以下三種方法定位三個未記錄的 API 函數(shù)，特別是 KdcVerifyEncryptedTimeStamp、KerbHashPasswordEx3 和 KerbFreeKey：
標(biāo)識Kerberos模塊的版本，并使用硬編碼偏移量掛鉤API函數(shù)；
聯(lián)系 Microsoft 的符號服務(wù)器以查找 Kerberos 模塊內(nèi) API 函數(shù)的偏移量，并通過與硬編碼字節(jié)序列進(jìn)行比較來確認(rèn)正確的函數(shù)；
在 Kerberos 模塊中搜索硬編碼字節(jié)序列；
KdcSponge 定位要掛鉤的 API 函數(shù)的主要方法是基于可移植可執(zhí)行 （PE） 文件的 IMAGE_FILE_HEADER 部分中的 TimeDateStamp 值來確定 Kerberos 模塊的版本。一旦確定了 Kerberos 模塊的版本，KdcSponge 就會有硬編碼的偏移量，它將用于掛鉤該模塊版本中的適當(dāng)函數(shù)。KdcSponge 查找以下 TimeDateStamp 值：
如果 KdcSponge 無法確定 Kerberos 模塊的版本并且域控制器正在運(yùn)行 Windows Server 2016 或 Server 2019（主要版本 10），則有效載荷將聯(lián)系 Microsoft 的符號服務(wù)器 （msdl.microsoft.com） 以嘗試找到幾個未記錄的 API 函數(shù)的位置。該示例將向如下結(jié)構(gòu)的 URL 發(fā)出 HTTPS GET 請求，URL 的 GUID 部分是 PE 的 IMAGE_DEBUG_TYPE_CODEVIEW 部分中 RSDS 結(jié)構(gòu)的 GUID 值：
/download/symbols/[library
name].pdb/[GUID]/[library name].pdb
該示例將結(jié)果保存到以下位置的文件中，文件名的 GUID 也是來自 IMAGE_DEBUG_TYPE_CODEVIEW 部分中 RSDS 結(jié)構(gòu)的 GUID 值：
ALLUSERPROFILE\Microsoft\Windows\Caches\[GUID].db:
如上所述，研究人員認(rèn)為代碼接觸符號服務(wù)器的原因是為了找到三個未記錄的與kerberos相關(guān)的函數(shù)的位置：KdcVerifyEncryptedTimeStamp、KerbHashPasswordEx3和KerbFreeKey。該示例主要在以下庫中查找這些函數(shù)：
kdcsvc.KdcVerifyEncryptedTimeStamp
kdcsvc.KerbHashPasswordEx3
kdcpw.KerbHashPasswordEx3
kdcsvc.KerbFreeKey
kdcpw.KerbFreeKey
如果找到了這些函數(shù)，示例將搜索特定的字節(jié)序列，如表1所示，以確認(rèn)函數(shù)是正確的，并驗證它們沒有被修改。
KdcSponge 用于確認(rèn) Windows 主要版本的正確函數(shù)的未記錄函數(shù)和字節(jié)序列
如果域控制器運(yùn)行的是 Windows Server 2008 或 Server 2012（主要版本 6），KdcSponge 不會訪問符號服務(wù)器，而是會搜索整個kdcsvc.dll模塊，以查找表2中列出的字節(jié)序列，以找到API函數(shù)。
KdcSponge用于定位查找函數(shù)的未記錄函數(shù)和字節(jié)序列
一旦找到 KdcVerifyEncryptedTimeStamp、KerbHashPasswordEx3 和 KerbFreeKey 函數(shù)，示例將嘗試掛鉤這些函數(shù)以監(jiān)視對它們的所有調(diào)用，竊取憑據(jù)。當(dāng)對域控制器進(jìn)行身份驗證的請求傳入時，Kerberos 服務(wù)（KDC 服務(wù)）中的這些函數(shù)將被調(diào)用，并且示例將捕獲入站憑據(jù)。然后將憑據(jù)寫入磁盤的以下位置：
%ALLUSERPROFILE%\Microsoft\Windows\Caches\system.dat
被竊取的憑據(jù)使用一個單字節(jié)的XOR算法進(jìn)行加密，使用0x55作為密鑰，并以如下結(jié)構(gòu)每一行寫入system.dat文件：
[< timestamp >]< domain >< username > < cleartext password >
總結(jié)
雖然研究人員無法驗證活動背后的攻擊組織是誰，但確實觀察到攻擊中使用的策略和工具與 Threat Group 3390（TG-3390，Emissary Panda，APT27）之間存在一些相關(guān)性。
正如 SecureWorks 在一篇關(guān)于之前 TG-3390 操作的文章中所記錄的那樣，研究人員可以看到 TG-3390 也使用了 Web 漏洞利用和另一個名為 ChinaChopper 的流行中文 webshell 作為其初始立足點(diǎn)，然后利用合法竊取的憑據(jù)進(jìn)行橫向移動和攻擊域控制器。雖然 webshell 和漏洞利用不同，但一旦攻擊者獲得了對環(huán)境的訪問權(quán)限，他們的一些信息竊取工具就會存在功能重疊。
研究人員發(fā)現(xiàn)，攻擊者使用 WinRar 偽裝作為不同的應(yīng)用程序，將數(shù)據(jù)分割到Recycler目錄中的RAR文件中。他們從部署的批處理文件中提供了以下片段來完成這項工作：
根據(jù)研究人員對 ManageEngine ADSelfService Plus 最近攻擊的分析，它們觀察到了相同的技術(shù)，傳遞給重命名的 WinRar 應(yīng)用程序的參數(shù)的順序和位置相同。
一旦文件被分割，在上述兩個示例中，它們都可以在面向外部的 Web 服務(wù)器上訪問。然后攻擊者將通過直接 HTTP GET 請求下載它們。
2021 年 9 月，在Unit 42 觀察到的一次攻擊活動中，攻擊者通過利用 Zoho 的 ManageEngine 產(chǎn)品 ADSelfService Plus 中最近修復(fù)的漏洞獲得了對目標(biāo)組織的初始訪問權(quán)限，該漏洞在 CVE-2021-40539 中進(jìn)行了跟蹤。在這次攻擊行動中，至少有9家科技、國防、醫(yī)療、能源和教育行業(yè)的實體都受到了攻擊。
漏洞被利用之后，攻擊者迅速在網(wǎng)絡(luò)中橫向移動，并部署了多種工具來運(yùn)行命令，以執(zhí)行其利用后的活動。攻擊者嚴(yán)重依賴Godzilla webshell，在操作過程中將開源 webshell 的幾個變體上傳到被攻擊的服務(wù)器。其他一些工具具有新穎的特征，或者在之前的攻擊中沒有被公開討論過，特別是 NGLite 后門和 KdcSponge 竊取程序。例如，NGLite 后門使用一種新穎的 C2 通道，涉及稱為 NKN 的去中心化網(wǎng)絡(luò)，而KdcSponge竊取器將未記錄的函數(shù)掛接到域控制器，從入站Kerberos身份驗證嘗試獲取憑證。
Unit 42 研究人員認(rèn)為，攻擊者的主要目標(biāo)是獲得對網(wǎng)絡(luò)的持續(xù)訪問權(quán)限并從被攻擊目標(biāo)中收集和竊取敏感文件。攻擊者將敏感文件收集到暫存目錄，并在 Recycler 文件夾中創(chuàng)建受密碼保護(hù)的多卷 RAR 文件。攻擊者通過直接從面向外部的 Web 服務(wù)器下載單個 RAR 文件來竊取文件。
