渗透测试不是渗透拿着扫描器跑一遍就完事。去年有个客户，测试某电商平台，技术安全团队自己用商业扫描工具跑了三遍，详解报告显示“无高危漏洞”。渗透我接手后，测试花了二十分钟，技术在用户注册接口的详解验证码逻辑里找到一处条件竞争——并发请求同一手机号，验证码校验会被绕过。渗透注册成任意手机号，测试再配合密码重置流程，技术直接接管账户。详解扫描器没报，渗透因为它不理解业务逻辑。测试
这就是技术渗透测试和自动化扫描的根本区别。工具能发现已知模式的漏洞，比如过时的Struts2、没打补丁的Log4j。但真正的风险往往藏在代码逻辑里：权限校验写错了位置、订单金额从前端传入、JWT密钥硬编码在JS文件里。这些东西，只有人去看、去试、去构造异常请求才能挖出来。
信息收集阶段，很多人直接上nmap扫端口。我习惯先翻GitHub。搜公司域名、搜员工邮箱前缀，经常能找到开发人员误提交的配置文件。有一次在某金融公司，GitHub上找到一个两年前的仓库，里面application.yml写着生产数据库的JDBC连接串和明文密码。数据库只开了内网，但同一仓库里还有一份VPN配置。从外网到内网，就差这一步。
漏洞利用环节，别迷信Metasploit的exploit模块。真实环境里，payload经常被WAF拦、被EDR杀。手动构造请求更可靠。比如SQL注入，工具跑出来的注入点可能只支持布尔盲注，速度慢还容易被封IP。自己写脚本，用DNS外带数据，或者利用MySQL的LOAD_FILE读文件，效率高得多。我见过一个Oracle注入点，工具跑不出来，因为WAF把union select全拦了。换成DBMS_XMLGEN函数，配合HTTP请求走私，数据直接带出来。
权限维持这块，说个实在的。拿到webshell之后，别急着提权。先看web目录的权限、看crontab、看SUID文件。有一次在Linux服务器上，web用户不能sudo，但/usr/bin/find有SUID位。一条命令：find / -exec /bin/sh -p \;，直接root。这种配置错误比内核提权漏洞常见得多，也稳定得多。
横向移动时，别只盯着SMB和WMI。Redis未授权、Docker API未授权、K8s的etcd暴露——这些云原生环境里的问题，传统渗透测试流程经常漏掉。去年一个客户，内网K8s集群的etcd端口对办公网开放，etcdctl直接读出所有Secret，包括service account token。拿着token创建Pod，挂载宿主机根目录，整台节点沦陷。从etcd到节点root，不到五分钟。
报告怎么写？别堆CVSS分数。业务方看不懂AV:N/AC:L/PR:N。直接说：这个漏洞能让攻击者以你的身份下单，不用付款。那个漏洞能让任何人重置你的管理员密码。把利用过程写清楚，截图、请求包、响应包都贴上。修复建议要具体到代码行，别写“加强输入验证”，写“在UserController.java第87行，把String sql = "select * from users where id = " + id改成PreparedStatement”。
最后说个观察。很多甲方把渗透测试当合规任务，测完拿报告交差。但真正有价值的渗透测试，是攻击者视角的思维过程。我每次测试完，都会给客户讲一遍“如果我是坏人，我会怎么利用这些漏洞组合攻击”。单看一个XSS可能只是中危，但配合CSRF和弱Session管理，就能变成账户接管。这种链条，报告里写不出来，得当面聊。