記一次某企業被入侵的遠程應急響應
0X00 事件概述
2019年的7月份左右，朋友那邊所在的企業收到了來自監管單位紅頭文件的通報，稱其網站存在異常的違規內容估計是被入侵了，并火急火燎的要我幫忙康康，又鑒于與他在校時同為最好的朋友便答應了下來。
0X01 情況了解
據朋友口中得知，他們的企業網站之前是委托第三方外包公司搭建的，維護的話建設好了幾乎就沒有什么維護了，平時也都是他們負責文案的同事只是上后臺更新更新文章內容而已，合著業主手里就有一個網站后臺的權限，后面讓朋友去溝通費了蠻長時間也才得到一些基本信息和網站源代碼和access.log網絡訪問日志。
網站部署在的是阿里云上至于是虛擬空間還是獨立主機也不清楚，主機殺毒也沒有更別說網頁防篡改等其他的安全服務了，后面問了朋友要通報里的圖片一看，看得出style.php頁面上的內容亂七八糟的指定是被篡改了。
0X02 入侵分析
將朋友發過來的整站源碼解壓后，發現在通報中的style.php文件不見了，去問了朋友才知道因為怕處罰那邊就第一時間把通報的文件給刪除了，這就很蛋疼，但問題不大像這類的網站篡改的尿性index.html首頁文件肯定也逃脫不了黑帽的魔爪，排序下時間果然index.html的修改時間為19年7月22日12點27分與其他頁面的時間是截然不同的。
下面用文本編輯器打開index.html文件查看內容，果然啊一眼看得出在標簽和keyword關鍵字處經過了unicode編碼轉換，這時候我們在去站長工具那的在線編碼轉換把unicode編碼轉換成中文就一目了然了，正常的網站標簽這大多都是網站的自身介紹是不會有這些涉Du的信息的，所以該首頁面已經被惡意修改了，那為什么頁面篡改大部分又偏偏只修改的是首頁的這幾行內容呢，其實各大的搜索引擎的蜘蛛爬蟲需要爬取的也是這幾行內容去做搜索引擎的收錄，所以那些黑帽植入的Du博鏈接網站從而提高他們網站的收錄和訪問量，受害者也變相性的幫他們做了推廣。
確定了篡改的時間為7月22的12點27分，下面就用D盾webshell查殺工具在殺一遍看看網站中是否還遺留有后門文件，果然查殺出來upload.php、tyuhsdb.php、botright.php三個可疑文件。
其中tyuhsdb.php、botright.php這兩個都為大馬文件，而upload.php是僅具備上傳功能的腳本文件，但仔細一看tyuhsdb.php和upload.php的修改時間都為2011年，這與事件發生的時間相差過于久遠，難道這又是一起長久的遺留后門文件的問題？
進入到\images\swfupload\images目錄下查看upload.php文件，在通過對比官方的源碼的目錄中并未發現該目錄下有upload.php這個文件的存在，在看其的創建時間為2019年7月10日11點52分但修改時間卻為2011年的，可以很確定入侵者為了掩人耳目把修改時間調整為與目錄中其他文件的時間相同，這就給人一種以為該文件是源碼本身就自帶的錯覺。
按照以上的特性，咱們也來看看tyuhsdb.php、botright.php這兩個大馬文件的創建日期是多少，這樣好方便后面篩查日志的時候好做溯源，圖中可以看到這兩個大馬文件都被轉移到了images圖片目錄下，botright.php的創建時間是7月10號12點01分的，tyuhsdb.php創建時間是7月22號12點49分的。
根據以上知道了這三個后門文件的創建時間，我們知道了upload.php是最先被生成上傳的，下面就根據upload.php這個文件進行對照日志的篩選看看這個文件是如何產生的，因為朋友發過來的access.log日志是以增量產生的數據，所以足足有260MB的文本文件這里推薦一款EmEditor編輯器，即使渣渣的電腦也能秒開上G大小的文本文件。
因為如果直接搜索upload.php這個文件名的話那結果會想當的多，而且upload.php大部分是正常網站的一些上傳腳本有些可能不是惡意的，所以就帶上絕對路徑進行查找images/swfupload/images/upload.php，看得出在該文件的前一條訪問記錄是由/include/ckeditor/images/multipic.php這個文件POST數據產生的但目前這個目錄下已經不存在這個文件了，應該也是個大馬文件可能被利用后刪除了，upload訪問的時間也與創建的時間7月10號11點52分對應得上。
繼續往上搜索multipic.php文件是如何產生的，雖然本地文件被刪除了但日志可都會還記錄著的，multipic.php是在11點49分的時候由/plus/task/xadsb.php目錄下的這個腳本文件產生的，而且這個文件本地也是不存在了可能又被刪除了，繼續往上走！
再再往上看看xadsb.php文件是怎么產生的，天吶！又是由/data/enums/inbox.php下的文件產生的而且這個本地也被刪除了，但從流量記錄日志上可以看得出他利用了inbox.php逐層的進入到task/目錄下最后上傳了xadsb.php文件，因此就不難看得出這也是個后門文件了。
不要氣餒！繼續往上翻inbox.php文件，到這里往上一條記錄是由plus/mytag_js.php文件產生的，而且這部分的記錄都是同一個IP所為，并且在7月10號10點28分的時候不止生成了這個后門文件還生成了其它大量亂七八糟的腳本，而且細一點的小伙伴就看得出生成的時間都是毫秒的間隔，千真萬確就是利用工具批量生成的。
以上知道了入侵者很可能就是利用了工具進行批量的植入木馬，所以不妨大膽的猜測plus/mytag_js.php這個腳本文件會不會是應用系統的漏洞點呢，當我想進到目錄去看看這個文件的時候，好家伙這個文件也不存在了這是利用完了就斷了路了嗎，不慌直接把路徑帶上腳本跟參數丟到搜索引擎去瞧瞧，果然沒猜錯直覺還是很靠譜的這是個老洞了，程序也是個老版本了也不難怪會存在怎么老的漏洞。
經過以上最終定位到了mytag_js.php這個腳本文件，而這個腳本在dedecms的5.7版本以下都存在變量覆蓋的漏洞，而這個漏洞利用方式是通過往數據庫插入惡意的語句后執行這個腳本帶上參數就可以生成惡意文件或者更改管理員密碼的操作，接著搜索mytag_js.php文件的流量情況，在7月10號的凌晨5點09分時執行了插入數據的操作，并通過JavaScript在線工具對該exp進行解碼。
通過以上分析已經確定了此次的漏洞利用的IP是哪個，下面繼續分析首頁文件是被哪個后門和IP利用的呢，對于分析出的那些后門文件進行逐個的全部篩選，最后在botright.php這個后門文件下發現142這個IP在7月22號12點27分的時候打開的index.html文件并在28分時修改了文件內容，時間點都與前面index.html修改的時間相對應。
0X03 總結
通過上述的分析，結合目前還留存的丁點后門文件，通過對比現有的日志文件一步一步的去分析它們其中所產生的關系，從而揪出問題的源頭。
事情到這里也簡單寫了份報告給朋友交了差，同時也叮囑朋友告誡他們老板不要找這么不靠譜的第三方公司，只管搭建不管運維就算了還拿滿是漏洞低版本的cms來搭建，最終受罰的還是責任主體得不償失啊，請第三方搭建的費用估計都沒罰得多。
