前序

以往已维，當CPU占用到80%或者100%的時候栅屏，我們就很容易判定它是挖礦行為栈雳，但是挖礦也會與時俱進，偽裝自己酌予，當CPU占用很低松靡，并且符合平常業(yè)務特征雕欺，這時候我們就得靠經(jīng)驗去分析了

挖礦事件告警

在客戶現(xiàn)場發(fā)現(xiàn)設(shè)備告警有挖礦軟件的外連行為

下載流量數(shù)據(jù)包進行分析啦逆，可以看到該請求具有明顯的訪問礦池的行為：

定位病毒所在位置

首先使用top查看CPU和Cpu(s)的占用率苛让，發(fā)現(xiàn)時高時低狱杰，符合正常業(yè)務行為食棕，并沒有挖礦占用大量CPU的特征：

ps -ef 查看進程信息，可以看到有向惡意IP發(fā)送請求的進程甥捺，可以看到UID是git：

查看網(wǎng)絡(luò)連接狀態(tài)可以看到服務器連接多個惡意IP吴侦，進程都是同一個與git相關(guān)的备韧，觀察發(fā)現(xiàn)IP變動是動態(tài)的，同一個進程會向不同的惡意IP發(fā)送TCP連接：

根據(jù)挖礦程序的PID查看進程文件，可以看到名為gitlab-workhorse的可疑文件拒课，該文件的名稱被偽裝成上級目錄的名稱：

通過溯源卢鹦，發(fā)現(xiàn)gitlab-workhorse下的config.json配置文件中被寫入了特殊的域名：pool.supportxmr.com:3333：

通過查詢域名pool.supportxmr.com:3333法挨，發(fā)現(xiàn)對應的是一個挖門羅幣的礦池：

通過查看gitlab-workhorse文件的MD5值，發(fā)現(xiàn)該文件為惡意文件荐糜，屬于CoinMiner木馬家族。

使用kill -9 187659直接殺掉該進程，使用ls -al /proc/187659和netstat -antpl查看該進程是否會重啟，觀察半小時后發(fā)現(xiàn)不會自動重啟進程：

查看是否開啟定時任務

查看定時任務發(fā)現(xiàn)沒有任何內(nèi)容，這樣殺掉惡意進程后笼沥，就不會自動重啟進程：

溯源入口

有些挖礦程序無法定位到具體位置，但是找到入口也可以交差乘凸，畢竟現(xiàn)在很多環(huán)境都經(jīng)過備份灵嫌，將入口修復后攻擊者也是無法再次利用的。

嘗試查看Nginx日志發(fā)現(xiàn)只有今年2月到4月的保存日志[未做反向代理]赂蠢，而error.log和access.log是0字節(jié)玖院，而git日志只能保存一個月(11.18-至今)，排查后無結(jié)果郊酒，無法通過日志進行溯源分析燎窘。

經(jīng)初步判斷該挖礦程序可能是通過服務器上部署的gitlab的相關(guān)漏洞傳入的褐健，該gitlab在11月24日之前具有最新的漏洞CVE-2021-22205银亲，而2021年10月28日gitlab遠程命令執(zhí)行漏洞(CVE-2021-22205)在野利用方法被公開。通過該漏洞可做到執(zhí)行任意命令拍谐，反彈shell獲取git的用戶權(quán)限等危害操作。
基于本臺服務器轩拨，可以做到反彈shell之后可以獲得git的用戶權(quán)限院喜、對gitlab配置文件內(nèi)容進行修改、對服務器植入挖礦病毒程序喷舀。

在態(tài)勢感知平臺發(fā)現(xiàn)2021-11-10 12:38:35有來自烏克蘭的惡意IP 212.3.101.118對xxxx服務器進行漏洞利用淋肾，該惡意IP分別請求了GET /users/sign_in和POST /uploads/user爸邢，并且請求體中附帶明顯的偽造的惡意圖片，符合CVE-2021-22205漏洞利用的特征杠河，并且存在寫入惡意文件的命令。

整改

(1). 更新Gitlab到最新版本
(2). 將Gitlab服務放入內(nèi)網(wǎng)中券敌，通過代理等方式訪問

總結(jié)

大佬隨手給個贊唄 0.0