★ FEATURED ARTICLE 1. 先说清楚为什么要研究Webshell攻防搞安全的人都知道Webshell这东西就像一只打不死的小强。你辛辛苦苦把服务器漏洞补了、弱口令改了、访问控制加了结果人家早已在你Web目录里藏了一个脚本文件通过URL就能远程控制服务器。你甚至不知道它什么时候上去的直到某天数据库被拖、文件被篡改、服务器变成肉鸡你才从日志里发现一条可疑的POST请求。我在某公司的安全团队做应急响应时处理过的Webshell事件没有一百也有八十。最典型的场景是某台业务服务器运行得好好的突然CPU飙高排查后发现Web目录下的某个图片文件被改成了PHP脚本或者某运维同事用编辑器全文搜索发现一行诡异代码躺在某个老旧的配置文件里。这个“一行诡异代码”就是圈内常说的一句话木马而管理它最顺手的工具之一就是蚁剑。这篇文章我想站在防御者和分析者的角度把这类后门从文件形态、通信特征、检测方法到本地实战环境搭建完整拆一遍。内容仅限于本地隔离环境全部样本都是自建演示用绝不涉及真实系统。适合谁来读安全运维、蓝队成员、刚入门的Web安全学习者以及被Webshell问题困扰过、想搞清楚“它到底长什么样、我该怎么防”的开发者和服务器管理员。下面全部是我实际处理事件时沉淀下来的思路和踩坑记录希望能帮你少走弯路。2. 一句话木马的文件特征与静态识别2.1 这类脚本长什么样一句话木马的核心逻辑非常简单接收外部传入的参数把参数内容当作代码或命令来执行。以PHP环境为例常见写法会用到代码执行类函数比如eval、assert再配合字符串处理函数做解码比如base64_decode、gzinflate、str_rot13把传输过来的加密内容还原成代码然后执行。很多人以为一句话木马必然是单个恶意PHP文件其实大错特错。真实环境里我见过太多变体有的是把恶意代码插入到正常的图片文件末尾让脚本解析器在遇到?php时开始执行有的把代码写进日志文件再用包含函数去加载还有的干脆把一句话代码拆成多段藏在十几个不相关的文件里通过include串联起来。防御时如果只按“文件名可疑”来查基本查不到。这里有个很关键的基础知识点PHP里很多函数具备“代码执行”能力但长得并不像eval那么明显。比如preg_replace在/e修饰符下会把替换字符串当作PHP代码执行array_map配合回调函数也能执行甚至${}字符串插值在某些情况下都能引发代码执行。攻击者选函数时特别偏爱这种看起来人畜无害、但实际上能跑代码的“曲线救国”写法。2.2 静态扫描规则怎么定静态查杀是检测Webshell的第一道防线也是最容易出误报的地方。我自己做查杀规则时会分层来建第一层看高危函数调用组合。单个eval出现在正常业务代码里并不罕见但eval加上base64_decode、gzuncompress这类解码函数再配合$_POST、$_REQUEST、$_COOKIE等请求变量这个组合就很可疑。简单说如果一个文件里同时出现了“外部输入”“解码函数”“代码执行函数”这三个要素它几乎就是Webshell。第二层看文件头部和尾部特征。正常PHP文件要么写业务逻辑要么写注释说明而恶意脚本往往刻意掩盖用途文件头没有版权说明尾部夹杂大量编码后的乱码字符串。很多脱库事件里查出来的木马整文件就一行代码前面是一堆废话注释真正的payload藏在最后。第三层看代码结构特征。比如极其少见的长字符串拼接、字符串逆序写入、变量动态命名等方式都是攻击者为了对抗静态检测做的混淆。我常说木马代码里的“刻意”感最强——正常人写代码追求可读性恶意代码反而处处提防你读懂它。2.3 常见伪装手法与识别陷阱伪装是Webshell绕不开的话题。常见的手法大概有这么几类改扩展名、改文件头、混入业务文件、利用大小写和空格迷惑扫描器以及在字符串里做拼接让关键词不连续。比如把eval拆成ev.al再借助PHP的动态变量名在运行时重组静态规则如果只用关键词匹配就会漏掉。我见过一个印象很深的样本攻击者把一句话木马改成了.jpg文件然后在某个正常的include逻辑里把图片路径当参数传进去。静态扫描时直接按文件扩展名过滤这个jpg就被漏掉了再深挖一层发现这个jpg文件大小异常开头是正常图片数据中间夹了一段PHP代码。这类隐藏在“看似正常文件”里的Webshell靠传统的扩展名和关键词双重过滤完全不够。所以要提醒一点静态扫描规则宁可多写几条可疑特征也不要过早追求低误报。规则可以先粗后细先把所有可疑文件捞出来人工过一遍再根据结果收紧范围。我自己的习惯是用YARA规则做初筛一次扫全盘把评分最高的前几百个文件捞出来人工复核效率比纯靠眼睛翻目录高得多。3. 蚁剑通信行为画像与流量分析3.1 连接协议的流量指纹这里要澄清一点我下面说的蚁剑全部是从防御角度去研究它的通信行为特征用来做威胁追踪和日志告警不是教怎么使用工具连接服务器。实际应急响应中我拿到一份流量包或访问日志最想确认的问题只有一个这个连接是不是后门通信。蚁剑这类Webshell管理工具通信模式和普通浏览器访问有明显差异。普通用户访问页面时GET请求居多POST请求通常就是提交个表单参数名跟业务强相关。而蚁剑连接后门时几乎每次都是POST请求请求体常常是很长的URL编码字符串参数名往往只有一个或两个内容以base64编码为主解码之后是一段结构化的数据包。这种“单个参数携带超长编码内容”的模式在业务流量里极少出现。另一个特征是请求头。虽然攻击者可以伪造User-Agent但默认状态下蚁剑发送的请求头与主流浏览器差异很大字段顺序、Accept头的写法、有没有Referer这些细节都可以作为初步判断依据。做流量检测时我不建议只盯着某一个特征最好是把“请求头异常”“参数结构异常”“响应数据异常”三个条件组合起来评分超过阈值再告警这样误报率能压到很低。3.2 从访问日志中抽取异常特征如果你手头没有专业抓包工具只有一份Web访问日志照样能发现线索。我处理过的一起事件里攻击者用后门在目标服务器上执行命令每次通信都是POST一个很长的body到某个.php文件日志里记录的状态码全是200。正常用户访问一个页面POST频率不会那么稳定也不会每次都带着超长参数。攻击者操作后门时请求节奏是有规律的基本是“点击一下发一个包”间隔均匀。从日志里抽取异常特征我会关注三个维度频率、大小、目标。频率上同一个URL在短时间内被高频POST且参数长度普遍超过1000字节这基本可以判定为脚本自动化操作。大小上正常POST表单很少超过几KB而后门通信里动辄几十KB的body很常见。目标上被请求的页面如果是图片、静态资源、或者平时根本没人用的老文件突然产生高频POST那基本等于报警。3.3 响应数据里藏着哪些线索检测Webshell通信响应数据同样重要。后门执行命令后会把结果拼进响应体里返回给客户端。这个响应体可能是一大段经过编码的文本正常情况下不会出现在静态页面中。如果你在WAF或者IDS的日志里看到某个URL的响应长度突然从几KB飙到几百KB且内容不是标准JSON也不是HTML那就要重视起来。我曾经用这个思路还原过一起数据窃取事件。攻击者把后门与一个正常API接口做了融合有人访问这个接口时返回正常JSON数据但如果请求里带了特定参数后门就会执行系统命令并把结果加密后返回。日志里看到的响应长度忽大忽小明显不符合API的正常行为。把响应长度波动、参数异常这两点结合才把这个隐蔽后门揪了出来。4. 本地实战从搭建隔离环境到完整分析4.1 环境准备与安全前提学习Webshell分析千万不要直接在公网服务器或者办公电脑上操作。我推荐用虚拟机加快照的方式搭建一个完全隔离的实验环境。具体配置大概是一台装有Linux的虚拟机网络设置为仅主机模式或NAT模式但不映射任何公网端口安装一个常见的Web服务软件和一个轻量数据库再准备一个调试用的脚本环境。所有样本只存在于这台虚拟机里实验结束后直接回滚快照。安全前提是三条底线实验环境不能接入公司内网或校园网不要在云服务器上操作实验过程中不要访问公网。哪怕只是做静态分析我也建议先把网络断开再解压样本。曾经有同事在分析一个样本时忘了断网样本里的恶意代码自动外联差点把整个实验网段搞出事来。搞安全的都知道一个铁律分析恶意代码先断网再看行为。4.2 一个完整分析流程的拆解我会把一次Webshell本地分析工作流分成六个步骤每一步都有明确目标和输出物。第一步是样本获取。自建演示样本时只需要写几行最简单但典型的脚本包含外部参数接收、base64解码、代码执行三个要素。人工构造样本有利于你彻底理解逻辑再去分析复杂变体会更从容。第二步是静态预检。用file命令看文件类型用文本工具查看完整内容计算文件哈希并记录下来。这一步的目的是建立样本的基本画像它是什么语言写的、文件大小多少、有没有被编码过。第三步是特征提取。提取出文件里的函数调用列表、字符串常量、请求变量名。把这些信息与已知恶意特征库比对确认样本属于什么类别。比如存在eval和base64_decode的高危组合那基本可以判定是代码执行型后门。第四步是动态监测。在隔离环境中模拟请求观察样本运行后产生了哪些文件、修改了哪些目录、有没有外联请求。我习惯先拍一张文件系统和进程列表的快照再触发样本运行结束后对比两张快照的差异这样所有行为变化一目了然。第五步是日志分析。查看Web服务访问日志和系统日志确认样本被执行时的访问路径、参数内容、返回长度。这一步能帮助你理解攻击者在真实环境中留下的痕迹。第六步是规则沉淀。把前面提取到的特征转化为检测规则包括YARA规则用于静态扫描、正则规则用于日志检索、网络流量规则用于告警。分析完一个样本如果没能产出规则那这次分析的价值就打了五折。4.3 把分析结果沉淀为检测规则实际工作中沉淀检测规则才是分析闭环的最后一环。一个简单的静态YARA规则可以长这样匹配eval、base64_decode、$_POST这三个关键词同时要求文件大小小于20KB。为什么会限定大小因为正常的业务PHP文件通常比较大且很少同时出现这三个特征恶意脚本为了隐蔽文件体积往往刻意做得小。这种组合式规则比单一关键词匹配准确得多。流量检测规则我一般用正则表达式匹配请求体和响应体。匹配的特征包括超长URL编码字符串、连续多个%XX编码字符、响应中出现的特征字符串等。这里要特别提醒规则里的特征字符串不要照搬样本里的原文要写得更抽象一点比如匹配解码函数的通用写法否则换个加密算法就绕过你的规则了。5. 绕过与反检测攻击手法升级后的应对5.1 常见绕过思路说句实在话静态查杀永远无法穷尽所有Webshell变体因为代码执行的方式实在太多了。攻击者绕过静态检测的主流思路有三条。第一条是混淆加密把payload用多层编码包裹让静态规则匹配不到明文关键词第二条是动态构造把函数名拆散后用变量拼接运行时再组合静态扫描看到的是变量赋值不是危险函数调用第三条是拆分隐藏把恶意代码拆成多个片段分散在不同文件任何一个文件单独看都不是Webshell只有通过包含关系串起来才成为完整后门。这三种思路对应到防御端意味着我们不能只靠静态特征来查杀需要引入行为维度的检测。比如某个进程突然执行了系统命令、某个Web请求导致服务器新增了账号、某个图片文件突然变成了可执行脚本这些行为即便没有任何已知特征也能被安全设备感知到。5.2 行为检测怎么补位行为检测的核心思路是不管代码怎么变它最终要做事做事就会留下痕迹。以Webshell为例无论它多隐蔽在被访问时一定会在Web日志中留下请求记录无论它执行了什么命令一定会在进程列表或系统日志中产生对应动作无论它怎么隐藏通信一定会与客户端进行数据交换。我在实际项目中用得比较多的是文件完整性监控。对Web目录里所有文件定期计算哈希并保存基线一旦发现某个文件哈希发生变化立刻告警。这个方法对付“隐藏式Webshell”特别有效——就算攻击者把恶意代码藏在图片里只要图片被修改过哈希一对比立刻暴露。再配合目录白名单机制Web目录下只允许特定扩展名的文件存在出现任何不在白名单里的执行文件都视为异常。5.3 主机侧的纵深防御单一检测手段永远有盲区纵深防御才是王道。我的建议是至少做四层网络层用流量检测设备识别异常通信主机层用文件监控和进程监控捕捉异常行为应用层在Web服务配置里禁用危险函数或限制执行权限日志层把所有访问日志和系统日志集中存储保存至少三个月保证事后还能溯源。主机侧有个很容易被忽略的细节Web服务运行账号的权限控制。很多服务器用root或管理员权限跑Web服务Webshell一旦执行就是最高权限攻击者想干嘛就干嘛。正确做法是给Web服务单独建一个低权限账号只授予Web目录的读写权限系统关键目录一律不给写权限。这样即便Webshell成功执行能造成的破坏也被限制在一个很小的范围内。6. 常见问题与排查技巧实录6.1 常见问题速查表我整理了平时处理Webshell事件时最常遇到的几类问题和对应排查方向做成一个速查表供参考。问题现象排查方向处置建议服务器CPU突然飙高查看Web日志中高频请求URL检查对应文件是否为恶意脚本隔离文件查进程父进程来源Web目录出现陌生文件查看文件修改时间和创建时间比对同期访问日志回溯攻击路径检查同目录其他文件某接口响应时快时慢检查接口逻辑中是否有包含外部文件的写法审查代码关闭文件包含功能日志中有大量超长POST请求抓取原始请求体解码查看内容确认后封禁来源IP清除恶意文件杀软或扫描器频繁误报人工复核被报文件的完整内容分析关键词上下文调整检测规则避免一刀切删除6.2 两个实操排查案例第一个案例是“图片文件里的后门”。某客户报告网站首页被篡改我们排查Web目录时发现一张产品图片大小异常正常几十KB的图片变成800多KB。用文本方式打开后文件开头是一堆图片二进制数据拉到末尾能看到完整的PHP代码。这张图片被包含在一个正常业务页面里每次页面被访问时图片内的PHP代码就被解析执行。这个案例给我的启发是查Webshell不能只看文件扩展名任何能被Web服务解析的文件都要纳入检查范围。第二个案例是误报处理。我们用静态规则扫描一个客户的生产环境时查出几十个“可疑文件”人工复核后发现有将近一半是正常业务代码。问题出在业务代码里确实用了eval函数处理模板变量配合了外部输入但没做代码执行。这个案例说明静态扫描误报率天然不低但聪明的做法不是把规则删掉而是给规则加白名单机制——对可信目录、可信文件跳过扫描同时重点盯那些不在白名单里的新增文件。6.3 排查工具推荐与使用心得工具方面我不推荐上去就买重型商业产品先把轻量工具用好就够了。文件扫描用开源的YARA和基于命令行的查杀工具日志分析用文本处理命令配合简单脚本流量分析用抓包软件和网络协议分析工具。这套组合拳对付大多数Webshell事件完全够用。我个人的心得是分析Webshell最忌讳“只看文件本身不看访问日志”。文件只是静态的存在它被谁访问了、传了什么参数、返回了什么内容这些动态信息才是还原整个攻击链的关键。我曾经只拿到一个样本文件怎么也分析不出攻击路径后来翻了目标服务器一个月的访问日志才在某个不起眼的深夜请求里发现了端倪。文件要查日志更要查两相结合才是完整的分析闭环。另外建议大家平时多写检测规则、多收集样本特征别等着出了事故再去研究。我在本地虚拟环境里存了一批去敏后的样本库定期更新规则每次处理新事件时都会先复盘旧样本再用新样本校验规则覆盖率。这套方法让我在多次紧急事件里都能快速定位问题比临时抱佛脚高效太多。最后再分享一个小技巧拿到一个可疑文件时不要急着删。先在隔离环境里运行一遍观察它的行为和通信特征搞清楚它到底做了什么、想连哪里再决定怎么处置。删一个文件很简单但如果你不知道它是怎么进来的后面还会有千千万万个同样的文件进来。搞清楚来源堵住入口才是治本之道。
阅读完成 · 觉得有帮助？
