从零到一：一次真实客户渗透测试的完整复盘与实战解析

最新推荐文章于 2026-06-29 14:29:37 发布

原创

最新推荐文章于 2026-06-29 14:29:37 发布 · 566 阅读

1. 从零到一：一次真实客户渗透测试的完整复盘

最近刚结束一个客户的授权渗透测试项目，整个过程堪称一部“经典漏洞教科书”。客户是一家中小型互联网公司，业务涉及在线服务和内部管理系统。在拿到授权书和测试范围后，我们开始了为期一周的“狩猎”。这次经历非常典型，几乎把Web安全里那些老生常谈但又屡试不爽的漏洞都碰了个遍，从信息收集的蛛丝马迹，到漏洞利用的层层递进，再到权限提升的内网漫游，完整走了一遍攻击链。对于想从零开始学习网络安全、理解渗透测试实战流程的朋友来说，这个案例的拆解价值极高。它不像那些高度抽象的CTF靶场，而是充满了真实业务逻辑、复杂交互和意想不到的“坑”。接下来，我就以这次实战为蓝本，带你一步步拆解，看看一个“白帽子”是如何思考、如何操作，并最终达成目标的。无论你是完全零基础的小白，还是有一定理论基础但缺乏实战经验的新手，这篇复盘都能给你提供一个清晰的、可复现的路径。

2. 项目整体设计与攻击思路拆解

2.1 目标分析与测试范围界定

拿到项目，第一步永远不是直接打开扫描器狂轰滥炸。我们首先和客户进行了深入沟通，明确了测试目标：不是搞破坏，而是以攻击者视角，评估其对外服务（官网、用户中心、API接口）和部分内部管理系统的安全性，发现潜在风险，并给出可落地的修复方案。测试范围白纸黑字写在授权书里：主域名 *.client.com 及其子域名，以及指定的两个管理后台IP地址。 这里有个关键点 ：授权范围之外的资产，即使发现了漏洞也绝对不能碰，这是职业操守和法律底线。

我们的核心思路是模拟一个具备中等技能水平的恶意攻击者。他不会一开始就使用0day漏洞，而是遵循一个成本最低、效率最高的路径：先利用公开的、常见的漏洞打开突破口，获取初始立足点，然后逐步深入，探索内网，寻找更高价值的资产。这个思路决定了我们整个测试流程的节奏和工具选型。

2.2 攻击链蓝图与阶段划分

基于上述思路，我将整个渗透过程划分为四个清晰的阶段，这构成了本次实战的“攻击链蓝图”：

信息收集与侦察 ：目标是尽可能全面地绘制目标网络地图，发现所有暴露在互联网上的资产（域名、IP、端口、服务、技术栈），并收集可能泄露的敏感信息（员工邮箱、代码片段、文档等）。这是所有后续动作的基础，信息越全面，攻击面就越广。
漏洞扫描与验证 ：在收集到的资产上，使用自动化工具和手动测试，寻找已知的、常见的漏洞。这里的关键是“验证”，扫描器报的漏洞十有八九是误报，必须手动验证其真实性和可利用性。
漏洞利用与初始入侵 ：针对已验证的高危漏洞，编写或使用现有利用代码（Exploit），获取对目标系统的第一个“立足点”。通常是一个低权限的Shell（命令执行界面）或Webshell（网页后门）。
权限提升与内网横向移动 ：在获得立足点后，尝试提升当前用户的权限（例如从普通用户提升到系统管理员），并以被攻陷的机器为跳板，探测和攻击内网中的其他机器，扩大战果。

这个蓝图不是线性的，而是一个循环往复、不断深入的过程。接下来，我们就按照这个蓝图，看看在这次实战中具体发生了什么。

3. 核心环节实操与漏洞深度解析

3.1 第一阶段：信息收集——打开视野的钥匙

信息收集是渗透测试中我最喜欢也最花时间的部分，它像侦探破案，考验的是耐心和想象力。我们分几个层面进行：

3.1.1 主动侦察：资产发现

首先从主域名开始。使用 subfinder 、 amass 等子域名枚举工具，我们发现了十几个子域名，除了常见的 www 、 api 、 admin 之外，还有一个 dev.client.com 和一个 test.client.com ，这立刻引起了我们的注意。开发（dev）和测试（test）环境往往是安全防护的薄弱环节。

接着进行端口扫描。使用 nmap 对发现的所有IP进行全端口扫描（ -p- ），配合服务版本探测（ -sV ）和脚本扫描（ -sC ）。结果发现除了80、443等Web端口，一台服务器还开放了21（FTP）、22（SSH）、3306（MySQL）和6379（Redis）端口。 这里有个技巧 ：对于像22、3306这种管理端口，如果暴露在公网且使用弱密码，那就是极佳的突破口。我们将其标记为后续重点测试对象。

3.1.2 被动信息收集：挖掘公开情报

这步常在搜索引擎、GitHub、网盘等公开平台进行。我们尝试搜索 site:github.com “client.com” password 、 site:client.com ext:pdf 等语法。果然有“收获”：在GitHub上发现了一个属于该公司前员工的仓库，里面竟然包含了一个数据库配置文件的旧版本，其中明文写着测试数据库的地址和密码！虽然密码可能已失效，但这是一个强烈的信号，表明公司的代码管理可能存在疏忽。我们还利用 theHarvester 工具收集了与公司域名相关的邮箱，为后续可能的钓鱼攻击或密码爆破准备了一份名单。

3.1.3 技术栈指纹识别

访问主要网站，通过浏览器的开发者工具查看HTTP响应头、Cookie、HTML源码中的注释，以及引入的JavaScript库，我们快速识别出技术栈：前端使用Vue.js，后端主要使用ThinkPHP 5.0框架，部分服务使用Nginx 1.18。知道框架和版本号至关重要，因为我们可以立刻去搜索这些版本是否存在公开的、未修复的漏洞。例如，ThinkPHP 5.0.x版本存在多个已知的远程代码执行漏洞。

注意：信息收集阶段一定要做好记录！我习惯用OneNote或Obsidian这样的笔记软件，为每个目标建立一个页面，分门别类地记录IP、域名、开放端口、服务版本、发现的敏感信息等。清晰的记录在后续复杂的测试中能节省大量回溯时间。

3.2 第二阶段：漏洞扫描与手动验证——去伪存真

有了资产列表，我们开始进行漏洞扫描。但切记， 完全依赖自动化扫描报告是新手最容易犯的错误 。

3.2.1 自动化工具辅助

我们使用 Nessus 和 AWVS 对Web应用进行扫描。扫描报告很快出来，列出了几十个“问题”，从低危的“Cookie缺少HttpOnly标志”到高危的“SQL注入可能性”。我们需要像过筛子一样处理这些结果。

误报剔除 ：大部分“中危”、“低危”漏洞，如 X-Content-Type-Options 头缺失，属于安全配置问题，我们记录但暂不深入。那些标记为“可能的SQL注入”或“可能的XSS”的点，需要手动验证。
重点标记 ：扫描器报告 dev.client.com 存在“源代码泄露”风险，提示了 .git 目录和 DS_Store 文件。同时，在 api.client.com 的一个接口参数处，报告了“潜在的SQL注入”。

3.2.2 手动验证实战：以SQL注入为例

报告指出 api.client.com/userinfo 接口的 id 参数可能存在注入。我们打开Burp Suite，拦截这个请求。

初步探测 ：将 id=1 修改为 id=1' ，发送请求。页面返回了数据库错误信息（ThinkPHP的默认错误页面暴露了SQL语句片段），这证实了该参数未对单引号进行过滤，存在注入点。
判断数据库类型 ：通过错误信息，直接确认是MySQL数据库。
信息获取 ：使用联合查询（Union Select）来获取数据。但直接使用 id=1 union select 1,2,3 可能会因为列数不匹配而失败。我们需要先判断列数。通过 id=1 order by 4 和 id=1 order by 5 测试，发现 order by 4 正常， order by 5 报错，说明当前查询的列数为4。
构造Payload ：构造注入语句： id=-1 union select 1, database(), user(), version()-- <