起因：某公司的運維人員在綠盟的IPS上監測到有挖"門羅幣"的惡意事件，受影響的機器為公司的大數據服務器以及其他Linux服務器。

我也是趕鴨子上架第一次解決運行在Linux上的挖礦病毒事件，由於當時自己沒有專門的Linux挖礦的清理工具，便開始分析IPS上提供的信息。

由於當時的部門對數據的保護比較敏感，並沒有對當時操作進行拍照截圖，我也只能根據當時我記錄的筆記和依稀的記憶來梳理整個事件。

IPS提供的信息：

1：受到影響的IP

2：受影響主機連接的地址（158.69.133.18）

3：事件名稱（具體的名稱忘記了，大概的意思就是，挖門羅幣的惡意事件），後面跟著發生的時間

根據這些信息，並結合當時沒有Linux的殺毒軟件這種情況，我整理了一下自己的工作思路

1：找到挖礦的進程

2：查找相關進程

3：清理

4：整理文檔

想清了思路，便開始幹活

由於當時太註重“挖礦”這個詞了，上來我就在那個命令行下輸入top命令，準備找找那些可疑的占內存特大的進程，看著嘩嘩的進程不斷在眼前流動，自己心裏有些慌了，好多進程占用的資源都挺高的。由於那是一臺雲計算的服務器，上面有好多進程自己也不清楚，結果自己就在那些正常的進程上廢了好多時間也沒找到有問題的進程。

然後我轉變入手的關鍵，從那個外聯的地址（158.69.133.18）入手。

輸入命令：netstat -anp | grep "158.69.133.18"

當時自己真的挺幸運的，還真找到了那條連接 百度上是加拿大地址的IP（158.69.133.18）。之所以說自己是幸運的，是因為後面發生了一個“奇怪”的現象。

當自己找到那個惡意進程後，身旁的那個運維人員也特高興了，趕緊將我的那條命令發給其他出問題的部門，讓他們也找一下。

就是因為她的積極也引出了接下來的“奇怪”事件。

其他部門的運維人員，用了那條命令（netstat -anp | grep "158.69.133.18"）後，有的反應說找到了，有的卻說沒有。

當說沒有的時候，我還以為他們輸入錯了，結果自己重新輸入那條命令時，返回來的竟然是空白。

“難道說那個病毒制作的人，發現我們在找他的惡意程序了？”，我當時自己亂想著，邊翻看著IPS上的告警信息。

我忽然想到了這些×××事件上的時間，利用IPS的條件過濾，將我分析的那臺Linux服務器IP地址輸上去，並選擇這條事件編號，回車。

看著重新刷新出來的數據，我看到了自己想知道的那條信息，受影響的主機並不是實時連接那個IP（158.69.133.18），每次的連接間隔大約是半小時。

“總不能等半個小時後再分析這個問題啊”，心裏這樣想著，我又在命令行下輸入netstat -anp。看著大量的進程出來了，沒思路看著大量的數據就困。閑著往上翻這些數據，我也在幻想著如果自己拿到一臺服務器，自己要做什麽，留後門！趕緊在netstat -anp 後加一條grep語句，這次grep bash。完整的命令是netstat -anp | grep bash。

果然，自己還是那麽幸運，一條過濾後的結果出來了。過濾出的結果，我謹慎的百度了一下那個IP，依稀記得是美國的一個地址。讓其他運維人員過濾 bash這個關鍵詞，也都找到了那條異常的進程。

順藤摸瓜，繼續深入，免得一會這個進程又消失，輸入命令：ps -ef | grep PID（那條異常的進程IP，我當時也沒記錄這個ID號）

然後出來了一個文件路徑，當時的筆記是/tmp/.lsb/路徑下的一個文件

這是當時那個文件裏的文件，當時裏面還存在兩個文件夾(h32和h64)，當時拷到電腦上結果直接被win10的windows defender給殺了。當時指向的是h32下的一個文件。

保留病毒樣本後，就將這個進程kill了，然後把這個文件夾刪除。

最後在計劃任務裏找到一個異常的計劃任務，刪除掉。

最後觀察了四個小時，IPS上沒有這臺服務器的告警信息了，在服務器上也沒有找到其他異常的進程了。

自己整理了一下，清理步驟，也就是那幾條命令，轉發給其他中這個挖礦的病毒的運維人員了。讓他們自己一起處理。

當然在這期間，還發現其他的挖礦病毒，有的真的很厲（jiao）害（hua），通過檢測cpu，只要達到25%就kill掉自己。

付一張在其他服務器上發現的不同的文件

其中那兩個後綴為jpg的文件其實是兩個腳本，用文本編輯器查看（部分截圖如下）

如果不是IPS上有告警，還真的不知道自己的服務器已經淪為別人的挖礦肉雞了。

總結：日常的運維要經常看看有沒有異常登錄，要看看管理的服務器的日誌。該架設的安全設備可以和老板提提，不然自己就多看看自己負責的服務器要經常看看日誌，看看有沒有新的進程。不然出了事情，解決不了，就準備背鍋吧。

記一次手動清理Linux挖礦病毒