红队实战：信息收集从侦察到资产测绘的工程化流程-育师

1. 项目概述：红队视角下的信息收集起点

在真实的攻防对抗演练或渗透测试项目中，信息收集的质量直接决定了后续所有行动的效率和成功率。很多刚入行的朋友容易犯一个错误：拿到一个目标域名或IP，就迫不及待地开始上漏洞扫描器，一通狂扫。结果往往是触发了告警，或者面对海量的扫描结果无从下手，效率极低。我干了十多年红队，最深的体会就是：信息收集不是“扫描”，而是“侦察”。你得像特种部队执行任务前一样，悄无声息地把目标周围的地形、建筑结构、人员活动规律摸得一清二楚。

今天要聊的“基础资产信息收集”，就是这场侦察行动的第一步，也是最关键的一步。它指的是在不触发目标安全设备告警的前提下，尽可能全面地发现和梳理与目标相关的所有互联网暴露面资产。这些资产不仅仅是官网域名，还包括子域名、关联域名、IP地址段、开放的端口、运行的Web应用、证书信息、历史DNS记录等等。把这些基础信息摸透了，你手里就有一张清晰的“作战地图”，后续无论是漏洞探测、权限提升还是横向移动，都能做到有的放矢。

这篇文章，我会以一个虚构但典型的“example.com”作为目标，带你完整走一遍我实战中常用的基础资产信息收集流程。我会重点分享工具背后的原理、操作顺序的逻辑，以及那些在公开手册里很少提到的“踩坑”经验和判断技巧。无论你是刚接触红队的新手，还是想优化自己工作流的老兵，相信都能从中找到一些可以直接拿来用的东西。

2. 信息收集的核心思路与原则

在开始具体操作之前，我们必须先统一思想。信息收集不是漫无目的地堆砌工具命令，而是一个有明确目标、分阶段、讲策略的工程化过程。

2.1 侦察而非攻击：保持隐蔽性原则

这是红队信息收集的铁律。所有操作都应以尽可能低的“噪音”进行。这意味着：

控制请求频率：避免对单一目标发起高频、并发的请求。很多工具默认的线程数都很高，在实战中需要手动调低。
使用分散的数据源：优先使用公开的、被动的情报源（如证书透明度日志、DNS历史记录、搜索引擎快照），这些操作不会直接与目标服务器交互。
伪装请求头：使用工具时，注意其User-Agent等HTTP头是否带有明显的工具特征（如httpx/1.2.3），必要时进行修改或使用代理池。
理解工具原理：知道你所用的工具在背后做了什么。比如，一个子域名枚举工具，它是通过暴力字典猜测，还是通过查询第三方API？前者噪音大，后者更安静。

我的经验：在针对防守严密的金融或大型互联网企业时，我通常会设置一个较长的延迟（--delay 2s），并使用住宅代理IP。虽然速度慢，但稳定性极高，几乎从未因信息收集阶段的活动而暴露。

2.2 资产测绘的广度与深度

“基础资产”的范畴需要明确。我们的目标是绘制一张尽可能完整的“数字地产”地图。

广度（横向扩展）：以给定的根域名（如example.com）为起点，发现所有相关的子域名（mail.example.com,api.example.com,dev.example.com）、兄弟域名（如同公司旗下的example.net,example.org）、以及通过投资关系、代码泄露、员工信息等发现的关联资产。
深度（纵向挖掘）：针对每一个发现的域名或IP，我们需要知道：
- 存活状态：它是否在线？（避免在“死”资产上浪费时间）
- 解析情况：它指向哪个或哪些IP地址？
- 端口开放情况：除了80/443，是否开了8080、8443、7001等非常见端口？
- Web应用特征：如果开放了Web服务，它的标题是什么？用了什么技术栈（如Nginx 1.18, PHP 7.4, WordPress 5.8）？是否有特殊的响应头？
- 关联信息：它的SSL证书里还藏着哪些域名？它的历史DNS解析记录有没有指向过内网IP或测试环境？

2.3 工作流设计：从被动到主动，从外部到内部

一个高效的工作流应该是层层递进的：

被动信息收集：利用第三方平台已有数据，零交互。这是第一步，最安全。
主动信息收集：在被动收集的基础上，对发现的资产进行有限的、低强度的主动探测（如HTTP请求、TCP端口连接）。
信息关联与整理：将散乱的数据（域名、IP、证书）进行关联分析，去重、合并，形成结构化的资产清单。
资产筛选与优先级排序：不是所有资产都有同等价值。需要根据业务重要性、技术特征（如使用了老旧框架）、暴露面大小等因素，筛选出高价值目标，供后续深度测试。

接下来，我们就按照这个工作流，一步步展开。

3. 被动信息收集：悄无声息地绘制轮廓

被动收集是梦开始的地方。这里主要依赖各种公开的网络空间测绘引擎、搜索引擎、证书数据库和DNS历史记录。

3.1 子域名发现：撒下一张大网

子域名是目标最常见的扩展资产。我通常会组合多种方法，确保覆盖率。

3.1.1 利用证书透明度（CT）日志这是目前最有效、最安静的发现手段。当目标网站申请HTTPS证书时，证书颁发机构（CA）会将记录提交到公共的CT日志中。这些日志包含了证书中所有的域名（Subject Alternative Name）。

工具：subfinder,amass(passive mode), 或在线工具如crt.sh。
实战命令与解析：
```
# 使用 subfinder 进行被动收集（主要查CT日志） subfinder -d example.com -silent -o subfinder_passive.txt
```
- -silent：只输出结果，不显示banner和错误信息，便于管道传递。
- 原理：subfinder会调用数十个被动数据源API（包括crt.sh,CertSpotter,BufferOverrun等）进行查询。
注意事项：CT日志有延迟，新上线的子域名可能还没记录。同时，它可能包含大量通配符证书（*.example.com）的记录，这类记录对发现具体子域名帮助有限，但证明了通配符证书的存在。

3.1.2 搜索引擎语法（Google Dorking）利用搜索引擎强大的索引能力。

常用语法：
- site:example.com：搜索该域名下的所有页面。
- site:*.example.com：搜索所有子域名（不一定完全准确）。
- 可以结合inurl:admin,intitle:login等关键词，直接寻找管理后台。
自动化工具：theHarvester。它不仅能查Google，还能查Bing、LinkedIn、Shodan等。
```
theHarvester -d example.com -b google,bing -l 500 -f results.html
```
- -b：指定数据源。
- -l：限制结果数量。
- -f：输出到HTML文件，便于浏览。

3.1.3 DNS聚合查询与暴力枚举

聚合查询：工具如amass enum -passive -d example.com，它整合了比subfinder更广泛的被动源。
字典暴力枚举：这是主动方法，但有技巧。关键在于字典质量。
```
# 使用一个优质子域名字典 assetfinder --subs-only example.com | ./altdns -i - -o altdns_output.txt -w words.txt -r -s resolved.txt
```
- altdns工具的作用是进行排列组合。例如，发现dev.example.com和test.example.com后，它会尝试dev-test.example.com、test-dev.example.com等，常用于发现那些遵循特定命名规则的测试、预发布环境。

3.2 关联资产挖掘：顺藤摸瓜

目标往往不是一个孤立的域名。我们需要找到它的“兄弟姐妹”和“邻居”。

Whois信息与备案查询：通过whois example.com查找注册邮箱、电话、注册商。同一邮箱注册的多个域名，极有可能属于同一主体。对于国内目标，ICP备案号是更强的关联依据。
ASN（自治系统号）发现：目标的IP地址属于某个ASN。这个ASN下可能托管了该公司的其他业务IP段。
- 方法：先通过dig +short example.com或nslookup example.com获取一个IP，然后用在线工具（如bgp.he.net）或whois查询该IP所属的ASN。最后，可以尝试查询该ASN下的所有IP段（有些网络空间测绘平台如Shodan,FOFA支持asn:"ASxxxx"语法查询）。
代码仓库与泄露信息：在GitHub、GitLab上搜索公司名、项目名、邮箱后缀，可能发现含有内部域名、API密钥、配置文件的代码片段。

3.3 网络空间测绘引擎的妙用

Shodan, Censys, FOFA, ZoomEye 这些引擎，可以理解为互联网的“全局摄像头”。它们持续扫描全网，并索引设备的banner信息。

搜索语法：
- Shodan:hostname:"example.com",ssl:"example.com",org:"Company Name"
- FOFA:domain="example.com",cert="example.com",icon_hash="-xxxx"（通过网站图标哈希找相同系统）
实战价值：
- 发现非Web服务：直接发现开放了SSH（22）、RDP（3389）、数据库（3306, 6379）等端口的资产。
- 识别技术栈：直接获取服务器软件版本（如nginx 1.16.1）。
- 证书搜索：在Censys中搜索证书的SHA256指纹或直接搜域名，能找到所有使用了该证书的IP，这常常能发现CDN背后的真实IP或未在域名解析中出现的内部资产。

4. 主动信息收集：有限度的接触验证

被动收集给了我们一份资产“候选名单”，现在需要验证它们是否真实存在、是否在线，并获取更多细节。这一步开始与目标有直接交互，需格外小心。

4.1 资产存活检测与解析

拿到一堆子域名，第一步是过滤掉“死”的。

工具选择：httpx,httprobe是常用工具。它们快速发送HTTP/HTTPS请求，根据响应判断存活。
实战命令与深度解析：
```
# 使用 httpx 进行智能存活检测 cat all_subs.txt | httpx -silent -title -status-code -tech-detect -ports 80,443,8080,8443,9000 -o alive_subs.txt
```
- -title：获取页面标题，有助于快速识别应用类型（如“登录后台”、“API Dashboard”）。
- -status-code：记录HTTP状态码。403、401可能意味着有访问控制，但路径存在；500可能暴露错误信息。
- -tech-detect：调用Wappalyzer等库识别技术栈（前端框架、服务器、编程语言等），这对后续漏洞利用选择至关重要。
- -ports：指定探测的端口。这里我除了常见Web端口，还加上了9000（常见于一些管理面板）。你可以根据目标行业调整，比如金融可能常用7001（WebLogic）。
- 原理：httpx会并发地对每个域名:端口组合进行TCP连接，并发送一个HEAD或GET请求。-tech-detect会分析响应头、Cookie名、HTML特征等匹配指纹规则库。

4.2 端口扫描：勾勒服务边界

存活检测主要针对Web，端口扫描则面向所有服务。

策略选择：
- 全端口扫描：耗时，噪音大。仅在目标网络规模小或授权明确要求时使用。masscan是速度之王。
```
masscan -p1-65535 <IP> --rate=1000 -oL masscan.out
```
- 常见端口扫描：最常用。使用nmap自带的服务版本探测和脚本扫描。
```
# 先快速扫描 top 1000 端口，确认开放端口 nmap -sS -T4 --open -n <IP> -oN nmap_quick.txt # 针对开放端口进行服务版本和漏洞脚本探测 nmap -sV -sC -p <开放端口列表> <IP> -oN nmap_detail.txt
```
  - -sS：TCP SYN扫描，半开连接，相对隐蔽。
  - -sV：版本探测。
  - -sC：使用默认的NSE脚本进行更深入的探测（可能触发告警，慎用）。
我的心得：不要一上来就对所有IP进行全端口扫描。我通常先对通过域名解析得到的IP进行常见端口扫描。如果发现某个IP是负载均衡或CDN节点，则对其背后的IP段（通过ASN或旁站信息推测）进行更有针对性的扫描。永远把Web端口（80,443,8080等）的扫描和深度探测放在最优先的位置，因为Web是当前最主要的攻击入口。

4.3 Web应用信息指纹识别

对于存活的Web服务，我们需要像法医一样提取其“指纹”。

手动查看：永远不要完全依赖工具。浏览器访问，查看：
- 源代码：注释里可能有开发者信息、内部路径、API密钥（虽然少见）。
- JavaScript文件：/static/js/app.js可能包含版本号、内部接口路径。
- robots.txt, sitemap.xml：暴露目录结构。
- 错误页面：故意触发404或500错误，可能泄露路径、框架信息。
自动化工具：
- whatweb：老牌指纹识别工具，速度快。
```
whatweb https://target.example.com --color=never
```
- Wappalyzer：浏览器插件，直观方便，适合手动排查时快速查看。
- httpx -tech-detect：如前所述，已集成此功能。
关键信息：
- Web服务器：Nginx/Apache/IIS的版本。特定版本可能存在已知漏洞。
- 开发框架：ThinkPHP 5.0.24, Spring Boot 2.3.0等。框架漏洞往往危害巨大。
- 前端框架/组件库：Vue.js, React, jQuery版本。虽然通常不直接导致RCE，但低版本可能包含XSS等前端漏洞的已知利用方式。
- 中间件：Tomcat, JBoss, WebLogic。这些是重点攻击目标。
- CMS系统：WordPress, Joomla, Drupal及其插件/主题版本。有庞大的漏洞库对应。

5. 信息整理与关联分析：从数据到情报

收集来的数据是原始、杂乱且重复的。这一步的目标是将其转化为结构化的、可操作的情报。

5.1 数据去重与归一化

域名去重：同一个域名可能被多种方法多次发现。使用sort -u即可。

IP去重与C段提取：将解析到的所有IP地址去重，并归类到C段（/24网段）。这有助于发现目标公司的IP地址范围。

# 假设从 alive_subs.txt 中解析出IP并存到 ips.txt cat alive_subs.txt | awk '{print $2}' | sort -u > unique_ips.txt # 提取C段 cat unique_ips.txt | sed 's/\.[0-9]*$/.0\/24/' | sort -u > c_blocks.txt

端口服务整合：将nmap扫描结果与httpx的Web探测结果合并，形成“资产-IP-端口-服务-应用”的对应表。

5.2 资产清单与可视化

我习惯用Markdown或Excel来维护最终的资产清单。一个简单的表格可能包含以下列：

序号	域名	IP地址	端口	服务/协议	Web标题	技术栈	备注（如CDN、WAF）
1	`www.example.com`	1.2.3.4	80,443	HTTP/HTTPS	Example Inc. Home	Nginx, React	Cloudflare CDN
2	`api.example.com`	1.2.3.5	443	HTTPS	Example API Gateway	OpenResty, Java	自建WAF
3	`devops.example.com`	1.2.3.6	22,8080	SSH, HTTP	Jenkins	Jenkins 2.346	高危资产

对于大型项目，可以使用Aquatone这样的工具进行可视化。Aquatone会对所有Web资产截图，并生成一个HTML报告，让你能快速浏览所有Web应用的界面，直观发现登录口、管理后台等。

cat alive_web_urls.txt | aquatone -out ./aquatone_report

5.3 高价值目标筛选

不是所有资产都值得投入同等精力。需要建立筛选标准：

业务重要性：官网、核心API、支付系统、管理后台。
技术脆弱性：
- 使用了已知存在漏洞的组件版本（如Log4j2, Fastjson特定版本）。
- 暴露了敏感服务（如Jenkins, GitLab, Docker Registry, Redis未授权）。
- 使用了老旧或不再维护的技术（如Struts2, WebLogic旧版）。
暴露面大小：面向公众登录的系统和内部员工使用的系统，优先级不同。
资产唯一性：如果多个子域名指向同一个IP的同一个应用（如多个域名泛解析到同一台服务器），可以合并测试，避免重复劳动。

基于这些标准，在资产清单中标记出“P0”（最高优先级）、“P1”、“P2”等级别，指导后续的渗透测试工作。

6. 实战流程串联与自动化脚本

理论说再多，不如一个完整的实战例子。下面我以example.com为目标，串联起一个半自动化的流程。这个流程平衡了效率和隐蔽性。

6.1 第一阶段：被动收集与初步枚举

#!/bin/bash TARGET="example.com" OUTDIR="./recon-$TARGET" mkdir -p $OUTDIR echo "[*] 开始被动子域名收集..." subfinder -d $TARGET -silent -o $OUTDIR/subfinder.txt amass enum -passive -d $TARGET -o $OUTDIR/amass_passive.txt echo "[*] 从证书透明度日志收集..." # 使用 curl 查询 crt.sh curl -s "https://crt.sh/?q=%25.$TARGET&output=json" | jq -r '.[].name_value' | sed 's/\*\.//g' | sort -u > $OUTDIR/crtsh.txt echo "[*] 合并去重..." cat $OUTDIR/subfinder.txt $OUTDIR/amass_passive.txt $OUTDIR/crtsh.txt | sort -u > $OUTDIR/all_subs_passive.txt echo "[+] 被动收集完成，共发现子域名: $(wc -l < $OUTDIR/all_subs_passive.txt) 个"

6.2 第二阶段：主动验证与Web探测

echo "[*] 开始HTTPX存活探测与指纹识别..." # 解析域名到IP，并去重 cat $OUTDIR/all_subs_passive.txt | dnsx -silent -a -resp-only -o $OUTDIR/resolved_ips.txt # 对子域名进行智能Web探测 cat $OUTDIR/all_subs_passive.txt | httpx -silent -title -status-code -tech-detect -ports 80,443,8080,8443,9000,7001 -o $OUTDIR/alive_web_details.txt # 对解析出的IP进行常见端口扫描（这里以 top 100 为例，实际可调整） echo "[*] 对解析出的IP进行快速端口扫描..." cat $OUTDIR/resolved_ips.txt | naabu -silent -top-ports 100 -o $OUTDIR/naabu_ports.txt echo "[+] 主动探测完成。存活Web资产详情见: $OUTDIR/alive_web_details.txt" echo "[+] 开放端口信息见: $OUTDIR/naabu_ports.txt"

6.3 第三阶段：信息整合与报告生成

echo "[*] 整合信息，生成简易报告..." # 提取纯存活域名列表 cat $OUTDIR/alive_web_details.txt | awk '{print $1}' | sort -u > $OUTDIR/final_alive_domains.txt # 生成一个简单的CSV格式资产表 echo "Domain,IP,Ports,Title,Technologies" > $OUTDIR/asset_inventory.csv # 这里需要编写更复杂的脚本将 httpx 和 naabu 的结果关联起来，此处为示意 # 可以使用python或更高级的bash脚本来处理 echo "[*] 使用 Aquatone 生成可视化报告 (如果资产较多)..." if [ $(wc -l < $OUTDIR/final_alive_domains.txt) -lt 50 ]; then cat $OUTDIR/final_alive_domains.txt | aquatone -out $OUTDIR/aquatone_report -screenshot-timeout 5000 echo "[+] 可视化报告已生成至: $OUTDIR/aquatone_report/aquatone_report.html" else echo "[-] 存活资产过多，跳过Aquatone截图以避免长时间请求。" fi echo "[!] 信息收集初步完成。请人工审查以下文件：" echo " - $OUTDIR/alive_web_details.txt (核心资产详情)" echo " - $OUTDIR/naabu_ports.txt (非Web服务)" echo " - $OUTDIR/aquatone_report/ (可视化截图，如有)" echo "" echo "下一步建议：根据技术栈和业务重要性，筛选出P0/P1级目标进行漏洞扫描和深度测试。"

这个脚本只是一个起点，你可以根据项目需求添加更多模块，比如GitHub监控、ASN查询、WAF识别等。

7. 常见问题、踩坑经验与进阶技巧

信息收集路上坑很多，分享几个我印象深刻的。

7.1 关于CDN与真实IP的“猫鼠游戏”

这是最常见的问题。目标用了Cloudflare、Akamai等CDN，你扫描到的IP都是CDN节点。

应对策略：
1. 历史DNS记录：查询securitytrails.com,viewdns.info等网站，看目标域名历史上是否直接解析到过真实IP。
2. 子域名探测：很多公司只给主站www用了CDN，而api、dev、mail等子域名可能直连源站。
3. SSL证书关联：在Censys/Shodan搜索目标证书的SHA256指纹，可能会找到绑定同一证书但未接入CDN的其他IP或域名。
4. 邮件服务器：给目标企业邮箱（如admin@example.com）发封邮件，查看邮件头中的Received字段，有时会泄露内部邮件服务器的IP。
5. 业务漏洞：如果目标有移动App，可以尝试抓包，App内的API接口可能直连源站IP。
我的心得：不要执着于“找到唯一真实IP”。在现代云架构下，真实IP可能是一个弹性负载均衡器，后面还有多层网络。我们的目标是找到“可攻击的入口”。如果主站防护严密，那些被忽略的、未接入CDN的子域名或测试环境，往往是更好的突破口。

7.2 工具误报与请求风暴

误报：工具可能把泛解析的域名（*.example.com）或CDN的边缘节点IP当作独立资产报出来。需要人工复核，尤其是那些返回相同内容的资产。
请求风暴：使用masscan或高线程的httpx、ffuf时，极易对目标造成DDoS攻击效果，触发防火墙或导致服务不可用。
- 解决方案：始终使用-rate或-t参数限制速率。在脚本中加入sleep随机延迟。对于重要项目，最好在本地或可控的VPS上先对一个小样本进行测试，确定合适的速率阈值。

7.3 信息过载与效率瓶颈

当目标资产成千上万时，如何高效处理？

分层处理：不要试图一次性对所有资产进行深度扫描。先进行轻量级的存活探测和端口扫描，快速筛选出一批“看起来有意思”的资产（如开放了非常见端口、使用了特定技术栈的），再对这批资产进行深度扫描和漏洞探测。
用好grep,awk,jq：命令行工具是处理文本数据的神器。例如，快速筛选出所有使用了Spring Boot的资产：
```
cat alive_web_details.txt | grep -i "spring" | awk '{print $1}'
```
引入消息队列和数据库：对于超大型项目，可以考虑用Redis做任务队列，用MySQL或Elasticsearch存储资产数据，并编写调度程序来管理扫描任务。但这属于高阶玩法，需要一定的开发能力。

7.4 法律与授权红线

这是最重要的一条，没有之一。

授权范围：严格在授权范围内进行测试。如果授权书只写了example.com，那么example.net即使属于同一公司，也不能测试，除非获得书面补充授权。
测试时间：遵守约定的时间窗口（如仅限工作时间）。避免在业务高峰或深夜进行可能影响服务的扫描。
敏感操作：禁止使用--script vuln这类可能直接攻击漏洞的Nmap脚本，除非授权明确允许。禁止对非授权目标进行暴力破解。
数据保密：收集到的所有信息，包括可能意外发现的用户数据、源代码片段，都必须严格保密，仅在报告中使用，测试结束后应安全删除。

信息收集是红队工作的基石，也是一门需要持续积累经验和更新知识的艺术。工具在变，目标的防御手段在变，但“侦察-分析-决策”的核心逻辑不变。这套流程和思路是我多年实战总结下来的，它不一定是最快的，但力求是稳健和全面的。真正的效率，不在于你敲命令的速度，而在于你能否从纷繁复杂的信息中，迅速找到那条通往目标核心的、最隐蔽的路径。每次项目结束后，记得复盘你的信息收集过程，看看漏掉了什么，哪些方法最有效，不断迭代你自己的“武器库”和“战术手册”。