企业官网建设流程全解析

Hvv-知攻善防应急响应靶机--Web1

搞安全的应该都懂，光会打点不算本事，出事了能稳住局面才叫真功夫。我最近在内部安全实验室里折腾了一套应急响应靶机环境，名字就叫 Hvv-知攻善防应急响应靶机--Web1，练的就是"网站被打穿之后，你怎么接手、怎么排查、怎么收尾"这一整套流程。

这个靶机模拟的场景很直接：一个正常的 Web 业务站点，某天被人上传了一个 webshell，攻击者还顺手留了后门、改了页面。你的任务不是去"反打"，而是站在防守方的角度，像真实的应急响应工程师一样，从服务定位、恶意文件筛查、日志分析、样本溯源，到最终清除加固，把整个事件按标准流程处置干净。换句话说，这台靶机练的是"知攻"之后的"善防"——你越能理解攻击者怎么想、怎么做，你的排查方向就越清晰。

这篇文章就顺着我实际跑靶机的过程，把 Web1 的完整处置链路拆开讲一遍。适合三类人看：一是准备参加攻防演练、想往蓝队方向走的新人；二是日常负责业务服务器运维、想提升安全应急能力的后端同学；三是过了靶机但没想明白"为什么要这么查"的入门朋友。我尽量把每一步为什么这样做、命令看什么、结果怎么解读都交代清楚，方便你照着复现。

1. Web1 靶机到底在模拟什么场景

1.1 一句话说清这个靶机的训练目标

Web1 的项目定位是"应急响应靶机"，而不是"渗透测试靶机"。这两者有本质区别：渗透靶机练的是你怎么攻进去，应急响应靶机练的是你接到告警之后怎么查、怎么修。

靶机里预设了一个"已经被攻破"的状态，你要做的是通过系统上残留的各类痕迹，反向还原攻击者的行为路径。它的核心考点有三个：能不能最快发现 Web 目录下的 webshell；能不能从日志里还原攻击时间线；能不能完成一次不留隐患的加固处置。

我拆这台靶机时最大的感受是，它没有故意设置那种"一眼就是恶意文件"的低级陷阱，而是把恶意文件混在正常的业务文件里，模拟了真实攻击者常用的混淆手法。这比单纯让你找一个"名为 shell.php 的文件"要有意思得多。

1.2 环境拓扑与关键技术栈

从靶机的命名 Web1 也能猜到，它的重点放在 Web 应用层。我搭这套环境时用的技术栈是 Linux + Nginx/Apache + PHP + MySQL，这是目前中小型业务系统最常见的组合，也最有代表性。业务逻辑模拟成了一个带用户上传功能的资讯发布系统，攻击者正是通过一个文件上传接口撕开了口子。

拓扑大概是这样：对外有一个 80/443 端口的 Web 服务，后端连着数据库，服务器上还开了 SSH 用于管理。攻击者留下的东西分散在三个层面——

• Web 层面：一个被混淆过的 PHP webshell 藏在上传目录里，文件名伪装成图片格式；
• 系统层面：/tmp 目录下有一个可疑的可执行文件，计划任务里被加了一条定时回连；
• 痕迹层面：访问日志里残留了大量异常 POST 请求，系统登录日志里也有几个非常规时段的会话记录。

之所以要把痕迹散落在不同位置，是为了强迫你做"全链路排查"，而不是盯着目录文件一眼定生死。只查 Web 目录的人会漏掉系统层的后门；只查进程的人又解释不了 webshell 是怎么进来的。

1.3 为什么"知攻"才能"善防"

"知攻善防"这四个字是这个靶机系列的核心理念。我在带新人时经常被问一个问题：防守方为什么要去学攻击思路？直接装个防护软件不就行了吗？

答案是：防护软件能拦掉 99% 的批量扫描，但拦不住 100% 的定向攻击。真实环境中，你必须能看懂攻击者的行为特征，才能在茫茫多的正常请求里挑出那条异常的。比如一个正常的图片上传请求，文件后缀是 .jpg，Content-Type 是 image/jpeg；但攻击者的上传请求可能把文件后缀伪装成 .jpg，同时 POST 的数据里夹了一段 PHP 代码。如果你不知道攻击者会这么干，你就会认为它只是一个普通图片文件。

Web1 靶机里的 webshell 就复刻了这种思路。我在处置时先看到的是一张"图片"文件，直到我打开文件头发现里面有明显的 PHP 标签，才确认这是伪装文件。这个发现过程，就是我所说的"先懂攻击，才能防守"的现场教学。

2. 应急响应排查的核心流程拆解

2.1 排查第一件事：确定时间和范围，不要上来就乱翻

很多人拿到靶机后的第一反应是到处看，这里翻翻那里翻翻，最后时间和精力都浪费了。我跑过太多攻防演练，总结出一个铁律——接到任何应急响应任务，先确认事件时间窗口，再谈排查。

时间窗口怎么确定？三个来源：一是告警平台给出的告警时间，二是系统管理员报告的异常时间，三是日志中最先出现异常行为的那个时间戳。Web1 的告警信息里明确提到了某个时间段出现了大量异常请求，我直接从访问日志里过滤那个时间段的记录，马上发现入口请求集中在某一天的下午时段，所有可疑操作都发生在这个窗口内。

确定时间窗口的价值在于，你可以把排查范围死死锁住。查文件时只看这个时间点之后新增或修改过的文件；查日志时只看这个时间段内的记录；查账号时只看这个时间点之后的登录行为。范围一缩小，噪音就大幅度降低。

有不少新手一上来就用find / -name "*.php"这种命令做全盘扫描，结果文件太多、输出太长，根本看不过来。正确做法是先定位到业务目录，再结合时间窗口做定向过滤。这个习惯如果养成了，后面处置真实故障时会节省大量时间。

2.2 五类关键战场：进程、文件、日志、账号、外联

我习惯把应急响应的排查对象归纳成五类，对应攻击者入侵后最常做的五件事。判断一个系统是否被攻破，本质上就是在五个战场上寻找痕迹。

第一是进程战场。攻击者可能通过 webshell 执行了系统命令，所以当前系统里有没有异常进程、CPU 或内存占用异常的进程，排在排查首位。

第二是文件战场。攻击者必然留下恶意文件，要么是 webshell，要么是后门程序，要么是落地的小工具。重点关注 Web 目录、临时目录、用户目录这些常规落地点。

第三是日志战场。这是还原攻击路径最重要的依据。Web 访问日志能告诉你攻击者请求过什么；系统认证日志能告诉你攻击者是否尝试过口令；bash 历史能告诉你攻击者在系统里执行了什么。

第四是账号战场。攻击者可能会创建新账号、修改已有账号权限，或者往 authorized_keys 里写入自己的公钥。这类持久化手段是排查中很容易漏掉的部分。

第五是外联战场。后门程序通常会尝试向外回连，或者下载更多恶意组件。ss -tnp看当前连接、查看历史网络连接记录，有时能直接帮你锁定恶意进程。

为了便于记忆和落地，我把它整理成了一个速查表，平时做应急响应时就是按这个顺序往下走的。

2.3 用时间线串起整场攻击

五个战场分开看，每个都只能得到一个孤立的线索，很难把整件事串起来。我的做法是：每发现一个可疑点，就把它记录到时间线上，最后用时间线还原完整的攻击路径。

Web1 的时间线整理出来大概是这样的：

一开始，攻击者对系统发起了多次探测请求，这是"踩点"阶段；紧接着，某次上传接口的请求返回了成功状态码，这是"打入"阶段；再往后，日志里开始出现对某个 .php 文件的调用，这是"执行"阶段；最后，计划任务里多了一条记录，这是"持久化"阶段。

这条时间线一旦建立，整个事件就非常清晰了：攻击者通过文件上传漏洞放入了 webshell，随后通过访问 webshell 执行了命令，最后通过计划任务实现长期驻留。后续所有处置动作都可以沿着这条时间线展开：删掉 webshell、清除计划任务、修补上传漏洞，彻底断开攻击链路。

很多人在应急处置时容易陷入"单点思维"，找到 webshell 就删，删完就以为没事了。但攻击者的行为是一条管线，不是孤零零的一个点。你只有把整条管线都疏通，才算真正处置干净。

3. Web1 靶机的实操全记录

3.1 环境准备与快照策略

实际动手前，我先例行做了一次准备工作。这套环节看着琐碎，实战中往往决定你后续工作的上限。

第一步是备份取证。我建议你在任何处置动作之前，先给靶机创建快照，同时把关键位置的文件做一个副本。千万不要小看这一步，我在真实处置中遇到过这种情况：把恶意文件删了，但是删之前没留记录，后面溯源和汇报时要补证据，只能干瞪眼。快照和备份是为了防止"越处置越破坏证据"，尤其是对文件做修改操作之前，先备份永远是对的。

第二步是准备排查工具。Web1 只要有一条 Linux 命令行就能完全处置，不需要额外安装重型商业软件。我常用的命令就是find、grep、stat、ps、ss、lsof、file这些基础命令，它们足以覆盖这次排查的绝大多数需求。

第三步是确认自己的角色视角。我是以"应急响应工程师"的身份进入这套环境的，不是以"攻击者"身份。所以我的目标不是把系统"打下来"，而是把系统"救回来"，同时保留完整的证据链用于复盘。这个角色意识很重要，它直接决定了后续每个动作的合规边界。

3.2 Step 1：确认服务状态与系统基础信息

处置开始，我先花五分钟摸清系统的底数——这台机器上跑了哪些服务、Web 根目录在哪里、用了什么中间件、日志路径在哪。这一步相当于医生接诊前的"先量体温血压"。

我用ss -tnlp查看当前监听的端口，发现 80 端口由 Apache 服务占用，443 没有启用，22 端口是 SSH，说明这是一台纯 Web 业务服务器。然后我确认了 Apache 的配置，找到DocumentRoot指向的目录，也就是 Web 根目录。再通过查看 Apache 配置文件中的CustomLog指令，确定了访问日志的具体路径。

在这个环节要特别注意的是，命令很容易看到"占用 80 端口的进程"这类信息，但高水平的排查者还会顺带确认服务对应的配置文件路径和运行用户。因为攻击者如果通过 Web 漏洞执行命令，命令的执行权限大概率就是 Web 服务运行用户的权限，后续很多痕迹排查范围都取决于这个用户是谁。Web1 里 Web 服务以低权限用户运行，所以攻击者在初始阶段能够操作的范围也受限，这会影响到后面对攻击行为的判断。

确认完这些基础信息后，我顺手把当前时间、系统运行时长、最近一次重启时间记录了一下。这些看似无关紧要的数据，在后续判断时间窗口时非常有用——如果系统最近有过重启，那内存里的证据可能已经丢失，重点就要放到磁盘上的文件和时间线分析上。

3.3 Step 2：Web 目录恶意文件定向筛查

接下来进入正题，排查 Web 目录下的恶意文件。Web1 的 Web 根目录结构比较典型，有静态资源目录、有上传目录、有模板目录，跟真实业务系统的组织方式基本一致。

我的第一步是用文件修改时间做定向筛查。结合此前根据告警信息确定的时间窗口，我执行了类似这样的操作：

find /var/www/html -type f -newermt "2025-01-15 00:00:00" ! -newermt "2025-01-20 23:59:59" -name "*.php"

这条命令的意思是找出指定时间窗口内新增或修改过的 PHP 文件。执行结果是三条记录，一条是正常业务逻辑文件（经对比确认是开发人员在窗口期内正常更新的），一条位于上传目录下、文件名伪装成了avatar.jpg（这里很可疑，用 PHP 扩展名的都没搜到，说明攻击者故意藏了），还有一条文件路径比较靠后、名字看起来是个正常功能模块。

这里有个很实用的技巧：Web 攻击者为了隐藏，经常会把 webshell 的文件命名伪装成图片服务器的常见格式，比如.jpg、.png、.ico，同时往文件头里拼上图片标记。所以我的第二步是用内容特征扫描，而不只是按文件名扫：

grep -rl "eval\|assert\|base64_decode\|system\|exec\|passthru" --include="*.php" /var/www/html

这条命令会递归扫描 Web 目录下所有 PHP 文件，找出包含危险函数调用的文件。结果返回了一个我此前没有注意到的文件：/var/www/html/uploads/avatar.jpg。整个文件按照目录结构应该属于图片文件，但内容里出现了危险函数的调用痕迹。

我用file avatar.jpg查看它的文件类型，输出结果是PHP script text，直接揭穿了伪装。再用head -c 200 avatar.jpg看文件头，能看到文件开头被塞了几行注释用来混淆，真正的代码在注释后面。这种"伪装成图片的 PHP 脚本"就是 Web1 这个靶机埋下的第一个核心考点。

3.4 Step 3：从访问日志里还原攻击链路

确认存在 webshell 之后，我没有急着删它，而是先转向访问日志，把攻击者是怎么进来的问题搞清楚。

Web1 的访问日志格式是标准 Apache 日志格式，我用时间窗口过滤，加上POST方法关键字，查到了一条关键记录，大致长这样：

xx.xx.xx.xx - - [15/Jan/2025:14:32:17 +0800] "POST /index.php?page=upload HTTP/1.1" 200 482 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)"

这条记录一看就有问题。首先，请求方法虽然是 POST，但它的 User-Agent 是一个老旧的浏览器标识，与正常用户的访问习惯不符；其次，响应状态码是 200，说明上传请求被成功处理了。这两点组合在一起，比单独某个异常更像是一次利用上传接口的可疑尝试。

继续往下翻，同一时间窗口内出现了对avatar.jpg的请求记录：

xx.xx.xx.xx - - [15/Jan/2025:14:33:05 +0800] "GET /uploads/avatar.jpg HTTP/1.1" 200 1735 "-" "curl/7.68.0"

注意这里的蹊跷：一个"图片文件"，被请求时使用的客户端是 curl，而不是浏览器；返回的报文大小有 1735 字节，而一个正常的、只包含少量 PNG 头数据的图片不可能有这么大的体积。事实很清楚——这个"图片"被执行了，它实际上是一个 PHP 脚本，攻击者在通过它传递参数、执行命令。

再结合系统日志中的内容，我在相同的时间窗口内找到了几条通过 SSH 登录的记录，登录来源与访问日志中的 IP 一致，成功登录的时间正好发生在 webshell 被请求之后。这说明攻击者通过 webshell 获得了执行命令的权限，再进一步是提取了服务器上的某个弱口令凭据，最终通过 SSH 完成了权限扩张。

日志分析到这里，攻击链路已经完整浮出水面：探测踩点 → 利用上传漏洞放置伪装图片 webshell → 访问 webshell 获取命令执行 → 提取凭据后通过 SSH 登录系统 → 创建计划任务实现持久化。这和我前面说的时间线完全对得上，处置方向也就清楚了。

3.5 Step 4：样本分析与证据固定

日志还原完成后，又回到了恶意文件本身。我先把avatar.jpg复制到取证目录，然后执行了一系列基础分析操作。

第一步是计算文件的哈希值：

md5sum /path/to/evidence/avatar.jpg sha256sum /path/to/evidence/avatar.jpg

哈希值相当于文件的指纹。记录哈希值有两个用途：一是作为处置报告中唯一的样本标识；二是后续如果从其他目录又发现同名或同内容的文件，可以通过哈希比对判断是否为同一恶意样本。这个习惯在任何应急处置中都应该强制执行。

第二步是用strings命令提取文件中的字符串，主要看文件里有没有明显的标记信息：

strings /path/to/evidence/avatar.jpg

执行结果里出现了几段特征信息。一个是用 base64 编码的字符串作为参数传递标记，一个是作者留下的注释文字。这个注释文字看似普通，实际上在溯源时有重要价值——不同攻击者会在自己的恶意代码里留下习惯性标识，这些标识与攻击者的习惯手法关联后，就组成了判断攻击者画像的重要线索。

第三步是查看文件的详细元数据信息，包括修改时间、访问时间、属主、权限等。命令行如下：

stat /var/www/html/uploads/avatar.jpg

这里能看出一个问题：文件的修改时间被刻意进行了篡改，伪造成了比真实攻击时间更早的时间点。攻击者通常会使用touch命令调整恶意文件的时间戳，让它"看起来"更早存在，从而躲过基于时间窗口的排查。我之所以仍然能认定它是恶意文件，靠的是内容特征分析和日志时间线，而不是依赖文件时间属性。这也解释了为什么我在前面的步骤中反复强调"内容优先、时间辅助"。

样本分析做完后，我写了简要的证据记录，内容包含文件路径、哈希值、文件类型、提取到的特征串、判断依据。这一步可能不会被所有初学者重视，但它是应急响应报告和内部复盘的核心支撑材料。

3.6 Step 5：清除、加固与复测验证

恶意文件分析完、链路确认完，最后进入处置阶段。这部分的每一步我都要确保可执行、可回滚、可验证。

第一件事是删除恶意文件。我先把文件从 Web 目录移动到隔离目录，确认业务系统没有任何依赖此文件的功能后，再彻底删除。之所以分两步走，是为了给自己留一条回滚路径——万一误删了正常业务所需的文件，还能从隔离目录恢复。

第二件事是清理计划任务。我用crontab -l查看了当前系统的计划任务列表，发现了一条可疑记录，内容大致是一个指向/tmp目录下脚本的定时执行任务。攻击者的思路是利用计划任务维持访问权限，即使 webshell 被发现并删除，后门仍然可以定时反弹回来。我这里不加展开说明后门的详细机制，但清理的思路是一样的——从计划任务中移除可疑条目，并彻底删除对应的脚本文件。

第三件事是修补上传接口的漏洞。前面分析已经确认，攻击者的入口是文件上传功能。我处置的时候重点检查了上传模块的逻辑，发现有明显缺陷：对上传文件只校验了后缀名，没有校验文件内容；文件直接存储在 Web 目录下，且该目录具备脚本执行权限。我的加固方案是：

• 后端增加文件内容校验，不再只依赖后缀名判断文件类型；
• 对允许上传的文件类型设置白名单，不在白名单内的直接拒绝；
• 上传目录禁止解析 PHP 等脚本文件，从中间件层切断 Web 执行路径。

第四件事是检查系统账号和 SSH 授权，看有没有遗留的后门账号。我查看了系统用户列表，注意到有一个可疑用户的 UID 为 0。正常情况下，普通业务用户的 UID 不会是 0，这是直接把账号提权成了超级用户的持久化手法。我立即对这个账号进行了锁定处理，同时检查了所有用户目录下是否有异常的 SSH authorized_keys 文件。经过排查，除上述账号外，其他位置未发现异常。

清理加固并不是最后一步，最后一步是复测验证。我重启了 Web 服务，确认业务界面可以正常访问；然后模拟了一次文件上传，确认新上传的恶意文件无法被解析执行；再查了一遍访问日志，确认在观察期内没有新的可疑请求出现；最后用find又扫了一遍 Web 目录，确认恶意文件已被彻底清除。全部验证通过，这次处置才算完成。

4. 复盘过程中的典型问题与避坑指南

4.1 排查顺序不对，先被假象带偏

我在带人做 Web1 的时候，见过最多的问题是一上来就全盘扫描，最后被大量正常文件淹没。新手遇到的最典型情况就是：对 Web 目录做了个grep -r "eval"，结果发现业务代码里到处都是 eval 调用，一时分不清哪些是业务需要、哪些是攻击者的后门。

我的建议是，排查顺序一定要遵循"从粗到细、从系统到代码"的原则。先用端口和进程确认系统整体是否异常，再确认业务目录结构是否正常，然后用时间窗口圈出范围，最后才做内容特征分析。如果你在内容扫描阶段就迷失了方向，可以回到时间线上来——攻击者留下的文件一定是在某个时间点出现的，这个时间点与日志里的异常请求是对应的。只要始终以时间线为主线，就不会被业务代码的正常复杂度带偏。

4.2 命令输出太多，怎么缩小范围

用find扫全盘、用grep扫全目录，命令执行完输出几百行甚至上千行，完全看不完——这也是新手常遇到的痛点。缩小范围的方法主要有三种。

第一种是给命令加时间条件，只查看特定时间窗口内变化的文件，前面已经演示过。第二种是给 grep 的结果排除正常业务路径，比如那些明确属于框架目录、模板目录、静态资源目录的路径，可以在命令里直接排除。第三种是先看数量，再看内容。先统计结果的行数，如果数量过大，说明筛选条件不够精确，而不是内容本身有大量问题。

我自己的习惯是，每执行一条排查命令，都会先想清楚"这条命令我要回答什么问题"。如果这个问题不需要精确到文件级别，只是确认"会不会有"，那么数量就足够了；如果需要精确到文件级别，那就把范围缩到不能再缩为止。

4.3 删了文件就完事？只清文件不掐链路等于白做

这可能是整个应急响应里最容易犯的错误，也是我最强调的一点：删除 webshell 文件只是"清点"，不是"处置"。

Web1 里我找到的 webshell 是入口，但如果只删掉它，攻击者通过 SSH 留下的账号依旧存在，计划任务里残留的定时任务还会在特定时间拉起来一个新的后门，相当于前门关了、后门还开着。真正的处置必须覆盖攻击链路的每一个环节：断入口、清样本、封后门、堵漏洞、杀权限。一个环节漏掉，整个处置就不算完成。

验证处置是否彻底的标准，不是"我把那个文件删了"，而是"我在时间线里发现的每一类痕迹都已清除，并且复测试验证明无法再次利用"。这也是区分熟练者和新人的重要分界线。

4.4 避免"二次攻击"和证据丢失

在实际处置中还会有一些隐蔽的坑，在此一并说明。

第一个是避免二次修改证据。有些人拿到恶意文件就想打开"研究"，结果编辑器自动修改了文件属性，无形之中破坏了证据的原始性。我处理样本时坚持"先复制、后分析、永远不直接改原文件"的原则，原始文件只用来做哈希和备份，分析都基于复制出来的副本进行。

第二个是避免在目标系统上安装来历不明的工具。在真实事件响应场景中，目标系统可能已经被全面接管，你再装工具反而可能引入新的风险。优先使用系统自带命令完成排查和分析，需要更多工具时，在我的实际操作经验里，最好从一个可信的介质中挂载使用，而不是直接在目标机上安装第三方软件包。

第三个是处置过程中始终保留现场快照。我在一开头就拍了快照，在删除任何文件之前又拍了一次，确保每个处置步骤的状态都有据可查。这样即使某个步骤操作失误，也能快速回退到上一步重新处理。

为了便于大家把这个经验直接落地成检查清单，我整理成了一张速查表：

5. 给新手的一些练习建议

5.1 从"看得懂"到"下得去手"

有些新人看教程的时候觉得什么都简单，一上手就懵。我建议拿 Web1 这样的靶机反复训练，第一遍照着完整流程做，哪怕慢一点没关系；第二遍不看任何笔记，只看告警信息和自己记录的时间线来推导下一步；第三遍给自己设定一个目标，比如"15 分钟内完成从服务定位到确认 webshell"。

我自己的经验是，应急响应能力提升最快的阶段，就是反复处理这类靶机的过程。第一次做到后面，你会发现排查动作已经内化成条件反射了——看到 POST 到 php 文件就知道要查内容，看到可疑文件就知道要先用file和strings确认性质，看到计划任务异常就知道要关联真实脚本路径。

5.2 整理自己的应急响应 SOP

做完 Web1 之后，我建议你把它沉淀成自己的标准操作流程。不需要很复杂，简单记录：接到告警后先做什么、再做什么、每步用什么命令、输出结果如何判断，做成一份 checklist 放在本地笔记里。

我在自己团队的内部培训中，会让每个新人在跑完 Web1 和 Web2 两个靶机后，各交一份自己的处置笔记。重点是记录自己实际踩过的坑，而不是抄标准答案。表格或者时间线都可以，重要的是能让自己在三个月之后回看时，一眼就能还原当时的处置过程。

5.3 后面可以怎么扩展玩

Web1 只是这个系列的开头。我实际搭建的经验是，你可以基于同一套环境做很多扩展练习：把 Web 日志统一收集到日志平台，练习从集中平台里做检索和关联；把环境切到 Windows 平台，练习 Windows 下的进程、计划任务、注册表排查；或者增加一份内存镜像，练习通过内存取证确认攻击者留下的网络连接痕迹。

每一次扩展，本质上都是在训练同一个底层能力：根据有限的线索还原完整的攻击链路，并在不破坏证据的前提下完成清理。这个能力在任何攻击面不断变大的今天都很有用——不管你负责的业务系统是自建的还是云上的，最终比拼的都不是你安装了多少防护软件，而是你发现问题、理解问题、处置问题的速度。

这套靶机是我在内部做安全培训时的一个重要练习场景，跑完 Web1 的很多人后来反馈，真正上了真实故障现场，第一反应仍然是"先圈时间窗口，再按五类战场排查"。能形成这种本能反应，说明这台靶机的训练目的也就达到了。