企业官网建设流程全解析

周末刷题时碰到 red_vs_blue 这个 Misc 题，第一眼看到名字就知道是红蓝对抗的套路：给你一个抓好的流量包，让你扮演蓝队，从一堆噪声里把红队的一举一动翻出来，最后拼出 flag。这种题在杂项里算高频题型，我前前后后解过几道类似的题目，这次就把完整思路和背后的判断逻辑写出来，希望对刚接触流量分析的新手有帮助，也欢迎老手一起交流。

这类题考的不是某个框架的漏洞利用，而是在一个模拟攻防场景里，你能不能把隐藏在协议细节中的信息还原出来。

1. 先搞清楚 red_vs_blue 到底在考你什么

1.1 红蓝对抗在 CTF 里的表现形式

红蓝对抗在安全行业里是一套很成熟的方法论。红队模拟攻击者，负责渗透、利用、横向移动；蓝队则站在防守侧，负责监控、分析、溯源。到了 CTF 赛场上，这种对抗往往被压缩成一两个附件：最常见的就是一个 pcap 流量包，或者一个内存镜像，再或者一整份系统日志。

red_vs_blue 这个名字已经直接把对抗双方写在了题目表面，它基本可以确定是流量分析方向。因为对杂项题来说，纯日志文件太单薄，内存镜像对出题和做题的成本都比较高，流量包是最平衡的选择：体积可控、信息层次丰富、可以从多个协议维度埋线索。

我当时拿到题目后的第一反应就是：红队是怎么进来的、做了什么、留下了什么。这三个问题其实就是蓝队日常应急响应的核心流程。出题人为了让题目不落俗套，通常会在里面塞两到三条链路，一条是常规的 Web 渗透痕迹，另一条是隐蔽信道传输数据。后者往往才是 flag 真正藏身的地方。

1.2 这类题目的通用套路

我复盘了近几年常见的挑战题，发现 Misc 场景下的红蓝对抗几乎都遵循同一套模板：

1. 红队先对目标做信息收集，也就是扫描和指纹识别，这段流量通常表现为大量 SYN 包、HTTP HEAD 请求、404 响应。
2. 然后是漏洞利用或弱口令尝试，HTTP 层会出现 POST 请求、异常 User-Agent、参数中包含命令拼接的痕迹。
3. 再后面是权限维持，最常见的就是上传一个文件，或者通过 DNS、ICMP 这类不容易被防火墙拦截的协议建立隐蔽通道。
4. 最后蓝队抓包，把所有行为记录成了 pcap，flag 就藏在某一层通信载荷里。

明白了这个流程，你就知道该往哪些协议上重点看。如果一开始像无头苍蝇一样从第一个包翻到最后一个包，别说 flag，光是想搞清楚谁和谁在通信就得花掉不少时间。这个题目本身并不算难，难的是你有没有建立一套"先总览、再聚焦"的分析习惯。

2. 开局准备：工具选型和环境搭建

2.1 工具清单与各自定位

做流量分析前先把手里的工具理清楚。我平时用的是一套开源组合，基本覆盖了从快速体检到深度提取的所有场景：

不要觉得 Wireshark 有图形界面就万事大吉。真实比赛里流量包经常有几十万甚至上百万个数据包，图形界面一打开就卡，这时候 tshark 的命令行提取能力才是主力工具。我建议新手至少在 Wireshark 里看懂基础过滤，再学几个常用 tshark 命令，后面你会感谢自己在工具上多花的这点时间。

2.2 拿到流量包后的 5 分钟快速体检

打开流量包之前，先用 capinfos 看一眼基本信息：

capinfos red_vs_blue.pcapng

它会输出包总数、时长、平均包速率、IPv4 地址数量、端口统计等。这一步能帮你快速建立对题目规模的认识。如果是个几十万包的流量，后面要大胆用过滤器缩小范围；如果只有几千包，那所有数据都可能有用，细节会更重要。

接下来用 Wireshark 打开，不要急着翻包，先看两处菜单：Statistics -> Protocol Hierarchy 和 Statistics -> Conversations。

Protocol Hierarchy 告诉你流量在哪些协议上分布，比如 UDP 占了多大比例、HTTP 占了多少。看到异常偏高的协议，基本就是题目在向你招手。Conversations 则列出通信双方和各自的字节数，帮助你定位一对主通信方。

我记得那次一打开 Protocol Hierarchy，就发现 UDP 的占比不正常，再看细分，大量 UDP 都落在 53 端口上。53 是 DNS，正常业务环境里 DNS 请求虽然多，但不会多到让 UDP 占比过半。这个信号直接在提醒我：红队可能用了 DNS 隧道。

3. 从通信特征锁定红队的影子

3.1 常见流量异常特征速查

流量分析说穿了是找"反常"。你自己先要知道正常长什么样，才能判断崩坏在哪里。我总结了一张平时做题会对照的异常特征表：

DNS 隧道在 CTF 里出现频率最高。原因是 DNS 几乎不会被防火墙拦截，而且出题人写个脚本就能批量生成，不需要太多基础设施。做这类题目时，看到长串子域名，心里就要有一个预期值：这段子域名字符串很可能就是编码后的数据。

3.2 从统计到会话的聚焦方法

Protocol Hierarchy 给了方向后，我用 tshark 快速拉出可疑域名的统计：

tshark -r red_vs_blue.pcapng -Y "dns.qry.name" -T fields -e dns.qry.name | sort | uniq -c | sort -nr

这条命令把所有 DNS query 名字取出来，按出现次数排序。正常解析的域名会分散在几十上百个不同域名上，而隧道域名会集中在某几个固定根域下，并且子域部分几乎每次都不重复。

还可以用过滤器进一步确认：

dns.qry.name contains "example"

这里的 example 是根域的关键字，你按实际情况替换。过滤后如果发现有几百条子域名都是以同一根域结尾的查询，那就不用犹豫了，直接进入提取环节。

HTTP 流量也一样。可以用 http.request.full_uri 字段查看所有请求的完整 URI，按状态码筛选。如果看到大量 404，说明红队在跑目录枚举；如果在枚举之外又发现了一个上传成功的 200 响应，那个响应对应的文件往往是后续隐蔽通道的跳板。

我在这里给新手一个建议：不要急着把所有可疑内容都背下来，先把主通信链路摸清楚。比如攻击者 IP 是 198.51.100.10，目标服务器是 192.0.2.80，那后续所有过滤都可以带上 ip.addr==192.0.2.80 和 ip.addr==198.51.100.10，把视野始终锁定在这对会话上，大幅减少噪声。

4. 解出数据的完整流程：DNS 隧道、多层编码与文件还原

4.1 DNS 隧道的识别与字段提取

确认目标根域后，我要把每一条查询的子域名部分完整提取出来。用 tshark 导出域名和时间戳：

tshark -r red_vs_blue.pcapng -Y "dns.qry.name contains \"example.com\"" -T fields -e frame.time_epoch -e dns.qry.name

注意这里会有坑：DNS 查询包和响应包都会含有 dns.qry.name 字段，如果不过滤只提取一次，会得到两倍数据。所以我会显式加上 dns.flags.response == 0，只保留查询请求，避免重复。

提取到的域名字段可能长这样：

1685527200.123456 dummy1.example.com 1685527200.126789 dummy2.example.com 1685527201.456123 dummy3.example.com

去掉.example.com后缀后，剩下的部分看起来像 Base64。判断依据很简单：字符串只包含 A-Z、a-z、0-9、+、/、=，而且每隔一定字符长度就会有一个 = 结尾。Base64 是最常见的编码方式，因为它能把二进制数据扁平化成 DNS 子域可以承载的文本字符。

把子域名部分拼接后，去掉分隔符，写到一个 txt 文件，然后解码：

base64 -d payload.txt > payload.bin file payload.bin

这次解码后仍然不是可读文本，file 也没识别出具体文件格式。当时我第一反应是数据经过了二次处理，这个等下再展开。但如果你运气好，file 输出的是 PNG、JPEG 或 Zip，那后面的路会清晰很多。

4.2 从 Base64 到文件头判断

CTF 题有个规律：越是藏在后面的数据，越喜欢套多层壳。Base64 解完如果是一堆乱码，别慌，先把数据保存下来，再用十六进制看一眼开头：

xxd payload.bin | head -5

常见文件头的特征要能背书：

• ZIP 是50 4B 03 04
• PNG 是89 50 4E 47
• JPEG 是FF D8 FF E0
• ELF 是7F 45 4C 46

当时我看到开头是一段不像文件的字符，但中间有大量连续 0。这让人怀疑真实的文件数据被分段埋进了一个二进制容器里，或者整体又做了一次异或、反转处理。异或这类编码比较烦人，因为单靠肉眼看不出来，需要先猜测密钥或者尝试常见单字节异或 0xFF、0x00、0x55 等。

这时候 CyberChef 的 Magic 功能很有用，它会把常见的编码、压缩、二进制识别自动跑一遍。但我建议把 Magic 当辅助而不是唯一工具。依赖 Magic 容易让你失去对数据本身的感知。正确做法是先手动试一遍 反转、URL 解码、二次 Base64，如果都没效果再去用 Magic 兜底。

4.3 从隐藏流量到图片隐写和隐藏输入

在我实际复盘的这个场景里，最终解出来的其实是一个 ZIP 压缩包。把它解压后获得了一个文本文件和一张小尺寸图片。

文本文件打开后看起来有内容，但 flag 不完整，后半段全是空格和不可见字符。这里就要引入零宽字符的知识了。零宽空格、零宽非连接符、零宽连接符这类 Unicode 控制字符在视觉上看不见，却能在文本里携带额外的二进制信息。常见的套路是：

• 两种零宽字符分别代表 0 和 1
• 把它们按顺序提取出来，转成 ASCII，再解码成可见文本

太典型的解法了。检查方法也很简单，用十六进制编辑器打开文本文件，看字与字之间是不是多了 E2 80 8B、E2 80 8C 之类的字节序列。发现之后提取出来，按空格切分、映射、合并，就能得到真正隐藏的 flag 片段。

图片那边同样需要看一眼。先用 strings 扫一遍，有没有作者或注释信息；再 binwalk 看有没有附加文件；然后才轮到 stegsolve 或 zsteg 去检查 LSB 隐写。很多时候图片并不复杂，就是藏了个字符串或者一段提示，没必要每次都上最重的隐写工具。

我记得那个图片用 strings 什么都没发现，但 binwalk 显示尾部多了一块数据，把尾部切出来以后又是一张小图和一段 URL 编码过的文本。这种层层套娃的题目，耐心比技术更能决定成败。

5. 实战中常见的坑与排查思路

5.1 流量包太大，图形界面卡死

不做过多处理直接开 Wireshark，很卡很正常。百万级别的包，光渲染就够电脑卡一阵。我的处理方式是把流量包先用 editcap 按会话或按 IP 切片，比如只留一对主通信 IP 之间的包：

editcap -A "2021-07-01 10:00:00" -B "2021-07-01 10:30:00" red_vs_blue.pcapng sliced.pcapng

或者用 tshark 直接导出过滤后的结果：

tshark -r red_vs_blue.pcapng -Y "ip.addr==192.0.2.80 && ip.addr==198.51.100.10" -w filtered.pcapng

产出一个更小的文件再丢进 Wireshark，体验会好很多。脚本化处理就是在这一步体现价值的。

5.2 拿到数据但解到一半看不懂

这种情况多半是编码层判断错了。比如我前面说到的 Base64 解码后乱码，很多人一看到乱码就放弃，其实乱码不一定真的乱。给几个排查思路：

1. 把解码后的字节交给file命令判断，识别出来格式就说明路走对了。
2. 看十六进制中是否出现PK、ffd8、8950这类文件头。出现就说明 Base64 只是第一层，数据本身是一个文件，剥离到正确边界就是完整文件。
3. 文本类乱码可以试常见字符集反转，比如 UTF-16 的小端序字符会被普通文本工具显示成乱码，但十六进制里能看到规律的 00 分隔。
4. 试试是不是数据里有冗余字符，比如每 N 位多一个填充符。

每次判断下一层编码，都要记录你做了什么操作，这样才不会在一个方向上反复绕圈。

5.3 文件提取失败与图片隐写毫无头绪

HTTP 对象导不出来或者导出文件损坏，优先用 NetworkMiner 做交叉验证。Wireshark 的 Export Objects 依赖 HTTP 头里的 Content-Length，如果传输用了分块编码，或者连接在文件传输完成前就被断开，导出的文件就会缺尾部。NetworkMiner 处理流重组的能力更强一些，同样一个流量包，它常常能在文件面世时给你惊喜。

图片隐写找不到线索，问题往往出在顺序上。不要上来就开 stegsolve，先做基础排查。通常顺序是：文件信息 -> strings -> binwalk -> LSB。每步都要记录结果，尤其要注意 binwalk 从第几个偏移开始发现附加数据，因为那直接决定了你怎么把附加数据切出来。

如果 binwalk 识别出的数据在图片中间，可以用 dd 按偏移量切割：

dd if=image.png of=hidden.bin skip=1024 bs=1 count=2048

这里的 skip 和 count 要根据 binwalk 输出调整。切出来的文件再 file 判断类型，继续下一层。

我在做题时还遇到过一个情况：图片本身完全正常，没有任何隐写，flag 藏在文件名里。文件名带下划线分隔的单词，连起来读就是一段提示。遇到这种情况，只能说明要先检查周边信息，再陷入技术操作。

6. 复盘心得：红蓝对抗 Misc 的做题节奏

这类题做多了，会发现解题过程完全可以流程化。首先是看协议分布，用统计给流量分类；其次是找异常通信，定位可疑目标；然后是聚焦到具体协议，提取负载数据；最后是解码和文件还原。四个环节里只要有一个做得太久，就会卡住，所以做题时我会给自己设置时间分片：体检阶段不超过 10 分钟，聚焦阶段不超过 20 分钟，遇到层数多的解码一定做记录。

我个人在使用中感受最深的，其实是 tshark 发挥的作用。图形界面可以让你看清楚一个包，但无法快速看清一万个包。掌握几个常用的字段提取命令，在处理大规模数据时效率完全不同。这也是新手最容易忽略的点：花在工具命令行上的十分钟，会在真正实战里省下半小时。

另外，解这类题一定要有耐心。Misc 和 Web、PWN 不同，后者有明确的漏洞入口，前者更像是在一堆文件里做拼图。常见的情况是最后一步解出 flag 之前，经历了三四次看似错误的尝试。只要方向合理，每一步都在收窄范围，就不要因为中途乱码而放弃。

如果你也准备参加 CTF 或者做安全应急相关的练习，建议自己动手把 DNS 隧道这类场景模拟一遍：用脚本往指定域名发几段编码后的数据，自己抓包、自己提取、自己解码。这个过程走一遍，远比看十篇题解更管用。下次再遇到 red_vs_blue 这样的流量分析题，你就能自然而然地知道下一步该做什么了。