0x00 基於流量的檢測方式

---

1.概述

筆者一直在關注webshell的安全分析，最近就這段時間的心得體會和大家做個分享。

webshell一般有三種檢測方式：

• 基於流量模式
• 基於agent模式（實質是直接分析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的深度分析。

0x01 深入使用者的內心

---

1.WEBSHELL是什麼？意味著什麼？

不同人的視角里，Webshell是什麼？

• 程式設計師：一個可以執行的web指令碼檔案。意味著：就是個指令碼。
• 駭客：一個可以拿來控制網站的東西。意味：網站已經搞定，儘量隱藏自己的身份別被發現，同時可以進行後續的破壞行為。
• 使用者（站長）： 發現了Webshell，麻煩來了,認真的管理員都會想到很多很多的問題。網站有漏洞，已經被別人攻擊了。我該怎麼辦？

2.Webshell檢測工具和產品（系統）的區別在哪？

網上有各種各樣的開源和免費工具，暫且不說他們的識別率。這些東西為什麼僅僅是一個工具？

筆者認為，工具為什麼叫工具，主要以下特點：

• 只能解決非常有針對性的問題；
• 使用工具需要預備很多的技術積累和安全知識；（非專業人士用不起來）
• 只會呈現專業結果，解決問題依然需要很多的能力和知識積累。（非專業人士用不起來）
• 工具沒有充分考慮使用者的需求場景和使用者體驗。

3.使用者的真正需求是什麼？

理解使用者需求確實很深入的一門藝術，使用者需求分析其實非常體現一個產品經理或決策人的視野和能力。這個需求是剛需？還是非剛需？是顯性需求還是隱性需求？是使用者的需求還是使用者的需求？需求的緊迫度如何？需求頻度呢？（現在都講使用者粘性，低頻度的需求很難熱賣）是點上的需求還是面上的需求？解決的是使用者的痛點和癢點？不要把痛點和癢點混為一談，痛點是雪中送炭，癢點是錦上添花。（有點跑題，掰扯多了，充分了解需求，從人性角度出發的產品才能更為市場接受）。

就Webshell而言，使用者說要檢測Webshell，為什麼要檢測Webshell？使用者說要分析日誌，為什麼要分析日誌？目標群體是站長（管理員）的話，他們關心什麼。他們心裡其實是一連串的問號。

• 我們的網站是不是被人搞了?
• 這個駭客是哪裡來的？怎麼入侵進來的？為什麼要攻擊我？進來都幹了什麼？（駭客是誰？從那裡來？想幹什麼？）
• 網站到底有什麼漏洞？如何修復漏洞，不讓駭客進來？
• 駭客進來了，可能幹了很多壞事，偷走了資料，可能監聽竊聽了內網很多敏感資訊。
• 還有沒有其他漏洞存在，別被駭客再攻擊進來？
• 有沒有其他同區域的系統遭受攻擊
• 為避免後遺症，是否需要修改系統口令，設定許可權等相關的安全提升措施。
• ……

簡單說我受破壞的程度，如何避免不再出現類似情況，同時關心駭客的來源身份手段等資訊（駭客畫像）所以Webshell檢測系統我們要做的到底是什麼？是覆蓋WEB類安全事件事後處置的一個平臺（或服務）。

主要的功能：

• 監測網站是不是被人入侵了。
• 根據流量找出攻擊者的IP地址。
• 結合外部威脅情報對攻擊者進行畫像，給使用者全面的資訊。
• 基於流量可以還原攻擊場景。
• 根據攻擊場景分析網站存在什麼漏洞。
• 根據漏洞給使用者提供修補加固方案。

4.使用者想要的是什麼效果？

• 告警準確（該報的報 不該報的不報）。
• 告警直觀、形象。（視覺化好）
• 部署成本小：最好0成本部署，或者便利的接入
• 告警獲取方便（比如微信、簡訊通知）。（使用者才沒時間天天去看產品的介面，以後監控類的產品告警資訊是不是幾乎都不要介面了，或者扔幾個牛逼的視覺化圖讓領導看，當然統計類的報表還是需要的）
• 告警處理方便：一鍵式的處理導向，看到告警，我按照自動化的一鍵式場景，可以方便的自動或人工去處理webshell事件。（傻瓜化處理）

再往俗的說五點：管用、好看、省事、便利、好使。

0x02 基於行為分析來發現"未知的Webshell"

---

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的方法。

• 資料庫層面檢測：通常一個正常的網站所有的資料庫操作都透過統一的API來進行的，如果某個指令碼檔案透過另一種方式來嘗試運算元據庫的話就可以追蹤到這個具體的檔案；
• 中介軟體層面檢測：透過第三方的定製化外掛來和中介軟體結合能夠實現對發起操作的指令碼檔案的檢測；
• 系統層面行為檢測：webshell起來如果執行系統命令的話，會有程式。比如Linux下就是nobody使用者起了bash，Win下就是IIS User啟動cmd，這些都是動態特徵。

0x03 基於流量的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檢測過程。

0x04 webshell之"看見"的能力分析

---

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.從防護方的“安全對抗”能力視角看

安全防護能力分幾個等級

• Detect: Can you see/find it?（能否檢測到攻擊）
• Deny: Can you stop it from happening? （能否避免遭受攻擊）
• Disrupt: Can you stop it while it’s happening?（能否阻止正在進行的攻擊）
• Degrade: Can you make it not worth it?（能否讓攻擊者覺得攻擊不值得，降低其攻擊級別）
• Deceive: Can you trick them [the adversary]?（能否誘騙或重定向攻行為）
• Destroy: Can you blow it up? （能否摧毀攻擊者）

針對web的安全防護能力手段總結如下圖：

4.Webshell的檢測的三種手段

從安全防護能力看，檢測是第一位的能力，webshell的檢測主要有以下幾種方式：

（1）基於流量的webshell檢測引擎

• 方便部署，透過流量映象直接分析原始資訊。
• 基於payload的行為分析，不僅對已知webshell進行檢測，還能識別出未知的、偽裝性強的webshell。
• 對webshell的訪問特徵（IP/UA/Cookie)、payload特徵、path特徵、時間特徵等進行關聯分析，以時間為索引，還原攻擊事件。

（2）基於檔案的webshell分析引擎

• 檢測是否包含webshell特徵，例如常用的各種函式。
• 檢測是否加密（混淆處理）來判斷是否為webshell
• 檔案hash檢測，建立webshell樣本hashing庫，進行對比分析可疑檔案。
• 對檔案的建立時間、修改時間、檔案許可權等進行檢測，以確認是否為webshell
• 沙箱技術，根據動態語言沙箱執行時的行為特徵進行判斷

（3）基於日誌的webshell分析引擎

• 支援常見的多種日誌格式。
• 對網站的訪問行為進行建模，可有效識別webshell的上傳等行為
• 對日誌進行綜合分析，回溯整個攻擊過程。

三種檢測方式，基於檔案的檢測，很多時候獲取樣本的部署成本比較高，同時僅僅靠樣本無法看到整個攻擊過程。基於日誌的有些行為資訊在日誌中看不到，總體來說還是基於“流量”的看到的資訊最多，也能更充分的還原整個攻擊過程。