Webshell簡介
攻擊者在入侵企業網站時，通常要通過各種方式獲取webshell從而獲得企業網站的控制權，然後方便進行之後的入侵行爲。常見攻擊方式有：直接上傳獲取webshell、SQL注入、遠程文件包含(RFI)、FTP，甚至使用跨站點腳本(XSS)作爲攻擊的一部分，甚至一些比較老舊的方法利用後臺數據庫備份及恢復獲取webshell、數據庫壓縮等。通用功能包括但不限於shell命令執行、代碼執行、數據庫枚舉和文件管理。
1.Webshell分類
webshell從協議上來看,最開始基於 TCP、UDP 的 Shell,到後來基於ICMP 的 Shell和基於DNS 的shell 。從依託工具上看,有 nc 反彈、telnet 反彈、SSH 端口轉發等手段,極度猥瑣的甚至還有利用 awk 的反彈 Shell。從語言上看,各種流行的語言都能用來寫後門,從bash 到 3P(Perl Python PHP)再到 Ruby 和 Java。
2.Webshell功能
（1）站長工具
Webshell被站長常常用於網站管理、服務器管理等，根據FSO權限的不同，作用有在線編輯網頁腳本、上傳下載文件、查看數據庫、執行任意程序命令等。
（2）持續遠程訪問
入侵者可以利用從而達到長期控制網站服務器的目的，若攻擊者自行修復了漏洞，以確保沒有其他人會利用該漏洞，攻擊者可以低調的隨時控制服務器。一些流行的webshell使用密碼驗證和其他技術來確保只有上傳webshell的攻擊者才能訪問它。（webshell密碼爆破工具表示不服）
（3）權限提升
在服務器沒有配置錯誤的情況下，webshell將在web服務器的用戶權限下運行，該用戶權限是有限的。通過使用webshell，攻擊者可以嘗試通過利用系統上的本地漏洞來執行權限提升，常見的有查找敏感配置文件、通過內核漏洞提權、利用低權限用戶目錄下可被Root權限用戶調用的腳本提權、任務計劃等（從入門到放棄）
（4）極強的隱蔽性
有些惡意網頁腳本可以嵌套在正常網頁中運行，且不容易被查殺。webshell還可以穿越服務器防火牆，由於與被控制的服務器或遠程主機交互的數據都是通過80端口傳遞，因此不會被防火牆攔截，在沒有記錄流量的情況下，webshell使用post包發送，也不會被記錄在系統日誌中，只會在web日誌中記錄一些數據提交的記錄。
WebShell檢測
1.基於webshell特徵檢測
常見webshell函數
（1）存在系統調用的命令執行函數，如eval、system、cmd_shell、assert等；
（2）存在系統調用的文件操作函數，如fopen、fwrite、readdir等；
（3）存在數據庫操作函數，調用系統自身的存儲過程來連接數據庫操作；
（4）具備很深的自身隱藏性、可僞裝性，可長期潛伏到web源碼中；
（5）衍生變種多，可通過自定義加解密函數、利用xor、字符串反轉、壓縮、截斷重組等方法來繞過檢測；
以上對於webshell本身的行爲分析 ，它帶有對於系統調用、系統配置、數據庫、文件的操作動作，可以通過關鍵詞匹配腳本文件找出webshell，再如一些壓縮後的數據， 有可能一些WAF並不會檢測到內容存在危險。變性後的數據，WAF也檢測不出存在的危險，首先腳本文件帶有這些特殊的函數，本身就是可疑文件，當然也還有其他方式可以去進行檢測。
這類檢測可以通過grep去查找webshell，D盾之類的webshell查殺工具也是利用這種原理，對源碼進行查殺。但經常會存在黑客在上傳完webshell後門，獲取到自己想要的信息後，就會刪除掉webshell，又或者遇到了一些變形過的webshell後門，我們的關鍵字沒有搜索到，這時候通過文件去找到webshell的方法就不適用了。
對搜索到的內容，手動查看是否是木馬，可以在本地打開腳本文件，查看網頁生成時間或者上傳至一些檢測的網站進行檢測（http://www.virscan.org/；https://x.threatbook.cn/），當然去分析代碼也是完全沒問題的。
2.基於流量特徵的webshell檢測
（1）基於流量行爲特徵的webshell檢測
基於流量的檢測，是無法通過檢測構成webshell危險函數的關鍵詞來做檢測的，但webshell帶有常見寫的系統調用、系統配置、數據庫、文件的操作動作等，它的行爲方式決定了它的數據流量中多帶參數具有一些明顯的特徵，通過匹配行爲的流量特徵做檢測，這也是基於webshell入侵後行爲特徵進行檢測，當然也可以從系統層面webshell入侵行爲進行檢測。
ipconfig/ifconfigsystemwhoaminetstatevaldatabasesysteminfo......
常見的可以從data數據中去檢索攻擊者常用的命令和payload等，當然大部分的webshell不會這麼直接，可能會經過編碼，如最經典的webshell中國菜刀採用的是先url編碼再base64編碼，對應的採取解碼的方式去發現敏感的行爲特徵。這也是抓取流量的好處，因爲在web訪問日誌中，是無法抓取POST方式的包，也就沒法分析webshell入侵後的行爲，而流量很好的做到了這一點。
（2）基於webshell工具特徵的檢測
中國菜刀webshell流量特徵檢測：
使用最常見的一句話木馬搭建的環境，直接抓包查看，可以看到菜刀發送的數據包。
經過解碼後可以看到當前執行的命令是netstat -an，那麼以上那些關閉錯誤回顯、“z1”等字符串操作就是中國菜刀這款webshell的特徵。
webacoo webshell流量特徵檢測：
使用webacoo工具生成webshell並進行連接抓包測試 。
通過wireshark等抓包工具進行分析，可以發現編碼通信內容通過cookie頭傳輸，其中有三個cm、cn和cp變量，這是webacoo webshell管理工具的特徵。
3.基於webshell系統行爲特徵的檢測
這個思路和基於webshell的流量行爲特徵進行檢測的想法大概一直，攻擊者上傳webshell總會做些什麼，那麼可以去監測系統的變化以及敏感的操作，儘可能的去收集服務器的信息，通過和之前的配置以及文件的變化對比監測系統達到儘可能發現webshell的成果。
（1）文件分析
查看/tmp、/init.d、/usr/bin、/usr/sbin等敏感目錄有無可疑的文件，針對可以的文件可使用stat進行創建修改時間、訪問時間的詳細查看，若修改時間距離事件日期接近，有線性關聯，說明可能被篡改或者其他。
對於文件還可使用查找新增文件的方式來查找接近安全事件時間的文件。
例如：
要查找24小時內被修改的PHP文件：
（2）進程分析
使用netstat 網絡連接命令，分析可疑端口、可疑IP、可疑PID及程序進程（top可以實時動態的查看系統的整體運行情況，主要分析cpu和內存多的進程，是一個不錯的綜合了多方面信息監測系統性能和運行信息的實用工具），最好可以去區分對外的監聽端口和對內的監聽端口，一般可以有效的查找出後門。
（3）系統信息分析
以上也是應急經常去分析的系統信息，但是放在webshell檢測上也同樣適合，也適用於webshell入侵檢測，如發現可疑項，可通過逆向思維去分析。這塊我也和很多大佬溝通過，包括在入侵檢測中，簡單的都可以很好去發現，比如通過最原始的爆破進行分析溯源，IDS很好的解決了很多人爲的重複性工作，對於變形或者繞過的攻擊，可能需要儘可能的提取多的信息，串線綜合去分析，APT等高級攻擊，檢測會相當的麻煩，願聽大佬講解。
（4）配置文件
如最普通的將pam.d下的ssh的驗證模塊改成su的驗證模塊，那麼再次登錄，驗證uid爲0，那麼root就免密登錄，而一般情況下，不仔細也是無法觀察出的，還有更多的後門，再入php.ini後門，所以需要去監控一些培訓文件，與之前的配置文件比較，以便於發現問題所在。
（5）chkrootkit/rkhunter
chkrootkit是用來監測 rootkit 是否被安裝到當前系統中的工具。rootkit ，是一類入侵者經常使用的工具。這類工具通常非常的隱祕、令用戶不易察覺，通過這類工具，入侵者建立了一條能夠常時入侵系統，或者說對系統進行實時控制的途徑。所以，我們要用 chkrootkit 來定時監測系統，以保證系統的安全。
chkrootkit主要功能：
檢測是否被植入後門、木馬、rootkit
檢測系統命令是否正常（避免在入侵檢測分析時使用已被替換的命令）
檢測登錄日誌
使用chkrootkit –n；如果發現有異常，會報出“INFECTED”字樣。
rkhunter主要功能：
系統命令（Binary）檢測，包括Md5 校驗
Rootkit檢測
本機敏感目錄、系統配置、服務及套間異常檢測
三方應用版本檢測
假如系統的命令（例如netstat ls 等）被替換，爲了進一步排查，需要下載一新的或者從其他未感染的主機拷貝新的命令。當然類似像Login後門這種的檢測，同樣可以使用命令md5sum對現有/bin/login文件作校驗，與以前的值作比較。
4.基於web日誌webshell行爲特徵的檢測
在準備分析webshell和攻擊事件之前，先了解系統架構，如服務器類型、業務架構、網絡拓撲等。
Ø 服務器類型：windows、linux etc..
Ø cms：dedecms、phpcms、trs cms etc..
Ø 中間件、容器、框架、數據庫：tomcat、iis、apache、weblogic、struts、mysqletc..
Ø 腳本語言：asp、php、jsp etc..
Ø 業務架構：如前端網頁內容是否是後端通過ftp上傳的（新聞網偏多） etc..
……
接着來看下常見黑客的攻擊步驟：
正常情況下攻擊者會先去尋找web漏洞，就像我下圖一樣，通過一些高危的漏洞，比如Struts2、反序列、SQL注入等等，然後直接獲取webshell。
最常見的就是通過尋找一個sql注入點，獲取網站後臺的管理員賬號密碼，然後在後臺上傳一個webshell。上傳了webshell，留下了一個腳本文件在服務器上，那麼通過查找webshell也是在應急的時候的一個切入口，通過webshell來確定時間和攻擊者，進而從時間維度和攻擊維度進一步分析。
如上文利用grep命令搜索常見webshell木馬裏面可能會用的危險函數，找到webshell，然後再從日誌裏翻出關於這個webshell的記錄，找到訪問wenshell的攻擊者ip，從而繼續搜索攻擊者的訪問記錄，就可以還原整個攻擊者做過的動作了。
1）少量的IP對其發起訪問
2）總的訪問次數少
3）該頁面屬於孤立頁面
那麼接下來就可以使用awk、uniq、sort或者腳本對url每天的總訪問數量、url獨立訪問的頁面等進行統計分析。
在日誌提權的時候儘可能的去除掉一些靜態的頁面和錯誤請求信息，常見的可以通過grep -v去排除，排除項有：
1）去除靜態path（例如jpeg,jpg,gif,png,bmp,css,js,xls,xlsx,doc,xml,wav,tar.gz,zip,swf,mp3,ico,pidf,torrent） ；
2）去除白名單path （例如主頁index.php,index.asp,index.aspx,index.ashx,index.html)；
3）去除非webshell後綴的path （例如asp,aspx,php,jsp,py,cgi,pl,java,sh,war,cfm,phtml)；
4）去除掃描器造成的path（按掃描器IP信譽庫（雲掃描器IP信譽庫與時效性掃描器IP信譽庫）與掃描器行爲（可以簡單的按ip host聚類，將單位時間內請求數超過M，獨立路徑數超過N的請求視爲掃描器）來去除）；
5）去除響應碼非200的path。
5.webshell其他檢測方法
從這開始以下內容全爲道聽途說，但很多企業是正在做的，本人技術有限，未能親自實踐，只是爲了文章的完整性！
（1）動態檢測（沙箱）
上面介紹了靜態檢測，通過對指定腳本的關鍵詞、高危函數、問價修改時間、權限等以及和其他文件的關聯性等多個緯度的特徵進行檢測。速度快，且能快速定位；動態特徵檢測通過Webshell運行時使用的系統命令或者網絡流量及狀態的異常來判斷動作的威脅程度，Webshell通常會被加密從而避免靜態 特徵的檢測，當Webshell運行時就必須向系統發送系統命令來達到控制系統或者操作數據庫的目的，通過檢測系統調用來監測甚至攔截系統命令被執行，從行爲模式上深度檢測腳本文件的安全性。這種我能想到的就是類似於python爬蟲的使用Selenium模擬瀏覽器行爲。
（2）統計學
在日誌分析中，基於webshell特徵去發現webshell也範屬於統計學。NeoPiS 國外流行的一個基於統計學的webshell後門檢測工具，它使用五種計學方法在腳本文件中搜索潛在的被混淆或被編碼的惡意代碼。
NeoPi使用以下五種檢測方法：
1）信息熵(Entropy):通過使用ASCII碼錶來衡量文件的不確定性；
2）最長單詞(LongestWord):最長的字符串也許潛在的被編碼或被混淆；
3）重合指數(Indexof Coincidence):低重合指數預示文件代碼潛在的被加密或被混效過；
4）特徵(Signature):在文件中搜索已知的惡意代碼字符串片段；
5）壓縮(Compression):對比文件的壓縮比。
機器學習：
引用下兜哥的分享基於機器學習的 Webshell 發現技術探索和github上的項目 機器學習檢測Webshell
0×03:webshell防禦
從根本上解決動態網頁腳本的安全問題，要做到防注入、防暴庫、防COOKIES欺騙、防跨站攻擊等等，務必配置好服務器FSO權限。
1.建議用戶通過ftp來上傳、維護網頁，儘量不安裝asp的上傳程序。
2.對asp上傳程序的調用一定要進行身份認證，並只允許信任的人使用上傳程序。
3.asp程序管理員的用戶名和密碼要有一定複雜性，不能過於簡單，還要注意定期更換。
4.到正規網站下載程序，下載後要對數據庫名稱和存放路徑進行修改，數據庫名稱要有一定複雜性。
5.要儘量保持程序是最新版本。
6.不要在網頁上加註後臺管理程序登陸頁面的鏈接。
7.爲防止程序有未知漏洞，可以在維護後刪除後臺管理程序的登陸頁面，下次維護時再通過上傳即可。
8.要時常備份數據庫等重要文件。
9.日常要多維護，並注意空間中是否有來歷不明的asp文件。
10.儘量關閉網站搜索功能，利用外部搜索工具，以防爆出數據。
11.利用白名單上傳文件，不在白名單內的一律禁止上傳，上傳目錄權限遵循最小權限原則。