實戰｜勒索病毒介紹及解密

  Sodinokibi勒索病毒簡介 

Sodinokibi 很可能由隸屬于臭名昭著的 GandCrab 勒索軟件家族的攻擊者分發，根據 GandCrab 首次出現的地下論壇，該家族應該很快就會退休。

Sodinokibi 勒索軟件利用 Oracle WebLogic 漏洞 (CVE-2019-2725) 訪問受害者的機器。一旦進入，惡意軟件會嘗試以提升的用戶權限執行自身，以便不受任何限制地訪問系統上的所有文件和資源。

Sodinokibi 試圖避免感染來自伊朗、俄羅斯和其他前蘇聯國家的計算機。

這種勒索軟件使用 AES 和 Salsa20 算法來加密用戶的文件，AES 用于加密發送到控制服務器的會話密鑰和數據，用戶文件使用 Salsa20 加密進行加密。

Sodinokibi 使用橢圓曲線 Diffie-Hellman 密鑰交換算法來生成和傳播加密密鑰。

一旦它滲透到一臺機器，它就會清除備份文件夾中的所有文件。

目前，勒索軟件需要交付贖金要求的BTC才能重新獲得對加密文件的訪問權限。他們聲稱應在四天內支付這筆款項，否則贖金要求將增加一倍。 

它是怎么運行的

我們分析的 Sodinokibi 勒索軟件樣本是使用自定義打包程序打包的。 即使在成功解包之后，主要的 Sodinokibi 代碼似乎也沒有太多可讀的字符串。 它也沒有任何系統庫和 API 的導入，這意味著依賴于可讀字符串和導入的 API 表的靜態 殺毒軟件掃描器將很難檢測到它。

API 名稱和其他必需的字符串在其運行時使用 RC4 算法解密。 為了使反病毒軟件的情況更具挑戰性，大多數對字符串的操作都是使用字符串的 DJB 哈希值而不是字符串本身來執行的。

初始化

Sodinokibi 首先構建一個動態導入表，并在互斥鎖的幫助下確保這是系統上當前運行的唯一實例。一旦互斥檢查通過，它就會使用 RC4 解密二進制文件中存儲的 JSON 配置，并檢查布爾鍵值“exp”。如果設置為“true”，Sodinokibi 將嘗試運行漏洞利用。在我們的例子中，“exp”鍵的值被設置為 true，所以它繼續運行漏洞利用函數。

圖 1：解密的 JSON 配置

負責運行漏洞利用的代碼首先檢查機器上是否應用了 2018 年 9 月 11 日的補丁 (KB4457138)。此補丁解決了下面提到的多個漏洞。如果未檢測到補丁，勒索軟件會根據平臺架構繼續執行 32 位或 64 位版本的 shellcode。我們認為它試圖通過利用 CVE-2018-8440 來提升其特權。

圖 2：片段 1

補丁 KB4457138 解決的漏洞如下表所示：

KB4457138 解決的漏洞

CVE-2018-8457 CVE-2018-8335 CVE-2018-8424 CVE-2018-8455 CVE-2018-8468 CVE-2018-8447

CVE-2018-8475 CVE-2018-8271 CVE-2018-8440 CVE-2018-8464 CVE-2018-8469 CVE-2018-8421

CVE-2018-8442 CVE-2018-8367 CVE-2018-8443 CVE-2018-8465 CVE-2018-8419 CVE-2018-8466

CVE-2018-8410 CVE-2018-8467 CVE-2018-8462 CVE-2018-8452 CVE-2018-8446 CVE-2018-8449

CVE-2018-8420 CVE-2018-8433 CVE-2018-8438 CVE-2018-8435 CVE-2018-8456 CVE-2018-8354

CVE-2018-8434 CVE-2018-8470 CVE-2018-8332 CVE-2018-0965 CVE-2018-8315 CVE-2018-8439

CVE-2018-8392 CVE-2018-8425 CVE-2018-8393

如果系統沒有漏洞并且進程仍然以受限用戶身份運行，它將使用 RUNAS 命令啟動另一個具有管理權限的實例，如果當前實例以受限權限運行，則終止當前實例。完整的流程可以在下面的代碼中看到。

圖 3

Sodinokibi 在管理員模式下成功啟動后，它會根據 JSON 配置中的“bro”鍵和國家/地區進行額外的預檢查。它將根據計算機的區域設置盡量不感染來自以下國家/地區的計算機。

圖4：匹配語言 ID

豁免國家名單

羅馬尼亞 俄羅斯 烏克蘭 白俄羅斯 愛沙尼亞 拉脫維亞 立陶宛 塔吉克斯坦 伊朗

亞美尼亞 阿塞拜疆 格魯吉亞 哈薩克斯坦 吉爾吉斯斯坦 土庫曼斯坦 烏茲別克斯坦 韃靼斯坦

通過預檢查后，它會終止 mysql.exe 進程（如果它正在運行），以便它可以訪問 MySQL 文件進行加密，然后使用 vssadmin 刪除所有 Windows SHADOW COPIES（Windows 內置備份機制），并禁用 Windows使用 bcdedit（啟動策略編輯器）恢復，如下所示：

vssadmin.exe 刪除陰影 /All /Quiet & bcedit /set {default} recoveryenabled No & bcedit /set {default} bootstatuspolice ignorealfailures

圖 5

在加密用戶文件之前，Sodinokibi 會在整個文件系統和網絡共享中搜索所有名為“backup”的目錄并將其清除。有趣的是，在擦除此目錄中的所有文件之前，它會用隨機字節覆蓋內容，從而無法恢復文件。幸運的是，Acronis Backup 文件無法輕易刪除，因為它們使用內核模式驅動程序進行保護，以阻止勒索軟件進行此類非法刪除。

密鑰生成

Sodinokibi 使用橢圓曲線 Di?e–Hellman (ECDH) 密鑰生成和交換算法來生成私鑰-公鑰對。 它使用它來生成一個共享秘密，該秘密將用作對稱加密算法 AES 和 Salsa20 的密鑰，這些算法用于

加密不同類型的數據。

?AES 加密用于加密私鑰-公鑰對的私鑰，該私鑰在本地生成

用戶的機器以及通過網絡發送的數據。

? 另一方面，Salsa20 用于加密用戶文件。

Sodinokibi 附帶兩個不同的公鑰，一個作為 JSON 配置的一部分，另一個嵌入在二進制文件本身中。 這些公鑰將用于加密本地生成的私鑰。 下面我們詳細介紹密鑰生成和加密過程中包含的步驟。

步驟1.在本地機器上生成會話私有（秘密，隨機數）和公鑰對。

圖 6：生成本地公鑰和私鑰

使用 JSON 配置中的公鑰加密步驟 1 中的私鑰

步驟 2. 生成另一個私鑰和公鑰對。

步驟 3. 使用步驟 2 中的私鑰和 JSON 中的公鑰（pk 密鑰值）生成共享密鑰并對其進行散列以生成對稱密鑰。

圖 7：使用共享密鑰生成對稱密鑰

步驟 4. 生成一個 16 字節的 IV（初始化向量）。

步驟 5. 使用步驟 3 和步驟 4 中生成的密鑰和 IV 使用 AES 加密對步驟 1 中生成的私鑰進行加密。

步驟 6. 計算步驟 5 中生成的加密私鑰的 CRC32。

步驟 7. 在包含來自步驟 5 的加密私鑰的緩沖區的末尾附加 IV 和 CRC32。

步驟 8. 將此緩沖區保存到內存中標記為“sk_key”的映射文件偏移量。

圖 8：使用攻擊者的公鑰加密第一步中的私鑰

使用嵌入在二進制文件中的公鑰加密步驟 1 中的私鑰

步驟 9. 使用嵌入在步驟 3 的二進制文件中的不同公鑰重復步驟 2 到 7。

步驟 10. 將此緩沖區保存到內存中標記為“0_key”的映射文件偏移量

sk_key、0_key 和 pk_key 根據訪問權限分別寫入以下注冊表項。

HKLM\SOFTWARE\recfg\sk_key OR HKCU\SOFTWARE\recfg\sk_key HKLM\SOFTWARE\recfg\0_key OR HKCU\SOFTWARE\recfg\0_key HKLM\SOFTWARE\recfg\pk_key OR HKCU\SOFTWARE\recfg\pk_key

圖 9：注冊表中的加密密鑰為 Salsa20 生成每個文件的密鑰

步驟 11. 生成新的私鑰和公鑰對。

步驟 12. 使用在步驟 2 中生成的會話公鑰生成共享密鑰并對其進行散列以獲取另一個對稱密鑰以用于 Salsa20 密鑰生成。

步驟 13. 設置 256 位（32 字節）Salsa20 密鑰狀態

步驟 14. 為 Salsa20 密鑰生成 8 位 IV

步驟 15. 生成 Salsa20 密鑰 ?

步驟 16. 使用這個 Salsa20 key_state 來加密使用 Salsa20 加密的用戶文件。

圖 10：按文件生成 Salsa20 密鑰

對每個要加密的文件重復步驟 11 到 16。

加解密圖解

要了解密鑰是如何在攻擊者和受害者機器之間生成和傳輸的，我們需要借助下圖來看看 Di?e Hellman 是如何工作的。

圖 11：橢圓曲線 Di?e-Hellman (ECDH) 密鑰交換

Sodinokibi 加密過程詳解

圖 12：加密過程

?Sodinokibi解密過程詳解

圖13：解密過程（攻擊者的秘密是攻擊者的私鑰）

用戶文件解密過程的簡化版本如下圖所示。

圖 14

本地硬盤驅動器和網絡共享上的文件加密

為了加密用戶文件，Sodinokibi 使用 I/O 完成端口并創建多個加密線程，最多為機器上處理器內核數量的兩倍，并將這些線程與創建的 I/O 完成端口相關聯。這些線程使用

GetQueuedCompletionStatus Win API 函數等待完成數據包排隊到 I/O 完成端口，然后再進行文件加密。

創建線程并等待 I/O 數據包到達后，Sodinokibi 將啟動枚舉除 CDROM 和 RAMDISK 驅動器之外的所有本地驅動器和網絡共享上的用戶文件，并開始關聯不在豁免文件夾、文件或文件擴展名中的文件通過調用 AddFileToIoCompletionPort 用戶函數列出此 I/O 完成端口并調用PostQueuedCompletionStatus Win API 在 I/O 完成端口上發布 I/O 數據包，這將觸發在此 I/O 完成端口上等待的線程恢復并繼續加密文件。 AddFileToIoCompletionPort 還為每個文件生成一個唯一的 Salsa20 密鑰。

被加密并將這個 Salsa20 密鑰作為包含其他元數據的結構的一部分傳遞給加密線程，這些元數據在使用 lpOverlapped 加密后也必須寫入文件PostQueuedCompletionStatus Win API 的參數。

最后，它設置一個標志，表明沒有更多的文件要枚舉并發布多個 I/O 完成數據包，通過這樣做，它確保等待文件的額外線程應該恢復并中斷執行流以立即完成。

圖 15

豁免文件夾

?"program ?les (x86)"

?"msocache"

?"$windows.~ws"

?"boot"

?"per?ogs"

?"application data"

?"programdata"

?"appdata"

?"$recycle.bin"

?"tor browser"

?"system volume information"

?"google"

?"windows"

?"windows.old"

?"mozilla"

豁免文件

?"bootfont.bin"     ?    "boot.ini"

?"ntuser.dat"

?"iconcache.db"

?"ntuser.dat.log"

?"bootsect.bak"

?"autorun.inf"

?"desktop.ini"

?"ntldr"

?"thumbs.db"

?"ntuser.ini"

豁免的文件擴展名

?"themepack" ?    "ldf"

?"scr"

?"386"

?"ani"

?"theme"

?"icl"

?"cmd"

?"adv"   ?

?"msi"   ?

?"hlp"

?"drv"

?"deskthemepack"

?"rom"

?"lnk"

?"spl"

?"msu"

?"key"

?"com"

?"diagpkg"

?"diagcab"

?"lock"

?"mpa"

?"cpl"

?"hta"

?"icns"

?"dll"

?"idx"

?"shs"

?"wpx"

?"bat"

?"msc"

?"cab"

?"ps1"

?"ics"

?"msp"

?"sys"

?"nls"

?"ico"

?"ocx"

?"cur"

?"mod"

?"exe"

?"prf"

?"nomedia"

加密線程負責讀取文件內容，對其進行加密，將其寫回同一個文件，寫入包含加密會話的元數據 每個文件 ECDH 公鑰和每個文件 Salsa20 IV 用于加密文件然后重命名它經過

附加隨機生成的擴展名。文件使用 Salsa20 ? 加密（Chacha 變體）EncryptAndWrite 用戶函數內部的加密算法。

圖 16

加密后的文件結構

圖 17：加密文件的結構 ?

加密過程完成后，勒索軟件準備將數據發送到控制服務器。 此數據包含與 JSON 配置不同的字段，系統信息和加密密鑰。 準備好的數據也保存到注冊表項中“[HKLM|HKCU]\SOFTWARE\recfg\stat”，然后用 AES 加密并將其發送到攻擊者的服務器。

圖 18：通過網絡發送的數據

圖 19：生成 URL

贖金記錄

Sodinokibi 包含一個贖金票據模板，其中包含用戶特定詳細信息的占位符。

這些占位符動態替換為用戶特定的擴展名、用戶 ID（uid– 有關說明，請參見上表）和鍵。 贖金票據放置在除白名單之外的每個目錄中。

圖 20：贖金說明

解密

該勒索軟件沒有可用的免費解密器，唯一的選擇是使用攻擊者提供的解密服務，可以通過以下方式訪問贖金說明中的說明。 解密器頁面如下:

圖 21:贖金說明文件

結論 ?

防護建議：

1.多臺機器，不要使用相同的賬號和口令

2.登錄口令要有足夠的長度和復雜性，并定期更換登錄口令

3.重要資料的共享文件夾應設置訪問權限控制，并進行定期備份

4.定期檢測系統和軟件中的安全漏洞，及時打上補丁。

5.定期到服務器檢查是否存在異常。查看范圍包括：

a)是否有新增賬戶

b)Guest是否被啟用

c)Windows系統日志是否存在異常

d)殺毒軟件是否存在異常攔截情況

6.安裝安全防護軟件，并確保其正常運行。

7.從正規渠道下載安裝軟件。

8.對不熟悉的軟件，如果已經被殺毒軟件攔截查殺，不要添加信任繼續運行。

Sodinokibi勒索病毒通用解密工具

誰是 REvil/Sodinokibi？

REvil 是一家勒索軟件即服務 (RaaS) 運營商，可能位于獨立國家聯合體 (CIS) 國家。它于 2019 年作為現已解散的 GandCrab 勒索軟件的繼任者而出現。 REvil/Sodinokibi 是暗網上最多產的勒索軟件之一：附屬機構針對全球數千家科技公司、MSP 和零售商。

在成功加密企業數據后，REvil 的附屬公司索要大筆贖金——高達 7000 萬美元——以換取解密密鑰，并承諾該團伙不會公布在攻擊期間竊取的數據。

在它消失之前最大的挑戰是 Kaseya 攻擊：一場讓數以千計的托管服務提供商 (MSP) 陷入困境的閃電戰。

從 7 月 2 日開始，REvil 團伙在 22 個國家/地區對 Kaseya 虛擬系統/服務器管理員 (VSA) 平臺發起了超過 5,000 次攻擊。這些攻擊不僅打擊了 Kaseya 的 MSP 客戶群，而且鑒于他們中的許多人使用 VSA 來管理其他企業的網絡，即這些 MSP 的客戶。

REvil 的密鑰層次結構

核心團隊還擁有一個通用密鑰，用于像 Kaseya 這樣的一組受害者。 Boguslavskiy 周三告訴 Threatpost，該通用密鑰可以覆蓋多個網絡和工作站。

“這是 Kaseya 攻擊后發布的密鑰，”他說，指的是據稱重生的 REvil 的新代表講述的一個故事，關于編碼器誤點擊并意外生成和發布密鑰。

此外，還有一個“操作員密鑰”或“主密鑰”，由頂級 RaaS 領導層使用，例如 UNKN——在 7 月 13 日服務器關閉之前活躍的 REvil 代表。

從Revil團隊在網絡犯罪論壇發布的消息看，該組織的核心成員之一的UNKN長期失聯——疑似被捕，同時其基礎設施遭到入侵，所以才沉寂長達兩個月之久。而在該團隊宣布回歸后不久，國外便有安全公司宣布和執法部門合作獲取到了針對Sodinokibi(Revil)勒索軟件的解密方案，不過僅能解密7月13日之前被Sodinokibi（Revil）勒索軟件加密的文件。

解密方法如下：

圖1：啟動通用解密工具

圖2：掃描匹配密鑰

圖3：成功恢復！