涉及的鏡像文件：

sdb.vhd
uac.tar
ubuntu.20211208.mem

需要利用的工具：

volatility3
volatility2.6.1
FTK/Autopsy
Strings

題干:

容器是一個Ubuntu Linux 蜜罐，用來觀察利用 CVE-2021-41773 的漏洞攻擊者想要做什么。

您將看到一個 cron 腳本，用于刪除 /tmp 中名為 kinsing 的文件。這是防止這些礦工的一種方式，因此可能會發生更多有趣的事情。作為SOC分析師，請幫忙分析以下問題

0x01 - 問題1

文件 => sdb.vhd

有一個腳本每分鐘運行一次以執行清理。文件的名稱是什么？

直接用FTK打開磁盤鏡像文件，找到計劃任務的路徑進去看就行

這個 bash 腳本的作用是查找正在運行的進程中包含 "kinsing" 或 "kdevtmp" 字符串，并且進程的可執行文件路徑包含 "/tmp" 的進程。然后，它使用 kill -9 來終止這些進程。接著，它更改以 "k" 開頭的文件在 /tmp 目錄下的所有者為 root，并將這些文件的權限設置為只讀（444）他的目的就是殺掉防護進程

0x02 - 問題2

文件 => sdb.vhd

題目1中的腳本終止與兩個比特幣礦工惡意軟件文件關聯的進程。第一個惡意軟件文件的名稱是什么？

#!/bin/bash for PID in `ps -ef | egrep "kinsing|kdevtmp" | grep "/tmp" | awk '{ print $2 }'` do kill -9 $PID done chown root.root /tmp/k* chmod 444 /tmp/k*

kinsing

0x03 - 問題3

文件 => sdb.vhd

題目1中的腳本更改某些文件的權限。他們的新權限是什么？

444

0x04 - 問題4

文件 => sdb.vhd

僵尸網絡代理文件的 sha256是什么？

這個文件在/tmp 文件夾下，此題有些牽強了，因為光憑借文件的名字沒人知道這是個啥，所以這里推薦大家用FTK把磁盤映射搞起來，然后用病毒掃描工具掃一下

0x05 - 問題5

文件 => sdb.vhd Q#4 中的僵尸網絡名稱是什么？

直接把vt掃描結果放進去就行

Tsunami

0x06 - 問題6

文件 => sdb.vhd

哪個 IP 地址與 題目4中僵尸網絡代理文件的創建時間戳匹配？

先看一下代理文件下載時間

然后去阿帕奇日志里找到了東西，這個題其實也有點牽強，但是翻日志確實是應急必須做的

141.135.85.36

0x07 - 問題7

文件 => sdb.vhd

攻擊者下載僵尸網絡代理使用的URL是什么？

這道題是在error.log里找到的，不知道為什么會出現在錯誤日志里 http://138.197.206.223:80/wp-content/themes/twentysixteen/dk86

0x08 - 問題8

文件 => sdb.vhd

攻擊者下載并執行惡意腳本，隨后刪除自身，文件的名稱是什么？

此題在error.log里看到了，這道題其實到最后我也沒做出來，太過于牽強了，簡直是大海撈針一樣

0x09 - 問題9

文件 => sdb.vhd

攻擊者下載了一些 sh 腳本。這些sh文件的名稱是什么？

還是看error.log

strings error_log | grep -E '\.sh'

只是不知道為啥會出現在error.log里面 0_cron.sh, 0_linux.sh, ap.sh

0x10 - 問題10

文件 => UAC

兩個可疑進程正在從已刪除的目錄運行。他們的 PID 是什么？

/uac-ApacheWebServer-linux-20211208202503.tar\live_response\process\lsof_-nPl.txt

過濾所有的deleted關鍵字

6388，20645

0x11 - 問題11

文件 => UAC

與上題第二個 PID 關聯的可疑命令行是什么？

/uac-ApacheWebServer-linux-20211208202503.tar\live_response\process\ps_auxwwwf.txt

sh .src.sh

0x12 - 問題12

文件 => UAC

UAC 從 第10道題目的第二個進程收集了一些數據。攻擊中使用的遠程 IP 地址和遠程端口是什么？

/uac-ApacheWebServer-linux-20211208202503.tar\live_response\process\proc\20645\environ.txt

116.202.187.77:56590

0x13 - 問題13

文件 => UAC

哪個用戶負責執行 第11題中的命令？

daemon

0x14 - 問題14

文件 => UAC

兩個可疑的 shell 進程正在從 tmp 文件夾運行。他們的 PID 是什么？

strings lsof_-nPl.txt | grep '/tmp'

15853，21785

0x15 - 問題15

文件 => ubuntu.20211208.mem

捕獲的內存的 MAC 地址是多少？

這里需要使用vol3版本，因為vol2.6.1無論是哪個版本使用imageinfo都是沒有任何響應

python vol.py -f ../ubuntu.20211208.mem banner

這里需要定向配置了 這里使用的docker 首先先在系統根路徑下把volatility-2.6.1整個拷貝過去

我們需要用的是里面的/volatility-2.6.1/tools/linux 里面的makefile文件和modules.c文件 在系統根路徑運行以下命令，首先更新apt-get，然后安裝docker，最后是運行容器

apt-get update apt install docker.io docker run -it --rm -v $PWD://volatility-2.6.1 ubuntu:18.04 /bin/bash cd /volatility-2.6.1/tools/linux

然后更新容器，安裝dwarfdump make zip等命令，同時在modules.c文件加入一句話

MODULE_LICENSE("GPL")

直接在末尾也可以

apt-get update apt-get install -y build-essential dwarfdump make zip apt-get install -y linux-image-5.4.0-1059-azure linux-headers-5.4.0-1059-azure make

第一次執行make的時候，報錯了，不知道為啥他找的是kali的路徑，所以執行以下命令手動make一下，由于makefile的報錯，所以dwarfdump 也得手

make -C //lib/modules/5.4.0-1059-azure/build CONFIG_DEBUG_INFO=y M="/root/" modules dwarfdump -di module.ko > module.dwarf zip Ubuntu-azure.zip module.dwarf /boot/System.map-5.4.0-1059-azure

同時如果不修改modules.c就會報錯 全部執行完畢后不報錯了

然后去自己物理機的目錄就能找到壓縮包了

把Ubuntu-azure.zip拷貝到/volatility-2.6.1/volatility/plugins/linux

試著執行一下，成功了，不容易

正常玩法

python2 vol.py -f ubuntu.20211208.mem --profile=LinuxUbuntu-azurex64 linux_ifconfig

當然了，環境配不出來可以strings過濾

strings ubuntu.20211208.mem | grep -E -o '([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2})'

0x16 - 問題16

文件 => ubuntu.20211208.mem 來自 Bash 歷史記錄。攻擊者下載了一個 sh 腳本。文件的名稱是什么？

正常玩法：

python2 vol.py -f ubuntu.20211208.mem --profile=LinuxUbuntu-azurex64 linux_bash

太多了

python2 vol.py -f ubuntu.20211208.mem --profile=LinuxUbuntu-azurex64 linux_bash | grep -i '\.sh'

unk.sh

同樣也可以在FTK工具中利用第一個鏡像找到文件

審核編輯：劉清