1. 項目概述為什么需要識別Webshell流量在安全運維和應急響應的日常工作中Webshell的檢測與處置是繞不開的核心議題。Webshell這個被上傳到Web服務器上的惡意腳本就像一把插在服務器心臟上的“后門鑰匙”。攻擊者通過它可以在不觸發(fā)常規(guī)安全告警的情況下遠程執(zhí)行命令、竊取數(shù)據(jù)、甚至作為跳板進行橫向滲透。傳統(tǒng)的基于文件特征碼的殺毒軟件或者基于行為規(guī)則的HIDS主機入侵檢測系統(tǒng)在面對日益“免殺化”、“混淆化”的Webshell時常常力不從心。更棘手的是攻擊者一旦得手其后續(xù)的遠程控制流量往往偽裝在正常的HTTP/HTTPS協(xié)議中如同水滴入海難以分辨。這時網(wǎng)絡流量分析的價值就凸顯出來了。無論Webshell本身如何偽裝攻擊者與它之間的“對話”——即網(wǎng)絡流量——總會留下痕跡。Wireshark作為一款開源、強大且被廣泛使用的網(wǎng)絡協(xié)議分析工具為我們提供了透視這些“對話”的顯微鏡。通過分析流量中的協(xié)議特征、載荷內容、交互模式我們可以繞過文件層面的對抗直接從通信行為上識別出異常。這不僅是應急響應中溯源分析的關鍵也是構建縱深防御體系、完善檢測規(guī)則如用于Suricata、Snort等NIDS的重要數(shù)據(jù)來源。本指南將聚焦于實戰(zhàn)中最常遇到的四款經(jīng)典Webshell管理工具中國菜刀、蟻劍、冰蝎和哥斯拉。它們各有特色流量特征也迥然不同。掌握通過Wireshark快速識別它們的方法意味著你能在安全事件發(fā)生時更快地定位威脅、理解攻擊者意圖并采取遏制措施。這不僅僅是工具的使用教學更是一種從網(wǎng)絡層面思考安全問題的視角訓練。2. 核心思路從混沌流量中提取特征指紋面對海量的網(wǎng)絡數(shù)據(jù)包直接進行人工分析無異于大海撈針。我們的核心思路是“由面到點由協(xié)議到載荷”層層遞進逐步縮小可疑范圍最終定位到特征性的“指紋”。這個分析流程可以固化為一套可重復的方法論。2.1 分析流程總覽一個高效的Webshell流量識別流程通常遵循以下四個步驟流量捕獲與過濾首先我們需要在正確的網(wǎng)絡位置如Web服務器前端、核心交換機鏡像口捕獲到完整的雙向流量。然后使用Wireshark的顯示過濾器快速聚焦到與疑似受害IP和Web服務端口通常是80/443相關的數(shù)據(jù)包排除無關干擾。協(xié)議行為初篩在HTTP/HTTPS流量中初步觀察其協(xié)議行為是否反常。例如一個普通的網(wǎng)頁瀏覽請求和Webshell的命令執(zhí)行請求在請求頻率、數(shù)據(jù)包長度分布、交互模式上可能存在肉眼可見的差異。載荷深度解析這是最關鍵的一步。我們需要深入查看HTTP請求的請求體POST Data和響應體。通過Wireshark的“追蹤流”功能重組應用層數(shù)據(jù)并仔細觀察其中是否包含可疑的關鍵字、編碼模式如Base64、十六進制、序列化數(shù)據(jù)或特定工具的標識符。特征匹配與判定將觀察到的可疑特征與已知的Webshell管理工具的特征庫進行比對。這些特征包括但不限于特定的URL參數(shù)名、Cookie字段、HTTP頭部、載荷中的魔術字、加密前的固定字符串等。一旦匹配成功即可做出判定。這個流程的成功依賴于對工具本身通信原理的理解。接下來我們將深入這四款工具的通信機制理解其流量特征的產(chǎn)生根源。2.2 工具通信原理與特征根源為什么不同工具的流量看起來不一樣根本在于它們的設計理念和實現(xiàn)方式。中國菜刀屬于“上古神器”設計簡單直接。其流量通常是明文或經(jīng)過簡單的Base64/十六進制編碼。它在請求中會通過固定的參數(shù)如z0傳遞經(jīng)過編碼的命令響應也是直接的命令輸出編碼。特征非常明顯幾乎“寫在臉上”。蟻劍作為菜刀的現(xiàn)代化繼承者它采用了插件化架構和更多的編碼器。默認情況下其流量也包含特征明顯的參數(shù)如_0x...這種形式的參數(shù)名和可識別的載荷結構。雖然支持自定義但很多使用者會采用默認配置從而暴露特征。冰蝎這是一款在流量隱蔽性上實現(xiàn)飛躍的工具。它的核心特征在于動態(tài)密鑰協(xié)商和全程加密通信?？蛻舳伺cWebshell首次連接時會協(xié)商一個只有雙方知道的密鑰后續(xù)所有指令和輸出都使用此密鑰進行AES等加密。因此其流量在Wireshark中查看通常是毫無規(guī)律、高熵的二進制數(shù)據(jù)傳統(tǒng)的關鍵字搜索完全失效。哥斯拉可以看作是冰蝎思路的進一步拓展和復雜化。它同樣采用強加密通信并且支持更多的加密算法和編碼方式。此外哥斯拉在HTTP頭部、Cookie等處也做了更多的隨機化和偽裝使得其流量更像正常的瀏覽器請求隱蔽性極強。理解這些原理差異是我們能識別它們的前提。對于菜刀、蟻劍我們主要進行“特征匹配”對于冰蝎、哥斯拉我們則需要進行“行為異常分析”和“加密流量識別”。注意本文討論的特征是基于這些工具的常見默認配置或典型使用模式。高水平的攻擊者會修改源代碼、自定義編碼器和通信協(xié)議以規(guī)避檢測。因此流量分析不能作為唯一的檢測手段必須與日志分析、主機行為監(jiān)控相結合。3. 實戰(zhàn)環(huán)境搭建與Wireshark準備在開始分析之前我們需要一個受控的實戰(zhàn)環(huán)境。強烈建議在虛擬機或隔離的網(wǎng)絡環(huán)境中進行以下操作切勿在生產(chǎn)環(huán)境或非授權系統(tǒng)上嘗試。3.1 實驗環(huán)境配置靶機準備一臺虛擬機安裝帶有PHP/ASP/ASP.NET/JSP等一種或多種語言環(huán)境的Web服務器如Apache PHP 或IIS。這里以Apache PHP為例。Webshell準備從安全研究渠道獲取上述四款工具的典型Webshell服務端腳本。例如菜刀一個包含eval($_POST[‘z0’]);的PHP文件。蟻劍使用蟻劍生成器生成的默認編碼的PHP Shell。冰蝎使用冰蝎自帶的服務器端腳本如server.jsp。哥斯拉使用哥斯拉生成的相應腳本。 將這些腳本上傳到靶機的Web目錄下并記錄訪問地址。攻擊機另一臺虛擬機安裝中國菜刀、蟻劍、冰蝎、哥斯拉的客戶端。確保攻擊機與靶機網(wǎng)絡互通。監(jiān)控點這是關鍵。有兩種方式捕獲流量在靶機上直接抓包在靶機系統(tǒng)上安裝Wireshark或使用tcpdump命令行工具監(jiān)聽提供Web服務的網(wǎng)卡如eth0。在網(wǎng)絡中鏡像流量更接近實戰(zhàn)的場景。將靶機所在的網(wǎng)絡端口流量鏡像到運行Wireshark的監(jiān)控機上。這需要在交換機上配置端口鏡像SPAN。3.2 Wireshark關鍵配置與過濾技巧安裝好Wireshark后進行以下配置能讓分析事半功倍首選項設置外觀 - 列建議添加“Src Port (源端口)”和“Dst Port (目標端口)”列方便快速查看通信雙方。協(xié)議 - HTTP確保啟用了“Reassemble HTTP bodies spanning multiple TCP segments”重組跨TCP分片的HTTP主體這對于查看完整的POST數(shù)據(jù)至關重要。核心顯示過濾器 捕獲到海量數(shù)據(jù)包后使用顯示過濾器快速定位ip.addr 192.168.1.100只看與特定IP假設靶機IP相關的所有流量。http只顯示HTTP協(xié)議流量。tcp.port 80顯示源或目的端口為80的TCP流量。組合過濾ip.addr 192.168.1.100 and tcp.port 80可以精確定位到靶機的Web流量。http.request.method POST只查看POST請求因為Webshell命令執(zhí)行大多通過POST傳遞。tcp contains “eval”在TCP載荷中搜索明文關鍵字“eval”注意這對加密流量無效。這是一個簡單但有時有效的初步篩查。關鍵功能“追蹤流” 在任何一個HTTP請求或響應包上右鍵選擇“追蹤流 - TCP流”或“追蹤流 - HTTP流”。這個功能會將一次完整的TCP會話或HTTP事務的所有數(shù)據(jù)重組并顯示在一個窗口里并以ASCII或十六進制形式呈現(xiàn)。這是分析Webshell載荷最常用、最強大的功能沒有之一。窗口上方可以選擇“整個會話”、“客戶端到服務器”請求、“服務器到客戶端”響應并可以切換顯示格式ASCII, 十六進制 C數(shù)組等。對于加密流量十六進制視圖可能更有用。4. 四款Webshell流量特征深度解析現(xiàn)在我們進入最核心的部分。假設我們已經(jīng)捕獲了一次完整的Webshell連接和操作流量我們將逐一拆解它們的特征。4.1 中國菜刀特征明顯的“古典派”菜刀的流量幾乎是最容易識別的。特征一固定的請求參數(shù)在Wireshark中追蹤其TCP流你會清晰地看到POST請求中有一個固定的參數(shù)名。對于PHP版本通常是z0、z1、z2等。例如POST /shell.php HTTP/1.1 ... Content-Type: application/x-www-form-urlencoded z0QGV2YWwoJF9QT1NUWyd6MSddKTs%3Dz1ZWNobyAnSGVsbG8gQ2hpbmVzZSBDaG9wcGVyJzs%3D這里z0的值是一段Base64編碼%3D是的URL編碼解碼后通常是eval($_POST[‘z1’]);。而z1的值是另一段Base64解碼后是實際的PHP命令如echo ‘Hello Chinese Chopper’;。特征二編碼模式固定菜刀默認使用Base64編碼有時也會使用十六進制編碼。在流量中你會看到大量由A-Z, a-z, 0-9, , /及填充符組成的字符串這是典型的Base64特征。即使參數(shù)名被修改這種密集的、作為參數(shù)值的Base64串出現(xiàn)在POST請求中也是極高的可疑信號。特征三響應內容特征服務器響應同樣包含特征。成功執(zhí)行命令后響應體開頭通常會有一個固定的“標識頭”后面跟著命令輸出。這個標識頭在菜刀的各個版本中可能不同但通常是一個可打印字符的固定組合用于客戶端識別響應開始。在TCP流中你可能會在返回的HTML源碼前看到類似{phpinfo};或其它特定分隔符。Wireshark快速識別法過濾POST請求http.request.method POST在列表欄查看Info列如果看到POST請求的URI路徑可疑如隨機文件名。選中該包右鍵追蹤流 - TCP流。在ASCII視圖中直接搜索z0、z1、z2或base64樣式的長字符串。幾乎一眼可辨。4.2 蟻劍繼承與演變蟻劍的默認流量比菜刀稍隱蔽但特征依然顯著。特征一參數(shù)名特征蟻劍默認生成的Payload其請求參數(shù)名具有明顯的模式通常以_0x開頭后面跟著一串十六進制數(shù)字例如_0x5c8f、_0x3bf2等。這是其前端代碼動態(tài)生成參數(shù)名時留下的特征。POST /antsword.php HTTP/1.1 ... Content-Type: application/x-www-form-urlencoded _0x5c8fY21k_0x3bf2ZWNobyAnSGVsbG8gQW50U3dvcmQnOw%3D%3D特征二載荷結構特征即使參數(shù)名被自定義其載荷內容也可能暴露。蟻劍的通信協(xié)議有固定的結構。在TCP流中你可能會看到經(jīng)過Base64編碼的JSON數(shù)據(jù)。解碼后其結構類似{action: exec, data: {cmd: whoami}}或者看到一些固定的鍵名如iv、data如果使用了加密插件但默認的編碼器下結構相對固定。特征三Cookie或Header中的標識某些版本的蟻劍或特定配置下會在HTTP請求的Cookie或User-Agent頭部插入可識別的字符串作為“密碼”或標識。Wireshark快速識別法過濾POST請求到可疑路徑。追蹤TCP流在ASCII視圖中查找_0x開頭的參數(shù)名。如果沒有查看整個請求體尋找類似Base64編碼的長字符串嘗試解碼。如果解碼后的字符串包含action、cmd、path等JSON鍵名嫌疑很大。檢查HTTP頭部的Cookie和User-Agent字段尋找異常值。4.3 冰蝎加密流量的挑戰(zhàn)者冰蝎的流量分析是真正的挑戰(zhàn)因為你看不到任何明文的可讀內容。特征一首次請求的“握手”特征這是識別冰蝎最關鍵的一步。客戶端首次連接Webshell時會發(fā)送一個特殊的GET或POST請求用于密鑰協(xié)商。這個請求的URL可能帶有特定參數(shù)或者其響應體是固定的、用于計算密鑰的“密鑰因子”。在Wireshark中你需要找到這個“第一次”請求。它的響應內容長度固定且較短如16字節(jié)、32字節(jié)內容看起來是隨機二進制數(shù)據(jù)。這與其他正常的網(wǎng)頁請求截然不同。特征二后續(xù)流量的高熵與固定長度密鑰協(xié)商成功后所有后續(xù)請求和響應都變?yōu)榧用軤顟B(tài)。在Wireshark中觀察這些數(shù)據(jù)包內容不可讀追蹤TCP流無論是ASCII視圖還是十六進制視圖都看不到任何可讀的英文單詞、命令或路徑全是亂碼。熵值高數(shù)據(jù)看起來完全隨機沒有明顯的模式。長度可能規(guī)整由于使用AES等分組加密算法密文長度往往是16字節(jié)AES塊大小的整數(shù)倍。你可以觀察連續(xù)多個POST請求的Content-Length它們可能非常接近甚至是相同的值因為執(zhí)行不同命令的請求結構被填充到了相同長度。特征三HTTP頭部相對“干凈”冰蝎的默認配置下其HTTP頭部如User-Agent會模仿得比較像正常瀏覽器沒有明顯的工具特征。這增加了識別難度。Wireshark快速識別法行為分析法尋找“孤立的”加密會話找到一個與Web服務器IP的TCP會話其流量模式為1個簡短的HTTP請求/響應可能是密鑰協(xié)商緊接著一系列Content-Length較大且數(shù)值規(guī)整的POST請求和響應。檢查響應內容選中一個后續(xù)的POST請求的響應包追蹤TCP流。如果響應體全部是亂碼且長度可能是16的倍數(shù)嫌疑激增。對比基線對比同一Web服務器上其他正常頁面的訪問流量。正常頁面如首頁、登錄頁的請求響應內容通常是HTML、JSON等可讀文本或格式數(shù)據(jù)。一個訪問/admin.jsp假設卻返回完全加密二進制數(shù)據(jù)的連接極不正常。輔助判斷雖然內容加密但URL路徑可能具有Webshell特征如非常規(guī)的、隨機字符串命名的.jsp、.php文件。4.4 哥斯拉集大成的“隱身者”哥斯拉繼承了冰蝎的加密通信思想并做了更多偽裝。特征一動態(tài)的HTTP頭部哥斯拉可以隨機生成每次請求的HTTP頭部包括User-Agent、Accept、Accept-Language等使其看起來更像來自不同瀏覽器或設備的請求規(guī)避基于固定Header的簡單規(guī)則匹配。特征二Cookie中可能攜帶加密信息哥斯拉有時會將一些會話狀態(tài)或校驗信息加密后放在Cookie中傳遞而不是全部放在POST體內。這使得其流量在表面上更分散。特征三多階段與多協(xié)議支持哥斯拉支持更多的加密算法和通信模式可能使用multipart/form-data格式上傳文件其流量模式比冰蝎更多變。但其核心特征依然是通信主體內容無論是POST體還是部分Cookie值是加密的高熵數(shù)據(jù)。特征四連接保活與心跳哥斯拉的連接可能具有更長的時間周期和規(guī)律的心跳包以維持會話。在流量中可能表現(xiàn)為在長時間無操作后仍有定時的、小數(shù)據(jù)量的POST請求發(fā)生。Wireshark快速識別法 識別哥斯拉需要結合冰蝎的識別方法并更加關注行為異常和元數(shù)據(jù)特征。加密內容判斷同冰蝎確認通信主體是否為不可讀的加密數(shù)據(jù)。頭部隨機性分析觀察來自同一源IP的多個請求其User-Agent等頭部是否在頻繁、無規(guī)律地變化正常用戶會話通常保持相對穩(wěn)定。URL與參數(shù)異常雖然內容加密但請求的URL路徑、查詢字符串如果有可能顯得突兀。例如對一張圖片的URL如.jpg發(fā)起大量POST請求這本身就很可疑。會話持續(xù)性觀察TCP會話的持續(xù)時間、數(shù)據(jù)包數(shù)量。一個長時間存在、進行多次POST交互、但從未請求過任何靜態(tài)資源如CSS, JS, 圖片的會話非?？梢?。5. 實戰(zhàn)演練從抓包到判定的完整過程讓我們模擬一個實戰(zhàn)場景監(jiān)控報警顯示內網(wǎng)一臺Web服務器192.168.56.101存在異常外連行為。你被要求快速分析其流量判斷是否被植入Webshell。步驟1定位與過濾你在核心交換機上已經(jīng)鏡像了該服務器的流量并保存為webserver.pcapng。用Wireshark打開。 首先應用過濾器ip.addr 192.168.56.101 and tcp.port 80。這能聚焦到該服務器所有的HTTP流量。步驟2協(xié)議行為初篩瀏覽過濾后的數(shù)據(jù)包列表。你注意到除了大量的GET /index.php、GET /static/logo.png等正常請求外有一個TCP會話格外顯眼它訪問的路徑是/wp-content/uploads/temp/下的一個隨機名.php文件假設網(wǎng)站是WordPress。該會話中先是一個簡短的GET請求可能返回200 OK但內容長度很短比如50字節(jié)緊接著是幾十個POST請求到這個同一文件。這些POST請求的Content-Length都在1000字節(jié)左右非常穩(wěn)定。而服務器的響應Content-Length也很大幾百到幾千字節(jié)但請求和響應之間沒有夾雜任何對圖片、樣式表等資源的請求。這種“單一端點、密集POST、無資源加載”的模式已經(jīng)高度可疑。你右鍵點擊第一個POST包選擇追蹤流 - TCP流。步驟3載荷深度解析TCP流窗口打開。你切換到ASCII視圖。情況A你看到了明文的z0...和Base64字符串。結論高度疑似中國菜刀。情況B你看到了_0x5c8f...之類的參數(shù)名。結論高度疑似蟻劍。情況C你看到的請求體和響應體全是亂碼像‰PNG...開頭但又不對或者完全是不可讀字符。你嘗試在流里搜索eval、system、POST等關鍵字一無所獲。結論流量被加密疑似冰蝎或哥斯拉。步驟4特征匹配與最終判定針對情況C你需要進一步判斷你仔細看這個TCP流的開頭。發(fā)現(xiàn)第一個客戶端請求是一個GET請求到那個php文件沒有參數(shù)。服務器響應很短內容是6gB1fP...一段Base64樣式的字符串但解碼后也是亂碼。這符合冰蝎的密鑰協(xié)商特征。你查看后續(xù)POST請求的HTTP頭部。User-Agent是Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36看起來正常。Cookie為空。你注意到所有POST請求的Content-Type都是application/x-www-form-urlencoded但載荷卻是二進制。這有點矛盾正常該類型的POST體應該是鍵值對文本。你對比另一個正常用戶登錄的POST請求/wp-login.php其TCP流里清晰可見logadminpwd...這樣的明文。基于以上首次特殊GET請求、后續(xù)POST內容全加密、Content-Type與內容不符、與正常流量對比鮮明。最終判定該流量符合冰蝎Webshell通信特征。你可以將相關IP、端口、URL路徑、以及這個特征“與特定URI的TCP會話首次為短響應GET后續(xù)為固定長度加密POST”記錄下來作為安全事件響應的證據(jù)并可以此特征編寫入侵檢測系統(tǒng)的規(guī)則。6. 進階技巧與自動化識別思路手動分析在應急時很有效但無法應對海量流量。我們需要將其轉化為自動化能力。6.1 Wireshark顯示過濾器與著色規(guī)則你可以將上述特征保存為Wireshark的顯示過濾器或著色規(guī)則實現(xiàn)快速高亮。菜刀過濾器http.request.uri contains “.php” and http.request.method “POST” and (tcp contains “z0” or tcp contains “z1”)蟻劍過濾器http.request.method “POST” and http.request.uri matches “\\.(php|jsp|asp|aspx)$” and frame contains “_0x”注意frame contains可能性能較差僅用于小流量分析冰蝎/哥斯拉行為過濾這個更復雜可以嘗試過濾出那些響應內容長度較大但內容看似“非文本”的請求。一個粗略的思路是尋找Content-Type為text/html但內容非ASCII的響應。但這可能誤報。更可靠的是在NIDS中實現(xiàn)。你可以為這些過濾器設置不同的顏色如菜刀標紅蟻劍標黃這樣在捕獲流量時可疑連接會立即突顯出來。6.2 編寫Suricata/Snort規(guī)則網(wǎng)絡入侵檢測系統(tǒng)NIDS如Suricata和Snort可以實時分析流量。我們可以將特征提煉成規(guī)則。菜刀規(guī)則示例Suricata格式alert http any any - $HOME_NET any (msg:WEBSHELL Possible China Chopper Activity; flow:established,to_server; http.method; content:POST; http.uri; content:.php; fast_pattern; content:z0; http.client_body; depth:4; sid:1000001; rev:1;)這條規(guī)則檢測流向內網(wǎng)的HTTP流量方法是POSTURI包含.php并且客戶端請求體中含有z0字符串。冰蝎規(guī)則基于首次響應特征 這需要更精細的規(guī)則可能需要對首次響應的長度和內容熵進行判斷。一個簡化的思路是檢測對特定擴展名文件的請求其響應長度非常短如16-64字節(jié)且緊接著有加密POST。這可能需要結合多個規(guī)則或使用Lua腳本實現(xiàn)更復雜的邏輯。6.3 流量行為畫像與機器學習對于冰蝎、哥斯拉這種加密Webshell傳統(tǒng)特征匹配失效。此時需要采用流量行為分析Network Traffic Analysis, NTA。統(tǒng)計特征計算一個HTTP會話的以下特征POST請求數(shù)量占比、請求/響應數(shù)據(jù)包平均大小、請求間隔時間規(guī)律性、會話持續(xù)時間、上行/下行流量比等。Webshell會話的這些特征可能與正常API調用或網(wǎng)頁瀏覽有顯著差異。熵值計算計算請求體和響應體的信息熵。加密數(shù)據(jù)的熵值通常遠高于未加密的文本或HTML。機器學習模型收集大量正常的Web流量和已知的Webshell流量作為訓練集提取上述行為特征和統(tǒng)計特征訓練分類模型如隨機森林、XGBoost。模型可以學習到正常與異常流量的微妙差異從而識別出新型或變種的加密Webshell。在實際工作中手動Wireshark分析是“最后一公里”的深度驗證和取證而自動化規(guī)則和NTA系統(tǒng)才是7x24小時守護網(wǎng)絡的“哨兵”。兩者結合方能構建起有效的Webshell流量檢測防線。7. 常見問題與排查技巧實錄在實際分析中你會遇到各種復雜情況。以下是一些常見問題及處理思路問題1流量是HTTPS加密的Wireshark看到的是TLS記錄怎么辦這是最大的挑戰(zhàn)。要解密HTTPS流量需要滿足以下條件之一擁有服務器私鑰在Web服務器上配置Wireshark或tcpdump將RSA私鑰導入Wireshark編輯 - 首選項 - Protocols - TLS - RSA keys list。這樣Wireshark可以解密所有到此服務器的TLS流量。僅用于安全測試和內部排查切勿泄露私鑰中間人解密有條件在內網(wǎng)部署SSL/TLS解密代理所有流量經(jīng)過該代理解密后再轉發(fā)。這需要部署專門的設備或軟件并處理好證書信任問題。分析元數(shù)據(jù)如果無法解密內容只能分析元數(shù)據(jù)TLS握手階段使用的協(xié)議版本、密碼套件可能與客戶端工具有關、服務器證書信息是否自簽名、異常、連接的時間規(guī)律、數(shù)據(jù)包長度和頻率的異常模式等。這些信息價值有限。問題2攻擊者使用了自定義編碼或加密特征不明顯怎么辦回歸行為分析放棄對載荷內容的直接解讀專注于會話行為異常。參考第6.3節(jié)的行為畫像方法。上下文關聯(lián)這個可疑連接發(fā)生前是否有文件上傳漏洞的利用流量是否有登錄爆破的流量將Webshell連接與前期攻擊入口點關聯(lián)起來。主機側驗證流量分析存疑時立即登錄可疑服務器進行主機側排查。檢查Web目錄下最近修改的文件、異常進程、網(wǎng)絡連接netstat -antp與流量分析結果相互印證。問題3Wireshark過濾器似乎不起作用抓不到想要的包確認捕獲位置確保Wireshark在正確的網(wǎng)卡上抓包。如果監(jiān)控鏡像口確保交換機鏡像配置正確。檢查過濾器語法Wireshark顯示過濾器語法嚴格。http和http.request不同contains對大小寫敏感。使用自動補全功能減少錯誤。使用更寬泛的過濾器如果ip.addr and tcp.port過濾后無結果先嘗試只使用ip.addr x.x.x.x看看是否有該IP的任何流量確認流量是否真的被捕獲。問題4如何區(qū)分冰蝎和哥斯拉的流量在Wireshark層面僅通過單次流量捕獲很難100%區(qū)分。可以關注以下幾點傾向性特征哥斯拉的頭部偽裝更徹底觀察連續(xù)請求中的User-Agent、Accept-Language等字段如果變化多端且無規(guī)律哥斯拉的可能性更大。哥斯拉可能使用Cookie傳遞數(shù)據(jù)檢查Cookie字段如果存在長且看起來隨機的字符串并隨著請求變化可能是哥斯拉。工具指紋如果能在客戶端或服務器端獲取樣本進行靜態(tài)分析是更準確的方法。流量分析更多是用于發(fā)現(xiàn)和預警。一個關鍵的排查技巧對比分析法。在分析可疑流量時永遠不要孤立地看它。同時打開一個已知正常的、對同一網(wǎng)站的用戶訪問流量例如你手動訪問一下網(wǎng)站首頁和登錄頁面。將兩個TCP流窗口并排對比觀察它們在請求頻率、數(shù)據(jù)包大小分布、載荷可讀性、HTTP頭部完整性、交互模式上的差異。這種差異往往比任何單一特征都更能說明問題。正常的用戶流量是“雜亂”的請求HTML、JS、CSS、圖片有重定向有緩存請求而Webshell流量通常是“純凈”的只與一個動態(tài)腳本進行密集的、結構化的數(shù)據(jù)交換。培養(yǎng)這種對比的直覺能極大提升你的分析速度和準確度。