[译] APT分析报告：08.漏洞利用图谱–通过查找作者的指纹来寻找漏洞
這是作者新開的一個專欄，主要翻譯國外知名安全廠商的APT報告，了解它們的安全技術，學習它們溯源APT組織和惡意代碼分析的方法，希望對您有所幫助。當然，由于作者英語有限，會借助機翻進行校驗，還請包涵！前文分享了APT組織拉撒路（Lazarus）使用的兩款惡意軟件——后滲透工具和BLINDINGCAN。這篇文章將詳細講解checkpoint公司提出的一個新技術，即漏洞利用圖譜，通過查找作者的指紋來尋找利用漏洞，文章內容非常值得我們學習，尤其搞科研研究的讀者。
- 原文標題：《Graphology of an Exploit – Hunting for exploits by looking for the author’s fingerprints》
- 原文鏈接：https://research.checkpoint.com/2020/graphology-of-an-exploit-volodya/
- 文章作者：伊泰·科金（Iyal Itkin）、伊泰·科恩（Itay Cohen）
- 發(fā)布時間：2020年10月2日
- 文章來源：research.checkpoint.com
文章目錄
- 一.背景
- 二.漏洞利用集成
- 三.指紋漏洞利用開發(fā)者
- 四.我們行動者的漏洞利用
- CVE-2015-2546
- CVE-2016-0040
- CVE-2016-0167
- CVE-2016-0165*
- CVE-2016-7255
- CVE-2017-0001
- CVE-2017-0263
- CVE-2018-8641*
- CVE-2019-0859
- CVE-2019-1132*
- CVE-2019-1458
- 五.作者指紋
- PlayBit（又名luxor2008）
- bool elevate（int target_pid）
- Sleep(200)
- 操作系統(tǒng)指紋
- 內核地址泄漏
- Token Swap
- 六.客戶分析
- 七.結論
- 附錄-IOC表
在過去的幾個月中，我們的漏洞和惡意軟件研究團隊共同努力，專注于惡意軟件內部的漏洞利用研究，尤其是漏洞利用者本身。從一個事件響應案例開始，我們構建了Windows最活躍的漏洞利用開發(fā)人員之一的檔案，稱為 Volodya 或 BuggiCorp。到目前為止，我們設法跟蹤了他們Windows內核本地特權升級（LPE）漏洞中的10多個(!)，其中許多漏洞為0-day漏洞。
一.背景
正如所有有趣故事一樣，我們的故事始于一個應急響應案例。在分析針對我們客戶的一個復雜攻擊時，我們注意到該惡意軟件執(zhí)行了一個很小的64位可執(zhí)行文件。該樣本包含了一些不尋常的調試字符串，這些調試字符串指向試圖利用受害者計算機上的漏洞。更重要的是，該示例有一個遺留的PDB路徑，并指向了該二進制目標文件：
- …\cve-2019-0859\x64\Release\CmdTest.pdb
由于 CVE-2019-0859 實現(xiàn)時沒有任何在線資源，我們意識到我們看到的不是一個公開可用的PoC，而是一個真實的開發(fā)工具。這激發(fā)了我們深入挖掘的興趣。
對漏洞進行逆向工程非常直接。二進制文件很小，并且調試消息在那里指導我們。它利用了 CreateWindowsEx 中的一個UAF漏洞來獲取父進程的更高特權。我們很快發(fā)現(xiàn)了一個有趣的現(xiàn)象：
- 似乎這個漏洞和惡意軟件本身并不是由同一個人編寫的，其代碼質量、缺乏混淆、PDB和時間戳都表明了這個結論。
CVE-2019-0859: Microsoft Win32k特權提升漏洞
CVE-2019-0859是CreateWindowEx函數(shù)中提供的Use-After-Free漏洞。當Win32k組件無法正確處理內存中的對象時，Windows中存在一個特權提升漏洞。成功利用此漏洞的攻擊者可以在內核模式下運行任意代碼，然后攻擊者可以安裝程序，查看、更改或刪除數(shù)據(jù)，或創(chuàng)建具有完全用戶權限的新帳戶。
- https://securelist.com/new-win32k-zero-day-cve-2019-0859/90435/
二.漏洞利用集成
我們傾向于將特定惡意軟件家族背后的人們視為一個完整的單元。設想每一個組件都是由一個人、團隊或小組編寫而成。事實是，編寫一個高級惡意軟件，無論是國家還是APT組織，都需要不同技能的不同人群。一個國家的網(wǎng)絡攻擊組織，很可能在不同的組織和分支中有數(shù)百甚至數(shù)千名員工。組織中的每個工人都有一個特定的角色，并通過特殊的技術培訓和多年的專業(yè)知識進行調整。在這樣的組織中，編寫公共組件的工作量被分解到專門的團隊中，不同的團隊將負責初始訪問、收集敏感數(shù)據(jù)、橫向移動等等模塊。
一個運營實體的目標是在它的惡意軟件中嵌入一個漏洞利用模塊（exploit），不能只依賴惡意軟件開發(fā)人員。發(fā)現(xiàn)漏洞并可靠地利用漏洞，很可能是由專門從事特定角色的特定團隊或個人來完成的。對于惡意軟件開發(fā)人員來說，他們并不真正關心其幕后是如何工作的，他們只是想集成這個模塊并完成它。
為了實現(xiàn)這種勞動分工，兩個團隊需要就一些API達成共識，這些API將成為不同組件之間的橋梁。這種集成API并不是國家參與者所獨有的，而是漏洞利用“自由市場”中很常見的功能。無論是在地下論壇、漏洞利用經(jīng)紀人，還是網(wǎng)絡攻擊組織，他們都會向客戶提供如何將利用漏洞利用程序集成到惡意軟件中的指導手冊。
從本質上講，這個集成點是我們研究的重點。假設利用漏洞的作者獨立工作，并且只將他們的代碼/二進制模塊分發(fā)給惡意軟件作者，我們決定對他們進行更改。通過分析嵌入在惡意軟件樣本中的漏洞利用程序，我們可以了解有關漏洞利用程序作者的更多信息，希望通過研究他們的編碼習慣以及將其產(chǎn)品分發(fā)給編寫惡意軟件的同行時留下的其他線索來區(qū)分他們的身份。
作者簡單總結下：在大型網(wǎng)絡攻擊活動或APT組織中，由于需要不同團隊協(xié)作來完成攻擊事件，因此各個團隊間需要調用API來搭建橋梁，比如實現(xiàn)初始訪問、數(shù)據(jù)收集、橫向移動等功能，最終構建惡意程序，并且會提供相應的集成手冊。基于此，會造成他們的編程習慣、漏洞利用細節(jié)信息不同，這篇文章將通過收集漏洞利用的線索來區(qū)分他們的身份。
三.指紋漏洞利用開發(fā)者
本文不是專注于一個完整的惡意軟件溯源和尋找新樣本的惡意軟件家族或參與者，而是想提供另一種觀點，并決定專注于漏洞利用開發(fā)人員編寫的這幾個功能。從事件響應案例中獲得這個小的64位二進制文件看起來是個不錯的開始。
該二進制文件除了利用 CVE-2019-0859 之外什么也沒做，并且它不基于開源的源代碼或POC。由于可執(zhí)行文件是由漏洞利用作者（攻擊者）以外的其他人編寫而成，因此它非常適合指紋識別。此外，可執(zhí)行文件與惡意軟件的主要二進制文件是分離的（一個臭名昭著的犯罪軟件），這讓我們相信這個漏洞不是由惡意軟件開發(fā)人員內部開發(fā)的。帶著這個希望，我們開始尋找同一作者編寫的更多的exploit。
我們首先從已經(jīng)擁有的二進制文件中收集簡單的信息（Checkpoint）：
- 字符串
- 內部文件名
- 時間戳
- PDB路徑
第一個結果立即出現(xiàn)了——一個與64位示例完全匹配的32位可執(zhí)行文件。具體來說，正如它們的時間戳和嵌入式PDB路徑所顯示的那樣，它們是在同一時間從相同的源代碼中一起編譯的。現(xiàn)在我們有了這兩個樣本，我們就能得出要尋找的東西。
為了對這個漏洞的作者進行指紋識別，我們將目光投向了以下方面：
- 二進制文件中的獨特工件
– 硬編碼值（加密常量，“垃圾”值，例如0x11223344）
– 數(shù)據(jù)表（通常是特定于版本的配置）
– 字符串（GDI對象名稱：“ MyWindow”、“ MyClass_56”、“ findme1”等）
– PDB路徑 - 代碼段
– (1) 獨特的功能實現(xiàn)
a.系統(tǒng)調用包裝器（syscall）
b.內聯(lián)匯編
c.專有加密函數(shù)/實現(xiàn)
– (2) 技術和習慣
a.首選的泄漏技術（HMValidateHandle、gSharedInfo等）
b.首選的提升技術（如何執(zhí)行token替換？）
c.堆溢出技術（使用AcceleratorTables？Windows？Bitmaps？）
– (3) 構架
a.漏洞利用流程（The flow of the exploits）
– 選項1：幾乎沒有分支的主要漏洞利用流程
– 選項2：針對不同版本操作系統(tǒng)的多個扭曲和旋鈕
b.代碼和函數(shù)的結構
– 模塊化：功能分離
– 結構：分離以清除階段（初始化、配置、噴涂、令牌交換等）
– 全局變量：哪些信息存儲在全局變量中？（操作系統(tǒng)版本？枚舉操作系統(tǒng)版本？特定字段偏移量？）
c.特定于版本的配置
– 字段偏移量：哪些字段特別重要？
– 首選系統(tǒng)調用：系統(tǒng)調用的首選集合
d.提供給客戶的API
對應原文：
帶著這些屬性，回到我們擁有的兩個樣本，并標記了一些我們認為獨特的工件。即使只有兩個小的二進制文件（本質上是相同的），我們仍然能夠創(chuàng)建搜尋規(guī)則來查找該開發(fā)人員編寫的更多示例。令我們驚訝的是，我們能夠找到比想象中更多的東西。
一個接一個的出現(xiàn)了幾十個樣本，隨著每一個樣本的出現(xiàn)，我們改進了搜尋規(guī)則和方法。通過對樣本的仔細分析，我們能夠了解哪些樣本利用了哪個CVE，并以此為基礎創(chuàng)建了一個時間表，以了解該漏洞是在暴露之前的0-day漏洞，還是基于補丁擴散和類似技術實現(xiàn)的1-day漏洞。
到目前為止，僅基于我們的指紋識別技術且沒有進一步的情報信息，我們就可以將10多個CVE歸因于同一個漏洞利用開發(fā)人員。后來，公開的報告披露了我們的目標漏洞利用（exploit）銷售者的名稱為——Volodya（又名Volodimir） ，以前稱為BuggiCorp。似乎我們不是唯一跟蹤此漏洞賣家的，卡巴斯基也報道關于他們的一些相關信息。此外，ESET在VB2019關于Buhtrap的演講中還提到了Volodya的一些重要線索。
根據(jù)卡巴斯基的說法，Volodya最初以其 “BuggiCorp” 綽??號成為頭條新聞，當時他們在臭名昭著的Exploit [.]網(wǎng)絡犯罪論壇上宣傳了Windows 0-day的待售廣告，起價為9.5萬美元。多年來，價格不斷上漲，他們的一些Windows LPE 0-day漏洞利用軟件的售價高達20萬美元。正如卡巴斯基報告中所發(fā)表的，后來得到我們的證實，Volodya將漏洞利用軟件賣給了犯罪軟件和APT團體。我們將在“客戶”一節(jié)中詳細討論actor的客戶。
四.我們行動者的漏洞利用
Our actor’s exploits
盡管我們最初的一些狩獵規(guī)則需要進行一些微調，但即使是我們得到的即時結果也相當令人驚訝。經(jīng)過進一步的校準后，我們??找到了許多示例，所有這些示例都是Windows中的本地特權升級（LPE，Local Privilege Escalation）漏洞。從這些樣本中，我們的行動者（actor）能夠確定所利用的CVE列表。
注意：
在對漏洞進行分類時，我們選擇了一種保守的方法來決定一個給定的漏洞是0-day還是1-day。如果其他安全供應商將在野的漏洞歸因于我們的行動者，那么它就是0-day。如果我們發(fā)現(xiàn)足夠的證據(jù)表明我們的某個樣本的確是利用在外傳播的漏洞，就像供應商在他們的報告中描述的那樣，那么我們也會標記它為0-day。在所有其他情況下，我們將該漏洞標記為1-day，寧愿有較低數(shù)量的0-day，而不錯誤計數(shù)超過正確的數(shù)量。
CVE-2015-2546
- 分類：1-day
- 基本描述：在 xxxSendMessage（tagPOPUPMENU） 中釋放后使用（Use-After-Free）
- 0-day報告供應商：FireEye
- 在以下惡意軟件樣本中發(fā)現(xiàn)：Ursnif，Buhtrap
我們的漏洞利用示例使用了與初始報告中所述不同的內存整形技術：噴射Windows（spraying Windows）而不是加速器表（Accelerator Tables）。此外，我們最早和最基本的攻擊示例包含以下PDB路徑，這表明作者已經(jīng)知道該漏洞的CVE-ID：
- C:\…\volodimir_8\c2\ CVE-2015-2546 _VS2012\x64\Release\ CmdTest.pdb
CVE-2016-0040
- 分類： 1-day
- 基本描述：WMIDataDevice IOControl 中未初始化的內核指針（Uninitialized kernel pointer）
- 0-day報告供應商：N/A. 從來沒有在野被當做0-day利用過
- 在以下惡意軟件樣本中發(fā)現(xiàn)：Ursnif
該漏洞利用已用于單個樣本，該樣本還包含前面描述的CVE-2015-2546漏洞。如果目標是Windows 8之前的Windows版本，則選擇此漏洞。否則使用CVE-2015-2546。
CVE-2016-0167
- 分類： 0-day
- 基本描述：在 Win32k!xxxMNDestroyHandler 中釋放后使用（Use-After-Free）
- 0-day報告供應商：FireEye
- 在以下惡意軟件樣本中發(fā)現(xiàn)：PUNCHBUGGY
我們的漏洞利用樣本與在野的漏洞利用技術報告完全吻合。
CVE-2016-0165*
- 分類： 1-day
- 基本描述：在 Win32k!xxxMNDestroyHandler 中釋放后使用（Use-After-Free）
- 0-day報告供應商：Kaspersky ，被卡巴斯基發(fā)現(xiàn)，但未公開發(fā)布任何報告
- 在以下惡意軟件樣本中發(fā)現(xiàn)：Ursnif
這是一個有趣的案例。我們方案的0-day（CVE-2016-0167）已于2016年4月由Microsoft修補。該補丁也修復了CVE-2016-0165，該漏洞也被廣泛在外使用。為了尋找新的漏洞進行利用，我們的行動可能對微軟的修補程序進行了不同的修補，并發(fā)現(xiàn)了一個認為是修補過的0-day漏洞。此漏洞源于之前漏洞 Win32k!xxxMNDestroyHandler 中修補過的函數(shù)。
注意，我們從他們針對該漏洞的漏洞樣本中找到多個跡象表明，該漏洞作者或他們的客戶確定他們已出售了一個針對CVE-2016-0165的漏洞。可悲的是，在分析這個漏洞之后，我們確定這個被利用的漏洞是一個不同的漏洞。
圖3：調試字符串顯示CVE-2016-0165的混淆，可以從Cutter中看到。這種困惑可能是由于微軟發(fā)布了一個解決多個漏洞的單一修復，而且它們是唯一一個在每個代碼修復與為其發(fā)布的CVE之間有完整映射的補丁。
CVE-2016-7255
- 分類： 0-day
- 基本描述：在 NtUserSetWindowLongPtr 中內存損壞（Memory corruption）
- 0-day報告供應商：Google ，被谷歌發(fā)現(xiàn)，通過技術報告趨勢科技（TrendMicro）
- 在以下惡意軟件樣本中發(fā)現(xiàn)：APT28，又叫Fancy Bear或Sednit。后來被使用在 Ursnif，Dreambot，GandCrab，Cerber，Maze 中
我們的漏洞利用樣本完美地與在野漏洞利用技術報告吻合。后來，這個特定的漏洞被不同的勒索軟件參與者廣泛使用。此外，我們還看到了其他針對這個特定漏洞的利用，這些漏洞在1-day期間被賣給了其他勒索軟件參與者。
注意：我們有多個間接證據(jù)認為，這個0-day就是那個由BuggiCorp在2016年5月發(fā)布到 exploit[.] 著名廣告中提到的漏洞。
CVE-2017-0001
- 分類： 1-day
- 基本描述：在 RemoveFontResourceExW 中釋放后使用（Use-After-Free）
- 0-day報告供應商：N/A. 從來沒有在野被當做0-day利用過
- 在以下惡意軟件樣本中發(fā)現(xiàn)：Turla，歸因于Turla。后來被使用在 Ursnif 中
Turla（FireEye）在操作中當作1-day漏洞使用過。
CVE-2017-0263
- 分類： 0-day
- 基本描述：在 win32k!xxxDestroyWindow 中釋放后使用（Use-After-Free）
- 0-day報告供應商：ESET
- 在以下惡意軟件樣本中發(fā)現(xiàn)：APT28，又叫Fancy Bear或Sednit
我們的漏洞利用樣本與在野的漏洞利用技術報告完全吻合。
CVE-2018-8641*
- 分類： 1-day
- 基本描述：在 win32k!xxxTrackPopupMenuEx 重復釋放（Double Free）
- 0-day報告供應商：N/A. 從來沒有在野被當做0-day利用過
- 在以下惡意軟件樣本中發(fā)現(xiàn)：Magniber
同樣，識別使用過的1-day通常比識別0-day漏洞更難。這一次，我們找不到任何可能暗示參與者認為他們正在利用的漏洞示例。我們發(fā)現(xiàn)該漏洞已于2018年12月被微軟修補。在掃描此補丁中解決的漏洞列表后，我們非常確定微軟將此漏洞標記為CVE-2018-8641，但我們無法確認。
2020年6月24日，卡巴斯基在其博客上發(fā)表了一份通過大規(guī)模漏洞利用工具（the Magnitude exploit kit）分發(fā)的漏洞利用攻擊。在他們的博文中，卡巴斯基分析了Magniber使用的LPE漏洞，將其歸因于 Volodya，并預測其可能是CVE-2018-8641。這進一步通過卡巴斯基的獨立結論驗證了我們的初步估計。
CVE-2019-0859
- 分類： 0-day
- 基本描述：在 CreateWindowEx 中釋放后使用（Use-After-Free）
- 0-day報告供應商：Kaspersky
- 在以下惡意軟件樣本中發(fā)現(xiàn)：用作一個獨立的組件被注入或加載，我們無法將其歸因于任何特定的APT/惡意軟件
我們的漏洞利用示例與有關野生漏洞利用的技術報告完全吻合。我們的研究始于在客戶網(wǎng)絡中發(fā)現(xiàn)的這種漏洞利用的單個樣本。在我們后來發(fā)現(xiàn)的樣本中，我們可以看清這個PDB字符串：
- X:\tools\ 0day \ 09-08-2018 \x64\Release\RunPS.pdb
該字符串和我們最初示例中的PDB字符串相反。
- S:\Work\Inject\ cve-2019-0859 \Release\CmdTest.pdb
CVE-2019-1132*
- 分類： 0-day
- 基本描述：在 win32k!xxxMNOpenHierarchy（tagPOPUPMENU） 中空指針引用（NULL pointer dereference）
- 0-day報告供應商：ESET
- 在以下惡意軟件樣本中發(fā)現(xiàn)：歸因于 Buhtrap
我們有多個理由相信這是Volodya的另一個0-day漏洞，因為報告中的多個技術細節(jié)匹配他們典型的利用方式。此外，，該漏洞報告其中嵌入了以下PDB路徑：
- C:\work\ volodimir_65 \…PDB
然而，這是我們列表中唯一尚未找到樣本的漏洞，因此我們不能確定這一漏洞的歸屬。
CVE-2019-1458
- 分類： 1-day
- 基本描述：在窗口切換時內存損壞
- 0-day報告供應商：Kaspersky （初始報告、詳細報告）
- 在以下惡意軟件樣本中發(fā)現(xiàn)：歸因于操作 WizardOpium
我們的漏洞利用和技術報告里的漏洞利用不一致。此外，在他們的詳細報告中，卡巴斯基指出“同樣有趣的是，我們在補丁發(fā)布一周后就發(fā)現(xiàn)了另一個1-day漏洞，這表明利用這個漏洞非常簡單。”事實上，我們的樣本是在卡巴斯基首次報告后的第6天。
最后，通過下表總結了我們列出的11個漏洞：
五.作者指紋
現(xiàn)在，我們從Volodya那里發(fā)現(xiàn)了10多個不同的exploit，我們可以更詳細地審查它們，并熟悉actor的工作習慣。從一開始我們就很清楚，我們的參與者可能有一個簡單的模板，他們可以針對不同的漏洞利用程序進行部署，因為每個漏洞利用程序的功能流程甚至不同功能的順序都在大多數(shù)漏洞利用程序之間共享。
在本節(jié)中，我們將描述一組關鍵特征，這些特征反映了在創(chuàng)建exploit模板時Volodya所做的不同實現(xiàn)選擇。我們將他們的實現(xiàn)與昵稱為PlayBit的另一個exploit編寫器的實現(xiàn)進行比較。通過這種比較，旨在概述漏洞利用各部分中存在的各種實現(xiàn)選項，從而使每個作者的實現(xiàn)選擇集成為他們思維和工作方式的獨特“簽名”。
PlayBit（又名luxor2008）
使用我們用來搜尋Volodya漏洞的相同技術，我們設法追蹤了PlayBit編寫的5個Windows LPE 1-day漏洞，以及作者多年來銷售的其他工具。我們從REvil勒索軟件使用的CVE-2018-8453樣本開始，并使用PlayBits的獨特指紋來尋找更多漏洞。
我們發(fā)現(xiàn)以下Windows LPE漏洞由作者實施為1-day：
- CVE-2013-3660
- CVE-2015-0057
- CVE-2015-1701
- CVE-2016-7255 – 這是Volodya的0-day
- CVE-2018-8453
從技術上講，PlayBit還出售了針對CVE-2019-1069（一個SandboxEscaper漏洞）和CVE-2020-0787的兩個漏洞。但是，我們忽略這些漏洞，因為它們不是內存損壞漏洞，而是不同服務中的漏洞，因此具有不同的結構。
注意：關于PlayBit的更深入分析，以及他們開發(fā)和銷售的不同漏洞，將在即將發(fā)布的博文中發(fā)布。
bool elevate（int target_pid）
Volodya的所有exploit樣本中的API總是相同的。無論它是嵌入在一個惡意軟件樣本中，還是一個獨立的POC，該漏洞都有以下簽名的單一API函數(shù)：
- bool elevate(int target_pid)
該漏洞本身并不包括將shellcode注入到另一個進程或任何類似的功能。它向所需的進程授予系統(tǒng)特權，只接受其PID作為參數(shù)。
Sleep(200)
該elevate()函數(shù)在被惡意軟件調用后所做的第一件事，是調用Sleep函數(shù)休眠200毫秒的固定時間。
圖5：通過調用Sleep(200)來啟動漏洞，如Cutter中所示。為什么Sleep(200)會出現(xiàn)在模板中還不是很清楚。我們懷疑這是為了避免不必要的不穩(wěn)定，特別是因為這些漏洞是基于時間安排（UAF races）。因此，短時間的等待與I/O和內存訪問相關的活動結束，可以提高穩(wěn)定性。
由于這些漏洞是惡意軟件的一部分，在漏洞利用程序執(zhí)行之前，所有這些與惡意軟件相關的代碼都會導致CPU / 磁盤 / RAM出現(xiàn)短暫的峰值，因此在進行實際漏洞利用之前讓情況有所緩和可能是有意義的。對于短期峰值負載（在啟動新進程，從磁盤讀寫文件等情況下自然會發(fā)生），它應該足足等待200毫秒。盡管我們在最近的示例中注意到這種模式的變化，但是仍然可以在我們發(fā)現(xiàn)的9個漏洞中找到該功能。
與PlayBit的比較：PlayBit在其利用中沒有任何此類功能。
操作系統(tǒng)指紋
sleep函數(shù)結束后，該漏洞利用程序就會識別并校準目標的Windows版本，以便為盡可能多的OS版本提供支持。從我們的樣本中，作者似乎使用了兩種技術來查詢操作系統(tǒng)。
-
(1) 解析ntdll.dll的頭部
這是最常用的技術。ntdll.dll句柄用于查找 IMAGE_NT_HEADERS 的偏移量，從這里解析 MajorOperatingSystemVersion 和 MinorOperatingSystemVersion 字段。 -
(2) GetVersionEx()
該技術通常與前一種技術一起使用，僅在2016年至2017年初的樣品中使用。這可能是因為這個API現(xiàn)在已經(jīng)棄用了。
在這兩種技術中，目標都是查詢操作系統(tǒng)的主版本和次版本，并相應地配置漏洞利用程序的全局變量。雖然大多數(shù)的利用都支持多種Windows版本，但Volodya似乎從不關心目標的特定服務包，也不關心它是否是Windows服務器。除了對特定的Windows 10構建版本感興趣之外（僅在CVE-2019-1458漏洞中使用），我們的actor只使用了主要版本和次要版本，僅此而已。
與PlayBit的比較：再次使用GetVersionEx()，通常隨后還要對流程環(huán)境塊（PEB）本身的主次編號進行額外解析，如圖7所示。不僅使用PEB代替 ntdll.dll，PlayBit還從GetVersionEx()輸出中提取額外的信息，如計算機的服務包（Service Pack），甚至檢查目標計算機是否使用服務器操作系統(tǒng)。
圖7：從PEB中提取主要版本和次要版本，如Cutter所示。這是兩個行動者在操作方式上的明顯區(qū)別。它們不僅以不同的方式提取相同的信息，而且即使它們都利用了相同的漏洞（CVE-2016-7255）， Volodya感興趣的信息也遠少于PlayBit。
通常，兩個參與者都持有詳細的特定于版本的配置，一旦確定了操作系統(tǒng)版本，他們就從這些配置加載相關信息。兩者之間的主要區(qū)別是：
- Volodya的漏洞利用代碼流很少依賴于操作系統(tǒng)版本
- PlayBit使用了多種依賴于操作系統(tǒng)版本的if-check來進行多重扭曲和旋轉
- 這反過來又影響了它們對確切版本細節(jié)的不同興趣
內核地址泄漏
Leaking Kernel Addresses
在絕大多數(shù)漏洞利用中，操作者使用內核指針泄漏原語來調整漏洞利用。在除CVE-2019-1458之外的所有漏洞利用中，此漏洞原語都是眾所周知的 HMValidateHandle 技術。
HMValidateHandle()是user32.dll的一個內部未導出函數(shù)，它被各種函數(shù)如isMenu()所利用，并可用于獲取所有Windows版本（直到Windows 10 RS4）中不同Window對象的內核地址。這種技術很有名，早在2011年就開始使用了，當時大多數(shù)開發(fā)教程都選擇專門解析isMenu()來找到HMValidateHandle()的地址。
令人驚訝的是，在數(shù)十個用于查找HMValidateHandle()的不同函數(shù)中，參與者只是簡單地遵循了著名的教程，并選擇了使用isMenu()。更令人驚訝的是，多年來，這種常見的利用技術仍然非常有效，使得參與者沒有動力通過選擇一個不太為人所知的函數(shù)（如CheckMenuRadioItem）來“隱藏”。
泄露給我們的信息如下：
- 我們窗口的內核地址
- THREAD_INFO（pti字段）的內核地址
該漏洞利用過程中的多個步驟將使用此信息：
- 地址在指向 / 創(chuàng)建假的內核結構體時使用
- 確保我們的內核地址是有效的Unicode字符串（不包含兩個連續(xù)的 ‘\x00’ 字節(jié)）
- 該pti用于定位一個有效的EPROCESS，然后其在令牌交換階段中使用
與PlayBit的比較：PlayBit選擇通過直接訪問用戶模式桌面堆來實現(xiàn)此功能。關于這個主題的更多內容，可以在未來關注這個actor的博文中找到。
Token Swap
該漏洞的最終目標是根據(jù)給定的PID參數(shù)將系統(tǒng)權限授予所需進程。傳統(tǒng)上，實現(xiàn)這一點的方法是用系統(tǒng)進程的令牌替換 EPROCESS / KPROCESS 結構中的進程令牌。
下面是一些常用的技巧。您會驚訝地發(fā)現(xiàn)有多少不同的選項可以實現(xiàn)此功能。
(1) 使用Ps 符號（Using Ps * symbols）
Windows內核包含以下與進程相關的函數(shù)和全局變量：
- PsLookupProcessByProcessId
獲取一個指向進程EPROCESS的指針 - pinitialsystemprocess
全局變量，它保存著一個指向系統(tǒng)EPROCESS的指針 - psreferencepprimarytoken
返回一個指向進程主令牌（token）的指針
通過在內核模式下執(zhí)行這些函數(shù)，一個給定的shellcode可以很容易地定位系統(tǒng)的令牌，但是它仍然不能解決如何在所需的EPROCESS中分配它的問題。為此，有兩種常見的解決方案：
- 使用特定版本的偏移量直接訪問EPROCESS內部的正確偏移量
- 掃描EPROCESS，查找我們自己的指針（通過前面對PsReferencePrimaryToken的調用知道），一旦找到匹配的條目，就替換它
這種技術需要以內核模式執(zhí)行代碼，因此會被SMEP保護阻止，除非部署了額外的SMEP旁路。
(2) 掃描PsList
查找目標進程和系統(tǒng)進程EPROCESS的常見替代方法是掃描雙向鏈接的進程列表，稱為PsList。此技術涉及的步驟為：
- 找到一個初始過程（使用泄漏的pti字段）
- 掃描PsList以查找具有目標PID的EPROCESS
- 通過查找PID為4或名稱為的方式，掃描PsList以搜索SYSTEM的EPROCESS SYS*
- 提取令牌并將其放置在目標進程中的匹配偏移量中
- 謹慎更新SYSTEM令牌的引用計數(shù)
這種技術需要PsList的主令牌和LIST_ENTRY的偏移量，要求它們都存儲在特定于版本的配置中。
該技術的主要優(yōu)點是，盡管它仍然可以作為一個簡單的shellcode在內核模式下執(zhí)行（正如CVE-2017-0263所做的那樣），但它也可以在用戶模式下完全實現(xiàn)。為此，您需要兩個利用原語，一個用于任意讀（來自內核空間），另一個用于任意寫（進入內核空間）。在用戶模式下運行解決了我們之前詳細介紹的關于SMEP的問題，使這種保護對此類exploit原語毫無用處。
由于令牌是一個引用計數(shù)對象，因此正確注冊剛剛添加的引用非常重要，以避免在升級的進程終止時出現(xiàn)藍屏死機(BSOD)。事實上，有兩種不同的引用計數(shù)：
- 令牌是一個EX_FAST_REF對象-較低的指針位用作引用計數(shù)
- 將anOBJECT_HEADER存儲在令牌之前，并保留另一個引用計數(shù)
由于參與者選擇更新后一個引用計數(shù)字段，因此需要執(zhí)行以下步驟：
- 從標記的指針中屏蔽掉refcount位——在32位進程上應該對齊到8字節(jié)，在64位進程上應該對齊到16字節(jié)
- 減去指向OBJECT_HEADER的ref-count字段所需的常量
- 讀取值（使用任意讀取的exploit原語）
- 相應地增加它
- 回寫更新后的值
但是，如圖9所示，我們在包含此功能的所有32位漏洞利用程序中發(fā)現(xiàn)了以下錯誤。
圖9：32位漏洞利用中的引用計數(shù)更新中的實現(xiàn)錯誤。讀取引用計數(shù)值時對齊掩碼對齊到8字節(jié)，而回寫更新后的值時使用不同的掩碼。如果令牌將被存儲在一個對齊到8字節(jié)而不是對齊到16字節(jié)的內存地址中，寫操作將更新錯誤的字段。
雖然CVE-2016-0040和CVE-2016-0167使用的是Ps*技術，但到目前為止，掃描PsList是我們的actor最喜歡的執(zhí)行令牌交換的方式，在他們的8個漏洞中使用過。在其中的7個例子中，他們使用了用戶模式的任意讀和任意寫。
與PlayBit的比較：在他們的所有樣本中，我們總是看到PlayBit使用Ps*函數(shù)進行令牌交換。這一決定迫使參與者實現(xiàn)了一些SMEP繞過，他們將這些繞過集成到CVE-2016-7255和CVE-2018-8453的后續(xù)攻擊中。這種設計選擇解釋了為什么參與者不麻煩地實現(xiàn)適當?shù)娜我庾x取原語作為利用的一部分。PlayBit不使用版本特定的配置來對EPROCESS中的令牌偏移量進行搜索，而是總是掃描EPROCESS來搜索它，通常使用0x300或0x600作為搜索的上限。
值得注意的是，PlayBit在不同的攻擊中使用的內存破壞技術也被Duqu 2.0所使用，并在微軟2015年的VB演講中進行了分析。通過這種內存破壞，它們可以觸發(fā)從內核內存到內核內存的一些內存讀寫，這將在攻擊期間起到幫助作用。
圖10： PlayBit漏洞掃描EPROCESS以搜索令牌，如Cutter所示。盡管我們可以討論其他方面，例如每個參與者在開發(fā)過程中喜歡使用的不同系統(tǒng)調用，對Windows和ScrollBars之類的已創(chuàng)建對象的命名約定，但我們相信上面的清單清楚地證明了我們方法的效率/有效性。從上面的列表可以看出，漏洞利用程序的幾乎每個方面都可以幾種不同的方式實現(xiàn)。盡管如此，我們兩個演員在各自的剝削程序上都非常一致，每個人都堅持自己喜歡的方式。
六.客戶分析
在我們的整個研究過程中，我們想把重點放在開發(fā)作者本身，無論是Volodya, PlayBit或其他。然而，我們認為，通過觀察這些利用作者的客戶，還有很多東西要學習。Volodya的客戶名單多種多樣，包括Ursnif等銀行家木馬作者，GandCrab、Cerber和Magniber等勒索軟件作者，以及Turla、APT28和Buhtrap等APT組織。有趣的是，我們可以看到Volodya的0-day更有可能賣給APT組織，而1-day則被多個犯罪軟件組織購買。沒有進一步的情報，我們只能假設一旦0-day漏洞被安全行業(yè)檢測到，該漏洞就會被回收，并以更低的價格作為非排他性的1-day漏洞出售。
APT的客戶Turla、APT28和Buhtrap，都被普遍認為是俄羅斯的，有趣的是，即使是這些高級團隊也購買漏洞，而不是自己開發(fā)。這是另一點，進一步加強了我們的假設，編寫exploits可以作為一個單獨的和不同的部分惡意軟件處理。
下表總結并顯示了我們能夠歸因于Volodya的CVE，以及使用這些漏洞發(fā)現(xiàn)的客戶或惡意軟件組。標有藍色的CVE為0-day，自然更昂貴，左側高亮顯示的組被視為APT。
圖11： Volodya的客戶和他們使用的CVE。在回顧我們在一段時間內檢查漏洞樣本時注意到的不同趨勢之前，我們應該強調，我們的可見性有限，因為我們不能討論尚未捕獲的0-day。此外，我們只能嘗試確定樣本的年代，直到它們被捕獲之前，但令人遺憾的是，我們通常基本上確定的是這種漏洞首次在野外被發(fā)現(xiàn)的時間。此外，值得一提的是，Volodya在開發(fā)第一個漏洞（CVE-2015-2546）時就已經(jīng)非常專業(yè)了。例如，它有一個獨特的任意編寫原語，我們無法追蹤到任何其他的exploit教程或exploit。
在分析這些漏洞以及我們收集的數(shù)十個惡意軟件樣本的過程中，我們注意到一個有趣的變化。早期的Volodya漏洞作為源代碼出售，以嵌入惡意軟件中，后來的漏洞作為接受特定API的外部工具出售。這一變化表明Volodya采取了更多的預防措施。在2015年至2019年期間，我們也注意到Volodya的技術技能有了顯著的提高。當他們變得更好和更有經(jīng)驗時，Volodya開始使用更有效的任意讀和寫原語，他們甚至修復了這些原語之間的一個bug。
CVE-2015-2546和CVE-2016-0165。此外，這些漏洞的代碼變得更加模塊化，因為大型函數(shù)被分割成更小的子例程。同時，他們在各種結構中搜索和訪問特定偏移量的技術也得到了改進，在最近的實現(xiàn)中，它變得更加動態(tài)和安全，因為它在Windows的小版本中更好地處理了變化。
這不僅顯示了我們actor的學習曲線和發(fā)展，也暗示了他們的技能。找到并可靠地利用Windows內核漏洞的能力并不是那么簡單的。相比之下，PlayBit在2015-2018年期間在這個市場上非常活躍，他們的重點是銷售1-day漏洞，其中之一是0-day的Volodya漏洞（CVE-2016-7255）。
七.結論
我們的研究方法是對漏洞利用作者的特征進行指紋識別，然后再將這些屬性用作唯一的狩獵簽名。在跟蹤Volodya和PlayBit的漏洞時，我們兩次部署了此技術。有了這兩個成功的測試案例，我們相信該研究方法可用于確定其他漏洞利用程序作者。我們建議其他研究人員嘗試我們建議的技術，并將其用作其武器庫中的其他工具。
在這項研究中，我們重點研究了APT攻擊和商品惡意軟件（尤其是勒索軟件）中不同惡意軟件系列所使用或嵌入的漏洞。盡管它們很普遍，但我們經(jīng)常發(fā)現(xiàn)詳盡的惡意軟件報告，而忽略了提及手邊的惡意軟件也利用漏洞來提升其特權的報告。
事實上，我們能夠反復地使用我們的技術來跟蹤16個Windows LPE漏洞，這些漏洞是由兩個不同的角色編寫和銷售的，這是非常令人驚訝的。考慮到其中15個是在2015-2019年的時間框架內，我們有理由認為它們構成了開發(fā)市場的重要份額，特別是針對Windows LPE的開發(fā)。
最后，我們不可能說出Windows內核0-day漏洞的總數(shù)，這些漏洞正在被廣泛利用。我們仍然可以通過觀察被捕捉到的漏洞來獲得洞見，同時記住這種生存偏差。去年，卡巴斯基報告說，一個單一的參與者分發(fā)了超過3個0-day的利用框架。把這些數(shù)字加起來，我們發(fā)現(xiàn)15個零日漏洞中有8個（超過一半的“市場份額”）是由兩名actor完成的。這意味著我們的研究技術有可能被用于追蹤“可視市場”中的許多actor，如果不是全部的話。
保護建議：Check Point威脅模擬可針對以下威脅提供保護。
- Trojan.Wins.Generic.F
- Trojan.Wins.Generic.G
前文分享：
- [譯] APT分析報告：01.Linux系統(tǒng)下針對性的APT攻擊概述
- [譯] APT分析報告：02.釣魚郵件網(wǎng)址混淆URL逃避檢測
- [譯] APT分析報告：03.OpBlueRaven揭露APT組織Fin7/Carbanak（上）Tirion惡意軟件
- [譯] APT分析報告：04.Kraken - 新型無文件APT攻擊利用Windows錯誤報告服務逃避檢測
- [譯] APT分析報告：05.Turla新型水坑攻擊后門（NetFlash和PyFlash）
- [譯] APT分析報告：06.猖獗的小貓——針對伊朗的APT攻擊活動詳解
- [譯] APT分析報告：07.拉撒路（Lazarus）使用的兩款惡意軟件分析
- [譯] APT分析報告：08.漏洞利用圖譜–通過查找作者的指紋來尋找漏洞
2020年8月18新開的“娜璋AI安全之家”，主要圍繞Python大數(shù)據(jù)分析、網(wǎng)絡空間安全、逆向分析、APT分析報告、人工智能、Web滲透及攻防技術進行講解，同時分享CCF、SCI、南核北核論文的算法實現(xiàn)。娜璋之家會更加系統(tǒng)，并重構作者的所有文章，從零講解Python和安全，寫了近十年文章，真心想把自己所學所感所做分享出來，還請各位多多指教，真誠邀請您的關注！謝謝。
(By:Eastmount 2021-04-06 星期二 晚上10點寫于武漢 http://blog.csdn.net/eastmount/ )
附錄-IOC表
Volodya
- CVE-2015-2546
3f6fe68981157bf3e267148ec4abf801a0983f4cea64d1aaf50fecc97ae590d3 - CVE-2016-0040
0ea43ba3e1907d1b5655a665b54ad5295a93bda660146cf7c8c302b74ab573e9 - CVE-2016-0165*
f1842080b38b3b990ba3ccc1d55ceedd901d423b6b8625633e1885f0dadee4c2 - CVE-2016-0167
6224efee6665118fe4b5bfbc0c4b1dbe611a43a4b385f61ae33b0a0af230da4e - CVE-2016-7255
a785ad170a38280fc595dcc5af0842bd7cabc77b86deb510aa6ebb264bf2c092 - CVE-2017-0001
ed7532c77d2e5cf559a23a355e62d26c7a036f2c51b1dd669745a9a577f831a0 - CVE-2017-0263
f9dca02aa877ad36f05df1ebb16563c9dd07639a038b9840879be4499f840a10 - CVE-2018-8641*
0829f90a94aea5f7a56d6ebf0295e3d48b1dffcfefe91c7b2231a7108fe69c5e - CVE-2019-0859 – Initial 64bit sample
895ab681351439ee4281690df21c4a47bdeb6691b9b828fdf8c8fed3f45202d8 - CVE-2019-0859 – Matching 32bit sample
eea10d513ae0c33248484105355a25f80dc9b4f1cfd9e735e447a6f7fd52b569 - CVE-2019-1458
8af2cf1a254b1dafe9e15027687b0315493877524c089403d3ffffa950389a30
PlayBit
- CVE-2013-3660
9f1a235eb38291cef296829be4b4d03618cd21e0b4f343f75a460c31a0ad62d3 - CVE-2015-0057
8869e0df9b5f4a894216c76aa5689686395c16296761716abece00a0b4234d87 - CVE-2015-1701 (yes, it is the same sample as CVE-2015-0057)
8869e0df9b5f4a894216c76aa5689686395c16296761716abece00a0b4234d87 - CVE-2016-7255
5c27e05b788ba3b997a70df674d410322c3fa5e97079a7bf3aec369a0d397164 - CVE-2018-8453
50da0183466a9852590de0d9e58bbe64f22ff8fc20a9ccc68ed0e50b367d7043
總結
以上是生活随笔為你收集整理的[译] APT分析报告：08.漏洞利用图谱–通过查找作者的指纹来寻找漏洞的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [Python人工智能] 二十九.什么是
- 下一篇： [网络安全提高篇] 一〇八.Powers