背景介紹：

　　近期客服的妹子來找我說，客戶服務器被惡意上傳了大量的非法頁面，客戶要求三天內必須確認漏洞并提出修復方案，作為偽粉絲的我正在聽某某女神唱歌，突然被打斷一種莫名的惆悵在心理慢慢升起，趕緊去洗了一把臉開始干活拉，理一理思路先。

　　分析思路：

　　1、非法頁面所屬用戶是誰 ，上傳時間是什么時候？

　　2、擁有什么權限可以上傳非法頁面到此目錄？

　　3、攻擊者利用什么樣的漏洞可以獲取這樣的權限？

　　4、攻擊者可以通過那些手段上傳非法頁面到服務器？

　　帶著這些疑問一一來驗證！

　　驗證思路：

　　1、非法頁面所有用戶是 Nginx， 上傳時間是晚上凌晨1點左右；

　　2、攻擊者只需要有Web項目編輯權限即可；

　　3、Web項目常見的如Sql注入、文件包含、代碼執行、文件上傳、后門等均可以獲取這樣權限；

　　4、Web項目常用一句話木馬、WebShell、反彈Shell等均可以上傳到目錄；

　　排查木馬：

　　首先使用WebShell掃描工具（如：河馬）先過一遍，一邊掃描一邊查看請求日志，由于項目文件較大花了將近2個多小時才掃描完成，遺憾的無論掃描結果還是請求日志并沒有發現異常，推測那么就有可能通過反Shell上傳、或者WebShell混淆加密掃描工具并不能發現，看來只能通過手動進行了，經過1個多小時奮戰最后發現一個異常的PHP文件，攻擊者利用PHP文件在Redis里面執行反彈shell 如圖：

　　有了IP和端口后就好辦了，只要確認了近期有這個IP的請求日志基本就可以確認，攻擊者通過反彈Redis反彈Shell上傳了非法頁面，但是分析近幾天的防火墻的日志分析并沒有發現此IP的任何請求日志，推測攻擊者在獲得反彈Shell后肯定進行了提權、或者部署其他的控制服務器手段；

　　經過幾個小時的努力和對流量層層過濾，最終確認了一個IP、一個域名比較異常（如圖1）且近期出現大量的鏈接，在相同的時間內多次鏈接，進一步對IP、域名進行分析發現發起該進程的文件是Bash看來又是一個反彈shell，通過查詢發現有7個Bash進程運行者均是Nginx用戶 （如圖2）：

圖1

圖2

　　既然是 Bash 發起的首先確認以下Bash是否被惡意修改，通過查看父進程發現發起的 bash 文件已被刪除，無法進一步確認，只能先把bash進程kill掉，一邊觀察，一邊查詢調度任務是否存在自動生成進程；

　　通過觀察和查詢并沒有發現該類進程運行，推測攻擊者使用Redis反彈Shell鏈接后創建了多條隧道來進行控制服務器，為了避免被發現Redis反彈Shell，故用來上傳非法頁面的反彈shell使用的并不是同一個IP，把Bash進程停止掉以后，經過一段時間觀察后并沒有發現異常的Bash再次運行，由此確認攻擊者避免被發現并沒有做過多的手段；

　　確認沒有異常的進程后清理Redis反彈Shell，刪除后在1個小時后發現此文件又被再次生成，推測攻擊者有可能利用漏洞，在此寫入或者項目文件里面有自動生成機制，看來又是一個煙霧彈，對請求日志、項目文件、數據庫掃描，最終發現攻擊者利用網站后臺其中一個功能寫入此段代碼到數據庫如圖：

　　看來攻擊者是拿到了網站后臺權限，在對網站后臺日志排查后最終確認攻擊者是利用xxx賬戶登入后臺并寫入反彈Shell代碼如圖（模糊了頁面）：

　　經過2天多的努力日志最終確認到非法登錄時間，登錄用戶、IP并移交相關部門處理，不辱使命提前完成任務，晚上要要好好慶祝以下，買5塊錢的烤串犒勞以下自己。

　　總結：

　　此次事件最終確認是從后臺密碼泄漏導致，不管有意還是無意，密碼一定要提高復雜度并且不定期的更換密碼賬戶信息，如果可以后臺可以限制IP，或者地域限制。

責任編輯：韓希宇