1.概述
筆者一直在關注webshell的安全分析，最近就這段時間的心得體會和大家做個分享。
webshell一般有三種檢測方式：
Webshell的分類筆者總結如下：
前段時間由于工作的需要完成了一個Webshell檢測系統，根據當時的需求寫了一篇關于使用基于Agent模型和基于日志分析模型來檢測服務器上的文件是否是Webshell的文章，原文可以參見：
http://www.sec-un.org/ideas-like-article-espionage-webshell-method.html
2.基于流量的webshell檢測思考
在研究了上述兩種模型的檢測之后就考慮能否在網絡流量上實現Webshell分析和檢測。畢竟要實現Agent模型和日志分析模型需要的成本太大不僅要考慮兼容性問題還需要考慮性能及安全性的問題，而如果采用流量（網關）型檢測的話成本和部署難度會減小很多，所以有了此文基于流量（網關型）的Webshell檢測方法。
要實現通過網絡流量檢測Webshell首先就需要對流量進行“可視化”，“可視化”的方法有很多可以借鑒目前市場上一些成熟的框架來實現這里就不再多述。我們主要討論在Webshell被上傳到服務器及Webshell在訪問過程中網絡流量中產生的payload來實現Webshell檢測。
3.上傳過程中的Payload
我們知道正常的網站在有需要的情況下通常會允許上傳一些“無害”的文件但是不會允許上傳以腳本文件形式存在的文件例如：PHP、ASP、JSP等，而Webshell就是以這種腳本文件的形式存在并且被服務器解析的。在上傳過程中雖然不會出現一些攻擊payload。但是要向服務器上傳文件所以也會產生一些和上傳相關的Payload。下面我們討論一下常見的兩種上傳的Webshell的形式即上傳“大馬”和“小馬”。
3.1上傳"大馬"
這種方式通過POST直接上傳一個Webshell文件或者經過簡單的變形然后上傳到服務器上,如下面的一個例子：
2009-02-10 06:32:58 W3SVC77065997 XXXX.XXXX.XXXX.XXXX POST /lesson_manage/upload/40/ASP.asp – 80 – XXXX.XXXX.XXXX.XXXX Mozilla/4.0+compatible;+MSIE+6.0; 200 0 0
從上面這條訪問記錄中能夠發現如下關鍵特：POST upload ASP.asp 200 通過這幾個關鍵特征的就能夠分析出ASP.php可能是一個疑似Webshell。
3.2上傳"小馬"
在不能直接上傳“大馬”Webshell的情況下黑客通常會上傳一個“小馬”以協助完成上傳“大馬”或者上傳一句話Webshell并配合一個客戶端實現控制服務器，這里我們也不討論如何上傳“小馬”以及一句話Webshell。我們只討論如何利用“小馬”來上傳“大馬”。
這種方式的特殊點在于不是一個完整的文件在網絡中中傳輸而是一個存在于HTTP協議中的一個參數在網絡中傳輸，傳輸參數的方式既可能是GET也可能是POST，我們來看下面一個真實的例子：
在上圖中我們不難發現這顯然是使用一句話木馬客戶端通過POST的形式正在上傳一個Webshell的腳本代碼，并且將內容寫入一句話木馬相同目錄下的一個body.asp的文件當中，從而實現上傳“大馬”。在截取到的流量數據中可以發現，如：act= body.asp value=Execute等payload，通過在檢測這些payload就可以在上傳的過程中分析Webshell及其行為。
4.訪問過程中的Payload
于Webshell是被制作用來控制服務器或者竊取機密信息的，要實現這些能力攻擊者就必須向Webshell發送一些控制指令從而操作Webshell。在控制指令中通常包含特征明顯的攻擊payload。我們來觀察一下如下幾種payload：
上圖中顯然是Webshell正在試圖連接網站的數據庫，并且攻擊者使用的是POST的方式向Webshell提交連接參數，其中可以發現的payload有：action=sqladmin,dbhost=localhost,dbport=3306,dbuser=root,dbpass=1qaz2wsx,connect=connect等。
我們再看一個由著名一句話Webshell管理工具“菜刀”遠程控制“菜刀馬”并發出的指令的流量數據：
上圖中看出“菜刀”使用了base64的方式加密了發送給“菜刀馬”的指令，通過分析我們能夠觀察到其中的兩個關鍵payload z1和z2。
z1=Y21k&
z2=Y2QgL2QgIkQ6XHd3d1xxaHJkd3dcIiZ3aG9hbWkmZWNobyBbU10mY2QmZWNobyBbRV0%3D
通過解密加密的內容可以得到解密的payload
z1=cmd
z2=cd /d “D:\www\qhrdww\”&whoami&echo [S]&cd&echo [E]7
解密之后的payload就尤為明顯了，從中我們可以找到cd /d cmd whoami echo [S] &cd &echo [E]7等payload.
經過一定的payload積累和規則的定制再經過和其它檢測過程相結合可以形成一套基于流量分析Webshell分析引擎，并且可以該引擎可以很方便的嵌入到現有的網關型設備或云上實現Webshell的深度分析。
1.WEBSHELL是什么？意味著什么？
不同人的視角里，Webshell是什么？
2.Webshell檢測工具和產品（系統）的區別在哪？
網上有各種各樣的開源和免費工具，暫且不說他們的識別率。這些東西為什么僅僅是一個工具？
筆者認為，工具為什么叫工具，主要以下特點：
3.用戶的真正需求是什么？
理解用戶需求確實很深入的一門藝術，用戶需求分析其實非常體現一個產品經理或決策人的視野和能力。這個需求是剛需？還是非剛需？是顯性需求還是隱性需求？是用戶的需求還是用戶的需求？需求的緊迫度如何？需求頻度呢？（現在都講用戶粘性，低頻度的需求很難熱賣）是點上的需求還是面上的需求？解決的是用戶的痛點和癢點？不要把痛點和癢點混為一談，痛點是雪中送炭，癢點是錦上添花。（有點跑題，掰扯多了，充分了解需求，從人性角度出發的產品才能更為市場接受）。
就Webshell而言，用戶說要檢測Webshell，為什么要檢測Webshell？用戶說要分析日志，為什么要分析日志？目標群體是站長（管理員）的話，他們關心什么。他們心里其實是一連串的問號。
簡單說我受破壞的程度，如何避免不再出現類似情況，同時關心黑客的來源身份手段等信息（黑客畫像）所以Webshell檢測系統我們要做的到底是什么？是覆蓋WEB類安全事件事后處置的一個平臺（或服務）。
主要的功能：
4.用戶想要的是什么效果？
再往俗的說五點：管用、好看、省事、便利、好使。
1."已知" or "未知"
已知的已知，已知的未知，未知的未知，這個最近安全行業也談的比較多，目前圈內熱炒的“威脅情報”，其實應該屬于“已知的未知”，對本地來說是未知威脅，其實是別的地方已經發生過的威脅。真正的“未知的未知”怎么辦，雖然從沒發生過的威脅首次在我們身上發生的概率很小很小，但是目前好多攻擊都是竊取管理員的身份或者合法用戶身份去做一些貌似合法的操作，這些內部發生的“異常”行為，沒有外部的“威脅情報”等數據可對比。
加密會逐步成為網絡流量的常態，基于“協議異常或行為異常”將成為無法解讀內容情景下安全威脅檢測的重要手段。 基于“內容”檢測和基于“行為”檢測互補來發現威脅。異常不一定是威脅，但一般來說威脅一定首先是異常。下圖也表達了基于白名單的異常行為分析的重要性。
當下的安全攻防一個特點就是，未知攻擊會越來越多，你所面臨的攻擊工具可能是從來沒有使用過（或者身邊的監控視野范圍沒有看到過），你手上的webshell樣本再多，攻擊者總是能制作出新的更輕量級功能更全的webshell，如何發現未知的webshell?如何做到天網恢恢疏而不漏？
2.基于流量的Webshell的行為檢測
webshell運行后，B/S數據通過HTTP交互，HTTP請求/響應中可以找到蛛絲馬跡，這是動態特征檢測先前我們說到過webshell通信是HTTP協議。基于payload的行為分析，不僅對已知webshell進行檢測，還能識別出未知的、偽裝性強的webshell。
（1）對webshell的訪問特征（IP/UA/Cookie)、payload特征、path特征、時間特征等進行關聯分析，以時間為索引，還原攻擊事件。
（2）基于異常的HTTP請求
Webshell總有一個HTTP請求，如果在網絡層監控HTTP請求（沒有監控Apache/IIS日志），有一天突然出現一個新的PHP文件請求或者一個平時是GET請求的文件突然有了POST請求，還返回的200，這里就有問題了。
（3）結合威脅情報，對webshell的來源和作者進行深度分析，充分畫像who? when?how? why？(出于什么目的？競爭對手還是惡意攻擊者） how?(攻擊方法）
3.基于沙箱技術的行為特征分析
我們知道中間件需要由某個系統賬戶來完成啟動，所有的WEB腳本文件都通過中間件來完成相應的動作，通過監視系統進程和SQL查詢被中間件使用的情況就可以初步的確定在網站中Webshell的存在并且正在運行。再通過中間件來確定最終發起操作的具體腳本文件就可以完成達到最終檢測、發現Webshell的目的。
本部分筆者了解有限，就簡單的列舉出來幾條發現具體Webshell的方法。
1."大馬"典型操作
經過前面多篇文章的全面介紹想必大家對如何檢測Webshell都有了一定的認識，今天我們一起探討一下如何從網絡流量中去實際的檢測和發現Webshell的。
我們知道“大馬”的目的就是為了提權以及控制。常見的“大馬”一般都是功能較多結構也較為復雜的，“單一文件實現眾多功能”是“大馬”的設計目的之一，一方面大在功能，另一方面大在體積。在形形色色的“大馬”中不難總結其中典型的功能。
當然通常講的“大馬”的功能遠不止，但我們將討論在流量中如何發現這三種功能被攻擊者操作進而發現Webshell的。
2.典型操作之流量Payload
2.1文件操作
讓我們來進行一個簡單的提權工具的上傳的操作，通過Webshell我們可以這樣做：
在文件成功發送到服務器上之后我們來看一下在服務器端我們從網絡流量中抓取的記錄：
緊接著我們從流量中看一下服務器返回的包的內容：
通過抓取實際的網絡流量來獲取一對Payload他們分別出現在訪問請求中和服務器返回的數據中：
Request Payload：POST|upfiles|pr.exe
Return Payload：200
通過上述Payload我們就可以大概總結出以下結論：
該服務器可能已經被入侵并且被成功上傳Webshell后門，攻擊者正在嘗試利用Microsoft Windows RPCSS服務隔離本地權限提升漏洞（MS09-012）漏洞進行提權，也意味著該服務器可能已經有很長未安裝過系統安全補丁。
2.2數據庫操作
再來看一個真實的操作MySQL數據的一個例子：
同樣的在服務器上通過抓包工具獲取的流量信息如下：
服務器返回的流量信息也一并拿出來：
可以看到在一個連接數據庫的操作過程中流量中也產生了眾多的Payload，簡單的將POST數據進行URL解碼可以看的更明顯一些：
auth[driver]=server&auth[server]=localhost&auth[username]=root&auth[password]=&auth[db]=mysql&auth[permanent]=1
再來分析一下Payload對：
Request Payload：POST|localhost|root|mysql
Return Payload：localhost|root|mysql|200|*.sql|user
通過上述成對的Payload可以分析出以下結論：
攻擊者正在試圖訪問MySQL數據庫并且訪問了mysql庫中的表信息攻擊者可以將該mysql庫中的表到導出.sql文件
2.3命令執行
最后我們來看一個命令執行的操作過程：
檢查服務器端獲取到的流量數據：
檢查服務器返回的流量可以得到如下數據：
在這個案例中攻擊者向服務器發送了一條查看當前權限的命令，服務器在獲得指令后運行并將結果通過響應主題反饋給攻擊者。我們來分析一下Payload
Request Payload：POST|act=cmd|cmd=who|precmd
Return Payload：200|net authority\|system
通過上述總結的Payload可以得出以下結論：
服務器已經被入侵，攻擊者試圖向服務器發送查詢中間件運行時所用操作系統權限并獲得了滿意的結果，接下來這臺服務器的悲慘的結局可想而知。
相對于一句話Webshell管理工具而言“大馬”在訪問過程中的Payload相對來說比較簡單也更顯而易見，在檢測的時候也相對容易一些，但是凡事沒有絕對，經過加密和預制命令的Webshell來講也完全可以逃脫上述Payload檢測過程。
1.webshell的典型攻擊序列圖
下圖是一個典型的webshell的攻擊序列圖，利用web的漏洞，獲取web權限，上傳小馬，安裝大馬，然后遠程調用webshell，執行各種命令，以達到獲取數據等惡意目的。
Rsa的一段分析材料，對看見能力做了便利的說明。并針對基于流量的分析手段與傳統的IDS\IPS\SIEM做了對比。 
2.從killchain來分析各階段“看見”能力
從kill chain來看，靠采集系統自身的流量的技術手段，在前兩個階段Reconnaissance、Weaponise這兩個階段是很難看到行為。（結合威脅情報可以更大范圍的看到這兩個階段的信息），基于流量的payload分析技術可以在Delivery、Exploit、Installation、Command &Control (C2)、Action這幾個階段都能看到攻擊行為。
3.從防護方的“安全對抗”能力視角看
安全防護能力分幾個等級
針對web的安全防護能力手段總結如下圖：
4.Webshell的檢測的三種手段
從安全防護能力看，檢測是第一位的能力，webshell的檢測主要有以下幾種方式：
（1）基于流量的webshell檢測引擎
（2）基于文件的webshell分析引擎
（3）基于日志的webshell分析引擎
三種檢測方式，基于文件的檢測，很多時候獲取樣本的部署成本比較高，同時僅僅靠樣本無法看到整個攻擊過程。基于日志的有些行為信息在日志中看不到，總體來說還是基于“流量”的看到的信息最多，也能更充分的還原整個攻擊過程。