内容摘要：```html 渗透测试不是拿着扫描器一顿乱扫就完事。我见过太多新手，一上来就打开Nmap和Burp Suite，对着目标IP狂轰滥炸，结果要么被WAF封了IP，要么触发了IDS告警，连门都没摸到就结

```html

渗透测试不是渗透顺序拿着扫描器一顿乱扫就完事。我见过太多新手，测试一上来就打开Nmap和Burp Suite，通常对着目标IP狂轰滥炸，进行结果要么被WAF封了IP，渗透顺序要么触发了IDS告警，测试连门都没摸到就结束了。通常真正有效的进行渗透测试，顺序比工具重要得多。渗透顺序

第一步永远是测试信息收集，但别急着扫端口。通常先搞清楚目标是进行什么。域名、渗透顺序子域名、测试whois记录、通常DNS历史解析、SSL证书透明度日志——这些公开信息里藏着大量线索。我去年做的一个项目，客户只给了一个主域名，结果通过证书透明度日志找到了一个测试环境子域，那个环境没开WAF，直接成了突破口。这步花的时间往往占整个测试的40%以上，但很多人只给10%。

拿到资产清单后，才开始被动扫描。用Shodan、Censys这类搜索引擎查目标暴露的服务，不直接接触目标。同时翻GitHub、Gitee上的代码仓库，找硬编码的密钥、内网IP、API接口。有个案例是某公司员工把生产环境数据库密码提交到了公开仓库，密码还是三年前没改过的。这种信息比任何漏洞都致命。

主动扫描要放在被动收集之后。用Nmap扫端口时，先做TCP SYN扫描，别用全连接扫描——快且隐蔽。发现开放端口后，再针对性地做服务识别和版本探测。这里有个坑：很多教程让你直接跑nmap -sV -sC，但-sC脚本会发送大量请求，容易触发告警。我一般先只开-sV，拿到版本号后手动查CVE，再决定要不要用脚本验证。

漏洞验证阶段，顺序是从低风险到高风险。先试默认口令、弱口令，比如admin/admin、root/123456。别笑，2023年某省级政务系统后台就是admin/admin。然后试已知CVE的PoC，但注意别用破坏性的exp。我习惯先手动构造请求验证，比如SQL注入先试单引号报错，再试and 1=1，最后才上sqlmap。直接上工具容易把数据库跑崩。

拿到低权限shell后，别急着提权。先做内网信息收集：ipconfig、net user、netstat -ano、查域信息、找共享目录。有次我拿到一个Web服务器权限，发现它连着域控，但直接打域控风险太高。于是先翻Web目录下的配置文件，找到了数据库连接串，再用数据库的xp_cmdshell提权到系统权限。整个过程没触发任何EDR告警。

横向移动要谨慎。优先用目标已有的凭据，比如从内存里抓的hash、从配置文件读的密码。别上来就扫内网445端口，动静太大。用net use试共享，用WMI或PsExec远程执行，但PsExec会留服务，容易被发现。我更喜欢用WinRM或SSH做横向，流量加密且日志少。记住：每跳一次都要清理痕迹，但别用wevtutil cl清日志——那本身就是告警。

最后是报告和复现。别只扔一堆漏洞列表，要写清楚利用链。比如“通过GitHub泄露的AK/SK访问OSS，下载了数据库备份，从备份里拿到用户表，破解出管理员密码，登录后台拿到webshell”。每个步骤附上请求包、响应包、截图。客户要的是能复现的路径，不是CVSS评分。

整个流程里，最容易被忽视的是“回退”。如果某个漏洞验证失败，别死磕。我见过有人在一个SQL注入点上耗了三天，结果换个参数就通了。渗透测试是动态的，顺序不是死的——信息收集可能贯穿始终，漏洞验证可能反复跳回信息收集。工具是死的，思路是活的。

```