眾所周知，攻擊者將合法的數字證照應用於其惡意軟體，這大概是為了躲避基本的簽名驗證程式。Petya勒索病毒便是這種情況。作為一名逆向工程師或red team的開發者，瞭解哪些合法的簽名可以被應用到其他的未簽名程式碼以及攻擊者提供的程式碼的方法。這篇部落格將會給出程式碼簽名機制、二進位制數字簽名，以及對數字證照應用於未簽名的PE檔案的相關技術背景的介紹。不久，你將會在我下個月釋出的研究中看到相關技術的聯絡。

背景

對PE檔案（如exe、dll、sys等檔案）進行簽名是什麼意思呢？一個比較簡明的答案就是選擇相應的PE檔案，右鍵單擊之後，檢視檔案屬性，如果存在“數字簽名”選項卡，則表示已經該檔案已經被簽名。當你看到檔案屬性中的這個“數字簽名”選項卡的時候，實際上意味著該PE檔案是Authenticode簽名的，在這個檔案中有一個二進位制的資料包，其中包括一個證照和這個檔案的簽名雜湊值（更具體點說，Authenticode雜湊值就是在雜湊計算中去除PE頭的那部分資料的雜湊值）。儲存Authenticode簽名的格式在PE程式碼簽名規範【見附件1】中有詳細說明。

然而，很多本應該被簽名的檔案（以notepad.exe為例），事實上卻並沒有我們所說的“數字簽名”選項卡。那這是否意味著該檔案沒有簽名，並且微軟也執行了這些未簽名的程式碼呢？這個要視情況而定。雖然notepad.exe本身沒有嵌入Authenticode簽名，但實際上它通過目錄簽名這種方式進行過簽名。Windows包含由許多目錄檔案組成的目錄儲存庫，基本上只是Authenticode的雜湊表。然後，每個目錄檔案都被簽名，以證明任何具有匹配雜湊的檔案源自目錄檔案的簽名者（基本上都是Microsoft的程式）。因此，當Explorer UI不嘗試查詢目錄簽名時，幾乎其他的所有簽名驗證工具都將執行目錄查詢。在PowerShell和Sysinternals Sigcheck中獲取可以Authenticode簽名。

注：目錄檔案儲存在%windir%\System32\CatRoot{F750E6C3-38EE-11D1-85E5-00C04FC295EE}

在上述螢幕截圖中，SignatureType屬性指示notepad.exe是目錄簽名（”Catalog”）。還值得注意的是IsOSBinary屬性。雖然具體的實現沒有文件化，但如果簽名連結到幾個已知的，雜湊的Microsoft根證照之一，則將顯示“True”。有興趣瞭解更多有關如何工作的人可以逆向CertVerifyCertificateChainPolicy函式【https://msdn.microsoft.com/en-us/library/windows/desktop/aa377163(v=vs.85).aspx】。

Sigcheck工具使用“-i”引數，執行目錄證照驗證，並顯示包含匹配的Authenticode雜湊的目錄檔案路徑。“-h”引數還將計算並顯示PE檔案的SHA1和SHA256形式的Authenticode雜湊（分別為PESHA1和PE256）：

sigcheck -q -h -i C:\Windows\System32\notepad.exec:\windows\system32\notepad.exe:Verified:       SignedCatalog: 
       
C:\WINDOWS\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Microsoft-Windows-Client-Features-Package-AutoMerged-shell~31bf3856ad364e35~amd64~~10.0.15063.0.catSigners:Microsoft WindowsStatus:         ValidValid Usage:    NT5 Crypto, Code SigningSerial Number:  33 00 00 01 06 6E C3 25 C4 31 C9 18 0E 00 00 00 00 01 06Thumbprint:     AFDD80C4EBF2F61D3943F18BB566D6AA6F6E5033Algorithm:      1.2.840.113549.1.1.11Valid from:     1:39 PM 10/11/2016Valid to:       1:39 PM 1/11/2018Microsoft Windows Production PCA 2011Status:         ValidValid Usage:    AllSerial Number:  61 07 76 56 00 00 00 00 00 08Thumbprint:     580A6F4CC4E4B669B9EBDC1B2B3E087B80D0678DAlgorithm:      1.2.840.113549.1.1.11Valid from:     11:41 AM 10/19/2011Valid to:       11:51 AM 10/19/2026Microsoft Root Certificate Authority 2010Status:         ValidValid Usage:    AllSerial Number:  28 CC 3A 25 BF BA 44 AC 44 9A9B 58 6B 43 39 AAThumbprint:     3B1EFD3A66EA28B16697394703A72CA340A05BD5Algorithm:      1.2.840.113549.1.1.11Valid from:     2:57 PM 6/23/2010Valid to:       3:04 PM 6/23/2035Signing date:   1:02 PM 3/18/2017Counter Signers:Microsoft Time-Stamp ServiceStatus:         ValidValid Usage:    Timestamp SigningSerial Number:  33 00 00 00 B3 39 BB D4 12 93 15 A9 FE 00 00 00 00 00 B3Thumbprint:     BEF9C1F4DA0F153FF0900303BE78A59ADA8ADCB9Algorithm:      1.2.840.113549.1.1.11Valid from:     10:56 AM 9/7/2016Valid to:       10:56 AM 9/7/2018Microsoft Time-Stamp PCA 2010Status:         ValidValid Usage:    AllSerial Number:  61 09 81 2A 00 00 00 00 00 02Thumbprint:     2AA752FE64C49ABE82913C463529CF10FF2F04EEAlgorithm:      1.2.840.113549.1.1.11Valid from:     2:36 PM 7/1/2010Valid to:       2:46 PM 7/1/2025Microsoft Root Certificate Authority 2010Status:         ValidValid Usage:    AllSerial Number:  28 CC 3A 25 BF BA 44 AC 44 9A 9B 58 6B 43 39 AAThumbprint:     3B1EFD3A66EA28B16697394703A72CA340A05BD5Algorithm:      1.2.840.113549.1.1.11Valid from:     2:57 PM 6/23/2010Valid to:       3:04 PM 6/23/2035Publisher:      Microsoft WindowsDescription:    NotepadProduct:        Microsoft« Windows« Operating SystemProd version:   10.0.15063.0File version:   10.0.15063.0 (WinBuild.160101.0800)MachineType:    64-bitMD5:    F60A9D3A9461F68DE0FCCEBB0C6CB31ASHA1:   2302BA58181F3C4E1E44A47A7D214EE9397CF2BAPESHA1: ACCE8ADCE9DDDE507EAE295DBB37683CA272DB9EPE256:  0C67E3923EDA8154A89ADCA8A6BF47DF7C07D40BB41963DEB16ACBCF2E54803ESHA256: C84C361B7F5DBAEAC93828E60D2B54704D3E7CA84148BAFDA632F9AD6CDC96FAIMP:    645E8D8B0AEA808FF16DAA70D6EE720E

理解Authenticode雜湊的概念會使你比較容易的在目錄檔案中找到相應的條目。你也可以雙擊目錄檔案來檢視其它條目。我還編寫了CatalogTools【https://github.com/mattifestation/CatalogTools】，這是用於解析目錄檔案的PowerShell模組。在“hint”後設資料欄位說明了notepad.exe確實是相應的條目：

數字簽名的二進位制格式

現在你已經瞭解了可以對PE檔案進行簽名的方法（Authenticode簽名和目錄簽名），那麼對簽名的二進位制格式有所瞭解也是十分必要的。無論是Authenticode簽名還是目錄簽名，其簽名都儲存PKCS＃7【https://tools.ietf.org/html/rfc2315】簽名資料中，這種資料是一種ASN.1格式的二進位制資料。ASN.1只是一個標準，用於說明應該儲存不同資料型別的二進位制資料。在觀察/解析數字簽名的位元組之前，你必須首先知道它如何儲存在檔案中。目錄檔案很簡單，因為檔案本身由原始的PKCS＃7資料組成。 網上有線上的ASN.1解析器【https://lapo.it/asn1js/】解析ASN.1資料，並以直觀的方式呈現出來。例如，嘗試將包含notepad.exe的雜湊的目錄檔案載入到解析器中，你將可以看到一個層次分明的資料佈局的檢視。 以下是解析輸出的程式碼段：

ASN.1編碼資料中的每個屬性都以物件識別符號（OID，object identifier）開頭，這是一個唯一的數字序列，用於標識以下資料的型別。上述程式碼段中值得注意的OID如下：

1.2.840.113549.1.7.2- 這表明PKCS＃7簽名資料 – 後面跟著Authenticode和目錄簽名程式碼。

1.3.6.1.4.1.311.12.1.1- 這表明後面會跟著目錄檔案雜湊資料

建議想要深入理解的讀者花點時間探索數字簽名中包含的所有欄位。然而，圖中的欄位都不在本部落格的討論範圍之內。這裡【https://support.microsoft.com/en-us/help/287547/object-ids-associated-with-microsoft-cryptography】列出了附加的加密/簽名相關OID。

嵌入式PE Authenticode簽名檢索

具有嵌入式Authenticode簽名的PE檔案中的數字簽名資料附加在檔案末尾（這裡說的是格式正常的的PE檔案）。作業系統顯然需要一些資訊來檢索嵌入式簽名的確切偏移量和大小。 給大家介紹一款我最喜歡PE解析/編輯工具CFF Explorer【http://www.ntcore.com/exsuite.php】，下面是使用CFF Explorer來解析kernel32.dll：

嵌入式數字簽名的偏移量和大小儲存在PE的可選頭內的“security directory”陣列中的“data directories”偏移量中。

資料目錄包含PE檔案中的各種結構的偏移量和大小——匯出表，匯入表，重定位表等。資料目錄中的所有偏移量都是相對虛擬地址（RVA），這意味著它們是載入時PE相應部分的在記憶體中的偏移量。只有一個例外——安全目錄表將其偏移量儲存為檔案偏移量，這是因為Windows載入程式實際上並沒有在記憶體中載入安全目錄表的內容。

安全目錄表的二進位制資料是WIN_CERTIFICATE結構【https://msdn.microsoft.com/en-us/library/windows/desktop/dn582059(v=vs.85).aspx】的。下面是kernel32.dll在010Editor中解析的結果【https://gist.github.com/mattifestation/d10f91859bd0dffd4a539945ae02eccb，相應檔案見附件2 】（檔案偏移是0x000A9600）：

PE檔案的Authenticode簽名應始終具有WIN_CERT_TYPE_PKCS_SIGNED_DA他的wRevision。後續的位元組陣列是與目錄檔案內容相同的PKCS＃7以及ASN.1編碼簽名資料。唯一的區別是你應該找不到1.3.6.1.4.1.311.12.1.1這樣的OID，因為這表明存在的目錄雜湊簽名。

在網上線上的ASN.1解碼器解析出的原始bCertificate資料證實我們正在處理正確的PKCS＃7的資料：

數字簽名對未簽名PE檔案的應用

現在你已經瞭解了數字簽名的二進位制格式和儲存位置的基本概念，接下來可以開始將現有簽名應用於未簽名的程式碼。

嵌入式簽名認證的應用

將嵌入的Authenticode簽名從簽名檔案應用到未簽名的PE檔案是非常簡單的。雖然這個過程可以自動化完成，這裡我將用十六進位制編輯器和CFF Explorer來講解如何手動實現。

步驟1:識別要竊取的Authenticode簽名。在例項中，我將使用kernel32.dll中的一個簽名作為演示。

步驟2:識別“security directory”中的WIN_CERTIFICATE結構的偏移量和大小。

可以看到上述截圖中的檔案偏移量為0x000A9600，大小為0x00003A68。

步驟3:在一款十六進位制編輯器中開啟kernel32.dll，從偏移量0xA9600處選擇0x3A68位元組的資料，然後複製這些資料。

步驟4：在十六進位制編輯器中開啟你的未簽名PE（在此示例中為HelloWorld.exe），滾動到最後，貼上從kernel32.dll複製的3A68位元組的資料。 注意簽名開頭的檔案偏移量（在我的機器環境下為0x00000E00）。貼上完資料之後記得儲存檔案。

步驟5：在CFF

Explorer中開啟HelloWorld.exe，並更新安全目錄以指向應用的數字簽名：offset - 0x00000E00，size -

0x00003A68。 進行修改後儲存檔案。 忽略“無效”警告，這是因為CFF

Explorer不將安全目錄視為檔案偏移量，並在嘗試引用資料所在的位置時發出警告。

這就完成了所有操作。現在，簽名驗證實用程式將正確解析和顯示簽名。 唯一需要注意的是，它們將報告簽名無效，因為所計算的檔案的Authenticode與證照中儲存的簽名雜湊的Authenticode不匹配。

現在，如果你想知道為什麼SignerCertificate指紋符號不匹配，那麼你是一個精明的讀者。考慮到我們應用了相同的簽名，為什麼證照指紋不符合？這是因為Get-AuthenticodeSignature首先嚐試對kernel32.dll進行目錄檔案查詢。在這種情況下，它找到了kernel32.dll的目錄條目，並顯示目錄檔案的簽名者的簽名資訊。kernel32.dll也是Authenticode簽名的。

所以要驗證Authenticode雜湊的指紋值是否相同，請臨時停止CryptSvc服務，該服務負責執行目錄雜湊查詢的服務。如此，你將看到指紋值匹配。

這表示目錄雜湊是使用不同的程式碼簽名證照用於簽署kernel32.dll本身的證照。

目錄簽名對PE檔案的應用

實際上，CryptSvc一直在執行，並且將會執行目錄查詢。假設你想要注意OPSEC，並匹配用於簽署目標二進位制檔案的相同證照。事實證明，您可以通過在WIN_CERTIFICATE結構中交換bCertificate的內容並相應地更新dwLength來將目錄檔案的內容實際應用於嵌入式PE簽名。 可以跟著後續的例項一起操作。請注意，我們的目標（在本例項中）是將Authenticode簽名應用於我們的無符號二進位制檔案，與用於對包含的目錄檔案進行簽名的二進位制檔案相同：本例項中，證照指紋為：AFDD80C4EBF2F61D3943F18BB566D6AA6F6E5033。

步驟1：識別包含目標二進位制檔案的Authenticode雜湊的目錄檔案——kernel32.dll。 如果一個檔案是Authenticode簽名的，Sigcheck工具將無法解析目錄檔案。然而，Signtool（包括在Windows SDK中）可以做到。

步驟2：在十六進位制編輯器中開啟目錄檔案，並獲取檔案大小為0x000137C7

步驟3：我們將在十六進位制編輯器中手動構造一個WIN_CERTIFICATE結構。我們來看看我們提供的每個成員:

dwLength：這是WIN_CERTIFICATE結構的總長度，即bCertificate位元組加上其他欄位的大小=4（DWORD大小）+ 2（WORD大小）+ 2（WORD大小）+ 0x000137C7（bCertificate——.cat檔案的檔案大小）=0x000137CF。

wRevision：這將是0x0200來表示WIN_CERT_REVISION_2_0。

wCertificateType：這將是0x0002來表示WIN_CERT_TYPE_PKCS_SIGNED_DATA。

bCertificate:由目錄檔案的原始位元組組成。

在十六進位制編輯器中製作資料時，請注意資料以小端格式儲存。

步驟4：複製所有WIN_ERTIFICATE的所有位元組，附加到未簽名的PE的末尾，並相應地更新安全目錄的偏移量和大小。

現在，假設你的計算和對齊是正確的，看看與目錄檔案的指紋匹配情況！

這篇博文中提出的技術，希望可以引起一些人考慮如何檢測數字簽名的濫用。雖然我沒有徹底研究清楚簽名的啟發，但我只是提出一系列問題，以期待能夠激勵他人開始調查和撰寫檢測潛在的簽名異常：

對於合法簽名的Microsoft PE檔案中PE時間戳和證照有效期之間是否存在任何相關性？攻擊者提供的程式碼的PE時間戳偏離上述相關性嗎？

閱讀本文後，你對一個一個具有雜湊不匹配的“簽名”檔案的信任級別是什麼級別呢？

你將如何檢測具有由目錄檔案組成的嵌入式Authenticode簽名的PE檔案？提示：前面提到的特定OID可能是有用的。

如何在不同的系統上驗證目錄簽名檔案的簽名？

停止/禁用的CryptSvc服務對執行本地簽名驗證的安全產品有什麼影響？如果發生這種情況，那麼所有意圖和目的的大多數系統檔案將不再被簽名。

我看到的每一個合法的PE填充在一個0x10位元組的邊界。我在示例中將目錄內容應用於Authenticode簽名的示例不是0x10位元組對齊。

如何區分合法的Microsoft數字簽名和所有證照屬性應用於自簽名證照的簽名？

如果在數字簽名之後附加資料，該怎麼辦？這在過去一直被濫用。

建議英特爾的專家應該在使用不同的證照調查相同的程式碼時，找到Authenticode雜湊成為一個有趣的實驗方向。VirusTotal將其提供為“Authentihash”值：即使用“sigcheck -h”計算的雜湊值。如果我正在調查在VirusTotal中的一個Authentihash上有多次命中的樣本的變體，我會發現這非常有趣。

本文由看雪翻譯小組 skeep 編譯，來源exploitmonday@mattifestation  轉載請註明來自看雪社群