渗透测试侦察报告怎么写：七段式结构 + 证据链组织 + 攻击路径规划
网络安全实战 90 天 · Week 2 侦察 · 难度 ★★ 入门 | 关键词：侦察报告 渗透测试报告 七段式 证据链 攻击路径 Markdown
扫描做完了，漏洞也查清了，但如果你交出去的是一堆终端截图和零散命令，这份工作等于白做。侦察报告是渗透测试唯一可交付的产物------它决定了别人能不能复现你的发现、能不能据此做决策。这篇讲怎么把一周的零散信息组织成一份 3--5 页、每条结论都有证据的报告。
一、报告为什么重要
很多人把报告当成「走流程的文书工作」，把精力全放在扫描和利用上。这是本末倒置。
渗透测试的交付物不是「我打进去了」这句话，而是一份能让甲方安全团队独立复现、独立验证、独立修复的文档。如果你的报告里写「发现 vsftpd 后门」，但没有版本号、没有 NSE 输出、没有命令，那甲方既无法确认，也无法验证修复是否生效。
更现实的一点：报告里的每一条结论，未来都可能被追问「你怎么知道的」。证据链就是答案。
说明 本文所有数据来自对自建 Metasploitable2 靶机（192.168.159.137）的侦察，在隔离 Host-Only 网络内完成，不涉及任何真实业务系统。报告中出现的 IP、域名均为实验环境内部地址。
二、第一步：先把资料归档
写报告之前先整理文件。一周下来会产生十几份输出：主机列表、端口扫描、版本识别、NSE 结果、searchsploit 输出。散在 home 目录里根本找不到。
按类别归档
text
mkdir -p recon/target recon/scan recon/vuln
mv hosts.txt full_scan.txt recon/scan/
mv vulns.txt recon/vuln/
ls -R recon/
三个目录的含义：target 放目标基本信息（IP、系统、开放服务概览），scan 放扫描原始输出，vuln 放漏洞验证结果。这个划分和后面报告的章节是对应的。
如果忘了某条命令是怎么跑的，用 history 找回来：
从历史记录找回命令
text
history | grep nmap
history | grep searchsploit整理完是 12 个文件。这个数量说明一件事：报告的每一节都应该有对应的原始文件支撑，写的时候直接引用，不靠回忆。
三、第二步：七段式结构
渗透测试报告有行业通用的结构，不需要自己发明。七段式足够覆盖一次侦察任务：
| 序号 | 章节 | 作用 | 篇幅占比 |
|---|---|---|---|
| 1 | 执行摘要 | 给管理层看：目标是什么、发现了什么、风险多大、建议怎么办 | 15% |
| 2 | 目标信息 | 给技术团队看：目标 IP、系统、网络位置、测试时间窗 | 5% |
| 3 | 信息收集 | 怎么找到目标的：域名、子域、资产范围 | 15% |
| 4 | 端口和服务 | 扫出了什么：端口、服务、版本 | 20% |
| 5 | 漏洞分析 | 每个漏洞：编号、影响、证据、严重程度 | 30% |
| 6 | 攻击路径 | 如果真要打，按什么顺序、用什么手段 | 10% |
| 7 | 附录 | 原始输出、完整命令清单、参考资料 | 5% |
这个结构的关键在于「读者分层」。执行摘要给不懂技术的管理层，一句话说清风险；端口和漏洞章节给技术团队，要有可复现的细节。同一份报告服务两类读者，所以顺序不能乱------先结论后细节。
四、第三步：写骨架
用 Markdown 写，纯文本、版本可控、能直接转 PDF。先把七个标题和空表格搭出来，再往里填内容。
report.md 骨架
bash
# 渗透测试侦察报告
## 一、执行摘要
## 二、目标信息
## 三、信息收集
## 四、端口和服务
## 五、漏洞分析
## 六、攻击路径
## 七、附录
为什么用 Markdown 而不是 Word？三个理由：纯文本可以用 git 管理版本；表格和代码块写起来快；pandoc 一条命令就能转 PDF 或 docx。
转成 PDF / Word
text
pandoc report.md -o report.pdf
pandoc report.md -o report.docx五、第四步：填正文
5.1 执行摘要：四要素
执行摘要只有一页，但它是唯一会被所有人读完的一页。四个要素缺一不可：
-
目标：测的是谁，IP 或域名是什么。
-
关键发现：最重要的 3--5 条，一句话一条，带 CVSS 分数。
-
整体风险：严重 / 高 / 中 / 低，一句话给结论。
-
建议：按优先级排的处置动作，第一条永远是最紧急的。
示例：
执行摘要示例
text
**目标**：Metasploitable2 (192.168.159.137)
**关键发现**：
1. vsftpd 2.3.4 存在源码后门（CVE-2011-2523, CVSS 9.8），可直接获取 root 权限
2. Samba 3.0.20 存在远程命令执行（CVE-2007-2447, CVSS 9.3）
3. 1524 端口直接暴露 root shell，无需认证
4. MySQL 5.0.51a root 账号空口令
**整体风险**：严重。攻击者可在无凭据情况下获取系统最高权限。
**建议**：立即将靶机从网络中隔离；生产环境中同类服务应升级至最新稳定版。
5.2 端口和服务：表格化
不要贴终端截图。截图不能复制、不能搜索、不能 diff。用表格：
| 端口 | 协议 | 服务 | 版本 | 状态 |
|---|---|---|---|---|
| 21 | tcp | ftp | vsftpd 2.3.4 | open |
| 22 | tcp | ssh | OpenSSH 4.7p1 | open |
| 23 | tcp | telnet | Linux telnetd | open |
| 80 | tcp | http | Apache httpd 2.2.8 | open |
| 139/445 | tcp | smb | Samba 3.0.20 | open |
| 3306 | tcp | mysql | MySQL 5.0.51a | open |
版本号这一列是重点------后面的漏洞分析完全依赖它。如果扫描时版本是 unknown，要么补扫 --version-all，要么在报告里明确标注「未能识别，需人工确认」。
5.3 漏洞分析：一条一个证据块
每个漏洞独立成块，固定四段：漏洞描述 → 验证过程（命令 + 输出）→ 影响 → 修复建议。
漏洞条目模板
text
### 5.1 vsftpd 2.3.4 源码后门
**CVE**：CVE-2011-2523 **CVSS**：9.8（严重）
**描述**：vsftpd 2.3.4 官方源码被植入后门，登录用户名含 ":)" 时
在 6200 端口启动 root shell。
**验证**：
nmap --script ftp-vsftpd-backdoor -p 21 192.168.159.137
→ VULNERABLE (CVE-2011-2523)
**影响**：未认证攻击者可直接获得 root 权限，完全控制系统。
**修复**：升级 vsftpd 至 3.0.0 以上；核查 6200 端口是否有异常监听。
注意「验证」这一段必须有命令和输出。只写「存在后门」是结论，不是证据。证据是「我跑了这条命令，它返回了这个」。
5.4 攻击路径：按优先级排
漏洞清单是并列的，攻击路径是有序的。要回答的问题是「如果我是攻击者，第一步做什么」。排序依据：成功率、所需前置条件、能拿到什么权限。
| 优先级 | 入口 | 手段 | 预期结果 |
|---|---|---|---|
| 1 | 21/tcp vsftpd 2.3.4 | CVE-2011-2523 后门触发 | 直接 root shell |
| 2 | 139/445 Samba 3.0.20 | usermap_script (CVE-2007-2447) | root 权限命令执行 |
| 3 | 80/tcp Web 应用 | 手工测试（注入、上传、遍历） | web 用户权限 |
为什么把 vsftpd 排第一？因为它只需要发一个特定用户名，不需要任何前置条件，且直接给 root。Samba 排第二是因为同样给 root，但需要构造特定的 SMB 请求，步骤稍多。Web 排第三是因为 Metasploitable2 的 Web 应用需要手工挖，不确定性最高。
六、踩坑记录
| 现象 | 原因 | 解决办法 |
|---|---|---|
| 信息散落在各处，写报告时找不到 | 没有归档习惯 | 按 target/scan/vuln 三类建目录，边做边存 |
| 报告只有结论没有证据 | 写的时候凭记忆 | 每条结论后跟命令 + 输出，从原始文件复制 |
| Markdown 表格在 Word 里错乱 | pandoc 默认样式不兼容复杂表格 | 简化表格列数，或用 docx 模板 |
| 忘了某条命令怎么跑的 | 没记录 | history | grep 关键词 找回，然后补进附录 |
| 报告写了十几页没人看 | 把过程全写进去了 | 控制 3--5 页，细节放附录 |
坑 1：信息散落，写报告时抓瞎
第一版报告写到一半发现，端口清单在 hosts.txt，版本信息在 full_scan.txt，漏洞验证结果在一个没存下来的终端里。只能重扫。
根因不是「忘了存」，是「没有归档结构」。所有输出默认堆在 home 目录，文件名还是 nmap 自动生成的。
改法：动手之前先 mkdir -p recon/{target,scan,vuln}，每条命令的输出直接 -oN 到对应目录。这样报告写到哪一节，就去哪个目录取文件。
坑 2：只有结论没有证据
第一版漏洞分析写的是「发现 vsftpd 存在后门漏洞」。交给同学看，他问「你怎么知道」。
这句话本身没错，但它不是证据。证据应该是：什么版本、用什么命令验证的、返回了什么、CVE 编号是多少。
改法：每个漏洞固定四段------描述、验证（命令+输出）、影响、修复。验证那段必须能被人复制粘贴重跑一遍并得到同样结果。
坑 3：Markdown 表格在 Word 里错乱
用 pandoc 把 md 转 docx，七列的漏洞表格直接挤成一团，列宽全乱。
原因：pandoc 默认按内容长度分配列宽，七列表格在 A4 页面上本来就放不下。
改法：要么减少列数（把「有无 EXP」并进等级列），要么用自定义 docx 模板控制表格样式。最简单的是控制在 5 列以内。
坑 4：忘了命令
写附录要列完整命令清单，但有些命令是几天前跑的，完全不记得参数。
解决：history | grep nmap。bash 的历史记录默认保存最近 1000 条，够用了。更好的习惯是每条关键命令跑完就顺手记到 notes.md 里。
坑 5：报告写太长
第一版写了 15 页，把每条命令的完整输出都贴上去了。自己回头看都嫌累。
报告的价值密度和长度成反比。3--5 页正文足够说清所有事，完整输出全部放附录。管理层只看第一页，技术团队看正文，需要复现的才翻附录。
七、小结
-
报告是渗透测试唯一的交付物，不是走流程的文书。没有报告，工作等于没做。
-
动手前先建目录：recon/target、recon/scan、recon/vuln，所有输出 -oN 到对应位置。
-
七段式结构：执行摘要、目标信息、信息收集、端口服务、漏洞分析、攻击路径、附录。
-
执行摘要四要素：目标、关键发现、整体风险、建议。只写一页。
-
每个漏洞固定四段：描述、验证（命令+输出）、影响、修复。验证段必须可复现。
-
端口和漏洞用表格，不用截图------表格能复制能搜索能 diff。
-
攻击路径要有优先级，排序依据是成功率和能拿到的权限。
-
正文控制在 3--5 页，完整输出进附录。
下一篇：Day014 是 Week 2 的周末闯关------把这一周学的所有技能串成一条完整流程，从 ping 到报告，三小时走完一遍。