企业官网建设流程全解析

Vulnhub上的靶机成千上万，但有主题、成系列、难度曲线设计合理的其实不算多。Shuriken系列是我最近几个月反复刷下来觉得最“懂新手”的一套，它不像某些靶机那样故意放一个冷门CVE刁难人，也不像CTF里的逆向题那样拼脑洞，而是把信息收集、Web漏洞利用、弱口令爆破、Linux提权这些核心环节串成一条完整的攻击链，练的是基本功和思路，不是背答案。如果你是准备打OSCP、考研复试面试，或者单纯想检验一下自己从信息收集到拿到root的完整闭环能力，这套靶机非常值得花点时间吃透。

这套系列到目前为止主要是两台机器，Shuriken 1和Shuriken 2，主题围绕日本忍者手里剑（Shuriken）展开，难度官方标注都是中等偏简单。但别被这个评级迷惑，简单不等于无脑，恰恰是这种难度最能暴露你在真实渗透测试中的坏习惯——比如看到80端口就只扫目录不深挖、拿到一个SQL注入就直接交给sqlmap跑全文而忽视手工验证、提权阶段只会跑LinPeas不会手动梳理关键信息。我实际刷完两台的感受是：这系列不需要你背很多exp，但对每一步“为什么这么做”的思考要求很高。

1. Shuriken系列到底是个什么来头

很多接触Vulnhub的新手有个误区，觉得靶机难度越高越好，上来就挑Hard级别的机器打，结果卡在信息收集阶段，心态直接崩。Shuriken系列的定位恰恰是帮你把心态摆正——它更像一套“渗透测试基本功验收卷”，考察的知识点虽然常见，但组合方式和出题逻辑贴近实战。

1.1 两台靶机的核心设定与攻击视角

Shuriken系列目前的主要成员是Shuriken 1和Shuriken 2，都是基于Linux的镜像，攻击机需要你自己准备（Kali或者任何带常用渗透工具的发行版都行）。两台靶机的故事背景可以忽略，你真正要面对的是一个模拟的受害者环境：有Web服务、有数据库、有系统用户、有脆弱的服务配置，从这个环境里找到入口、提升权限、最终拿到root，整个过程和你去给一家真实企业做授权测试的流程没有任何区别。

Shuriken 1的主线是Web漏洞利用加登录凭据获取，最终落到某个普通用户的可交互shell；Shuriken 2则在此基础上增加了服务配置错误和本地信息利用的设计，提权环节更有层次。两台的难度坡度是从“能扫到思路”到“需要点联想能力”递进的，非常适合连续刷完，因为第二台的第一条线索其实暗含着第一台的影子。

1.2 为什么说这套靶机适合作为新手背书项目

我见过不少人打了十几个靶机还是一团浆糊，问题就出在他们跳过了基础阶段的刻意练习，直接去掰那些需要丰富经验的High级靶机。Shuriken系列的节奏刚好踩在“不让新手直接崩盘，但也不让你纯靠工具混过去”的红线上。它的每个漏洞点都对应一种高频真实场景，比如弱口令、SQL注入点、错误的文件上传逻辑、包含敏感信息的本地服务，这些不是出题人自己发明的设定，而是真实业务系统里每天都在发生的问题。

还有一点很棒，就是这台机器的文档和官方writeup写得相对克制，给提示但不给完整路径，逼着你思考。多打几遍，你实际上在建立自己的“套路库”：端口扫描之后怎么快速判断服务重点、拿到数据库中一堆hash怎么务实分析、普通用户权限下哪些方向最可能提权成功。这套思维框架比记住某个exp的命令行重要太多。

2. 开打之前的环境准备，这一步最容易被忽略

Vulnhub靶机百分之八十的问题其实都出在环境搭建上，不是打不进去，而是压根连不上。Shuriken系列的处理方式和大多数Vulnhub镜像一致，但网络配置稍微有点讲究，我先把最容易踩坑的部分说清楚。

2.1 下载镜像与虚拟化平台选型

Vulnhub官网上每个靶机页面都会提供镜像下载链接，两种常见格式：.ova（针对VirtualBox）和.vmdk或者.qcow2（针对VMware等其他平台）。Shuriken 1和Shuriken 2都提供通用格式，我个人的主力是VMware Workstation，也试过VirtualBox，两者都能顺利跑起来，但有几个细节值得注意。

如果用的VMware，下载下来如果是.ovf配套.vmdk，直接导入即可。如果只有.vmdk，需要手动新建一个Linux虚拟机，然后把磁盘文件挂在上面。内存建议分配512MB到1GB，给太少服务可能起不来，给太多也无意义，靶机又不是重型应用。网络适配器选同一块网桥或Host-Only，这点很关键，因为我们希望通过宿主机直接访问靶机，而不是让靶机自己DHCP到公网未知地址。

2.2 网络模式配置：为什么优先用Host-Only而非NAT

在国内很多文章里大家都习惯用NAT模式，觉得方便上网，但打靶机这个场景里，我强烈建议把攻击机和靶机放在同一个隔离的Host-Only网段，比如VMnet1或者VMnet8。原因是NAT模式下靶机通常位于另一个虚拟子网内，很多情况下它的IP地址和你的攻击机不在一个广播域，你用nmap或者netdiscover扫到的地址可能是虚拟网卡上的宿主地址，干扰判断。

Host-Only模式下，两台虚拟机之间互通，但不需要外网出口，完全模拟一个隔离的内部渗透场景。这样你能拿到的第一个信息就是靶机在网段内的唯一IP，后续的所有扫描和攻击都在这个干净的网段里进行，有效排除网络上其他设备的噪声。对应到真实内网渗透场景，Host-Only的隔离感也更贴近“你拿到了一个内网入口，然后在这个环境里横向捯饬”的体验。

重要提示：别图省事把两台虚拟机直接配置成DHCP自动分配，尤其不要在NAT模式下进行操作。Vulnhub镜像的默认网卡设置可能并不适合你的Hypervisor版本，如果靶机起不来或者IP获取不到，建议进系统后用dhclient或systemctl restart networking重新请求一次地址。

2.3 开机后的联通性验证

先把两台机器都启动，然后从攻击机执行一个简单的ping或ARP扫描。如果发现目标不通，先分别确认三件事：第一，虚拟机界面的网络连接图标是否是“已连接”；第二，靶机内部的网卡配置，是否存在/etc/network/interfaces中残留的旧配置；第三，宿主机防火墙是否拦截了主机到虚拟机网段的通信。绝大多数环境搭不起来都是这些鸡毛蒜皮的小事。

这一步其实是整台靶机战术中最枯燥但最关键的部分，因为后面所有扫描结果都建立在这个稳定的内网连接上。网络不通时别急着怀疑靶机难打，先回到连接层面排查。

3. 核心攻击流程拆解，从信息收集到getUser

准备工作做好后，正式进入攻击链。我把两台靶机分开讲，因为这个系列设计的最妙的地方是两台机的攻击路径有同有异，只有亲自打一遍才能体会到其中的设计乐趣。

3.1 Shuriken 1的突破口：Web服务与SQL注入的隐藏链路

先对目标做一次全端口扫描，肯定能发现80端口的HTTP服务和3306端口疑似数据库服务。用nmap自带的默认脚本扫一遍端口服务版本，这是必须做的基础动作。我的习惯是同时用-sC -sV并保存输出文件，防止后面需要回溯。

浏览器的首页通常就是一个忍者风格的主题页，这个页面本身没什么可看的，真正的入口是隐藏目录或参数。这里就体现出工具和手工的差别了：直接裸跑dirsearch或gobuster常规字典，运气好能扫出一个常见路径名，但未必能找到真正的业务逻辑入口。我建议先翻看页面源码注释，再尝试在URL参数中加入一些针对SQL查询的参数（比如id=1、page=2这类），观察响应差异。

实际打下来，Shuriken 1的入口是一个存在SQL注入点的Web应用模块。手工注入的第一步是判断注入类型和闭合方式，然后枚举数据库版本、库名、表名和字段。如果你不熟悉这个过程，可以先用sqlmap跑一遍，但跑完之后一定要手工重放一遍看返回结果，别把自动化当全程。

有时候注入点并不直接给你shell，而是暴露一堆业务数据，比如用户名、邮箱、密码哈希。把这些哈希保存下来，下一步才真正开始判断破解优先级。这里有个实用的习惯：先识别哈希类型，不要盲目猜测。用John the Ripper的--format提示或者hash-identifier之类的脚本快速判定，否则你可能在一堆MD5上浪费很长时间才发现它其实是别的算法。

拿到了凭据哈希，下一步就开始爆破了。用字典选择有讲究，弱口令优先，别一上来就上rockyou.txt全集——对于靶机来说它的字典小很多，直接上rockyou反而费电。在确保协议允许尝试次数的情况下，可以尝试一些轻量级字典；如果失败，再考虑覆盖多种组合的规则增强。

爆破成功后，你就获得了一个Web应用或SSH的登录入口。这里建议拿到shell后不要停，因为Web入口通常只是第一步，且权限极大概率不是root。

3.2 Shuriken 2的进阶设计：服务配置错误与信息二次利用

Shuriken 2的攻击链比1更绕，初期看起来像是一个内容管理类的Web站点，实际上存在一个容易被忽略的敏感文件泄露点。很多新手会止步于扫出一个admin目录或一个登录框然后卡住，这时候要切换思路：既然暴露了源码或配置，就去后台找备份文件、环境变量、数据库配置文件，这些文件里往往带着数据库账号和敏感信息。

打到这里你可能会发现一个有趣的设定：Shuriken 2的备份文件不是放在Web根目录下，而是有严格的权限控制，只有特定路径才可读。这种做法很贴近真实业务——开发人员会把备份放在隐秘路径备份在服务器上，然后透过Web容器映射出来。

找到备份文件之后，从中提取的对象可能是一个服务账号的密码，或者一个没被做过权限隔离的数据库连接串。利用它连进数据库，你的视角就不一样了。之前作为匿名访客看到的只是前端页面，现在你有机会看到业务表、用户表、会话表。如果运气好，用户表的哈希以及管理员口令也可以直接导出。

Shuriken 2的漏洞利用点不止一个，比如可能存在一个可以执行命令的上传功能或者参数注入点，也可能存在一个smtp配置泄露导致的信息收集。它的最大的训练价值就是告诉你要在“看似无效的页面和接口”上多逗留二十秒，因为设计者把最有用的信息藏在了最不像突破口的地方。这就引出了信息收集的另一条心法：所有返回内容中的注释、错误提示、版本号都是线索，直接丢弃等于主动放弃了一半的解题机会。

4. 本地提权：从普通用户到root的关键一步

做到这里，两台靶机你大概都拿到了一个普通业务用户的shell。接下来就是整套渗透中权重最高的部分：提权。Shuriken系列两台机的提权路线都设计得比较经典，不依赖内核野性exp爆破，而是配置层面的逻辑漏洞。

4.1 SUID与sudo -l，两个最常被忽略的入口

不管从哪条路拿到的shell，第一件事永远是先执行sudo -l看当前用户有哪些免密或不需要密码的授权命令。命令列表里的每一项都要想一想：这个命令有没有能力读写文件、加载配置、调用其他解释器？

如果没有直接的sudo权限，下一件事就是检查全盘有没有非root用户可写或可执行的SUID二进制。经典的查找命令是find / -perm -4000 -type f 2>/dev/null，结果里很可能出现某个捆版脚本或系统工具。网上有很多现成的提权参考表（GTFOBins），对照一下就能看到哪个二进制存在利用方式。比如某个工具通过-p参数能直接开启交互shell，或者某个自定义脚本读取了一个相对路径配置文件，而相对路径恰好能被你作为可写用户修改——这种就是设计者留给你的“钥匙”。

Shuriken 1的提权点与定时任务无关，是一个SUID程序调用外部命令的PATH劫持；Shuriken 2的提权点则涉及某个用户可写的系统服务配置文件和重新加载服务的组合。这两种情况在真实环境中都很高发，理解了原理之后，就能从容应对其他靶机和真实系统。

4.2 内核提权要谨慎：一击制胜与稳定性的权衡

总有人拿到普通shell就想上脏牛、OverlayFS等内核提权exp，这种做法在靶机上当然可以，但真实环境极其危险。Shuriken系列其实有一个隐藏的教学目的：它想要你走逻辑漏洞路线而不是内核炸路线。

用uname -a查看内核版本，然后查exp库的做法没错，但大多数情况下你根本不需要它。先从本地信息入手，比如历史记录文件~/.bash_history、环境变量env、日志文件，很多时候管理员习惯性地把密码参数带在命令行后面，这就等于把钥匙放在脚垫底下。我打靶机和做真实授权测试都遵循一个原则：先翻配置、再找凭据、然后看服务，最后才考虑内核实弹。内核exp不仅可能把靶机直接打崩，还可能在真实环境中造成不可逆的数据丢失，为了拿一个演示权限而冒这个险，不值得。

每台靶机拿到root之后，我建议立刻做一件事：快速比对一下这个提权路径如果在真实Linux环境里，哪些缓解措施能够阻断它。比如AppArmor、SELinux、sudo提权规则白名单、文件系统只读挂载，每加一层能挡住多少攻击？这种“反向防御视角”思考，比多打十台镜像都涨功力。

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

打Shuriken系列的过程中，我遇到了一些非常典型的问题，也观察过不少初学者在同一处卡壳。这里整理成速查表，帮大家少走弯路。

5.1 靶机IP扫描不到，镜像起不来怎么办

这个问题出现的频率远超预期。第一步查虚拟机网卡状态，确认是不是Host-Only模式下宿主机防火墙挡了ICMP和HTTP端口；第二步用netdiscover -r 网段或arp-scan -l，比nmap的ICMP探测更容易发现那些主动忽略ping的靶机；第三步直接上靶机console登录，看它是没拿到网卡地址还是命令没有自动配置。

Shuriken这台镜像默认账号在文档里有说明，用那个凭据登录到本地shell，手工执行ip addr add或dhclient强制获取地址，然后把IP记下来。为什么这一步容易卡住？因为Vulnhub镜像的网卡在导入不同虚拟化平台后，有时无法正确启用。这不是靶机设计得不好，而是你的虚拟环境解析存在差异，请把环境调试视为第一道小题。

5.2 Web漏洞利用失效，多半是WAF和代码过滤的“陷阱”

Shuriken 1的注入点起初看起来十分直接，但如果你用合一攻击型payload提交，可能返回500或者一个通用错误页面，这是因为目标后端对单引号、注释符、联合查询关键词做了简单过滤。破解思路是：先测闭合方式，然后尝试注释符替代、大小写换写、双写绕过，甚至用URL编码二次解码。

很多人在这种时候直接放弃，认定“靶机有问题”，其实真实渗透里遇到WAF或过滤比这复杂得多。建议放平心态，把它当作练习手工绕过的绝佳机会。检查响应长度差异和布尔型状态变化，逐步判断注入是否存在。一个比较容易入门的技巧是：用1和1 AND 1=1、1 AND 1=2三次请求观察数据变化，如果变化明显，说明数据库对条件求值敏感，后面就有戏。

5.3 工具版本差异带来的痛，用大多数人的配置做参考

Kali滚动更新后有些工具默认行为变化很大。比如sqlmap默认会关闭mysql注入时的“safe-union”功能，导致联合注入结果为空；又比如ssh新版禁止了ssh-rsa算法参数，靶机里如果用的老版本OpenSSH可能出现算法协商失败。这些其实都不算漏洞，是环境适配。

遇到手动ssh客户端连接不上的情况，试着用ssh -o HostKeyAlgorithms=+ssh-rsa或-o PubkeyAcceptedAlgorithms=+ssh-rsa开启兼容模式。渗透脚本里如果引用了过时的exp，也要注意gcc版本和内核头文件缺失导致的编译失败，别一门心思只调exp代码，看看日志里报的是不是找不到头文件。

5.4 一条高效的权限提升排查命令速查表

太多同学问我提权的检查顺序是什么，我在Shuriken系列上验证过的最效率的一套流程是：

1. 先看当前用户和组成员：id、whoami
2. 再看sudo授权：sudo -l
3. 搜SUID文件：find / -perm -4000 -type f 2>/dev/null
4. 翻历史记录和环境变量：cat ~/.bash_history、env
5. 查看可写的系统目录：find / -writable 2>/dev/null | grep -v proc | grep -v sys
6. 查看网络服务状态和开放端口：ss -tlnp、ps auxw

这串命令做成一个脚本放在你自己的工具目录里，以后每台靶机提权都可以先跑一遍。它帮你把“模糊的提权”变成“有框架的查找”，效率提升非常明显。

6. 打完全系列后的几点真实体会

说一点自己的感受。Shuriken系列最打动我的不是某个具体的漏洞点，而是它的出题逻辑处处体现着“务实”二字。第一台的入口看起来平淡，但SQL注入点的定位和哈希破解环节练的是你基础功的扎实程度；第二台的心思则花在备份文件和配置泄露上，这在真实环境中完全是每天都在发生的事。

根据我个人实际操作的经验，建议不要急着看writeup，先卡三天，实在卡住了再瞄一眼提示然后就自己推。每台机器至少完整打两遍，第一遍允许用工具，第二遍强制手工复现所有关键步骤——你会发现自己对每条命令的理解完全不同。这个系列后续其实还可以继续扩展，比如它的机制完全可以拓展到真实内网渗透模拟环境中去，用Shuriken 1做Web入口，再用Shuriken 2做横向跳板，中间加一台域名控制器或者业务服务器作为目标，整条链路练下来，内网渗透的思维框架就会非常清晰了。