渗透测试信息收集

真正决定一次渗透测试成败的渗透收集，往往不是测试漏洞利用那一下的炫技，而是信息前期信息收集的深度和广度。我见过太多新手，渗透收集拿到靶标就急着扫端口、测试跑目录，信息结果在低价值目标上耗光时间，渗透收集最后连入口都没找到。测试信息收集不是信息体力活，它是渗透收集一场需要策略的情报战。

先从最基础的测试域名枚举说起。很多人只知道用子域名爆破工具，信息跑完字典就完事。渗透收集但真正的测试老手会先查证书透明度日志，crt.sh上随便翻翻，信息往往能发现比爆破多出好几倍的子域名。我曾在一次授权测试中，通过证书日志找到一个隐藏的测试环境子域，上面挂着未鉴权的Spring Boot Actuator，直接拖出了数据库配置。那个客户自己都不知道这个子域的存在。

再说IP资产。现在云环境普及，光看DNS解析结果远远不够。你得把目标公司拥有的ASN号找出来，用bgp.he.net查一下，再把ASN下的所有IP段拉下来，跟已知域名解析结果做交叉比对。有个朋友做过一次红队演练，目标用了CDN防护，主站怎么都打不动。他通过ASN定位到目标在海外的一个机房段，发现那个段里有个老旧的SVN服务器，里面竟然存着生产环境的源码备份。

端口扫描也讲究取舍。全端口扫描当然全面，但耗时长，容易被发现。我习惯先用masscan快速扫TCP 1-65535，再用nmap对开放端口做服务版本识别。重点不是看端口开没开，而是看服务版本有没有过时。比如发现某个内网管理系统开着8080端口，跑的是Tomcat 8.0.30，那基本等于告诉我它有CVE-2017-12615这个上传绕过漏洞。版本号就是财富。

Web应用的信息收集更得细。别只跑目录字典，要手动看robots.txt、sitemap.xml，甚至检查网站源码注释。有一次我就是在页面底部HTML注释里看到开发者的调试接口，参数里带着数据库连接字符串。还有，记得分析JS文件。现在前端框架盛行，很多API路径和内部接口都写在JS里。用工具自动提取JS中的URL和敏感关键字，能省不少力气。

社会工程学层面的信息收集容易被技术型渗透人员忽略。LinkedIn上的员工职位、GitHub上公司组织的代码仓库、招聘网站上的技术栈描述，这些都是线索。我看到过一份招聘JD，明确写着“熟悉Kafka和Redis集群运维”，那基本确认了目标内部用了这些组件。后续打点时就专门找对应的未授权访问漏洞。

信息收集的终点不是数据堆积，而是攻击路径的清晰化。你收集到的每一条信息，都应该能回答一个问题：它如何帮助我突破下一层防线？如果收集了一堆数据却理不出头绪，那只是自我安慰式的努力。我在实战中习惯画一张资产关系图，把域名、IP、端口、服务、人员、技术栈全部连起来。当这张图上的某个节点出现明显弱关联时，往往是突破口的征兆。

最后说句实在话，信息收集没有捷径。工具只是辅助，关键在于你愿不愿意多翻几个页面、多查几个数据源、多问几个为什么。那些看似不起眼的小细节，比如一个默认的报错页面、一个未删除的测试账号、一条过期的DNS记录，都可能成为撬动整个内网的支点。