來自網(wǎng)絡(luò)安全解決方案團隊(Cyber Safety Solutions Team)的分析結(jié)果
通常來說開發(fā)者在發(fā)布新版本的應(yīng)用或維護創(chuàng)建的項目時需要經(jīng)常修改源代碼。為滿足此方面需求,GitHub 作為一個提供版本控制管理的在線存儲庫托管服務(wù)應(yīng)運而生。在許多方面,它就像一個程序員和開發(fā)人員的專屬社交網(wǎng)站,為代碼管理、共享、協(xié)作和集成提供了一個寶貴的平臺。
盡管如此,GitHub 被濫用的現(xiàn)象也屢屢發(fā)生。例如,據(jù)稱以學(xué)習(xí)為目的創(chuàng)建的開源勒索軟件項目 EDA2 和 Hidden Tear 就曾在 GitHub 上進行托管并由此滋生了指向企業(yè)的各種分支。此外,物聯(lián)網(wǎng)(IoT)設(shè)備漏洞利用工具在 GitHub 上也有提供。即使是用于針對性攻擊的無限鍵盤記錄器( Limiless Keylogger )也與 GitHub 項目相關(guān)聯(lián)。
最近,具有傳統(tǒng)網(wǎng)絡(luò)犯罪(尤其是金融詐騙)背景的中國黑客組織 Winnti 集團被指控將 GitHub 濫用為疑似其新后門(被 Trend Micro 檢測為 MBKDR64_WINNTI.ONM )的命令與控制( C&C )通信傳輸渠道。研究還表明,該組織目前仍在使用一些臭名昭著的 PlugX 惡意軟件變種( Winnti 兵器庫主要內(nèi)容)通過特定的 GitHub 帳戶進行有針對性的攻擊操作。
惡意軟件分析安全團隊分析的惡意軟件分為兩個文件:loader 和 payload。
loadperf.dll 是與其有著相似名稱的合法對應(yīng)文件的修改版本。作為 Microsoft 文件,它有助于操縱性能注冊表。目前,已在原有分區(qū)上新添加了一個額外組件。該文件自復(fù)制在 WINDIR%\system32\wbem\ 上并替換原始 DLL,利用 Windows 收集與系統(tǒng)性能相關(guān)信息的合法文件——WMI 性能適配器服務(wù)(wmiAPSrv),通過 services.exe 導(dǎo)入loader。該系統(tǒng)還導(dǎo)入所有相關(guān) DLL 文件并將payload loadoerf.ini 包括在內(nèi)。感染鏈包括從 loadoerf.ini 導(dǎo)入的附加功能 gzwrite64(雖然為空)。gzwrite64 被用作 payload 入口點的虛假應(yīng)用程序接口(API)。盡管 gzwrite64 由 loadperf.dll 導(dǎo)入,payload 主要功能實際上位于 loadoerf.ini 的 DLLMain 中。
圖 1:添加至原 loadperf.dll 文件的附加分區(qū) .idata
圖 2: 導(dǎo)入的附加功能 gzwrite64
payload 是一個名為 loadoerf.ini 的文件,具有解密、運行和代碼注入功能。DLLMain 被系統(tǒng)加載時通過 CryptUnprotectData 解密 payload。由于該功能高度依賴于實際“設(shè)備 ID ”,無法通過非原始受感染主機解密,增加了惡意軟件分析難度。
圖 3:payload 中使用的解密功能
解密之后,在設(shè)備上運行的部分代碼隨即被注入到 svchost.exe(一個關(guān)鍵的 Windows 組件);payload 被加載到內(nèi)存。
圖 4:loadoerf.ini 執(zhí)行/感染流程
說到這里,GitHub 到底如何被濫用呢?感染成功后,惡意軟件開始通過存儲在 GitHub 項目中的庫與 HTML 頁面展開通信。
圖5:托管 C&C 通信 HTML 頁面的 GitHub 賬號
看到上述圖像,任何惡意軟件威脅分析師都會立即將第3行代碼識別為潛在的 PlugX 加密特征。開始標記 DZKS 與結(jié)束標記 DZJS 在 PlugX 中極具代表性。然而,仔細觀察后發(fā)現(xiàn)解密算法不同于 PlugX。在此例中,解密過程會為實際的命令與控制(C&C)服務(wù)器提供引用:惡意軟件將連接到的 IP 地址與端口號。
Winnti 目前通過使用不同的加密算法將這些 C&C 信息存儲在 Github 文件中。其中之一就是 PlugX 使用的算法。事實上,我們已從分析的 C&C 字符串中發(fā)現(xiàn)了 PlugX 引用,表明該組織也可能在這次特定活動中使用相同后門。雖然我們無法通過那個特定的 GitHub 賬號查找到 PlugX 樣本,但可以由此推測出一些 PlugX 變種如何在復(fù)雜大環(huán)境下通過該 GitHub 庫獲取 C&C 信息。
本次 GitHub 活動中使用的所有其他算法幾乎全部派生自原始的 PlugX 算法:
○ PlugX 類型 +移位字符串 + Base64
○ PlugX 類型 +移位字符串+ Base64 + XOR
○ PlugX 類型 + Base64 + XOR
其中一種算法還內(nèi)置了標記字符串+ 移位字符串 + Base64編碼。
Winnti 尋蹤網(wǎng)絡(luò)犯罪分子使用的 GitHub 帳號創(chuàng)建于 2016 年 5 月。他們還曾于 2016 年 6 月通過該賬號創(chuàng)建了一個源自另一個 GitHub 通用頁面的合法項目/存儲庫(手機項目)。
Winnti 的 C&C 通信庫創(chuàng)建于 2016 年 8 月。我們推測該 GitHub 帳戶未被入侵、確由 Winnti 創(chuàng)建。截至 2017 年 3 月,該庫已經(jīng)包含了創(chuàng)建于不同時間的 14 個不同的 HTML 頁面。
活動時間線我們通過分析 GitHub 中暴露的日期映射 Winnti 開展的活動。對于每個文件,GitHub 存儲首次與末次提交時間戳;這使我們能夠創(chuàng)建該組織多臺 C&C 服務(wù)器首次使用時間表。
我們對 IP 地址連接至 Winnti C&C 服務(wù)器的時間段進行監(jiān)控,了解到具體行動從下午開始持續(xù)至深夜。此份時間表的特征與網(wǎng)絡(luò)犯罪分子的傳統(tǒng)工作時間相似,此類群體都有著較為簡單的組織架構(gòu)、偏好較晚時間開始工作直至深夜。實際上,我們僅觀察了在周末開展的一次活動實例(在此期間創(chuàng)建了一個新的 HTML 文件)。
我們追蹤到關(guān)于此 GitHub 賬戶的最早活動時間是 2016 年 8 月 17 日,最近一次發(fā)生在 2017 年 3 月 12 日。以下是根據(jù)監(jiān)控記錄整理出的 C&C 服務(wù)器 IP 地址首次使用時間線:
圖6:C&C服務(wù)器IP地址時間線
C&C服務(wù)器Winnti 使用的 GitHub 帳號顯示了使用各種端口號的 12 個不同的 IP 地址。發(fā)送至這些 C&C 服務(wù)器的所有通信都經(jīng)由三個不同的端口號:53(DNS)、80(HTTP)和 443(HTTPS)。這些均是 PlugX 和 Winnti 惡意軟件變種在被入侵設(shè)備與 C&C 服務(wù)器之間進行通信時采用的典型技術(shù)。幾乎所有 C&C 服務(wù)器都在美國托管,其中兩臺位于日本。
圖 7:用于 C&C 通信的 IP 地址以及相應(yīng)端口號
我們在此篇文章文發(fā)布前向 GitHub 私下透露了本次發(fā)現(xiàn),目前正積極與他們展開合作,共同應(yīng)對該威脅。
結(jié)論濫用 GitHub 等備受歡迎的平臺使 Winnti 等威脅行動者得以在雷達覆蓋區(qū)域內(nèi)實現(xiàn)被入侵計算機與服務(wù)器之間的網(wǎng)絡(luò)連通。盡管 Winnti 可能仍在使用傳統(tǒng)的惡意軟件,通過相對獨特的策略在威脅活動曲線上保持領(lǐng)先地位的能力反映出他們在具體行動中采用了更加高深的技術(shù)。
被檢測為 BKDR64_WINNTI.ONM 的相關(guān)哈希值(SHA256):
○ 06b077e31a6f339c4f3b1f61ba9a6a6ba827afe52ed5bed6a6bf56bf18a279ba — cryptbase.dll
○ 1e63a7186886deea6c4e5c2a329eab76a60be3a65bca1ba9ed6e71f9a46b7e9d – loadperf.dll
○ 7c37ebb96c54d5d8ea232951ccf56cb1d029facdd6b730f80ca2ad566f6c5d9b – loadoerf.ini
○ 9d04ef8708cf030b9688bf3e8287c1790023a76374e43bd332178e212420f9fb — wbemcomn.ini
○ b1a0d0508ee932bbf91625330d2136f33344ed70cb25f7e64be0620d32c4b9e2 — cryptbase.ini
○ e5273b72c853f12b77a11e9c08ae6432fabbb32238ac487af2fb959a6cc26089 — wbemcomn.dll