惡意軟體開發檔案解密之根據PDB路徑和其他調試細節來推測相關的惡意活動（上）

新聞 09-16

你是否想過惡意軟體開發者在開發時的最初想法是什麼？他們如何構建他們的工具？他們如何組織他們的開發項目？他們使用什麼樣的計算機和軟體？

通過探索惡意軟體調試信息，我們嘗試回答其中的一些問題。首先，我們發現惡意軟體開發人員為所開發的文件夾和代碼所起的名稱，通常都明確的表明了其所包含的功能。因此，當使用符號調試信息編譯惡意軟體項目時，這些描述性名稱將顯示在PDB路徑中。通過調試信息可以讓我們深入了解惡意軟體開發環境，雖然這些信息不顯眼，但只要最夠細心，我們可以使用PDB路徑和其他調試細節來檢測相關的惡意活動。

人機協議

數字存儲系統徹底改變了我們的世界，但為了利用我們存儲的數據並以有效的方式檢索它，我們必須合理地組織它。為此，用戶要仔細構建目錄，並為文件和文件夾提供唯一的描述性名稱。用戶通常根據文件內容命名文件夾和文件，而計算機會強制用戶根據數據類型，功能和目的標記和注釋其數據。這種人機協議意味著大多數存儲的數數據會具有一些明確的描述文件，同樣，惡意文件也不例外。對於PDB路徑尤其如此，它是惡意軟體中描述開發環境的工具標記。

PDB

在編譯時生成的程序資料庫（PDB）文件，通常稱為「符號文件」，它會存儲關於程序的單個構建的調試信息。 PDB可以存儲符號、地址、函數和資源的名稱以及可以幫助調試程序找到異常或錯誤的確切來源的其他信息。

惡意軟體就是軟體，惡意軟體開發人員就是軟體開發人員。與任何軟體開發人員一樣，惡意軟體開發者通常必須調試他們的代碼，有時還必須在開發過程中創建PDB。如果他們沒有花時間調試他們的惡意軟體，他們的惡意軟體就有可能無法在目標主機上正常運行，或者無法成功地與他們的惡意軟體進行遠程通信。

PDB路徑是如何生成的?

但PDB如何創建並連接到程序呢？讓我們通過惡意軟體開發人員的視角來研究一個PDB路徑的形成（以Smiller為例）。

Smiller有很多編程項目，並在他的計算機上以適當標記的文件夾結構進行組織。此項目用於嵌入在HTML應用程序（HTA）文件中的shellcode載入程序，可以看出，開發人員把它很有邏輯地存儲在文件夾中：

D：\smiller\projects\super_evil_stuff\shellcode\

簡單的「Test」項目代碼文件「Program.cs」，它將一段shellcode和一個可執行的啟動程序嵌入到HTML應用程序(HTA)文件中

通過Windows資源管理器看到的惡意Visual Studio解決方案HtaDotnet和對應的「Test」項目文件夾，文件夾和文件的名稱則明確描述了它們的功能

惡意軟體開發者然後在默認的「Debug」配置中編譯他們的「Test」項目Visual Studio（圖3），並將Test.exe和Test.pdb寫入子文件夾（圖4）。

默認編譯配置的Visual Studio輸出

Test.exe和Test.pdb被寫入代碼項目文件夾的默認子文件夾

在Test.pdb文件（圖5）中，引用了源代碼文件的原始路徑以及用於調試的其他二進位信息。

Test.pdb包含二進位調試信息和對原始源代碼文件的引用，以便在調試時使用

在編譯期間，鏈接程序通過在IMAGE_DEBUG_DIRECTORY中添加一個指定調試信息類型的條目，將PDB文件與構建的可執行文件相關聯。在本文的示例中，調試類型是CodeView，因此PDB路徑嵌入在文件的IMAGE_DEBUG_TYPE_CODEVIEW部分下。這使調試器能夠在調試Test.exe時找到正確的PDB文件Test.pdb。

PEview實用程序中顯示的Test.exe，它可以輕鬆地從可執行文件的IMAGE_DEBUG_TYPE_CODEVIEW部分解析出PDB路徑

CodeView調試信息中的PDB路徑

CodeView結構

調試信息的確切格式可能因編譯器和鏈接器以及軟體開發工具的現代化程度而異。CodeView調試信息存儲在IMAGE_DEBUG_TYPE_CODEVIEW下面的結構中：

圖7：CodeView調試目錄信息的結構

完整與部分PDB路徑

通常有兩種CodeView PDB路徑，一種是完全限定的目錄路徑，另一種是部分限定的目錄路徑，它們只指定PDB文件的名稱。在這兩種情況下，都包含擴展名為. PDB的PDB文件的名稱，以確保調試器為程序找到正確的PDB。

部分限定的PDB路徑將只列出PDB文件名，例如：

Test.pdb

完全限定的PDB路徑通常以卷驅動器號和PDB文件名的目錄路徑開頭，例如：

D：\smiller\projects\super_evil_stuff\shellcode\Test\obj\Debug\Test.pdb

通常，本機Windows可執行程序使用部分限定的PDB路徑，因為許多調試PDB文件在Microsoft公共符號伺服器上是公開可用的，因此在符號路徑（PDB路徑）中不需要完全限定的路徑。在本文中，我們將主要關注完全限定的PDB路徑。

調查惡意軟體中的PDB路徑

在與APT41有無數連接的Shadowhammer操作中，每個示例都有一個簡單但描述性的PDB路徑：

D：\C \AsusShellCode\Release\AsusShellCode.pdb

可以看出，這個命名非常有意義。該惡意軟體旨在偽裝成華碩公司的軟體，傳播惡意的shellcode，惡意軟體開發人員根據惡意軟體本身的功能和角色為該項目命名。

如果我們接受人機協定的約定，迫使開發人員採用這些命名約定，那麼我們認為這些約定將適用於其他攻擊者、惡意軟體家族和入侵操作。一些研究團隊喜歡從入侵集中獲取看似無害的特性，並判斷這些特性的攻擊性。比如什麼是正常的，什麼是不正常的?什麼是全球流行的攻擊，什麼是罕見的攻擊?惡意軟體開發者的做法與非惡意軟體開發人員的做法有何不同？我們可以做出哪些假設並加以衡量?

出於好奇心，我們將CodeView調試信息結構調整為正則表達式(圖8)，並開發了Yara規則(圖9)來調查數據集。這幫助我們識別共性，並使我們能夠僅根據PDB路徑字元串中的功能查看哪些威脅參與者和惡意軟體系列可「檢測」。

可執行文件中PDB7調試信息的perl兼容正則表達式(PCRE)，其中以包含特定的關鍵字元

模板Yara規則，用於搜索與關鍵字匹配的PDB文件的可執行文件

PDB路徑展示：惡意軟體命名約定

我們在事件響應和惡意軟體庫中調查了1000多萬個樣本，發現許多常見的PDB路徑關鍵詞似乎來自不同的來源、受害者、受影響地區、受影響行業和參與者動機。為了幫助闡明惡意軟體開發人員的廣泛共性，我們詳細介紹了一些較強的關鍵字，以及示例PDB路徑，其中包含表示惡意軟體家族和威脅組，其中至少有一個示例具有適用的關鍵字。

請注意，示例路徑和表示的惡意軟體家族和組是從整個數據集中選擇的，它們不一定相互關聯或以其他方式關聯。這是為了說明PDB路徑與關鍵字的廣泛存在，以及惡意軟體開發人員如何在不考慮來源、目標和動機的情況下，最終在命名中使用一些相同的單詞。我們認為，這種共性增加了惡意軟體的攻擊面，並為檢測和搜索帶來了新的機會。

PDB路徑關鍵字非常普遍

PDB路徑中選擇的常見關鍵字，包括觀察到的惡意組和軟體家族和示例

PDB路徑展示：可疑的開發人員環境術語

通常用於描述惡意軟體的關鍵字的強度足以引起警告，但是PDB路徑中還有其他一些常見的術語或特性，它們可能表明可執行文件是在非企業設置中編譯的。例如，任何包含「Users」目錄的PDB路徑都可以告訴你，該可執行文件可能是在Windows Vista/7/10上編譯的，並且可能不代表「官方」或「商業」開發環境。術語「用戶」在保真度上比「shellcode」弱得多，甚至更低，但正如我們下面所演示的，這些術語確實存在於許多惡意軟體中，可以用於微弱的檢測信號。

PDB路徑術語的普遍性

PDB路徑中常見術語的選擇，以及觀察到的惡意組和軟體家族以及示例

PDB路徑展示：探索異常

除了關鍵字和術語之外，我們還發現了一些不常見的特性，這些特性，可能對未來的研究和檢測機會感興趣。

非ascii字元

在我們的數據集中，任何非ascii字元的PDB路徑的惡意軟體與非惡意軟體的比率都很高，此信號的強弱僅僅是因為我們的惡意軟體語料庫和客戶群中存在數據偏差。但是，如果此數據偏差是一致的，我們可以在PDB路徑中使用非ASCII字元作為可執行文件值得進一步審查的信號。在主要使用ASCII的組織中，我們認為這將是一個強烈的信號。下面我們在Yara中表達這種技術的邏輯：

rule ConventionEngine_Anomaly_NonAscii

{

meta:

author = "@stvemillertime"

strings:

$pcre = /RSDS[\x00-\xFF][a-zA-Z]:\\[\x00-\xFF][^\x00-\x7F][\x00-\xFF]\.pdb\x00/

condition:

(uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $pcre

}

單個文件中的多個路徑

每個編譯的程序應該只有一個PDB路徑。單個對象中存在多個PDB路徑表示該對象具有子文件可執行文件，你可以從中推斷父對象具有「刪除」或「安裝」其他文件的能力。雖然作為dropper或安裝程序本身並不是惡意的，但是將這些分類應用於文件對象的替代方法可能有助於表現惡意活動。在此示例中，我們還可以使用Yara搜索此功能：

rule ConventionEngine_Anomaly_MultiPDB_Triple

{

meta:

author = "@stvemillertime"

strings:

$anchor = "RSDS"

$pcre = /RSDS[\x00-\xFF][a-zA-Z]:\\[\x00-\xFF]\.pdb\x00/

condition:

(uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and #anchor == 3 and #pcre == 3

}

在調試部分之外

編譯文件時，調試信息的條目位於IMAGE_DEBUG_DIRECTORY中。與在單個文件中看到多個PDB路徑類似，當我們在沒有調試目錄的可執行文件中看到調試信息時，可以推斷該文件具有子文件可執行文件，並且可能具有dropper或安裝程序功能。在此規則中,我們使用Yara的PE 模塊來檢查IMAGE_DIRECTORY_ENTRY_DEBUG條目的相對虛擬地址（RVA），如果是零,我們可以假定沒有調試條目,因此CodeView PDB路徑的存在表明有子文件。

rule ConventionEngine_Anomaly_OutsideOfDebug

{

meta:

author = "@stvemillertime"

description = "Searching for PE files with PDB path keywords, terms or anomalies."

strings:

$anchor = "RSDS"

$pcre = /RSDS[\x00-\xFF][a-zA-Z]:\\[\x00-\xFF]\.pdb\x00/

condition:

(uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $anchor and $pcre and pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_DEBUG].virtual_address == 0

}

含有null的PDB路徑

在典型的CodeView部分中，我們將看到「RSDS」標頭、16位元組的GUID、4位元組的「age」和PDB路徑字元串。然而，我們已經確定了大量的惡意軟體樣本，其中嵌入的PDB路徑區域為空。在這個例子中，我們可以很容易地看到CodeView調試結構，包括header、GUID和age，然後是段的末尾的null值。

00147880: 52 53 44 53 18 c8 03 4e 8c 0c 4f 46 be b2 ed 9e : RSDS...N..OF....

00147890: c1 9f a3 f4 01 00 00 00 00 00 00 00 00 00 00 00 : ................

001478a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................

001478b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................

001478c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................

對於如何以及為什麼CodeView PDB路徑可能為null，有幾種可能性，但是在故意篡改的情況下，為了刪除工具標記，最簡單的方法是用\x00s手動覆蓋PDB路徑。通過十六進位編輯器手工編輯和覆蓋的風險是，這樣做很費力，並且可能引入其他靜態異常，例如校驗和錯誤。

另一個最簡單的方法是使用一個實用程序，該實用程序設計用於刪除可執行文件中的調試構件。一個典型的例子是「peupdate」，它不僅用於提取或構造PDB路徑信息，還可以重新計算校驗和，並刪除Rich標頭信息。下面我們將會演示如何使用peupdate刪除PDB路徑。