這是作者新開的一個專欄，主要翻譯國外知名安全廠商的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）
• 發布時間：2020年10月2日
• 文章來源：research.checkpoint.com

在過去的幾個月中，我們的漏洞和惡意軟體研究團隊共同努力，專注于惡意軟體內部的漏洞利用研究，尤其是漏洞利用者本身，從一個事件回應案例開始，我們構建了Windows最活躍的漏洞利用開發人員之一的檔案，稱為 Volodya 或 BuggiCorp，到目前為止，我們設法跟蹤了他們Windows內核本地特權升級（LPE）漏洞中的10多個(!)，其中許多漏洞為0-day漏洞，

一.背景

正如所有有趣故事一樣，我們的故事始于一個應急回應案例，在分析針對我們客戶的一個復雜攻擊時，我們注意到該惡意軟體執行了一個很小的64位可執行檔案，該樣本包含了一些不尋常的除錯字串，這些除錯字串指向試圖利用受害者計算機上的漏洞，更重要的是，該示例有一個遺留的PDB路徑，并指向了該二進制目標檔案：

• …\cve-2019-0859\x64\Release\CmdTest.pdb

由于 CVE-2019-0859 實作時沒有任何在線資源，我們意識到我們看到的不是一個公開可用的PoC，而是一個真實的開發工具，這激發了我們深入挖掘的興趣，

對漏洞進行逆向工程非常直接，二進制檔案很小，并且除錯訊息在那里指導我們，它利用了 CreateWindowsEx 中的一個UAF漏洞來獲取父行程的更高特權，我們很快發現了一個有趣的現象：

• 似乎這個漏洞和惡意軟體本身并不是由同一個人撰寫的，其代碼質量、缺乏混淆、PDB和時間戳都表明了這個結論，

CVE-2019-0859: Microsoft Win32k特權提升漏洞
CVE-2019-0859是CreateWindowEx函式中提供的Use-After-Free漏洞，當Win32k組件無法正確處理記憶體中的物件時，Windows中存在一個特權提升漏洞，成功利用此漏洞的攻擊者可以在內核模式下運行任意代碼，然后攻擊者可以安裝程式，查看、更改或洗掉資料，或創建具有完全用戶權限的新帳戶，

• https://securelist.com/new-win32k-zero-day-cve-2019-0859/90435/

二.漏洞利用集成

我們傾向于將特定惡意軟體家族背后的人們視為一個完整的單元，設想每一個組件都是由一個人、團隊或小組撰寫而成，事實是，撰寫一個高級惡意軟體，無論是國家還是APT組織，都需要不同技能的不同人群，一個國家的網路攻擊組織，很可能在不同的組織和分支中有數百甚至數千名員工，組織中的每個工人都有一個特定的角色，并通過特殊的技術培訓和多年的專業知識進行調整，在這樣的組織中，撰寫公共組件的作業量被分解到專門的團隊中，不同的團隊將負責初始訪問、收集敏感資料、橫向移動等等模塊，

一個運營物體的目標是在它的惡意軟體中嵌入一個漏洞利用模塊（exploit），不能只依賴惡意軟體開發人員，發現漏洞并可靠地利用漏洞，很可能是由專門從事特定角色的特定團隊或個人來完成的，對于惡意軟體開發人員來說，他們并不真正關心其幕后是如何作業的，他們只是想集成這個模塊并完成它，

為了實作這種勞動分工，兩個團隊需要就一些API達成共識，這些API將成為不同組件之間的橋梁，這種集成API并不是國家參與者所獨有的，而是漏洞利用“自由市場”中很常見的功能，無論是在地下論壇、漏洞利用經紀人，還是網路攻擊組織，他們都會向客戶提供如何將利用漏洞利用程式集成到惡意軟體中的指導手冊，

從本質上講，這個集成點是我們研究的重點，假設利用漏洞的作者獨立作業，并且只將他們的代碼/二進制模塊分發給惡意軟體作者，我們決定對他們進行更改，通過分析嵌入在惡意軟體樣本中的漏洞利用程式，我們可以了解有關漏洞利用程式作者的更多資訊，希望通過研究他們的編碼習慣以及將其產品分發給撰寫惡意軟體的同行時留下的其他線索來區分他們的身份，

作者簡單總結下：在大型網路攻擊活動或APT組織中，由于需要不同團隊協作來完成攻擊事件，因此各個團隊間需要呼叫API來搭建橋梁，比如實作初始訪問、資料收集、橫向移動等功能，最終構建惡意程式，并且會提供相應的集成手冊，基于此，會造成他們的編程習慣、漏洞利用細節資訊不同，這篇文章將通過收集漏洞利用的線索來區分他們的身份，

三.指紋漏洞利用開發者

本文不是專注于一個完整的惡意軟體溯源和尋找新樣本的惡意軟體家族或參與者，而是想提供另一種觀點，并決定專注于漏洞利用開發人員撰寫的這幾個功能，從事件回應案例中獲得這個小的64位二進制檔案看起來是個不錯的開始，

該二進制檔案除了利用 CVE-2019-0859 之外什么也沒做，并且它不基于開源的源代碼或POC，由于可執行檔案是由漏洞利用作者（攻擊者）以外的其他人撰寫而成，因此它非常適合指紋識別，此外，可執行檔案與惡意軟體的主要二進制檔案是分離的（一個臭名昭著的犯罪軟體），這讓我們相信這個漏洞不是由惡意軟體開發人員內部開發的，帶著這個希望，我們開始尋找同一作者撰寫的更多的exploit，

我們首先從已經擁有的二進制檔案中收集簡單的資訊（Checkpoint）：

• 字串
• 內部檔案名
• 時間戳
• PDB路徑

第一個結果立即出現了——一個與64位示例完全匹配的32位可執行檔案，具體來說，正如它們的時間戳和嵌入式PDB路徑所顯示的那樣，它們是在同一時間從相同的源代碼中一起編譯的，現在我們有了這兩個樣本，我們就能得出要尋找的東西，

為了對這個漏洞的作者進行指紋識別，我們將目光投向了以下方面：

• 二進制檔案中的獨特工件
  – 硬編碼值（加密常量，“垃圾”值，例如0x11223344）
  – 資料表（通常是特定于版本的配置）
  – 字串（GDI物件名稱：“ MyWindow”、“ MyClass_56”、“ findme1”等）
  – PDB路徑
• 代碼段
  – (1) 獨特的功能實作
  a.系統呼叫包裝器（syscall）
  b.行內匯編
  c.專有加密函式/實作
  – (2) 技術和習慣
  a.首選的泄漏技術（HMValidateHandle、gSharedInfo等）
  b.首選的提升技術（如何執行token替換？）
  c.堆溢位技術（使用AcceleratorTables？Windows？Bitmaps？）
  – (3) 構架
  a.漏洞利用流程（The flow of the exploits）
  – 選項1：幾乎沒有分支的主要漏洞利用流程
  – 選項2：針對不同版本作業系統的多個扭曲和旋鈕
  b.代碼和函式的結構
  – 模塊化：功能分離
  – 結構：分離以清除階段（初始化、配置、噴涂、令牌交換等）
  – 全域變數：哪些資訊存盤在全域變數中？（作業系統版本？列舉作業系統版本？特定欄位偏移量？）
  c.特定于版本的配置
  – 欄位偏移量：哪些欄位特別重要？
  – 首選系統呼叫：系統呼叫的首選集合
  d.提供給客戶的API

對應原文：

帶著這些屬性，回到我們擁有的兩個樣本，并標記了一些我們認為獨特的工件，即使只有兩個小的二進制檔案（本質上是相同的），我們仍然能夠創建搜尋規則來查找該開發人員撰寫的更多示例，令我們驚訝的是，我們能夠找到比想象中更多的東西，

一個接一個的出現了幾十個樣本，隨著每一個樣本的出現，我們改進了搜尋規則和方法，通過對樣本的仔細分析，我們能夠了解哪些樣本利用了哪個CVE，并以此為基礎創建了一個時間表，以了解該漏洞是在暴露之前的0-day漏洞，還是基于補丁擴散和類似技術實作的1-day漏洞，

到目前為止，僅基于我們的指紋識別技術且沒有進一步的情報資訊，我們就可以將10多個CVE歸因于同一個漏洞利用開發人員，后來，公開的報告披露了我們的目標漏洞利用（exploit）銷售者的名稱為——Volodya（又名Volodimir） ，以前稱為BuggiCorp，似乎我們不是唯一跟蹤此漏洞賣家的，卡巴斯基也報道關于他們的一些相關資訊，此外，ESET在VB2019關于Buhtrap的演講中還提到了Volodya的一些重要線索，

根據卡巴斯基的說法，Volodya最初以其 “BuggiCorp” 綽??號成為頭條新聞，當時他們在臭名昭著的Exploit [.]網路犯罪論壇上宣傳了Windows 0-day的待售廣告，起價為9.5萬美元，多年來，價格不斷上漲，他們的一些Windows LPE 0-day漏洞利用軟體的售價高達20萬美元，正如卡巴斯基報告中所發表的，后來得到我們的證實，Volodya將漏洞利用軟體賣給了犯罪軟體和APT團體，我們將在“客戶”一節中詳細討論actor的客戶，

四.我們行動者的漏洞利用

Our actor’s exploits
盡管我們最初的一些狩獵規則需要進行一些微調，但即使是我們得到的即時結果也相當令人驚訝，經過進一步的校準后，我們??找到了許多示例，所有這些示例都是Windows中的本地特權升級（LPE，Local Privilege Escalation）漏洞，從這些樣本中，我們的行動者（actor）能夠確定所利用的CVE串列，

注意：
在對漏洞進行分類時，我們選擇了一種保守的方法來決定一個給定的漏洞是0-day還是1-day，如果其他安全供應商將在野的漏洞歸因于我們的行動者，那么它就是0-day，如果我們發現足夠的證據表明我們的某個樣本的確是利用在外傳播的漏洞，就像供應商在他們的報告中描述的那樣，那么我們也會標記它為0-day，在所有其他情況下，我們將該漏洞標記為1-day，寧愿有較低數量的0-day，而不錯誤計數超過正確的數量，

CVE-2015-2546

• 分類：1-day
• 基本描述：在 xxxSendMessage（tagPOPUPMENU） 中釋放后使用（Use-After-Free）
• 0-day報告供應商：FireEye
• 在以下惡意軟體樣本中發現：Ursnif，Buhtrap

我們的漏洞利用示例使用了與初始報告中所述不同的記憶體整形技術：噴射Windows（spraying Windows）而不是加速器表（Accelerator Tables），此外，我們最早和最基本的攻擊示例包含以下PDB路徑，這表明作者已經知道該漏洞的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利用過
• 在以下惡意軟體樣本中發現：Ursnif

該漏洞利用已用于單個樣本，該樣本還包含前面描述的CVE-2015-2546漏洞，如果目標是Windows 8之前的Windows版本，則選擇此漏洞，否則使用CVE-2015-2546，

CVE-2016-0167

• 分類： 0-day
• 基本描述：在 Win32k!xxxMNDestroyHandler 中釋放后使用（Use-After-Free）
• 0-day報告供應商：FireEye
• 在以下惡意軟體樣本中發現：PUNCHBUGGY

我們的漏洞利用樣本與在野的漏洞利用技術報告完全吻合，

CVE-2016-0165*

• 分類： 1-day
• 基本描述：在 Win32k!xxxMNDestroyHandler 中釋放后使用（Use-After-Free）
• 0-day報告供應商：Kaspersky ，被卡巴斯基發現，但未公開發布任何報告
• 在以下惡意軟體樣本中發現：Ursnif

這是一個有趣的案例，我們方案的0-day（CVE-2016-0167）已于2016年4月由Microsoft修補，該補丁也修復了CVE-2016-0165，該漏洞也被廣泛在外使用，為了尋找新的漏洞進行利用，我們的行動可能對微軟的修補程式進行了不同的修補，并發現了一個認為是修補過的0-day漏洞，此漏洞源于之前漏洞 Win32k!xxxMNDestroyHandler 中修補過的函式，

注意，我們從他們針對該漏洞的漏洞樣本中找到多個跡象表明，該漏洞作者或他們的客戶確定他們已出售了一個針對CVE-2016-0165的漏洞，可悲的是，在分析這個漏洞之后，我們確定這個被利用的漏洞是一個不同的漏洞，

這種困惑可能是由于微軟發布了一個解決多個漏洞的單一修復，而且它們是唯一一個在每個代碼修復與為其發布的CVE之間有完整映射的補丁，

CVE-2016-7255

• 分類： 0-day
• 基本描述：在 NtUserSetWindowLongPtr 中記憶體損壞（Memory corruption）
• 0-day報告供應商：Google ，被谷歌發現，通過技術報告趨勢科技（TrendMicro）
• 在以下惡意軟體樣本中發現：APT28，又叫Fancy Bear或Sednit，后來被使用在 Ursnif，Dreambot，GandCrab，Cerber，Maze 中

我們的漏洞利用樣本完美地與在野漏洞利用技術報告吻合，后來，這個特定的漏洞被不同的勒索軟體參與者廣泛使用，此外，我們還看到了其他針對這個特定漏洞的利用，這些漏洞在1-day期間被賣給了其他勒索軟體參與者，

注意：我們有多個間接證據認為，這個0-day就是那個由BuggiCorp在2016年5月發布到 exploit[.] 著名廣告中提到的漏洞，

CVE-2017-0001

• 分類： 1-day
• 基本描述：在 RemoveFontResourceExW 中釋放后使用（Use-After-Free）
• 0-day報告供應商：N/A. 從來沒有在野被當做0-day利用過
• 在以下惡意軟體樣本中發現：Turla，歸因于Turla，后來被使用在 Ursnif 中

Turla（FireEye）在操作中當作1-day漏洞使用過，

CVE-2017-0263

• 分類： 0-day
• 基本描述：在 win32k!xxxDestroyWindow 中釋放后使用（Use-After-Free）
• 0-day報告供應商：ESET
• 在以下惡意軟體樣本中發現：APT28，又叫Fancy Bear或Sednit

我們的漏洞利用樣本與在野的漏洞利用技術報告完全吻合，

CVE-2018-8641*

• 分類： 1-day
• 基本描述：在 win32k!xxxTrackPopupMenuEx 重復釋放（Double Free）
• 0-day報告供應商：N/A. 從來沒有在野被當做0-day利用過
• 在以下惡意軟體樣本中發現：Magniber

同樣，識別使用過的1-day通常比識別0-day漏洞更難，這一次，我們找不到任何可能暗示參與者認為他們正在利用的漏洞示例，我們發現該漏洞已于2018年12月被微軟修補，在掃描此補丁中解決的漏洞串列后，我們非常確定微軟將此漏洞標記為CVE-2018-8641，但我們無法確認，

2020年6月24日，卡巴斯基在其博客上發表了一份通過大規模漏洞利用工具（the Magnitude exploit kit）分發的漏洞利用攻擊，在他們的博文中，卡巴斯基分析了Magniber使用的LPE漏洞，將其歸因于 Volodya，并預測其可能是CVE-2018-8641，這進一步通過卡巴斯基的獨立結論驗證了我們的初步估計，

CVE-2019-0859

• 分類： 0-day
• 基本描述：在 CreateWindowEx 中釋放后使用（Use-After-Free）
• 0-day報告供應商：Kaspersky
• 在以下惡意軟體樣本中發現：用作一個獨立的組件被注入或加載，我們無法將其歸因于任何特定的APT/惡意軟體

我們的漏洞利用示例與有關野生漏洞利用的技術報告完全吻合，我們的研究始于在客戶網路中發現的這種漏洞利用的單個樣本，在我們后來發現的樣本中，我們可以看清這個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
• 在以下惡意軟體樣本中發現：歸因于 Buhtrap

我們有多個理由相信這是Volodya的另一個0-day漏洞，因為報告中的多個技術細節匹配他們典型的利用方式，此外，，該漏洞報告其中嵌入了以下PDB路徑：

• C:\work\ volodimir_65 \…PDB

然而，這是我們串列中唯一尚未找到樣本的漏洞，因此我們不能確定這一漏洞的歸屬，

CVE-2019-1458

• 分類： 1-day
• 基本描述：在視窗切換時記憶體損壞
• 0-day報告供應商：Kaspersky （初始報告、詳細報告）
• 在以下惡意軟體樣本中發現：歸因于操作 WizardOpium

我們的漏洞利用和技術報告里的漏洞利用不一致，此外，在他們的詳細報告中，卡巴斯基指出“同樣有趣的是，我們在補丁發布一周后就發現了另一個1-day漏洞，這表明利用這個漏洞非常簡單，”事實上，我們的樣本是在卡巴斯基首次報告后的第6天，

最后，通過下表總結了我們列出的11個漏洞：

五.作者指紋

現在，我們從Volodya那里發現了10多個不同的exploit，我們可以更詳細地審查它們，并熟悉actor的作業習慣，從一開始我們就很清楚，我們的參與者可能有一個簡單的模板，他們可以針對不同的漏洞利用程式進行部署，因為每個漏洞利用程式的功能流程甚至不同功能的順序都在大多數漏洞利用程式之間共享，

在本節中，我們將描述一組關鍵特征，這些特征反映了在創建exploit模板時Volodya所做的不同實作選擇，我們將他們的實作與昵稱為PlayBit的另一個exploit撰寫器的實作進行比較，通過這種比較，旨在概述漏洞利用各部分中存在的各種實作選項，從而使每個作者的實作選擇集成為他們思維和作業方式的獨特“簽名”，

PlayBit（又名luxor2008）

使用我們用來搜尋Volodya漏洞的相同技術，我們設法追蹤了PlayBit撰寫的5個Windows LPE 1-day漏洞，以及作者多年來銷售的其他工具，我們從REvil勒索軟體使用的CVE-2018-8453樣本開始，并使用PlayBits的獨特指紋來尋找更多漏洞，

我們發現以下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的更深入分析，以及他們開發和銷售的不同漏洞，將在即將發布的博文中發布，

bool elevate（int target_pid）

Volodya的所有exploit樣本中的API總是相同的，無論它是嵌入在一個惡意軟體樣本中，還是一個獨立的POC，該漏洞都有以下簽名的單一API函式：

• bool elevate(int target_pid)

該漏洞本身并不包括將shellcode注入到另一個行程或任何類似的功能，它向所需的行程授予系統特權，只接受其PID作為引數，

Sleep(200)

該elevate()函式在被惡意軟體呼叫后所做的第一件事，是呼叫Sleep函式休眠200毫秒的固定時間，

為什么Sleep(200)會出現在模板中還不是很清楚，我們懷疑這是為了避免不必要的不穩定，特別是因為這些漏洞是基于時間安排（UAF races），因此，短時間的等待與I/O和記憶體訪問相關的活動結束，可以提高穩定性，

由于這些漏洞是惡意軟體的一部分，在漏洞利用程式執行之前，所有這些與惡意軟體相關的代碼都會導致CPU / 磁盤 / RAM出現短暫的峰值，因此在進行實際漏洞利用之前讓情況有所緩和可能是有意義的，對于短期峰值負載（在啟動新行程，從磁盤讀寫檔案等情況下自然會發生），它應該足足等待200毫秒，盡管我們在最近的示例中注意到這種模式的變化，但是仍然可以在我們發現的9個漏洞中找到該功能，

與PlayBit的比較：PlayBit在其利用中沒有任何此類功能，

作業系統指紋

sleep函式結束后，該漏洞利用程式就會識別并校準目標的Windows版本，以便為盡可能多的OS版本提供支持，從我們的樣本中，作者似乎使用了兩種技術來查詢作業系統，

• (1) 決議ntdll.dll的頭部
  這是最常用的技術，ntdll.dll句柄用于查找 IMAGE_NT_HEADERS 的偏移量，從這里決議 MajorOperatingSystemVersion 和 MinorOperatingSystemVersion 欄位，

• (2) GetVersionEx()
  該技術通常與前一種技術一起使用，僅在2016年至2017年初的樣品中使用，這可能是因為這個API現在已經棄用了，

在這兩種技術中，目標都是查詢作業系統的主版本和次版本，并相應地配置漏洞利用程式的全域變數，雖然大多數的利用都支持多種Windows版本，但Volodya似乎從不關心目標的特定服務包，也不關心它是否是Windows服務器，除了對特定的Windows 10構建版本感興趣之外（僅在CVE-2019-1458漏洞中使用），我們的actor只使用了主要版本和次要版本，僅此而已，

與PlayBit的比較：再次使用GetVersionEx()，通常隨后還要對流程環境塊（PEB）本身的主次編號進行額外決議，如圖7所示，不僅使用PEB代替 ntdll.dll，PlayBit還從GetVersionEx()輸出中提取額外的資訊，如計算機的服務包（Service Pack），甚至檢查目標計算機是否使用服務器作業系統，

這是兩個行動者在操作方式上的明顯區別，它們不僅以不同的方式提取相同的資訊，而且即使它們都利用了相同的漏洞（CVE-2016-7255）， Volodya感興趣的資訊也遠少于PlayBit，

通常，兩個參與者都持有詳細的特定于版本的配置，一旦確定了作業系統版本，他們就從這些配置加載相關資訊，兩者之間的主要區別是：

• Volodya的漏洞利用代碼流很少依賴于作業系統版本
• PlayBit使用了多種依賴于作業系統版本的if-check來進行多重扭曲和旋轉
• 這反過來又影響了它們對確切版本細節的不同興趣

內核地址泄漏

Leaking Kernel Addresses
在絕大多數漏洞利用中，操作者使用內核指標泄漏原語來調整漏洞利用，在除CVE-2019-1458之外的所有漏洞利用中，此漏洞原語都是眾所周知的 HMValidateHandle 技術，

HMValidateHandle()是user32.dll的一個內部未匯出函式，它被各種函式如isMenu()所利用，并可用于獲取所有Windows版本（直到Windows 10 RS4）中不同Window物件的內核地址，這種技術很有名，早在2011年就開始使用了，當時大多數開發教程都選擇專門決議isMenu()來找到HMValidateHandle()的地址，

令人驚訝的是，在數十個用于查找HMValidateHandle()的不同函式中，參與者只是簡單地遵循了著名的教程，并選擇了使用isMenu()，更令人驚訝的是，多年來，這種常見的利用技術仍然非常有效，使得參與者沒有動力通過選擇一個不太為人所知的函式（如CheckMenuRadioItem）來“隱藏”，

泄露給我們的資訊如下：

• 我們視窗的內核地址
• THREAD_INFO（pti欄位）的內核地址

該漏洞利用程序中的多個步驟將使用此資訊：

• 地址在指向 / 創建假的內核結構體時使用
• 確保我們的內核地址是有效的Unicode字串（不包含兩個連續的 ‘\x00’ 位元組）
• 該pti用于定位一個有效的EPROCESS，然后其在令牌交換階段中使用

與PlayBit的比較：PlayBit選擇通過直接訪問用戶模式桌面堆來實作此功能，關于這個主題的更多內容，可以在未來關注這個actor的博文中找到，

Token Swap

該漏洞的最終目標是根據給定的PID引數將系統權限授予所需行程，傳統上，實作這一點的方法是用系統行程的令牌替換 EPROCESS / KPROCESS 結構中的行程令牌，

下面是一些常用的技巧，您會驚訝地發現有多少不同的選項可以實作此功能，

(1) 使用Ps 符號（Using Ps * symbols）
Windows內核包含以下與行程相關的函式和全域變數：

• PsLookupProcessByProcessId
  獲取一個指向行程EPROCESS的指標
• pinitialsystemprocess
  全域變數，它保存著一個指向系統EPROCESS的指標
• psreferencepprimarytoken
  回傳一個指向行程主令牌（token）的指標

通過在內核模式下執行這些函式，一個給定的shellcode可以很容易地定位系統的令牌，但是它仍然不能解決如何在所需的EPROCESS中分配它的問題，為此，有兩種常見的解決方案：

• 使用特定版本的偏移量直接訪問EPROCESS內部的正確偏移量
• 掃描EPROCESS，查找我們自己的指標（通過前面對PsReferencePrimaryToken的呼叫知道），一旦找到匹配的條目，就替換它

這種技術需要以內核模式執行代碼，因此會被SMEP保護阻止，除非部署了額外的SMEP旁路，

(2) 掃描PsList
查找目標行程和系統行程EPROCESS的常見替代方法是掃描雙向鏈接的行程串列，稱為PsList，此技術涉及的步驟為：

• 找到一個初始程序（使用泄漏的pti欄位）
• 掃描PsList以查找具有目標PID的EPROCESS
• 通過查找PID為4或名稱為的方式，掃描PsList以搜索SYSTEM的EPROCESS SYS*
• 提取令牌并將其放置在目標行程中的匹配偏移量中
• 謹慎更新SYSTEM令牌的參考計數

這種技術需要PsList的主令牌和LIST_ENTRY的偏移量，要求它們都存盤在特定于版本的配置中，

該技術的主要優點是，盡管它仍然可以作為一個簡單的shellcode在內核模式下執行（正如CVE-2017-0263所做的那樣），但它也可以在用戶模式下完全實作，為此，您需要兩個利用原語，一個用于任意讀（來自內核空間），另一個用于任意寫（進入內核空間），在用戶模式下運行解決了我們之前詳細介紹的關于SMEP的問題，使這種保護對此類exploit原語毫無用處，

由于令牌是一個參考計數物件，因此正確注冊剛剛添加的參考非常重要，以避免在升級的行程終止時出現藍屏死機(BSOD)，事實上，有兩種不同的參考計數：

• 令牌是一個EX_FAST_REF物件-較低的指標位用作參考計數
• 將anOBJECT_HEADER存盤在令牌之前，并保留另一個參考計數

由于參與者選擇更新后一個參考計數欄位，因此需要執行以下步驟：

• 從標記的指標中屏蔽掉refcount位——在32位行程上應該對齊到8位元組，在64位行程上應該對齊到16位元組
• 減去指向OBJECT_HEADER的ref-count欄位所需的常量
• 讀取值（使用任意讀取的exploit原語）
• 相應地增加它
• 回寫更新后的值

但是，如圖9所示，我們在包含此功能的所有32位漏洞利用程式中發現了以下錯誤，

讀取參考計數值時對齊掩碼對齊到8位元組，而回寫更新后的值時使用不同的掩碼，如果令牌將被存盤在一個對齊到8位元組而不是對齊到16位元組的記憶體地址中，寫操作將更新錯誤的欄位，

雖然CVE-2016-0040和CVE-2016-0167使用的是Ps*技術，但到目前為止，掃描PsList是我們的actor最喜歡的執行令牌交換的方式，在他們的8個漏洞中使用過，在其中的7個例子中，他們使用了用戶模式的任意讀和任意寫，

與PlayBit的比較：在他們的所有樣本中，我們總是看到PlayBit使用Ps*函式進行令牌交換，這一決定迫使參與者實作了一些SMEP繞過，他們將這些繞過集成到CVE-2016-7255和CVE-2018-8453的后續攻擊中，這種設計選擇解釋了為什么參與者不麻煩地實作適當的任意讀取原語作為利用的一部分，PlayBit不使用版本特定的配置來對EPROCESS中的令牌偏移量進行搜索，而是總是掃描EPROCESS來搜索它，通常使用0x300或0x600作為搜索的上限，

值得注意的是，PlayBit在不同的攻擊中使用的記憶體破壞技術也被Duqu 2.0所使用，并在微軟2015年的VB演講中進行了分析，通過這種記憶體破壞，它們可以觸發從內核記憶體到內核記憶體的一些記憶體讀寫，這將在攻擊期間起到幫助作用，

盡管我們可以討論其他方面，例如每個參與者在開發程序中喜歡使用的不同系統呼叫，對Windows和ScrollBars之類的已創建物件的命名約定，但我們相信上面的清單清楚地證明了我們方法的效率/有效性，從上面的串列可以看出，漏洞利用程式的幾乎每個方面都可以幾種不同的方式實作，盡管如此，我們兩個演員在各自的剝削程式上都非常一致，每個人都堅持自己喜歡的方式，

六.客戶分析

在我們的整個研究程序中，我們想把重點放在開發作者本身，無論是Volodya, PlayBit或其他，然而，我們認為，通過觀察這些利用作者的客戶，還有很多東西要學習，Volodya的客戶名單多種多樣，包括Ursnif等銀行家木馬作者，GandCrab、Cerber和Magniber等勒索軟體作者，以及Turla、APT28和Buhtrap等APT組織，有趣的是，我們可以看到Volodya的0-day更有可能賣給APT組織，而1-day則被多個犯罪軟體組織購買，沒有進一步的情報，我們只能假設一旦0-day漏洞被安全行業檢測到，該漏洞就會被回收，并以更低的價格作為非排他性的1-day漏洞出售，

APT的客戶Turla、APT28和Buhtrap，都被普遍認為是俄羅斯的，有趣的是，即使是這些高級團隊也購買漏洞，而不是自己開發，這是另一點，進一步加強了我們的假設，撰寫exploits可以作為一個單獨的和不同的部分惡意軟體處理，

下表總結并顯示了我們能夠歸因于Volodya的CVE，以及使用這些漏洞發現的客戶或惡意軟體組，標有藍色的CVE為0-day，自然更昂貴，左側高亮顯示的組被視為APT，

在回顧我們在一段時間內檢查漏洞樣本時注意到的不同趨勢之前，我們應該強調，我們的可見性有限，因為我們不能討論尚未捕獲的0-day，此外，我們只能嘗試確定樣本的年代，直到它們被捕獲之前，但令人遺憾的是，我們通常基本上確定的是這種漏洞首次在野外被發現的時間，此外，值得一提的是，Volodya在開發第一個漏洞（CVE-2015-2546）時就已經非常專業了，例如，它有一個獨特的任意撰寫原語，我們無法追蹤到任何其他的exploit教程或exploit，

在分析這些漏洞以及我們收集的數十個惡意軟體樣本的程序中，我們注意到一個有趣的變化，早期的Volodya漏洞作為源代碼出售，以嵌入惡意軟體中，后來的漏洞作為接受特定API的外部工具出售，這一變化表明Volodya采取了更多的預防措施，在2015年至2019年期間，我們也注意到Volodya的技術技能有了顯著的提高，當他們變得更好和更有經驗時，Volodya開始使用更有效的任意讀和寫原語，他們甚至修復了這些原語之間的一個bug，

CVE-2015-2546和CVE-2016-0165，此外，這些漏洞的代碼變得更加模塊化，因為大型函式被分割成更小的子例程，同時，他們在各種結構中搜索和訪問特定偏移量的技術也得到了改進，在最近的實作中，它變得更加動態和安全，因為它在Windows的小版本中更好地處理了變化，

這不僅顯示了我們actor的學習曲線和發展，也暗示了他們的技能，找到并可靠地利用Windows內核漏洞的能力并不是那么簡單的，相比之下，PlayBit在2015-2018年期間在這個市場上非常活躍，他們的重點是銷售1-day漏洞，其中之一是0-day的Volodya漏洞（CVE-2016-7255），

七.結論

我們的研究方法是對漏洞利用作者的特征進行指紋識別，然后再將這些屬性用作唯一的狩獵簽名，在跟蹤Volodya和PlayBit的漏洞時，我們兩次部署了此技術，有了這兩個成功的測驗案例，我們相信該研究方法可用于確定其他漏洞利用程式作者，我們建議其他研究人員嘗試我們建議的技術，并將其用作其武器庫中的其他工具，

在這項研究中，我們重點研究了APT攻擊和商品惡意軟體（尤其是勒索軟體）中不同惡意軟體系列所使用或嵌入的漏洞，盡管它們很普遍，但我們經常發現詳盡的惡意軟體報告，而忽略了提及手邊的惡意軟體也利用漏洞來提升其特權的報告，

事實上，我們能夠反復地使用我們的技術來跟蹤16個Windows LPE漏洞，這些漏洞是由兩個不同的角色撰寫和銷售的，這是非常令人驚訝的，考慮到其中15個是在2015-2019年的時間框架內，我們有理由認為它們構成了開發市場的重要份額，特別是針對Windows LPE的開發，

最后，我們不可能說出Windows內核0-day漏洞的總數，這些漏洞正在被廣泛利用，我們仍然可以通過觀察被捕捉到的漏洞來獲得洞見，同時記住這種生存偏差，去年，卡巴斯基報告說，一個單一的參與者分發了超過3個0-day的利用框架，把這些數字加起來，我們發現15個零日漏洞中有8個（超過一半的“市場份額”）是由兩名actor完成的，這意味著我們的研究技術有可能被用于追蹤“可視市場”中的許多actor，如果不是全部的話，

保護建議：Check Point威脅模擬可針對以下威脅提供保護，

• Trojan.Wins.Generic.F
• Trojan.Wins.Generic.G

前文分享：

• [譯] APT分析報告：01.Linux系統下針對性的APT攻擊概述
• [譯] APT分析報告：02.釣魚郵件網址混淆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大資料分析、網路空間安全、逆向分析、APT分析報告、人工智能、Web滲透及攻防技術進行講解，同時分享CCF、SCI、南核北核論文的演算法實作，娜璋之家會更加系統，并重構作者的所有文章，從零講解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