信息收集常见误区：90%渗透测试员过度依赖自动化工具

误区："工具越多=结果越好"？

通常的情况是这样的。一位安全研究人员发现了一个目标，例如 target.com，立刻兴奋地打开终端开始运行一系列工具：

subfinder -d target.com -o subdomains.txt
amass enum -d target.com >> subdomains.txt
assetfinder --subs-only target.com >> subdomains.txt
findomain -t target.com -u findomain_results.txt
chaos -d target.com -o chaos_subs.txt

然后对结果进行排序、去重，再运行 httpx 探测存活：

cat *.txt | sort -u | httpx -threads 200 -o live_hosts.txt

成功拿到3400个活跃子域名后，在所有目标上运行自动化漏洞扫描器 nuclei：

nuclei -l live_hosts.txt -t ~/nuclei-templates/ -o nuclei_results.txt

然后...一片寂静。

虽然得到了海量的数据，但没有发现任何有价值的漏洞。最终的结果只是令人困惑、不知如何处理的大列表，缺乏真正的理解。

一次亲身经历的教训

去年，我在一个金融科技公司的漏洞赏金项目中狩猎。项目范围大，赏金丰厚，竞争也十分激烈。我按部就班地运行了“武器库”中的每一个侦察工具：

subfinder -d fintech-target.com -all -o subs.txt
amass enum -passive -d fintech-target.com -o amass.txt
cat subs.txt amass.txt | sort -u | httpx -silent -threads 200 | tee live.txt
cat live.txt | nuclei -t cves/ -t exposures/ -o nuclei.txt

我收集了大量数据，运行了自动化扫描，然后开始随机地对各个端点进行测试。

两周后，我的收获是：0个漏洞。

与此同时，另一位安全研究员在短短三天内，就在该公司的合作伙伴门户中发现了一个关键性的IDOR漏洞。当我问他是如何做到的时，他的回答让我大吃一惊：

“我只关注了大约5个子域名，使用Burp Suite代理了所有流量，仔细映射了每个端点，并理解了它们背后的业务逻辑...”

核心误区：广度优先于深度

这正是90%的安全从业者容易犯的错误：他们优先追求覆盖范围，而非理解深度。

他们希望在理解任何东西之前，先扫描一切。典型的工作流是这样的：

典型的错误工作流

子域名枚举 → httpx探测存活 → nuclei漏洞扫描 → 或许再用ffuf模糊测试 → 困惑与迷茫

这个过程完全没有理解，没有分析，只有自动化，最终导致困惑。

高质量的侦察应该是怎样的？

以下是我在实际工作中采用的方法论，它更注重深度而非广度。

第一步：聚焦子域名发现

不再盲目运行5个工具，而是最多使用一两个质量较高的工具。

主要使用 subfinder 并指定特定的、高质量的数据源：

subfinder -d target.com -sources crtsh,alienvault -o subs_initial.txt

有时会辅以 amass 的被动模式进行补充：

amass enum -passive -d target.com -o amass_passive.txt

合并并去重

cat subs_initial.txt amass_passive.txt | sort -u | tee all_subs.txt

这种方法通常能获得50-200个子域名，数量可管理，不会让人不知所措。

第二步：智能过滤

不要把所有的子域名都盲目地丢给 httpx 进行存活探测。应该先检查哪些是存活的，并获取其技术栈信息，为后续分析提供线索：

cat all_subs.txt | httpx -silent -tech-detect -status-code -title -o live_detailed.txt

寻找有趣的模式

从存活的资产中，过滤出那些更可能包含脆弱功能或敏感信息的目标：

cat live_detailed.txt | grep -iE "admin|staging|dev|test|api|internal|vpn|jenkins|gitlab" | tee interesting.txt

经过这一步，我可能只剩下10-20个真正值得深入调查的目标，效率大大提高。

第三步：深度端点发现

这是大多数人容易搞砸的地方。例如，他们发现了 admin-panel.target.com，马上就开始尝试SQL注入，却从未搞清楚这个管理面板到底存在哪些具体的功能和端点。

我的做法是进行深度爬取：

使用 gospider 进行爬取以寻找端点：

gospider -s "https://admin-panel.target.com" -o gospider_output -c 10 -d 3

提取爬取到的URL和参数：

cat gospider_output/* | grep -Eo "(http|https)://[a-zA-Z0-9./?=_-]*" | sort -u | tee endpoints.txt

重点寻找JavaScript文件（往往包含重要信息）：

cat gospider_output/* | grep "\.js" | tee js_files.txt

运行 GAU 来查找历史端点（从公共档案中）：

echo "admin-panel.target.com" | gau --blacklist png,jpg,gif,css | tee gau_urls.txt

现在，我看到的是真正的攻击面——不仅仅是域名列表，而是具体的、可供测试的端点集合。

第四步：JavaScript 分析

大多数安全测试人员会跳过这一步，这是大错特错的。JavaScript文件常常会泄露API端点、硬编码的秘密、内部逻辑甚至潜在的逻辑缺陷。

下载所有识别出的JS文件：

cat js_files.txt | while read url; do wget -q "$url" -P js_files/; done

在JS文件中搜寻API端点：

grep -r -E "api|endpoint|/v1/|/v2/" js_files/ | tee api_endpoints.txt

搜寻可能泄露的密钥或令牌：

grep -r -iE "api_key|apikey|secret|token|password|aws_access" js_files/ | tee secrets.txt

寻找有趣的参数名：

grep -r -E "\\?[a-zA-Z_]+=|&[a-zA-Z_]+=" js_files/ | tee parameters.txt

第五步：配合 Burp Suite 进行手动探索

我会将所有浏览器流量通过 Burp Suite 代理，然后像一个真实用户一样去使用这个Web应用。

设置Burp为系统代理（Linux环境示例）：

export http_proxy=http://127.0.0.1:8080
export https_proxy=http://127.0.0.1:8080

接着，在应用中到处点击、尝试创建账户、使用各种功能，并仔细观察 Burp 的HTTP历史记录。

主要寻找以下内容：

• 身份验证相关的端点（登录、注册、令牌刷新）
• 有趣的API路径
• 非常规或可疑的请求参数
• HTTP方法（GET, POST, PUT, DELETE等）和状态码
• Cookies和自定义Headers
• 应用程序的业务逻辑流程

这种深入的手动探索是理解应用、发现逻辑漏洞的关键，无法被任何自动化工具完全替代。在云栈社区的安全板块，经常有研究者分享他们通过手动测试发现的精妙逻辑漏洞案例。

一个真实的漏洞赏金案例

某SaaS公司的漏洞赏金项目：

第一步：基础侦察

subfinder -d saas-company.com -o subs.txt
cat subs.txt | httpx -silent -status-code -title | tee live.txt

发现了一个有趣的子域名：api-internal.saas-company.com。

第二步：创建账户并通过 Burp 代理

手动使用应用时，注意到有API调用发送到 api-internal.saas-company.com/v2/。

第三步：使用 ffuf 发现更多端点

ffuf -w ~/wordlists/api-endpoints.txt -u https://api-internal.saas-company.com/v2/FUZZ -mc 200,401,403

发现了 /v2/users, /v2/teams, /v2/admin/reports 等端点。

第四步：测试 /v2/admin/reports（无认证）

curl -X GET "https://api-internal.saas-company.com/v2/admin/reports" \
  -H "Content-Type: application/json"

返回 401 Unauthorized。

第五步：使用我的普通用户令牌尝试访问

curl -X GET "https://api-internal.saas-company.com/v2/admin/reports" \
  -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLC..." \
  -H "Content-Type: application/json"

返回 200 OK，并且响应中包含了所有用户的个人身份信息！
权限失效 = 关键性IDOR漏洞。

最终赏金：4500美元，耗时约3小时。

实用的聚焦侦察脚本

以下是一个简单的Bash脚本，自动化执行上述聚焦侦察的核心步骤：

#!/bin/bash
# focused_recon.sh 🎯

TARGET=$1
if [ -z "$TARGET" ]; then
    echo "用法: ./focused_recon.sh target.com"
    exit 1
fi

echo "[+] 开始对 $TARGET 进行聚焦侦察 🚀"
# 子域名发现 🔍
echo "[+] 寻找子域名..."
subfinder -d $TARGET -silent -o subs.txt

# 检查存活主机并探测技术栈 💻
echo "[+] 检查存活主机..."
cat subs.txt | httpx -silent -tech-detect -status-code -title -o live.txt

# 过滤有趣的目标 🎯
echo "[+] 过滤有趣的目标..."
cat live.txt | grep -iE "admin|staging|dev|test|api|internal" | tee interesting.txt

# 爬取每个有趣的目标 🕷️
echo "[+] 爬取有趣的目标..."
while read url; do
    echo "[+] 爬取 $url"
    gospider -s "$url" -o crawl_output -c 10 -d 2 -t 10
done < interesting.txt

# 提取 JS 文件 📜
echo "[+] 提取 JS 文件..."
grep -r "\.js" crawl_output/ | grep -Eo "(http|https)://[a-zA-Z0-9./?=_-]*\.js" | sort -u | tee js_urls.txt

# 下载并分析 JS 🔎
echo "[+] 分析 JavaScript 文件..."
mkdir -p js_files
cat js_urls.txt | while read js_url; do
    wget -q "$js_url" -P js_files/
done

echo "[+] 在 JS 中寻找秘密... 🔑"
grep -r -iE "api_key|apikey|secret|token|password" js_files/ | tee secrets_found.txt

echo "[+] 寻找 API 端点... 🗺️"
grep -r -E "api/|/v1/|/v2/|endpoint" js_files/ | tee api_endpoints.txt

echo "[+] 侦察完成！✅ 检查输出文件："
echo "    - interesting.txt (先看这里！ 🎯)"
echo "    - secrets_found.txt 🔑"
echo "    - api_endpoints.txt 🗺️"

使用方法：

chmod +x focused_recon.sh
./focused_recon.sh target.com

一些高级技巧与工具

1. 使用 Arjun 发现隐藏参数
   当我找到一个有趣的端点时，会用 Arjun 来发现可能被遗漏的隐藏参数：

   arjun -u https://api.target.com/v1/users/profile -m GET -o arjun_params.txt

   这常常能发现导致漏洞的隐藏参数。

2. 使用 ffuf 进行针对性模糊测试

   • 枚举API版本：

     ffuf -w <(seq 1 10) -u https://api.target.com/vFUZZ/users -mc 200,401,403

   • 模糊测试端点路径：

     ffuf -w ~/wordlists/api_endpoints.txt -u https://api.target.com/v2/FUZZ -mc all -fc 404

   • 模糊测试参数名：

     ffuf -w ~/wordlists/parameters.txt -u "https://target.com/api/user?FUZZ=test" -mc all -fr "error|invalid"

3. 利用 Wayback Machine 查找历史端点

   • 获取目标所有历史URL：

     echo "target.com" | waybackurls | tee wayback.txt

   • 过滤出有趣的模式（如配置文件、管理后台、API）：

     cat wayback.txt | grep -E "\.json|\.xml|\.conf|\.sql|\.bak|admin|api" | tee wayback_interesting.txt

   • 测试这些历史URL是否仍然有效：

     cat wayback_interesting.txt | httpx -silent -status-code -mc 200

4. GitHub 搜索泄露的秘密

   • 使用自动化工具（需要GitHub Token）：

     github-search -d target.com -t $GITHUB_TOKEN -o github_results.txt

   • 或手动搜索关键词，如：
     • "target.com" api_key
     • "target.com" password
     • "target.com" filename:.env

心态的转变：从收集者到分析师

你需要停止思考：“我能找到多少个子域名？”
开始思考：“我对这一个子域名的理解有多深？”

你的终端命令应该反映的是理解的过程，而不仅仅是数据收集的堆砌：

• 糟糕的做法： 巨大的工具输出.txt → ???
• 好的做法： 聚焦的发现.txt → 手动分析 → 针对性测试 → 实质性成果

我当前的实际工作流程

当我开始研究一个新目标时，实际流程如下：

1. 运行聚焦的子域名发现 (5–10 分钟)

   subfinder -d target.com -o subs.txt
   cat subs.txt | httpx -silent -tech-detect | grep -iE "admin|api|dev" | tee interesting.txt

2. 挑选1-2个最有趣的子域名
   （根据关键词、技术栈、状态码等信息判断）

3. 对选定目标进行1–2小时的深度分析

   • 彻底爬取：gospider -s "https://interesting-sub.target.com" -d 3 -c 10 -o crawl/
   • 提取并分析JavaScript文件
   • 手动试用应用，观察Burp Suite中的HTTP历史记录
   • 尝试理解并映射应用的功能点

4. 系统地记录所有发现

   • 子域名：api.target.com
   • 技术栈：Node.js, Express
   • 有趣的端点：/v2/admin/*, /internal/*
   • 奇怪的行为：在 /users/{id} 中接受任意用户ID
   • 下一步行动：测试 /users/{id} 端点是否存在IDOR漏洞

5. 设定时限，有条不紊地测试
   例如，设定一个2小时的计时器，从初步发现中挑选1个子域名，并执行以下深度工作流：

   TARGET="你选择的子域名.com"
   # 1. 爬取 (15分钟)
   gospider -s "https://$TARGET" -d 3 -c 10 -o crawl_$TARGET/
   # 2. 分析JS (30分钟)：提取、下载、grep搜索秘密/端点
   # 3. 在Burp中映射 (45分钟)：使用应用，观察流量
   # 4. 测试发现 (30分钟)

精简高效的工具列表

• 子域名发现：🔍 subfinder, amass (被动模式)
• HTTP探测与指纹识别：💻 httpx (带状态码、标题、技术栈检测), nmap (针对特定端口)
• 爬取：🕷️ gospider, gau (用于历史URL)
• 模糊测试与参数发现：💥 ffuf, arjun
• JavaScript分析：📊 wget, grep
• 手动测试与分析：👨💻 Burp Suite, 浏览器，以及最重要的——你的大脑。

关键在于质量胜于数量。掌握少数几个工具并深入理解其用法，远比盲目堆砌工具链有效。对于希望系统提升手动测试与逻辑漏洞挖掘能力的安全爱好者，可以参考安全/渗透/逆向板块中的深度案例分析。

---

原文：https://infosecwriteups.com/the-recon-mistake-90-of-hackers-make-52723b69b154