請點擊上面 一鍵關注!
近一年很多人問我,中了勒索病毒怎麼辦,問我的有醫療行業、財務系統等等,今天給大家介紹其中一個Sodinokibi勒索病毒背景和解密過程。
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 使用橢圓曲線 Diffie–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。
加解密圖解
要了解密鑰是如何在攻擊者和受害者機器之間生成和傳輸的,我們需要藉助下圖來看看 Diffie Hellman 是如何工作的。
圖 11:橢圓曲線 Diffie-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 files (x86)"
•"msocache"
•"$windows.~ws"
•"boot"
•"perflogs"
•"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:成功恢復!