渗透测试基础

一次真实的渗透渗透测试，往往是测试从一条看起来毫无价值的报错信息开始的。去年我帮一家小型电商做安全评估，基础扫端口时发现8080端口跑着一个Jenkins服务，渗透版本是测试2.289。这个版本存在未授权访问漏洞。基础登录进去之后，渗透在“系统管理”里翻到了数据库连接串，测试明文写的基础。整个过程不到二十分钟，渗透从外部直接摸到了核心数据。测试渗透测试的基础核心就在这里——不是堆工具，是渗透顺着信息碎片往深处挖。

很多人把渗透测试和漏洞扫描混为一谈。测试扫描器跑一遍，基础出一份报告，那叫体检。渗透测试是模拟真实攻击者的思维，手工验证每一个可能的入口。扫描器告诉你“这里可能有个SQL注入”，渗透测试要证明它能不能查数据、能不能写文件、能不能提权。前者是报警器，后者是破门而入。

流程上，正规的渗透测试分几个阶段。信息收集排第一位，也最耗时间。目标域名、子域名、IP段、邮箱格式、员工姓名、技术栈版本，这些信息散落在搜索引擎、GitHub、招聘网站、SSL证书透明度日志里。我习惯先跑一遍theHarvester和subfinder，再去Shodan和Fofa上看看有没有暴露的资产。有一次从目标公司一个离职员工的GitHub仓库里翻到了内网VPN的配置文件，虽然密码已经过期，但VPN的域名和端口信息直接暴露了边界入口。

拿到足够信息后进入扫描和枚举阶段。Nmap扫端口，Nessus或OpenVAS做初步漏洞识别，Gobuster或Dirsearch扫目录。这一步的关键是别贪快。全端口扫描慢，但能发现非标准端口上的服务。很多管理员以为把SSH从22改成2222就安全了，实际上扫描器几秒钟就能找到。枚举阶段要细，比如Web目录扫到一个/backup/，里面可能有数据库导出文件，也可能什么都没有。不试就不知道。

漏洞利用是最考验经验的部分。工具能帮你发现“可能存在”的漏洞，但利用过程往往需要手工调整payload。比如一个文件上传点，前端做了白名单校验，但后端只检查了Content-Type。改包绕过之后上传了.php文件，结果发现服务器禁用了system函数。这时候得换思路，用assert或者preg_replace的/e修饰符，甚至尝试.htaccess配合文件包含。每个环境都不一样，没有一键getshell的万能脚本。

拿到初步权限后，内网横向移动才是重头戏。用mimikatz抓本机密码哈希，用BloodHound分析域内权限关系，找配置错误的服务账户。我见过最离谱的一次，域管理员把密码设成Company@2023，然后这个密码在二十多台服务器上重复使用。抓到一个等于抓到全部。横向移动的核心是信息复用——密码、哈希、票据、SSH密钥，任何一样都能成为下一跳的跳板。

清理痕迹和写报告经常被忽视。真实攻击者会删日志、留后门，渗透测试人员必须记录每一步操作，包括时间戳、IP、执行的命令、产生的文件。报告里要写清楚漏洞的复现步骤、影响范围、修复建议。修复建议不能只写“升级到最新版本”，要具体到配置项。比如“将Jenkins的/script路径限制为管理员访问，并在config.xml中关闭CLI远程调用”。

最后说一个观察。很多企业做完渗透测试，拿到报告就锁进抽屉。三个月后再测，同样的漏洞还在。渗透测试的价值不在于报告本身，而在于修复闭环。我见过一家公司，每次测试完把漏洞按业务线拆解，责任到人，修复后要求复测截图。他们的安全水位在半年内从“一塌糊涂”变成“勉强能看”。工具会过时，漏洞会更新，但“发现-验证-修复-复测”这个循环，才是渗透测试真正该留下的东西。