前言：

版權(quán)作者：思而聽(山東)網(wǎng)絡(luò)科技有限公司、solar應(yīng)急響應(yīng)團隊、州弟學(xué)安全
特別注意：環(huán)境中的勒索家族全版本加密器已被 solar應(yīng)急響應(yīng)團隊 破解
系統(tǒng)：Windows server 2016
賬號密碼：administrator/Sierting789@
防勒索官網(wǎng)：http://應(yīng)急響應(yīng).com(查詢勒索家族及解密器搜索)
必須注意：禁止在本地運行勒索病毒加密器，造成的后果自行承擔(dān)
環(huán)境中恢復(fù)了一部分文件作為線索，實際情況中勒索組織不講武德，幾乎會加密所有可運行、可讀取文件，增大溯源排查難度

題目：

1. 上機排查提交病毒家族的名稱，可訪問應(yīng)急響應(yīng).com確定家族名稱，以flag{xxx}提交(大小寫敏感)
2. 提交勒索病毒預(yù)留的ID，以flag{xxxxxx}進行提交
3. 解密并提交桌面中flag.txt.LIVE的flag，以flag{xxxx}提交
4. 提交Windows Defender刪除攻擊者C2的時間，以flag{2025.1.1_1:10}格式提交
5. 提交攻擊者關(guān)閉Windows Defender的時間，以flag{2025.1.1_1:10}格式提交
6. 提交攻擊者上傳C2的絕對路徑，格式以flag{C:\xxx\xxx}提交
7. 提交攻擊者C2的IP外聯(lián)地址，格式以flag{xx.x.x.x}提交
8. 提交攻擊者加密器絕對路徑，格式以flag{C:\xxx\xxx}提交
9. 溯源黑客攻擊路徑，利用的哪個漏洞并推測驗證，提交此業(yè)務(wù)運行文件的絕對路徑，如：flag{C:\xxx\xxx\xxx} 注：此處需具備一些滲透思維和文件特征識別能力

準備：

自己本地跑的靶機，電腦太拉了，更改配置為4h。

1、上機排查提交病毒家族的名稱，可訪問應(yīng)急響應(yīng).com確定家族名稱，以flag{xxx}提交(大小寫敏感)

發(fā)現(xiàn)加密文件特征以.LIVE結(jié)尾，結(jié)合信息收集：

LIVE2.0勒索病毒是LIVE家族的第二代惡意軟件，該惡意軟件會加密受害者的文件，并且將受害者的ID、文件名稱和文件名稱的長度寫入到加密文件的末尾，最后會將文件名重命名成帶.LIVE的文件 ，尤其是針對較重要的文本類文件會采用全部數(shù)據(jù)加密的方式。此外，它還會提供給受害者一封“FILE RECOVERY_ID_+受害者ID.txt”的勒索信。

flag{LIVE}

2、提交勒索病毒預(yù)留的ID，以flag{xxxxxx}進行提交

根據(jù)信息收集，該勒索家族，會給受害者提供一封“FILE RECOVERY_ID_+受害者ID.txt”的勒索信。

找到：FILE RECOVERY_ID_170605242653與FILE RECOVERY_ID_170605242653
flag{170605242653}

3、解密并提交桌面中flag.txt.LIVE的flag，以flag{xxxx}提交

尋找LIVE勒索病毒家族解密工具：https://www.solarsecurity.cn/tools?page=1&keyword=live

解密密碼：solarsecurity
放入虛擬機，直接運行
LIVE_Decrypto.exe -path=C:\Users\Administrator\Desktop\flag.txt.LIVE

flag{cf0971c1d17a03823c3db541ea3b4ec2}

4、提交Windows Defender刪除攻擊者C2的時間，以flag{2025.1.1_1:10}格式提交

時間在2025.8.25_10:43

flag{2025.8.25_10:43}

5、提交攻擊者關(guān)閉Windows Defender的時間，以flag{2025.1.1_1:10}格式提交 ，

這題的flag沒找出來....
以下是錯誤過程：
在eventvwr查看系統(tǒng)日志，篩選7036：

防火墻服務(wù)被關(guān)閉（Windows Firewall 服務(wù)停止）

• 系統(tǒng)日志：

• 事件源：Service Control Manager

• 事件 ID：7036

安全日志 - 防火墻策略變更相關(guān)：

• 安全日志

  （如果開啟了“審核策略更改”）

  • 事件ID：4946（A change has been made to Windows Firewall exception list.）
  • 事件ID：4950（A Windows Firewall setting has changed.）
  • 事件ID：2003，2004（某些版本/角色下）
    

flag{2025.8.25_18:54}
最早的日志：2025/8/25 18:54:29
最晚的日志：2025/9/1 14:09:59

正確的應(yīng)急姿勢：
使用工具fulleventlogview
關(guān)閉Windows defender的時間，Windows默認是記錄的，其事件id為5001會記錄開啟和關(guān)閉的日志

flag{2025.8.25_10:45}

6、提交攻擊者上傳C2的絕對路徑，格式以flag{C:\xxx\xxx}提交

直接根據(jù)習(xí)慣在下載中找到：

C:\Users\Administrator\Downloads\Wq12D.exe

flag{C:\Users\Administrator\Downloads\Wq12D.exe}

7、提交攻擊者C2的IP外聯(lián)地址，格式以flag{xx.x.x.x}提交

不是網(wǎng)絡(luò)連接的這兩個。是上一個flag找到的惡意C2的上線payload得到：

flag{192.168.186.2}

8、提交攻擊者加密器絕對路徑，格式以flag{C:\xxx\xxx}提交

思路：根據(jù)8.25時間以及C2payload分析附近時間點的文件情況，尋找加密器。上線時間點確定了加密器出現(xiàn)時間的起始，加密文件的出現(xiàn)點確定了加密器出現(xiàn)時間的結(jié)尾。
download.7z是可疑，排查后發(fā)現(xiàn)是systime.exe。
flag{C:\Users\Administrator\Documents\systime.exe}

9.溯源黑客攻擊路徑，利用的哪個漏洞并推測驗證，提交此業(yè)務(wù)運行文件的絕對路徑，如：flag{C:\xxx\xxx\xxx} 注：此處需具備一些滲透思維和文件特征識別能力

因為肯定是遠程滲透進入的，這臺靶機windows上遠程可以訪問的服務(wù):3389、小皮(nginx、apache、ftp)、若依。依次排查入侵點
看一下3389登錄失敗日志：4625

結(jié)合之前獲得的C2信息，未找到192.168.186.2的登錄信息。
注意到有小皮，找對應(yīng)的PbootCMS-3.2.12漏洞，未發(fā)現(xiàn)nday，Nginx版本發(fā)現(xiàn)存在解析漏洞：
https://blog.csdn.net/weixin_43606134/article/details/108652890
進一步打開小皮打開nginx日志進行排查，在error.log處發(fā)現(xiàn)可疑日志信息：

解碼：

GET /${(#a=@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec("id").getInputStream(),"utf-8")).(@com.opensymphony.webwork.ServletActionContext@getResponse().setHeader("X-Cmd-Response",#a))}/

顯然使用的payload為java語言，且開啟nginx并嘗試復(fù)現(xiàn)解析漏洞，失敗。
在E:\找到若依框架，版本為4.7.1，信息收集存在nday：
https://blog.csdn.net/lza20001103/article/details/142638979
嘗試復(fù)現(xiàn)，沒有能夠登錄的賬密，還原若依文件后，在sql文件中找到了加密的賬密：'29c67a30398638269fe600f73a054934','111111'。
嘗試利用無果(暫時沒爆破出來)。
查看日志記錄，發(fā)現(xiàn)框架spring和spring boot繼而尋找框架漏洞，

使用框架漏洞掃描工具發(fā)現(xiàn)框架存在信息泄露：

http://192.168.52.7:9988/actuator/heapdump 下載heapdump解密進行利用，根據(jù)信息收集利用方式依次排查：
https://blog.csdn.net/WangsuSecurity/article/details/140873359
https://cloud.tencent.com/developer/article/1630225
最后嘗試利用shiro_key，解密工具如下
https://github.com/wyzxxz/heapdump_tool

找到shirokey但是利用顯示錯誤：

后面發(fā)現(xiàn)是因為高版本shiro的rememberme加密模式變成了AES-GCM，需要在工具里勾選，不然檢測不對。目前可以確定入口是若依框架，對應(yīng)的啟動文件是：E:\ruoyi\start.bat

總結(jié)：若依系統(tǒng)的漏洞未徹底測試，至少spring框架存在信息泄露，導(dǎo)致了shiro_key的泄露。
flag{E:\ruoyi\ruoyi-admin.jar}

學(xué)習(xí)內(nèi)容：

勒索病毒分析處置：
1、判斷勒索病毒：
	1. 更改文件擴展名(部分勒索家族會將文件重命名如加密或編碼)  
	2. 預(yù)留勒索信(目的為了告知其聯(lián)系方式與威脅信息)  
	3. 加密器(截至目前，大部分勒索家族會在觸發(fā)加密器后，待文件加密完畢后自刪除加密器，防止逆向分析)  
	4. 預(yù)留勒索id(id一般唯一，用于后期數(shù)據(jù)恢復(fù)的憑證)。一般勒索id會存放在以下位置:
		(1)勒索信
		(2)被加密后的文件名
		(3)勒索信文件名
2、了解此勒索家族慣用攻擊手法，如一些家族喜歡rdp爆破，一些家族喜歡攻擊OA等，后期溯源就可以優(yōu)先側(cè)重于此處排查，此家族之前有無被破解的解密器，是否可以使用被破解的解密器進行恢復(fù)。
3、在正常排查過程中，大部分勒索家族會在加密完畢后做痕跡清理和加密器自刪除，給溯源排查增加難度，更有甚者會刪除Windows事件日志，這個時候更考驗藍隊工程師對于環(huán)境中的應(yīng)用服務(wù)排查能力以及滲透能力，因為當日志被清理后，需要判斷哪些服務(wù)對外開放且存在漏洞最后給出合理的報告。