简介面向中职网络安全技能比赛与网络空间安全学习者的B.pcap数据包流量分析解析文档聚焦数据流量分析与数据安全取证场景可帮助备赛选手快速理解渗透测试与流量审计的关键技法。文档为单文件docx格式整体大小3.27MB内容以Word笔记形式呈现便于查阅与打印。目前已有744人学习下载适用于网络安全相关专业学生及技能竞赛训练。解析围绕Windows7虚拟机上的B.pcapng数据包展开完整梳理了数据库flag字符定位、黑客扫描主机IP识别、服务器内核版本查询、网段扫描命令还原、一句话木马上传文件提取以及服务器下载文件内容获取等任务每题均给出分析路径与最终Flag值并附有Base64解码等操作提示。读者可对照文档中的逐步分析思路独立复现数据包解码过程从而加深对流量分析、命令还原与日志取证的掌握提升竞赛实战与日常安全分析能力。1. 这份 B.pcapng 分析资源六个 flag 背后是一条完整攻击链流量分析题最怕的不是包多是拿到一个 pcapng 之后不知道往哪看。这份 B.pcapng 不一样它把一整条攻击链直接摆在你面前扫描网段、SQL 注入、传 webshell、下载文件六个 flag 分别对应攻击链上的六个关键点。这份 docx 把题干和答案一起给了但我拿到手第一反应不是背答案而是把每个 flag 反推回数据包里的对应位置因为真正比赛时你面前只有一个裸包。适合正在备赛网络安全赛项、以及想用真实攻击流量做取证练习的从业者。网盘里那个 B.pcapng 解压之后就能照着下面的思路完整复现一遍。2. 从打开数据包到还原攻击链Wireshark 全局视角与三条关键线索2.1 先看全局这台 Windows7 到底经历了什么拿到 B.pcapng别急着搜 flag 字符串。我一般先看 Wireshark 的 Statistics 菜单里的 Protocol Hierarchy这一步 30 秒就能把包的「骨架」摸清楚。这份数据包里TCP 流量占绝对大头HTTP 请求数量不少还有一定量的 MySQL 协议流量和 ICMP 探测包。这个组合本身就说明问题有扫描、有 Web 交互、有数据库操作典型的攻击链特征。Wireshark 打开文件之后第一时间切到 Statistics Protocol Hierarchy其实是在回答三个问题这个包是纯内网抓的还是跨网段的有没有应用层协议HTTP、MySQL有没有明显的探测行为大量 ICMPB.pcapng 的答案分别是内网抓包、有 HTTP 和 MySQL、ICMP 数量异常。就凭这三条已经能猜出后面大半剧情。另一个值得先做的事是看 Conversations 视图按流量大小排序。攻击阶段的流量通常集中在某一对 IP 之间这对 IP 就是后续所有 flag 的主线。我在 B.pcapng 里看到的活跃会话基本都汇聚到同一个目标地址上这个地址就是后面任务书里说的服务器也是第 2 题要提交的主机 IP。先锁定会话比在几百个包里瞎翻效率高得多。2.2 三条线索扫描、注入、shell 行为对应三类协议把攻击链映射到具体协议后面筛包就有方向了。扫描阶段最明显的特征是 ICMP echo 请求和大量的 TCP SYN 包源地址固定目的地址在一个网段内连续变化这是内网主机发现的典型形态。SQL 注入阶段则表现为 HTTP 请求里带查询参数同时数据包里出现 MySQL 协议流量说明 Web 应用把恶意请求透传到了数据库。到了 webshell 阶段特征是连续多个 HTTP POST 请求body 里有大段 base64 字符串这类请求在正常业务里很少见。Wireshark 里我已经习惯把下面几个筛选器直接存成收藏拿到任何 pcap 都先轮流点一遍http.request # 只看 HTTP 请求行快速列出所有 Web 交互 mysql.query # 只看发往数据库的查询语句 icmp # 看扫描探测痕迹 tcp.flags.syn 1 tcp.flags.ack 0 # 只看 SYN 包找端口扫描这些筛选器的逻辑差别在于http.request过滤的是请求方向的数据包响应包会被滤掉所以看到的是一串 URL适合还原 Web 攻击路径mysql.query过滤的是 MySQL 协议里的查询语句能把注入 Payload 直接显示在列表里SYN 包筛选则用来数一数扫描器发了多少次连接尝试次数越多扫描范围越大。B.pcapng 里我最早注意到的是 HTTP 层因为 POST 请求特别扎眼。正常内网环境里 GET 居多POST 通常对应登录、上传、命令执行这一类敏感操作。顺着 POST 请求往下追踪流基本就是攻击者从 Webshell 下发指令的完整记录。2.3 用分组字节流确认攻击入口追踪流比翻包更快当筛选器定位到可疑请求之后右键选择 Follow TCP StreamWireshark 会把这次会话的所有数据按时间顺序拼成一个完整字节流。这一步在分析 B.pcapng 时非常关键因为攻击者的操作经常被打散在好几个包里单独看任何一个包都拼不出完整意图只有追踪流才能看到从「请求」到「响应」的因果。我在追踪 HTTP 流时会把显示模式切成 Raw而不是默认的 ASCII。原因很实在数据包里如果有二进制内容或经过编码的字符串ASCII 模式显示不全容易漏掉关键信息。呼出「查找」对话框直接搜 flag 这个关键词能立刻定位到数据库查询相关的流量。B.pcapng 里那个数据库 flag 相关的记录就是用这种方式定位到的它藏在 MySQL 的响应报文里而不是 HTTP 层。调查到这里攻击入口基本清晰了攻击者先对内网网段做了存活扫描发现了一台运行 Web 服务的主机随后针对 Web 应用做了 SQL 注入尝试拿到数据库中的某些记录后又上传了 webshell 文件最后通过 webshell 从服务器下载了一个文件。这个判断和后面几章要逐个验证的 flag 完全对得上。全局视角真正节省的是时间直接告诉你往哪个方向筛包而不是让你把几千个包从头翻到尾。3. 数据库 flag 最后一个字符SQL 注入流量与容易漏看的右大括号3.1 用 mysql.query 筛选器把注入语句捞出来第 1 题问的是「数据库里的 flag 最后一个字符是什么」很多人一上来就去 HTTP 层找结果翻遍 GET/POST 参数也找不到。其实答案根本不在 Web 层而在数据库协议层。Wireshark 里输入mysql.query筛选所有发往 MySQL 的查询语句会直接列出来包括注入语句构造的 SELECT。我在 B.pcapng 里找到的是一条典型的 UNION 查询大致是读取某个数据表里的 flag 字段。这类查询在流量里的可读性很高因为 MySQL 协议会用明文传输查询语句只要筛选器给对SQL 原文直接显示在包列表里不需要额外解密。攻击者通过 Web 应用把注入语句发到数据库数据库返回的结果会跟着响应包回到攻击者手里整个过程中查询语句和返回内容都在同一个 TCP 流里。如果你想用命令行复现这一步可以用 tshark它的效率比在图形界面里一条条翻更高tshark -r B.pcapng -Y mysql.query -T fields -e mysql.query-r指定读取的数据包文件-Y是显示过滤器-T fields -e mysql.query表示只输出 mysql.query 字段的内容。跑完之后你会看到一串 SQL 语句其中就有操作 flag 表的那条 SELECT。这里有个细节部分 MySQL 报文会把查询拆成多个分片tshark 的输出里可能出现半截语句这时候需要回 Wireshark 里追踪完整流不能只凭一条截断的语句下结论。3.2 为什么答案是右花括号你看到的 flag 可能不是完整的顺着追踪流找到数据库返回的内容能看到类似flag{...}的完整字符串。但第 1 题问的是「最后一个字符是什么」不是问你整个 flag。很多人卡在这一步是因为复制出来的字符串末尾有个右大括号}下意识觉得这是格式符号提交时把它截掉了结果永远对不上。这题的题眼恰恰就是这个右大括号。任务书后面有一句「这题谁都不会记住答案即可flag 是半边大括号」说的就是答案是一个字符}。我复盘时特别留意了一下数据包里的原始数据确认数据库返回的字符串确实以}结尾也就是说这个字符本身就是数据库里存的数据内容不是 SQL 结果集自带的格式符号。实际比赛里遇到过类似情况选手提交flag{x之类的一长串永远报错最后发现答案只是一个字符。这种题考验的不是技术是心态。你会在流量里看到完整的 flag但目标字段被限定成「最后一个字符」这时候要敢于只提交一个字符。我一般会右键复制返回内容的原始字节粘贴到编辑器里对照 ASCII 表逐个看确认最后那个字节的十六进制是7d对应的字符就是}。3.3 从响应包里提取字段内容时要注意编码数据库查询结果的提取比查询语句本身麻烦一点。MySQL 协议在返回结果时字段值默认按文本协议传输但如果数据库字符集设置或连接参数影响某些字符会以转义形式出现。我在 B.pcapng 里看到的返回内容比较规整直接就能读出flag{...}的完整字符串但如果你在别的包上做同样的操作建议先确认 Wireshark 的 Packet Bytes 面板里显示的是 UTF-8 明文而不是十六进制转义。查看返回内容的推荐做法是选中 MySQL 响应包在下面的 Packet Bytes 面板里切换到 Raw 标签把数据复制出来。不要用列表视图里的摘要文本那个有时会被截断。复制出来的内容放到一个空的十六进制查看器里过一遍确认首尾字符的字节值。最后一位应该是7d这就是右大括号}的 ASCII 码。这个 flag 的根源其实在数据库内容本身。攻击者通过注入拿到了 flag 字段的完整值但题目只要求提交最后一个字符。所以做这类题时养成一个习惯每次从流量里提取字符串先把完整内容存到本地文本文件里再根据题目要求截取。因为后面几题还要从同一批流量里提取主机 IP、内核版本、扫描命令、上传文件名这些内容经常是彼此关联的完整保留上下文能少走很多弯路。4. 内网扫描复盘扫描命令、主机 IP 与内核版本一次说清4.1 场景线索BT5 攻击机、Windows7 靶机与内网拓扑任务书里明确写了渗透机场景是 BT5用户名 root 密码 toor数据包则是在 Windows7 虚拟机上抓的。这个信息对分析有直接帮助BT5 是老牌渗透测试发行版里面自带扫描器和各种脚本工具攻击者大概率就是从这台机器发起扫描和后续攻击的。Windows7 作为被攻击目标抓到的包里源 IP 是攻击机目的 IP 是 Windows7 自己拓扑结构非常清楚。我在分析时先在 Wireshark 里按 IP 分组统计了一下流量来源发现攻击机 IP 与目标网段 192.168.10.0/24 之间有密集的 ICMP 和 TCP 探测包。这种流量特征说明攻击者做的是水平扫描也就是探测整个网段内哪些主机在线。如果你拿到的数据包也是类似结构可以先按ip.src排序看看哪些地址发出的包最多优先级最高的那个通常就是攻击机。第 2 题要提交的主机 IP 是 192.168.10.12这个地址在扫描流量里非常显眼它几乎响应了攻击机发来的每一个探测请求而且在后续的 SQL 注入、webshell 上传阶段都持续出现。可以理解为扫描阶段发现的存活主机里只有这台机器开了 Web 服务所以攻击者把后续所有精力都集中在它身上。这就是为什么第 2 题的答案指向它而不是网段里其他地址。4.2 扫描命令是如何还原出来的RASscan.py 的参数含义第 4 题要求找到黑客扫描网段的命令答案是一整行命令行RASscan.py 192.168.10.10 192.168.10.110 -t 20 log.txt。这个命令从流量里是「看」不出来的得靠推断。攻击者不会在数据包里敲一行命令给你看但扫描行为会留下痕迹ICMP 请求的目的地址从 192.168.10.10 一路递增到 192.168.10.110对应命令里给出的起止 IP 范围每个地址的探测节奏相对均匀符合脚本化扫描的特征。-t 20按这类扫描脚本的常见约定是并发线程数或超时时间。如果是线程数表示同时开 20 个探测任务如果是超时表示每个目标等待响应 20 个单位时间。具体含义要看脚本源码但比赛里只需要你把这个参数原样记住。命令末尾的 log.txt是把输出重定向到日志文件这也是命令行扫描的典型写法避免结果刷屏。从流量反推命令参数时常看这几个字段ICMP 请求的目的 IP 序列是否连续、请求间隔是否均匀、探测的目标数量范围。B.pcapng 里 ICMP 的目标地址基本覆盖了 192.168.10.10 到 192.168.10.110 这一段所以任务书给的答案里起止 IP 是这两个地址而不是整个 192.168.10.1 到 192.168.10.254。如果你在做别的题时发现扫描范围被截断记得按实际出现的 IP 序列去反推命令别想当然地补全整个网段。4.3 内核版本从 Banner 或漏洞探测响应里读出来第 3 题的内核版本答案是3.10.0-123.e17.x86_64这个字符串是怎么进到流量里的有两种常见途径一是扫描器发送特定探测请求后目标主机返回的响应头里带上了系统信息二是攻击者连接目标服务的某个端口服务主动返回 Banner。B.pcapng 里这个版本信息是在一次 TCP 连接后的数据段里出现的属于服务 Banner 泄露。这里有个容易被忽略的细节任务书里写的是e17不是常见的el7。很多选手看到这个版本号会下意识把它改成自己熟悉的写法el7结果提交不上。遇到这种题一切以流量里实际出现的字符串为准。你从数据包里提取到什么就提交什么不要做任何「修正」。提取这个版本号的推荐操作是在 Wireshark 里筛选包含x86_64的包直接按字符串搜索。搜索时注意区分大小写Linux 内核版本号的字段通常是全小写。找到之后追踪 TCP 流把包含版本号的完整字段复制出来对照题目确认要提交的是纯版本号还是连同其他信息。这道题只要版本号本身不要画蛇添足加上系统名或其他字符。第 4 题的扫描命令和第 3 题的内核版本是关联的攻击者正是通过扫描确认了目标系统类型和内核版本才决定后续用哪种注入方式。从攻击链视角看扫描是信息收集注入是攻击实施这两步在流量里紧挨着。所以做流量分析时不要孤立地找答案把每个 flag 对应回攻击链的某个节点记忆会牢固得多。5. 流量分析避坑与常见问题排查五处翻车点记录5.1 三个最容易「白忙一场」的坑现象打开 B.pcapng 后包列表里全是 TCP Dup ACK 和 Retransmission应用层协议一条都看不到。原因抓包时网卡或虚拟机网络配置导致大量重传也可能是 Wireshark 没有启用对应协议的解码器。B.pcapng 本身是好的但如果你先看了 Statistics Protocol Hierarchy会发现 HTTP 流量其实存在只是被 TCP 层噪声淹没了。解决不要从包列表顶部开始翻。直接用筛选器定位应用层协议比如http || mysql。看到的重传包直接忽略它们通常不影响应用层内容提取。如果http筛选出来是空的右键任意 TCP 包选择 Decode As把端口手动指定为 HTTP就能强制解析明文 Web 流量。现象从 POST 请求里复制 base64 字符串用base64 -d解码结果是一堆乱码。原因复制出来的字符串带着 URL 编码或者复制时漏掉了末尾几个字符。Web 表单提交时特殊字符会被转义成%XX格式直接送给 base64 解码器当然不认。解决先做 URL 解码再做 base64 解码。完整的处理流程我放在第六章里面给了 Python 一行命令。这里只提醒一句复制参数值时从value后面开始复制到结束中间的内容一个字符都不能少少了就白干。现象第 3 题提交内核版本时一直报错你确信自己从包里看到的版本号没错。原因把e17写成了el7。答案里的版本号用了不太常规的e17而不是 CentOS 常见的el7。你「修正」了它反而丢了分。解决流量分析题的提交内容必须以数据包里的原始字符串为准。我在分析 B.pcapng 时提取到3.10.0-123.e17.x86_64原样提交。从那以后凡是遇到版本号、文件名、命令语句这类答案我一律不做任何「美化」。5.2 两个与文件还原相关的坑现象用 tshark 导出 HTTP 对象导出的文件大小和包里的传输长度对不上解压失败。原因Wireshark 的 Export Objects 功能在某些分块传输或压缩传输场景下可能只导出了最后一个分块或把多个对象合并了。B.pcapng 里的 webshell 上传文件是完整的一段但如果你自己抓的包里有分段上传就会遇到这个问题。解决改用 Follow TCP Stream在窗口右下角选择 Show data as Raw然后 Save As 保存为本地文件。这种方式保存的是完整的字节流不受分块影响。保存后用file命令检查文件类型确认是 ZIP 再解压。现象从服务器下载的文件用编辑器打开全是乱码cat输出一堆不可见字符不知道内容是什么。原因文件是二进制格式或经过编码直接按文本查看当然读不出来。任务书里给出的vim编辑流程本质上是把二进制转成十六进制文本修改后再还原方便你查看和修改其中特定位置的内容。解决按任务书的操作走一遍 vim 流程把文件内容转成十六进制文本。具体命令在第六章统一说明。这里先记结论遇到下载文件内容当 flag 的题先不要急着用记事本打开先看文件头判断是文本还是二进制。6. 一句话木马与文件下载Z1 参数解码与 vim 还原的完整过程第 5 题和第 6 题是整个 B.pcapng 里技术含量最高的部分也最能体现解题流程的连贯性。第 5 题问的是一句话木马上传的第一个文件名答案是socks.py第 6 题问的是从服务器上下载的文件内容按任务书给出的流程把文件还原后提交。第 5 题的关键线索在 POST 请求的参数里。攻击者通过一句话木马向服务器传文件文件内容被编码在 POST body 中参数名是z1。我在 Wireshark 里筛选http.request.method POST然后逐个检查请求参数发现某个请求的z1参数值是一长串 base64 字符而且解码后头几个字节是PK也就是 ZIP 文件的文件头。提取参数值的操作逻辑是在 Wireshark 里选中该 POST 包展开 HTML Form URL Encoded 字段复制z1的 value然后按下面的流程解码import urllib.parse, base64 raw 粘贴 z1 参数的原始值 decoded urllib.parse.unquote(raw) # 先做 URL 解码 with open(B.zip, wb) as f: # 写出的 B.zip 就是上传的文件 f.write(base64.b64decode(decoded))这段代码的意思很简单第一步用urllib.parse.unquote把 URL 编码还原成原始字符比如%2B会变回%2F变回/第二步用base64.b64decode把 base64 字符串还原成二进制数据。两步顺序不能反因为 base64 字符串里可能有和/万一被 URL 编码过直接解码会出错。B.zip是文件名任务书里叫它 B.zip保存后解压就能看到第一个上传文件socks.py。解压之后确认文件内容再用file socks.py查看类型。第 5 题只问文件名所以看到socks.py就可以提交了。但我建议多留一步记录一下这个文件从下载到落地的完整链路因为第 6 题的文件下载操作紧接着就发生了。第 6 题的文件还原流程任务书里给了 vim 里的操作按i进入编辑模式在行首加aaaa按Esc退出编辑模式然后输入%!xxd回车再输入%!xxd -r最后保存。这个流程在 vim 中的标准使用场景是把当前缓冲区内容用外部命令xxd处理%!xxd会把二进制内容转成十六进制文本显示%!xxd -r则把十六进制文本还原成二进制。行首加的aaaa相当于一个自定义标记方便文件还原后快速定位到你改动的位置。我当时实际操作的时候特别注意了保存的时机%!xxd -r执行完之后文件已经恢复到二进制状态这时候如果不保存直接打开看到的还是乱码。需要在命令模式下输入:wq保存退出再重新查看文件内容。如果还原正确文件里的明文就是你需要的 flag。如果还原后文件头被改动过aaaa标记本身不会影响后续解析但要注意它占用了前 4 个字节看内容时要跳过。从那以后我每次遇到「从流量里还原上传文件、再还原下载文件内容」这类题都会强制走一遍标准流程先筛 POST再解 URL 编码再解 base64存盘后先用file检查类型最后用 vim 的xxd流程处理二进制内容。这套流程救过我很多次尤其是在比赛现场时间紧张的时候按固定顺序操作能避免漏掉任何一个编码环节。希望帮到你。本文还有配套的精品资源点击获取