Winnti組織是如何利用GitHub來進行C&C通信的

寫在前面的話

在發布某個新版本的應用程序或維護代碼項目時，開發人員通常需要不斷地修改或重寫他們的源代碼，而這也許就是 GitHub（在線代碼托管服務，提供了版本控制管理）能夠如此受歡迎的原因了。從某種程度上來說，GitHub 已經成為了程序員的一個特殊的社交平臺了，因為這個平臺提供了代碼管理、代碼共享、協作開發以及代碼整合等對于程序員來說非常有價值的功能，而且不同國家的開發人員都可以在項目評論區中進行問題討論。

不過，GitHub 與惡意軟件之間也有著千絲萬縷的關系。比如說，以普及安全教育為目的的開源惡意軟件項目 EDA2 和 Hidden Tear 就托管在 GitHub 上，但是不法分子卻利用這些惡意軟件的源代碼開發出了相應的變種來攻擊企業用戶。除此之外，也有大量能夠攻擊物聯網（IoT）設備的工具源碼也托管在 GitHub 上，而這些代碼是任何接入了互聯網的用戶都可以獲取到的，甚至連 Limitless Keylogger 這樣針對性極強的攻擊工具源碼我們都可以在 GitHub 上找到。

近期，安全研究人員發現，一個名叫 Winnti 的黑客組織把 GitHub 變成了一個用來跟后門（趨勢科技標識為 BKDR64_WINNTI.ONM）進行C&C遠程通信的工具。在此之前，這個黑客組織進行的都是一些類似金融欺詐等傳統的網絡犯罪活動，而這一發現也證明了黑客的攻擊技術又上升了一個層次。除此之外，我們還發現該組織正在通過 GitHub 賬號并利用臭名昭著的 PlugX 惡意軟件變種來處理某些有針對性的攻擊活動。

惡意軟件分析

我們所分析的惡意軟件主要分為兩個文件：一個加載器（loader）和 payload。

loader 文件名為 loadperf.dll，在 Windows 操作系統中，也有一個名叫 loadperf.dll（用于管理系統性能的注冊表鍵）的文件，不過我們這里分析的這個 loadperf.dll 是被惡意修改過的，因為攻擊者在該文件中額外增加了一個數據域。在感染成功之后，這個文件會被復制到%WINDIR%\system32\wbem\目錄下并替換原始的 DLL 文件，然后它會利用 WMI 性能適配器服務 wmiAPSrv（Windows 下的合法服務，用于收集與系統性能相關的信息）和 services.exe 來導入惡意軟件的加載器。除此之外，系統還會將所有相關的 DLL 文件一起導入進去，包括 payload“loadoerf.ini”在內。整個感染鏈還包括一個從 loadoerf.ini 中導入的函數 gzwrite64，它將偽裝成一個應用程序編程接口（API）并作為 payload 的入口。雖然 gzwrite64 是通過 loadperf.dll 導入進來的，但 payload 的主函數實際上位于 loadoerf.ini 的 DLLMain（DLL 的入口函數）之中。

圖片1:攻擊者在原始 loadperf.dll 中添加的額外數據域 .idata

圖片2:額外導入的 gzwrite64 函數

payload 是一個名為 loadoerf.ini 的文件，該文件中包含解密、運行以及代碼注入函數。當系統加載了這個 payload 文件之后，DLLMain 會根據 CryptUnprotectData 的的值來解密 payload，由于這個函數的運行需要“設備 ID”作為參數，因此在一臺非初始感染主機的計算機中是無法完成解密操作的，這也使得惡意軟件的分析變得更加困難了

圖片3:payload 所使用的解密函數（部分代碼）

解密完成之后部分惡意代碼會在目標系統中運行，這些代碼將會注入到 svchost.exe（Windows 中的一個核心組件）中，并將 payload 加載進系統內存。

圖片4:loadoerf.ini 的執行／感染流程

那么這一切與 GitHub 有什么關系呢？在成功感染之后，惡意軟件便會通過一個托管在 GitHub 代碼庫中的 HTML 頁面來與遠程C&C主機進行通信。

圖片5:用于C&C通信的 HTML 信息（托管在 GitHub 上）

想必每一位惡意軟件分析人員第一眼都會注意到上圖中的第三行代碼，因為這行代碼與 PlugX 有關。這行代碼的起始和結束標簽為 DZKS 和 DZJS，這種標簽是 PlugX 的典型標記。在進一步分析之后，我們發現其解密算法與 PlugX 的是不一樣的，因為它在解密過程中還需要訪問一臺C&C服務器（代碼中標記有通信主機的 IP 地址和端口號）。

目前，Winnti 使用了多種不同的算法來加密文件（托管在 GitHub）中與這些C&C服務器有關的引用信息，但其中有一個算法 PlugX 也曾使用過。實際上，我們在代碼的C&C字符串中發現了與 PlugX 有關的引用，這也表明該組織在其攻擊活動中也使用了 PlugX，但我們卻沒有在這個 GitHub 庫中發現 PlugX 的樣本，因此我們推測可能有其他的 PlugX 樣本也在使用這個 GitHub 代碼庫來獲取自己相應的命令控制信息。

除了解密算法不同之外，這個 GitHub 庫文件所使用的其他算法與原始的 PlugX 算法幾乎相同：

PlugX style + shift string + Base64

PlugX style + shift string + Base64 + XOR

PlugX style + Base64 + XOR

追蹤 Winnti 的活動蹤跡

Winnti 黑客組織所利用的這個 GitHub 賬號創建于 2016 年 5 月份，并在 2016 年 6 月創建了一個合法的項目（mobile-phone-project），而這個項目來自于另一個普通的 GitHub 頁面。這個用于C&C通信的代碼庫創建于 2016 年 8 月份，而且我們認為這個賬號并不是一個被盜賬號，而是 Winnti 自己創建的。直到 2017 年 3 月份，這個代碼庫中已經有 14 個不同的 HTML 頁面了，而且這些頁面的創建時間也不同。

活動時間軸

我們通過對該 GitHub 庫的代碼更新日期進行了分析之后，大致得出了 Winnti 的活動時間圖。對于每一份文件，GitHub 都會保存其首次和最新提交的時間戳，因此我們得到了下面的這張圖片。

圖片6:C&C服務器的 IP 以及相應的活動時間軸

我們對這些 IP 地址進行了持續跟蹤，并且發現他們通常會在下午到深夜的這段時間與 Winnti 的C&C服務器進行通信，而這種時間段也是大多數網絡犯罪分子的“正常工作時間”，而且在我們的觀察過程中，這個 GitHub 庫中又出現了一個新創建的 HTML 文件。

C&C服務器

我們在這個 Winnti 所使用的 GitHub 賬號中總共發現了 12 個不同的 IP 地址以及相應端口號。所有與這些C&C服務器有關的網絡通信主要是通過三個端口完成的：53（DNS）、80（HTTP）和 443（HTTPS），而這也是 PlugX 和 Winnti 惡意軟件變種用來控制受感染主機與其C&C服務器進行通信交互的典型技術手段。根據 IP 地址我們了解到，除了兩臺C&C服務器位于日本之外，剩下所有的服務器都托管在美國境內。

圖片7:C&C 通信所使用的 IP 地址及端口號

目前，我們已經將研究結果披露給了 GitHub，并將會幫助他們一同解決這些安全問題。

總結

通過利用 GitHub 這樣的熱門平臺可以幫助網絡犯罪分子實現受感染主機與惡意服務器之間的持久化網絡通信，而且這種惡意行為也很難被檢測到。雖然 Winnti 仍在使用傳統的惡意軟件，但是他們的攻擊策略卻是非常領先的，而這也是網絡安全威脅復雜化的大勢所趨。

后門 BKDR64_WINNTI.ONM 的哈希（SHA256）：

06b077e31a6f339c4f3b1f61ba9a6a6ba827afe52ed5bed6a6bf56bf18a279ba— cryptbase.dll

1e63a7186886deea6c4e5c2a329eab76a60be3a65bca1ba9ed6e71f9a46b7e9d– loadperf.dll

7c37ebb96c54d5d8ea232951ccf56cb1d029facdd6b730f80ca2ad566f6c5d9b– loadoerf.ini

9d04ef8708cf030b9688bf3e8287c1790023a76374e43bd332178e212420f9fb— wbemcomn.ini

b1a0d0508ee932bbf91625330d2136f33344ed70cb25f7e64be0620d32c4b9e2— cryptbase.ini

e5273b72c853f12b77a11e9c08ae6432fabbb32238ac487af2fb959a6cc26089— wbemcomn.dll

* 參考來源：trendmicro， FB 小編 Alpha_h4ck 編譯

來自: www.freebuf.com