这一题是典型的“流量里找后门”的实操场景拿到一份包含WebShell交互记录的流量包要求在混杂的访问请求里定位恶意会话、还原攻击手法、提取可落地的主机侧IOC。相比直接读日志或者扫文件流量侧分析更贴近真实蓝队的第一视角——攻击者已经落了一个WebShell在服务器上你只能靠网络请求判断它是什么、干了什么、还有没有后续。这套题目适合刚接触Web流量分析的安全工程师也适合在做恶意流量检测产品的朋友拿来对照思路。我在本地复现了一遍完整链路从抓包文件到出结论把中间踩过的坑和判断依据都整理在后面。1. 题目场景还原与解题思路1.1 先搞清楚这是在模拟哪一类攻击拿到流量包不要急着打开Wireshark乱翻先看几个基础信息会话是HTTP还是HTTPS是单向流量还是双向流量时间跨度多大源IP和目的IP大概集中在哪几个网段。这个习惯能帮你快速判断题目想模拟的是外网打点阶段还是内网横向阶段。我解Practice2时的第一印象是这更像“已完成入侵后的后门利用阶段”。流量里没有明显的扫描爆破特征取而代之的是少量但高度可疑的POST请求参数里带明显的函数关键字。攻击者已经拿到了WebShell正在尝试执行命令和读取敏感文件。这类流量往往是防守方最容易漏掉的——单个请求看起来和业务请求长得差不多频率也不高不落在传统WAF的规则阈值里。1.2 分析前的标准动作先建索引再动手会比直接看包更高效。我把流量包导入分析工具后先按TCP会话分组再把所有HTTP请求按URI和参数结构列一次目录。这一步能快速区分哪些是静态资源、哪些是业务接口、哪些是异常请求。建议把所有请求的请求行、响应码、响应体大小记录到表格里后面做时间线还原会非常有用。一个容易忽略的细节是检查流量里的时间戳分布。正常业务的流量在时间轴上是松散的而WebShell操作往往集中在某一小段时间内且请求间隔很有规律——比如攻击者每几秒发一条命令再拿响应内容判断下一步操作。这种时间聚集性本身就是强信号。2. 流量侧的WebShell特征到底长什么样2.1 一句话木马的请求形态WebShell流量最经典的就是一句话木马交互。以PHP为例常见的写法是在POST参数里放eval、assert、system这类能被动态执行的函数配合编码后的payload。流量侧的特征是参数名往往固定比如cmd、pass、a参数值是Base64或十六进制字符串且解码后能看到完整的PHP代码或命令。实际操作中不要只盯着参数名。攻击者会刻意把参数名换成和业务字段相近的名字比如name、token但参数值里的编码特征骗不了人——正常的业务参数不会出现大段Base64且解码后是system(id)这种内容。遇到类似请求把参数值拿去解码就是标准验证动作。2.2 加密型WebShell的破解思路现在很多WebShell为了绕过流量检测把交互内容做了加密。典型做法是自定义异或、AES或自定义算法对payload加密服务端脚本里内置解密逻辑。这类流量的特征是POST数据看起来是随机二进制或不可打印字符响应内容同样是加密后的数据。面对这种情况思路是把流量里出现过的脚本代码还原出来。很多WebShell在使用时会把整个脚本内容传上去流量里会有明显的代码片段特征。只要还原出脚本本体解密逻辑就直接暴露了剩下的事情是写个脚本模拟解密过程把流量里的payload批量解出来。我在练习中就碰到了类似的加密样本最终是靠流量里一个很不起眼的function x($s,$k)定义破的局。2.3 User-Agent和协议头里的细节很多分析只看URL和参数忽略协议头里的异常。WebShell交互有一个特点很多攻击工具或脚本在发送请求时会保留默认的User-Agent比如Python脚本的python-requests/x.x、Go语言的Go-http-client/1.1和正常浏览器差异极大。这类乘客特征一定要看。另外就是Content-Type的一致性正常表单提交是application/x-www-form-urlencoded如果发现POST请求的Content-Type是text/plain或者干脆没有参数却是表单结构这就不对劲。还有一类高级的做法是把WebShell命令藏在HTTP头里比如自定义Cookie字段、Referer字段里。识别这类流量的方法是对比请求头是否有冗余字段以及这些字段值是否符合正常语义。3. 完整的分析实操过程记录3.1 第一轮过滤缩小可疑范围我的做法是先按HTTP方法聚合统计。题目的流量包里GET请求占大头POST请求大概占一成不到但真正的线索全在POST里。把所有POST请求单独拉出来看参数、URI、响应码一列异常点会相对突出。举个例子正常业务POST的参数结构是稳定的键名和值的长度都有规律。如果出现单个请求的参数值和响应体大小相差好几个数量级比如请求只有几十字节、响应却有几千字节这就是典型的命令执行结果回传。另一个角度是看同一URI在短时间内的POST次数如果连续多次带不同参数提交到同一个动态脚本大概率是人在手动测试命令而不是程序在调接口。3.2 第二层聚焦用关键词定位直接证据在可疑请求集合上做深度检索。拿PHP WebShell来说空格和运算符会被URL编码但函数名是明文的可能性很高。eval、assert、system、exec、shell_exec、passthru、popen这些关键字值得逐个检一遍同时把大小写变体也覆盖上。我在做这一步时把“http响应体里出现Linux命令输出格式”作为另一个检索维度。比如响应体以uid开头、包含/bin/bash路径、出现total 数字这种目录列表格式这些都是WebShell执行命令后回显的文本特征。把请求关键字的命中集和响应体的命令特征集做交集基本能锁定核心恶意会话。3.3 第三层还原把攻击者的操作过程串起来锁定会话后逐包还原该TCP流的内容。这里要特别留意时间顺序攻击者的操作是一步接一步的前面的命令输出直接影响后面的命令选择。我复现出来的路径大致是先执行id确认权限再执行pwd和ls看当前目录接着读配置文件和源码文件最后尝试连接内网其他机器。这个还原过程的价值在于产出高质量的审计报告。一个合格的流量分析结论不只是“发现WebShell请求”而是能说清楚攻击者访问了哪些文件、尝试执行了什么命令、有没有把数据外传。其中判断数据外传的重要线索是看流量里是否出现大体积的响应体比如一个请求的响应高达几MB多半是读了日志或数据库备份文件。3.4 第四步同步关联主机侧证据流量分析不能只看流量本身。我在提取出恶意会话的源IP、目标URI、请求参数结构以后还会拿这些IOC去虚拟环境里核对主机侧的web日志和文件落盘情况。比如流量里发现/uploads/avatar.php的POST请求异常就去对应的web目录里查这个文件是否存在、文件修改时间是否和流量时间吻合。做这一步的意义是把流量侧的可疑判断升级为主机侧的确定结论。我在模拟环境里用同样的条件重新发了一次请求响应内容和原始流量完全一致这说明不只是特征命中而是真的把后门功能还原出来了。一个完整的分析流程到这一步才算闭环。4. 常见误判与实战排查技巧4.1 别把代码审计工具的爬虫当攻击我见过不少初学者看到某个Agent的请求就高度紧张结果一查是某扫描器发的正常探测。区分方法是看请求路径是否规律、参数是否有随机后缀、请求频率是否恒定。扫描器的流量往往是机械式的而WebShell流量有明显的人工试探痕迹——命令选择、报错后的调整都带着逻辑。遇到拿不准的请求优先级最高的是去验证参数解码后的内容。请求里如果带着大段Base64就解出来看一眼如果是十六进制串就转ASCII再判断。大部分误判只需要做一个解码动作就能消除。4.2 小心编码绕过的视觉盲区攻击者用URL编码、双重编码、Unicode编码来混淆关键字时直接看流量包里的URI会漏掉线索。处理办法是先做一次标准化把URL解码后的请求体和参数摘出来再分析。我习惯把所有请求的URI和POST body做一次urldecode之后转储成文本再在这个解码后的版本上做全文检索。这类混淆对检测系统的影响比对人工分析更大所以作为人工分析更要补上标准化这一步否则很容易被表象骗过去。4.3 实用排查小工具清单做这类分析我不会只用一款工具通常按场景搭配流量包查看和会话还原主流的抓包分析工具比如Wireshark就够用重点用它的流跟踪功能看完整交互内容。批量请求特征提取用脚本把pcap里的HTTP请求抽成结构化表格方便做统计和排序。编码解码辅助手边备一个支持多种编码的转换工具Base64、十六进制、URL编码、Unicode之间来回切。正则表达式工具在提取出的请求列表里做复杂匹配效率远高于肉眼。4.4 流量分析速查表观察维度正常业务特征WebShell交互特征参数结构键名稳定、值语义明确参数名可区分度低、值多为编码文本响应体与业务输出一致大小波动可预期可能出现命令回显、纯文本结果User-Agent浏览器UA且来源分散工具UA或与URL后缀不匹配时间分布分散、无固定节奏聚焦短时间窗、间隔均匀编码方式一般URL编码Base64、十六进制、自定义加密请求目标静态文件、业务API动态脚本、上传目录、编辑器入口这类表格在出分析报告的时候可以直接作为附件既能支撑结论也能给团队其他人做参考基线。4.5 一个容易被忽略的“低频交互”场景最后补充一种最容易被漏掉的场景低频率的WebShell连接。攻击者不会每秒钟都向服务器发指令有的恶意会话一天只有几次请求刻意模仿正常用户行为。识别这种流量的关键不是看单次请求有多可疑而是看“某一对源IP和目标URI”的请求长期存在、且请求内容带有缓慢递增的试探性。如果平台上没有现成的UEBA或流量基线能力人工判断时要重点对比业务基线一个正常业务接口不会突然开始接收内容为编码字符串的POST请求时间还持续多天。把这类长期会话拉出来看历史流量往往能发现更早的入侵痕迹。个人复盘的一点体会整套练习做下来我最大的感受是流量分析能力本质上是在训练“分层过滤”的思维每一个单点特征都可能被绕过但多个维度交叉验证会大幅提高准确率。建议大家练习时不要只满足于找到题目里的那个恶意会话而是把完整链路跑通从流量线索到主机落地点再到功能还原最后能独立产出一份带证据链的溯源报告。我每次做完这类题目都会顺手把分析过程中用的检索式、解码脚本存成模板下一次遇到类似的加密WebShell能节省大量重复劳动。