渗透测试工作内容

客户把一台服务器交给你，渗透说“随便测”。测试你拿到IP，工作扫端口，内容发现开了22、渗透80、测试443、工作3306。内容80端口跑着一个老旧的渗透CMS，后台路径是测试/admin。你试了admin/admin，工作进去了。内容整个过程不到十分钟。渗透这就是测试渗透测试最理想的状态——但大多数时候没这么顺利。

渗透测试的工作核心是模拟攻击者的思路去发现系统弱点。它不是拿着扫描器跑一遍就完事。扫描器能告诉你“这里可能有个漏洞”，但能不能利用、利用之后能拿到什么权限、会不会被WAF拦截，这些都得靠人手动验证。我见过太多报告里堆满了“疑似SQL注入”“可能存在XSS”，结果客户拿去问开发，开发说“这个参数我们做了过滤”。扫描器误报率高得离谱，不手动确认一遍，报告就是废纸。

信息收集阶段最枯燥，也最关键。WHOIS查域名注册信息，子域名爆破找边缘资产，Google Hacking搜敏感文件，GitHub上翻员工泄露的代码仓库。有次我在一个客户的GitHub公开仓库里翻到了数据库连接字符串，账号密码直接写在配置文件里。那个仓库是两年前一个实习生建的，用来做测试，后来人走了，仓库还在。这种事扫描器永远发现不了。

拿到入口之后就是提权。Windows上跑个PowerUp.ps1看有没有没打补丁的本地提权漏洞，Linux上翻SUID文件、看cron任务、查内核版本。有个细节很多人忽略：/etc/passwd可写的话，直接加个root权限的用户就行。比费劲找内核exploit快多了。提权这事讲究性价比，能简单拿下的绝不绕远路。

横向移动是渗透测试里最像“攻击者”的部分。拿到一台机器后，翻浏览器保存的密码、翻SSH私钥、翻配置文件里的数据库凭证。用mimikatz抓Windows内存里的明文密码，用BloodHound分析域环境里的攻击路径。有次我在一台运维跳板机上找到了整个内网所有服务器的SSH密钥，因为那个运维图省事，把私钥放在了跳板机的~/.ssh/下面，还没设密码。一台机器失守，整个内网沦陷。

报告是渗透测试的最终交付物。但写报告比做测试还累。漏洞描述要清晰到开发能复现，修复建议要具体到改哪行配置。别写“建议加强输入验证”这种废话，要写“在/api/login接口的username参数处，使用参数化查询替换字符串拼接”。风险等级别乱标，一个反射型XSS标成高危，客户会觉得你在凑数。我通常把能直接获取服务器权限的漏洞标高危，能获取敏感数据的标中危，其余标低危。主观但实用。

渗透测试的边界很模糊。客户说“测这个网站”，你发现网站和内部OA系统共用同一个数据库，那要不要继续往下测？我的原则是：任何可能影响业务连续性的操作，提前和客户确认。别自作主张去跑drop table，也别在客户没授权的情况下对内网其他机器发起攻击。技术再强，进去踩缝纫机就不好玩了。

这行做久了会发现，最薄弱的环节永远是人。弱密码、配置错误、忘记删除的测试接口、离职员工没回收的权限。技术漏洞好修，人的习惯难改。每次测试完，我都会在报告最后附上一段“管理建议”，虽然客户通常只看漏洞列表。但该说的还是得说。