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

刷靶机的念头，我是从一个很实际的焦虑来的：学了小半年的网络基础和 Linux 命令，看了大量漏洞原理文章，可一打开真实环境还是发懵。信息收集不知道从哪下手，拿到 shell 之后不知道下一步干什么，更别提什么提权思路。那时候有前辈丢了一句——先去把 DC-1 刷了，刷完你就有感觉了。说实话，当时我对"靶场"这两个字是有偏见的，觉得不就是个假网站嘛，能有多难。真动手之后我才发现，DC-1 不是给你"练按键"的，它是用来逼你把渗透测试的完整思路链走通的。这篇文章我就把整个实战过程、当时卡住的地方，以及每一步背后的判断逻辑，完整复盘一遍。

DC-1 是 DC 系列靶机的第一台，属于经典的"入门即劝退"型靶机，但恰好是这种"有点难度但又不至于完全没头绪"的节奏，最适合用来建立对渗透测试的整体认知。它内置了一个基于 Drupal 7 搭建的站点，里面藏着好几个 flag，每一个 flag 都指向下一步的线索。你需要从信息收集开始，一路做到漏洞利用、权限提升，最终拿到 root 权限。整个过程覆盖了 Web 渗透的常见链路，但又不会像真实环境那样有大量干扰噪音，非常适合新手集中精力学思路。

如果你正在学渗透测试，刚接触 Kali 和基本命令，想找一台靶机练手又不知道选哪台，DC-1 是目前我刷下来最推荐的第一台。这篇文章不会只贴步骤，我会把"为什么这么做""当时我还试过哪些错误方法"也一并写清楚，希望你能顺着我的思路自己动手走一遍。

1. 为什么 DC-1 能成为"新手第一靶机"，它到底难在哪

先说个容易误导人的点：DC-1 的难度标签是"入门"，但它的入门是指"渗透流程的完整闭环"，而不是指"简单到不需要动脑"。恰恰相反，如果你不做信息收集，不思考漏洞背后的原理，直接拿着工具乱扫，很可能连第一步从哪里进入都找不到。

1.1 靶机里藏了什么，以及它的训练目标

DC-1 本质上是一个跑在虚拟机里的网站，它基于 Drupal 7 搭建。靶机里预设了好几个 flag 文件，散布在不同权限层级：Web 目录下、数据库相关配置里、系统用户目录里、最后是 root 权限下。你需要一层一层往上拿权限，每拿到一个 flag，里面往往有一条线索指向下一步。

这台靶机的精妙之处是它不靠"堆漏洞"来制造难度，而是靠"环节多"来训练完整思路。从外网探测，到 Web 漏洞利用，再到 getshell 后的系统内部信息收集，最后是提权，每个环节都是真实渗透中一定会遇到的。刷完这一台，你对"渗透测试到底在测什么"会有一个非常具体的认识，而不是停留在"拿个 shell 就结束了"的错觉。

1.2 它的难度分布：容易卡住的地方恰恰是最值得练的

我刷完的体感是，这台靶机最难的还不是漏洞利用本身，而是两处：第一是信息收集阶段能否准确地判断出目标站点用了什么 CMS、什么版本、有什么潜在漏洞；第二是拿到低权限 shell 之后能不能从系统的犄角旮旯里翻出提权密码和文件线索。这两处分别对应了渗透测试里两个最容易被新手忽略的能力——"细致"和"耐心"。

它的提权方式也很有意思，涉及 SUID 文件的利用，这个点在后来的很多靶机和真实环境中都很常见。理解了 DC-1 里的 SUID 提权逻辑，等于学会了一个通杀的提权思路，后面刷别的靶机会觉得顺很多。总的来说，DC-1 很适合正在从"只会用工具"向"理解渗透思路"过渡的这批人。

2. 环境搭建与踩坑：导入虚拟机后先别急着开扫

很多新人刷 DC-1 最容易死在地一步——靶机都起不来，或者起来了但 Kali 扫不到。这种问题八成不是靶机坏了，而是网络配置没对上。

2.1 导入虚拟机文件可能遇到的兼容性提示

解压下载的 DC-1 虚拟机文件之后，用 VMware 直接打开 .vmx 文件即可。部分版本可能会弹出一个"此虚拟机可能已被配置"之类的兼容性提示，通常直接选择"重试"或"仍要继续"就能正常启动。如果遇到无法开机的情况，优先检查 VMware 版本是否过老，升级到较新的版本基本能解决问题。

还有一点，如果你用的是 VirtualBox，需要先把 VMware 磁盘文件转换一下格式，具体工具是 qemu-img 或 StarWind V2V Converter。不过为了省事，我更建议直接装 VMware Workstation 来刷这套靶机，兼容性问题最少。我自己第一次就是图省事用了 VirtualBox，结果在网络配置上折腾了不少时间，后面换回 VMware 一下子就通了。

2.2 网络模式选择：为什么最推荐 NAT

DC-1 是不需要图形界面交互的靶机，它只需要与你的攻击机（Kali）互通就行。最稳妥的网络配置是让两台虚拟机都挂在 NAT 模式下，这样它们会自动分配同一网段的 IP，可以互相通信。

为什么不推荐桥接模式？桥接会让靶机直接暴露在你的真实局域网里，虽然技术上也能打，但一来可能造成 ARP 干扰，二来如果靶机自带一些不安全的服务，对你自己局域网里的真实设备也有风险。NAT 模式相当于把所有实验机器隔离在一个虚拟内网中，既能互通，又不影响外部网络环境，是最适合做靶场练习的选择。

2.3 扫不到靶机 IP 的排查顺序

启动 DC-1 之后，它会在终端里显示当前网卡获取到的 IP 地址。如果没显示或者显示的还是 192.168.56.x 之类的旧地址，不用慌，用以下顺序排查：

1. 查看靶机控制台是否已经显示出 IP；如果没有，登录进去执行ifconfig或ip addr查看。
2. 检查 Kali 与靶机是否在同一个网段。NAT 模式下，两者应该都在 192.168.x.x 网段，但要注意 VMware 可能会为每个虚拟机分配独立的 NAT 子网。此时打开两个虚拟机的网络设置逐一比对即可。
3. 如果 IP 在一个网段但 Kali ping 不通，关闭双方防火墙再测一次。
4. 实在不行，把两台虚拟机都重启一遍，让 DHCP 重新分配地址。

我的建议是，无论是否看到 IP，都在 Kali 里做一次主动探测。很多人习惯手动猜 IP，其实效率很低，直接nmap -sn 网段扫一遍在线主机，一眼就能锁定靶机。这里有个小技巧：如果只知道网段不确定具体 IP，可以先ip addr查看自己 Kali 的 IP，比如是 192.168.137.128，那靶机大概率就在 192.168.137.0/24 这个网段内，直接扫描这个段就行。

3. 信息收集：先摸清目标开了哪些门、用什么技术建站

信息收集是整个渗透测试的第一步，也是最容易被急性子跳过的一步。我在刷 DC-1 的时候犯过一个典型错误——看到 80 端口开着就直接一把梭扫漏洞目录，结果浪费了大量时间在无关路径上。正确做法是先把目标"看透"，再决定用什么武器。

3.1 端口扫描：确认服务入口

先用 Nmap 做一次全端口扫描，命令不复杂：

nmap -sV -p- 靶机IP

-sV的作用是探测服务版本，-p-表示扫描全部 65535 个端口。DC-1 作为靶机，开放的服务不会太多，通常就是 22 端口（SSH）和 80 端口（HTTP）。看到这两个端口，心里基本有数了——这是一台 Web 服务器，攻击面集中在 80 端口的网站应用上，SSH 端口可以作为后续拿到凭据之后的横向入口。

端口扫描的输出结果里，我会特别关注 80 端口对应服务的版本信息。此时 Nmap 通常会给出类似"HTTP service"的提示，但不会直接告诉你具体用了什么 CMS，这需要下一步手动识别。

3.2 Web 指纹识别：认出 Drupal 7

确认 80 端口开放后，直接在浏览器里访问靶机 IP。我第一眼看到的是一个普通的 Drupal 站点页面，带有明显的"欢迎使用 Drupal"风格界面。此时应该做的不是急着找漏洞目录，而是确认它的精确版本和潜在已知漏洞。

有几种方式可以识别 CMS 版本：

• 查看页面 HTML 源码中的 meta 生成器标签，通常会写"Generator: Drupal 7"。
• 查看robots.txt和CHANGELOG.txt，Drupal 这些文件往往会暴露版本字符串。
• 访问/CHANGELOG.txt，如果访问到，文件前面几行通常直接写着版本号，比如"Drupal 7.x"。

我在实际操作中直接访问了CHANGELOG.txt，确认是 Drupal 7 的某个版本，心里就有数了。Drupal 7 在当年出过好几个严重的远程代码执行漏洞，具体能不能打，取决于版本是否在受影响区间。这个判断过程不是碰运气，而是基于"先精确识别版本，再搜索该版本已知漏洞"的标准打法。

3.3 目录枚举与用户枚举：找入口之前先找破绽

端口和指纹确认之后，我习惯做一轮目录扫描，目的是发现后台路径、备份文件、隐藏配置文件等。常用的工具是 gobuster 或 dirb，配合一份常见目录字典。DC-1 的目录结构不算复杂，重点看一下/admin、/user、/modules这些 Drupal 常见的路径是否存在。

这里还要提一个 Drupal 特有的信息收集姿势：用户枚举。Drupal 默认的用户页面路径是/?q=user，而且不同用户 ID 的页面地址是可以直接访问的。逐次访问/?q=user/1、/?q=user/2，就能判断出系统存在哪些用户名。你在网页源码里会看到"登录"或"用户名"相关的信息，虽然靶机不一定把用户名列全，但能枚举到有效用户名，对后续爆破或漏洞利用都是关键线索。

信息收集到这一步，我已经掌握了几条关键信息：开放端口是 22 和 80，Web 应用是 Drupal 7，存在后台和用户登录入口。接下来就是从"知道目标用 Drupal"到"利用 Drupal 漏洞"的环节了。

4. 漏洞利用：从 CMS 已知漏洞打到低权限 shell

拿到准确的 CMS 版本后，如果你对这个领域有了解，脑子里应该立刻浮现"这是不是有现成漏洞可利用"的问题。DC-1 的历史版本 Drupal 7 恰好有个非常出名的漏洞，利用条件宽松，非常适合用来做练习。但这台靶机的高明之处是：即使你知道有漏洞，如果没有认真做信息收集，照样不知道下一步怎么走。

4.1 选择利用路径：手动构造还是自动工具

如果你搜过 Drupal 的漏洞，大概率会看到 Drupalgeddon2 这个词，它对应的是一个远程代码执行漏洞，影响范围覆盖了大量 Drupal 7 版本。针对这个漏洞，网络上有很多现成的 PoC 脚本，也可以在 Metasploit 里直接调用相关模块。

我在实际操作中用的是 Metasploit 里的 Drupal 相关模块，因为流程最稳定：search drupal找到可用模块，设置 RHOSTS 为靶机 IP，run之后能直接反弹一个 shell。整个过程不到一分钟。但我要提醒一句：用工具拿 shell 只是手段，重点在于拿到 shell 之后要做什么。很多人拿到一个低权限 shell 就觉得自己"打进去了"，其实距离真正的目标（root 权限）还差得很远。

4.2 getshell 后的第一件事：确认自己是谁、在哪

拿到一个 shell 后，我先执行了以下命令：

id whoami pwd ls -la

输出显示执行权限只是www-data，也就是 Web 服务运行用户，权限相当有限。这个用户无法读取系统其他用户的目录，更不可能直接打开 root 目录下的文件。但这不代表没机会——Web 目录本身是可读可写的，里面往往藏着应用配置、数据库密码甚至备份归档。

我按顺序浏览了当前目录和上级目录，最后在网站根目录下找到了一个名为flag1.txt的文件。打开它之后，里面是一句提示，大意是"每个站点都会有配置文件"之类的话。这个 flag 不是终点，而是地图上标记的第一个坐标：它在告诉你，去翻应用配置文件。

4.3 低权限 shell 的下一步：从 Web 目录翻到数据库凭据

在 Drupal 站点的目录里，最值得关注的文件是sites/default/settings.php，因为它保存了数据库连接信息。浏览这个文件时会发现，文件中包含数据库名、数据库用户名和密码，并且是以明文形式写在配置里的：

'database' => 'drupaldb', 'username' => 'dbuser', 'password' => '某段密码', 'host' => 'localhost'

看到这里，密码已经拿到了。但直接用这些凭据去连 MySQL 不行，因为数据库配置的是localhost，也就是只能从靶机本机连接。于是我当前的思路很明确：既然我手里已经有一个 shell，那就用 shell 在靶机本地执行 MySQL 客户端连数据库。

这里涉及一个很实用的技巧：当你拿到了应用配置里的数据库账号密码，不要只想着远程连接，很多时候数据库绑定了本机地址，只有通过已经拿到的 shell 才能访问。我在 shell 里执行了类似这样的命令：

mysql -udbuser -p密码 drupaldb -e "show tables;"

看到表结构之后，我心里已经有数了：下一步应该看看用户表里有什么。Drupal 的密码哈希不是明文，光靠破解需要时间，但这不影响继续收集信息。我随后在另一个目录下找到了flag2，内容提示是"暴力攻击和字典攻击不是唯一途径，你可以试试别的思路"。这时候我意识到，一味猜密码走不通，应当把重点转回系统权限本身——也就是提权。

5. 提权之路：从 Web 用户到 root 的经典操作组合

在拿到 shell 并确认当前是低权限用户之后，整个靶机就进入"提权"环节。对新手来说，这是最陌生也最兴奋的一段，因为它是判断你对 Linux 系统理解深度的试金石。DC-1 的提权设计很经典，没有复杂的 0day，没有内核漏洞利用，全靠你对系统文件的敏感度。

5.1 提权前的系统信息收集：枚举 SUID 文件

提到 Linux 提权，SUID 是一个绕不开的概念。SUID 是 Linux 里一种特殊的文件权限位，设置为 SUID 的可执行文件在运行时，会让进程以文件所有者的身份运行，而不是以执行者的身份运行。举个例子，如果一个属主是 root 的二进制文件带上了 SUID 位，那么普通用户执行它时，进程就会临时获得 root 权限。

问题在于，系统中大部分带 SUID 的二进制文件是系统必需的，比如passwd、mount等。但如果有某个不该带 SUID 的普通命令被错误地加上了这个位，就可能被利用。找 SUID 文件的命令很简单：

find / -perm -4000 -type f 2>/dev/null

当时我刷的时候，输出结果里静静躺着一行/usr/bin/find。看到 find 具备 SUID 权限，我的第一反应是"这题我见过"——find 命令本身支持-exec参数可以在找到文件后执行系统命令，如果它以 root 权限运行，那我们就能通过它执行任何命令。这不就是在系统里开了一道 root 后门吗？

5.2 利用 find 的 SUID 执行高权限命令

具体执行逻辑是这样的：使用 find 找到某个确凿存在的文件，然后利用-exec参数去执行我们想要的命令。由于这个 find 进程继承了文件属主（root）的权限，所以它执行的命令也会是 root 权限。

find / -exec whoami \;

输出结果是root。那一刻基本可以宣告提权成功。接着再读取任意文件、获取完整 shell，就只是下一步的操作了。我在拿到的 root 权限下，直接查看了/root目录里面的 flag，最后一枚 flag 就在这里。

这一步的精彩之处不在命令多新奇，而在于你能不能想到"先看 SUID 文件列表"。很多新手在这一步会去翻数据库、爆破密码、查内核版本，却忽略了系统里最直接的高权限入口。这也印证了 DC-1 的核心教学意图：Linux 系统的提权思路，本质上是对系统本身特权配置的审计。

5.3 提权后的完整收尾：确认目标达成

拿到 root 权限后，我按顺序做了几件事：

1. 确定当前身份确为 root。
2. 浏览/root目录，读取最终 flag。
3. 回头看整个攻击链，确认从漏洞利用到提权的每一步都有据可依。

到这一步，DC-1 的全部目标就算完成了。回顾整个过程，整个链路是：Web 漏洞 getshell，读到配置拿到数据库密码，通过 MySQL 找出更多线索，发现 SUID 异常找到提权突破口，最终拿到 root 权限。这个流程看起来清晰，但如果没有前面扎实的信息收集和对系统特权的敏感度，任何一环都可能卡住很久。

6. 复盘与扩展：这台靶机教给我的三件事

刷完 DC-1 后，我没有急着刷 DC-2，而是先把整个流程在笔记里复盘了一遍。现在想想，这台靶机对我最有价值的不是某个具体漏洞的利用姿势，而是三件方法论层面的事。

6.1 渗透测试不是打点，而是一条链

新手最容易犯的错误是认为渗透测试就是"找到漏洞然后 getshell"，拿到 shell 的那一刻就宣布胜利。DC-1 完整地否定了这个想法：这只是整个链条的中间一环。从信息收集、漏洞识别、初始立足、权限提升、目标达成，每一步都缺一不可。更重要的是，系统的很多敏感信息散落在不同位置，需要靠线索去一步一步串起来。你会发现，"找 flag"这个行为本身就是在模拟真实渗透中的"找敏感数据"。

6.2 低权限不代表没戏，系统内部信息才是突破口

很多人在拿到 www-data 的 shell 时就觉得走投无路了，其实恰恰相反。低权限 shell 是信息收集的延续：我们可以读配置文件、查数据库、看目录权限、找 SUID 文件。DC-1 用一条清晰的线告诉我们，系统内的配置信息和权限设置，比外部的漏洞扫描重要得多。这一思路在真实环境里也适用——很多"攻不进去"的系统，一旦你进入内网拿到了一个普通账号，反而处处是突破口。

6.3 靶机经验迁移：DC-1 之后还能刷什么

DC-1 刷完，紧接着可以刷 DC-2、DC-3 等后续系列，它们各自的侧重点不同：DC-2 开始涉及更复杂的攻击面，DC-3 则会推到另一个 CMS 的漏洞利用上。如果有意准备 OSCP 之类偏实战的认证，这套靶机也适合作为练习材料。

不过我个人的建议是，刷完 DC-1 不要急着追求"通关数量"，先把这台机器里的每一条命令、每一步判断都弄清楚，尤其是 SUID 提权那部分，自己动手多试几次直到完全理解原理。这就好比练武的人先学扎马步，扎稳了，后面学什么都快。

最后再说一个我在刷这台靶机时踩过的小坑：提权成功后别直接关掉靶机，先把所有命令执行结果留档记录，日志里写清楚每一步用了什么命令、看到了什么输出。后面如果再做类似靶机，这份记录就是你最好的参考资料，也方便复盘思路。毕竟靶机刷再多，真正长在自己身上的，是那条"遇到新环境不慌，一步步来"的思路习惯。