reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
baradok609hecl1pq6qi
140
vendor-new/rev-skills/.claude/skills/re-tls/SKILL.md
Normal file
140
vendor-new/rev-skills/.claude/skills/re-tls/SKILL.md
Normal file
@@ -0,0 +1,140 @@
|
||||
---
|
||||
name: re-tls
|
||||
description: >
|
||||
TLS/加密流量深度：指纹、密钥导出、TLS 1.3。
|
||||
触发词：TLS、SSL、ClientHello、指纹、SSLKEYLOG、证书分析
|
||||
capabilities: [tls-analysis, crypto-identification]
|
||||
---
|
||||
|
||||
# TLS/加密流量深度分析
|
||||
|
||||
## 何时使用 / 何时不用
|
||||
|
||||
- 用：TLS/HTTPS 流量要"解密看明文"（有 keylog 或中间人）——C2 通信、固件回连、加密应用协议
|
||||
- 用：只有密文 pcap 也要做深度——ClientHello/证书指纹聚类、异常 TLS 特征判定
|
||||
- 用：证书链验证/证书内容分析（openssl x509）
|
||||
- 不用：只抓包不深入（那是 [[re-netcap]]）
|
||||
- 不用：流量已解密、无 TLS 层（直接 [[re-proto-rev]] 重建状态机）
|
||||
- 不用：非标准 TLS 的自定义加密（走 [[re-crypto-id]] → [[re-crypto-keys]] → [[re-crypto-decrypt]]）
|
||||
- 注意：本技能处理流量与密钥文件，不运行样本，默认可免沙箱；抓包环节按 [[re-netcap]] 在隔离环境进行（[[re-analyze/platform-tips]] 最高原则）
|
||||
|
||||
## 工具准备
|
||||
|
||||
所有工具先验证再使用。
|
||||
|
||||
### tshark / wireshark —— 解析、指纹、解密主力（安装见 [[re-netcap]]）
|
||||
|
||||
- Linux: `apt install wireshark tshark` / `dnf install wireshark-cli wireshark` / `pacman -S wireshark-cli wireshark-qt`
|
||||
- macOS: `brew install --cask wireshark`（含 tshark CLI）；Windows: `choco install wireshark`
|
||||
- 验证: `tshark --version`；`tshark -r out.pcap -Y 'tls.handshake.type == 1' | head -1` 能解析 ClientHello
|
||||
- JA3 字段（Wireshark 3.6+ 内置）与 JA4 字段（Wireshark 4.2+ 原生，仅客户端）: 验证 `tshark -r out.pcap -T fields -e tls.handshake.ja4 | head -1` 有输出；本机字段存在性以 `tshark -G fields | grep -iE 'ja3|ja4'` 为准
|
||||
|
||||
### openssl —— 证书解析与 TLS 交互（跨 OS）
|
||||
|
||||
- Linux: `apt install openssl` / `dnf install openssl` / `pacman -S openssl`（多数预装）
|
||||
- macOS: `brew install openssl`（keg-only，PATH 加 `/opt/homebrew/opt/openssl@3/bin`（Apple Silicon）或 `/usr/local/opt/openssl@3/bin`（Intel））
|
||||
- Windows: `choco install openssl.light`（PATH 需手动加，见包说明）或 Git for Windows 自带 `openssl.exe`
|
||||
- 验证: `openssl version`
|
||||
|
||||
### python3 —— 指纹聚类/批量分析脚本（可选）
|
||||
|
||||
- 安装与验证见 [[re-proto-rev]] 工具准备（python3）
|
||||
|
||||
### SSLKEYLOG 环境 —— Chrome/Firefox 密钥导出（非独立工具）
|
||||
|
||||
- Chrome: 启动前设置环境变量 `SSLKEYLOGFILE=/tmp/keys.log`（Linux/macOS）或 `set SSLKEYLOGFILE=C:\keys.log`（Windows）
|
||||
- Firefox: 同样环境变量（设置后需重启浏览器）
|
||||
- Wireshark: 编辑 → 首选项 → Protocols → TLS → (Pre)-Master-Secret log filename 指向该文件；tshark 侧用 `-o tls.keylog_file:...`
|
||||
- 验证: 设置后访问 HTTPS 站点，keys.log 出现 `CLIENT_HANDSHAKE_TRAFFIC_SECRET` 等行（TLS 1.3）或 `CLIENT_RANDOM` 行（TLS 1.2）
|
||||
|
||||
### mitmproxy —— 中间人解密（可选，安装见 [[re-netcap]]）
|
||||
|
||||
- 场景: 无 keylog 权限的第三方程序（自实现 TLS 栈、证书固定见坑 4）
|
||||
- 验证: `mitmdump --version`
|
||||
|
||||
## 操作步骤
|
||||
|
||||
按顺序执行，每步产物（指纹表/证书/解密流量）存档 sha256 + 路径（[[re-ioc]] 证据链要求）。
|
||||
|
||||
1. **ClientHello 指纹（JA3/JA4）**：
|
||||
```sh
|
||||
# JA3（ClientHello 协商参数哈希，Wireshark 3.6+ 内置）
|
||||
tshark -r out.pcap -Y 'tls.handshake.type == 1' -T fields \
|
||||
-e tls.handshake.ja3 -e ip.src -e tls.handshake.extensions_server_name \
|
||||
| sort | uniq -c | sort -rn
|
||||
# JA4（Wireshark 4.2+ 原生，客户端侧；含协议/版本/SNI/密码套件数/ALPN 维度）
|
||||
tshark -r out.pcap -Y 'tls.handshake.type == 1' -T fields -e tls.handshake.ja4 \
|
||||
| sort | uniq -c | sort -rn
|
||||
```
|
||||
- 用途: 按"客户端指纹"聚类——同一指纹 = 同一客户端栈（浏览器/库/恶意工具），新簇 = 可疑客户端
|
||||
- 对照: 与公开 JA3/JA4 情报源比对命中已知恶意客户端；未命中 = 弱信号，需步骤 5 综合（坑 3）
|
||||
- 字段注: SNI（`tls.handshake.extensions_server_name`）与 IP 一起聚类——同一指纹连不同目标也是信号
|
||||
|
||||
2. **证书链分析（openssl x509 解析）**：
|
||||
```sh
|
||||
# 一个 Certificate 消息常含多张证书，该字段是逗号分隔的十六进制串（hex 带冒号）——先按逗号切行再逐行转 DER
|
||||
# 链的次序即发送次序，第一行是叶子（服务器）证书；只取叶子在切行后加 | head -1（放在 tr -d ':' 之前）
|
||||
tshark -r out.pcap -Y 'tls.handshake.type == 11' -T fields -e tls.handshake.certificate \
|
||||
| head -1 | tr ',' '\n' | tr -d ':' | xxd -r -p > cert_chain.der
|
||||
openssl x509 -in cert_chain.der -inform DER -text -noout | head -60
|
||||
# 逐张分别导出（cert_1.der、cert_2.der…）用循环或 csplit 按行切开；
|
||||
# 不要一次 xxd 把整条链写进同一个文件——多张 DER 拼接不是一个合法的 DER 对象，openssl 只读第一张且可能报错
|
||||
# 实时抓取（对已知主机）
|
||||
openssl s_client -connect <host>:443 -servername <host> -showcerts </dev/null 2>/dev/null \
|
||||
| openssl x509 -noout -text
|
||||
# 证书链校验结果
|
||||
openssl s_client -connect <host>:443 -servername <host> -verify_return_error </dev/null 2>&1 \
|
||||
| grep -i 'verify return'
|
||||
```
|
||||
- 分析点: 签发者/主题（CN/SAN）、有效期（异常日期/过期）、自签名 vs 受信 CA、SPKI/指纹（`openssl x509 -noout -fingerprint -sha256`）、证书重用（同一证书多个 C2 域 = 批量签发）
|
||||
- 注意: TLS 1.3 的 Certificate 消息（type 11）在加密握手内，`-Y 'tls.handshake.type == 11'` 匹配不到——TLS 1.3 流量需先按步骤 3 解密（SSLKEYLOG）或用 openssl s_client 实时抓取
|
||||
- 平台注: `</dev/null` 是 POSIX 语法、Windows cmd 不适用——Windows 下用 `echo | openssl s_client ...` 或去掉 `</dev/null` 交互式退出
|
||||
- 恶意特征: 自签名 + 新注册域名 + 短有效期（90 天-1 年批量自动化签发常见）
|
||||
|
||||
3. **SSLKEYLOG 解密（TLS 1.2/1.3 密钥导出）**：
|
||||
```sh
|
||||
# tshark 侧解密（keylog 文件 + 重新解析）
|
||||
tshark -r enc.pcapng -o tls.keylog_file:keys.log -Y 'http' \
|
||||
-T fields -e http.host -e http.request.uri
|
||||
# 或 GUI: 首选项 → Protocols → TLS → (Pre)-Master-Secret log filename
|
||||
```
|
||||
- TLS 1.2: keylog 记录 `CLIENT_RANDOM <hex> <master secret>`——主密钥可直接解本会话所有记录
|
||||
- TLS 1.3: keylog 记录的是各阶段 traffic secret（`CLIENT_HANDSHAKE_TRAFFIC_SECRET` / `SERVER_HANDSHAKE_TRAFFIC_SECRET` / `CLIENT_TRAFFIC_SECRET_0` / `SERVER_TRAFFIC_SECRET_0` / `EXPORTER_SECRET`）——没有 1.2 的 master secret，手工推导按 HKDF-Expand(-Label) 从各 traffic secret 派生记录密钥（Extract 是更早阶段的运算，见坑 1）；Wireshark/tshark 直接读 keylog 文件可自动处理两代协议
|
||||
- 验证解密成功: 解密后能看到明文 HTTP/应用协议字段（步骤 4 语义还原的原料）；解密失败先看 keys.log 里有没有该会话的 CLIENT_RANDOM 或 traffic secret 条目（坑 2）
|
||||
- 实时抓取场景: 设置 SSLKEYLOGFILE 后启动 Chrome/Firefox（工具准备），抓包与 keylog 同步产生
|
||||
|
||||
4. **加密流量语义还原（应用层协议恢复）**：
|
||||
```sh
|
||||
# 解密后按应用层协议还原（TLS 只是载体，语义在 ALPN/上层协议）
|
||||
tshark -r decrypted.pcapng -Y 'http' -T fields -e http.request.method -e http.host -e http.request.uri
|
||||
tshark -r decrypted.pcapng -Y 'tls.handshake.extensions_alpn_str' -T fields -e tls.handshake.extensions_alpn_str | sort | uniq -c # ALPN 应用协议：ClientHello 里是客户端候选列表（offered）；最终协商结果（negotiated）TLS ≤1.2 在 ServerHello、TLS 1.3 在 EncryptedExtensions
|
||||
```
|
||||
- 流程: 解密（步骤 3）→ 识别上层协议（ALPN: http/1.1、h2、自定义；或按端口/特征）→ 会话重组 → 语义提取（C2 命令/配置/明文凭据）
|
||||
- offered 与 negotiated 要区分: `tls.handshake.extensions_alpn_str` 同时命中 ClientHello（客户端候选列表）与承载最终结果的那条握手消息，直接统计会把候选当结论。TLS 1.3 的 ALPN 结果不在 ServerHello——ServerHello 只回扩展类型，真正的 ALPN 扩展在 EncryptedExtensions（握手密钥/keylog 解密后才可见）；未解密时该字段只能看到 ClientHello 的候选。判最终协议取 negotiated 一侧，或直接看解密后的应用层记录类型
|
||||
- 自定义协议: 明文还原后转 [[re-proto-rev]] 做状态机重建（[[re-protocol]] 工作流第 5 步）
|
||||
- 边界: TLS 解密只解开"标准 TLS 栈"的流量——自实现/魔改 TLS（无 ClientHello 结构、keylog 无对应条目）解密失败，只能走特征分析（步骤 5）
|
||||
|
||||
5. **恶意 TLS 特征（指纹聚类/异常证书）**：
|
||||
- 特征清单: ① 指纹聚类——JA3/JA4 新簇或命中已知恶意库（curl/python requests 原生栈也是常见信号）② 异常证书——自签名/短有效期/SNI 与 IP 不匹配/证书 CN 是 IP ③ 信标节奏——固定间隔短连接（与 [[re-behavior]] 时间线对齐）④ SNI 异常——随机子域名/高熵 SNI/无 SNI（硬编码 IP 直连，[[re-netcap]] DoH 坑同源）⑤ 混合协议——443 上跑非 TLS
|
||||
- 聚类方法: 步骤 1 的指纹表 + 会话统计（连接时长/包大小/方向比）分层；与正常浏览器流量做基线对照（沙箱内先抓一段基线）
|
||||
- 结论纪律: 指纹与证书都是"弱信号"，可被伪造（坑 3）——定论要行为侧（进程归属/信标/下载行为）交叉验证，进 IOC 时标注信号类型
|
||||
- 产出: 恶意 TLS 会话清单（时间/IP/指纹/证书/SNI）+ 特征进 [[re-ioc]] YARA（证书字节/指纹模式）
|
||||
|
||||
## 跨域联合
|
||||
|
||||
- [[re-netcap]]：捕获与过滤（本技能输入原料；DoH/加密流量盲区的捕获策略见其坑）
|
||||
- [[re-proto-rev]]：解密后的明文流量做状态机重建（本技能步骤 4 的下游）
|
||||
- [[re-protocol]]：本技能是其网关的 TLS 专项——标准 TLS 流量深度分析分支；自定义加密走 crypto 三件套
|
||||
- [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]]：非标准/自实现加密链路（TLS 指纹与解密失败时的转场）
|
||||
- [[re-malware]]：恶意 C2 的 TLS 特征判定（回连流量分析的第 4 步细化）
|
||||
- [[re-frida]]：证书固定绕过（坑 4）——hook 校验函数配合 mitmproxy
|
||||
- [[re-sandbox]]：抓包环境隔离与基线流量采集（[[re-analyze/platform-tips]] 最高原则）
|
||||
- 引用 [[re-analyze/platform-tips]] 静态优先思路与沙箱网络隔离分支
|
||||
|
||||
## 常见坑与陷阱
|
||||
|
||||
- **TLS 1.3 密钥导出与 1.2 不同**：现象——用 1.2 的"CLIENT_RANDOM → master secret"思路手工解 1.3 流量解不出，keys.log 里也没有 master secret 条目；原因——TLS 1.3 前向保密 + 每会话独立派生，keylog 记录的是 traffic secret（CLIENT_HANDSHAKE_TRAFFIC_SECRET 等），没有 master secret/RSA premaster；对策——keylog 文件直接交给 Wireshark/tshark（`-o tls.keylog_file:...`）自动处理两代协议；手工推导时按 HKDF-Expand(-Label) 从各 traffic secret 派生各阶段记录密钥（handshake 与 application 阶段密钥不同）
|
||||
- **前向保密（无 keylog 解不了）**：现象——只有 pcap 没有密钥，怎么都解不出明文；原因——ECDHE 会话密钥只存在于会话两端内存，静态位置没有；对策——承认解不了，转指纹/元数据分析（SNI/证书/长度/时序，步骤 5）；提前准备两条路: 抓包前设 SSLKEYLOGFILE（自控客户端）或 mitmproxy 中间人（第三方程序，配坑 4 证书固定绕过）
|
||||
- **指纹可伪造**：现象——JA3/JA4 聚类把恶意客户端归到"正常浏览器"簇，或两个无关客户端同指纹；原因——指纹只反映 ClientHello 协商参数，curl/requests/恶意代码可自定义模仿（指纹欺骗是 C2 基础设施常规手法）；对策——指纹当弱信号用于聚类与关联，不做身份判定；命中/未命中都要用证书、SNI、行为侧（进程归属/信标）交叉验证，结论注明证据强度
|
||||
- **证书固定绕过需中间人配合**：现象——mitmproxy 中间人后目标程序拒绝连接/证书错误，明文拿不到；原因——应用内嵌公钥/SPKI 指纹做 certificate pinning，不信任系统 CA；对策——[[re-frida]] hook 校验函数（SSL_CTX_set_verify / X509_verify_cert / 自实现 pin 校验）返回成功，或 patch 程序跳过校验，再走 mitmproxy 拿明文；沙箱内操作（[[re-sandbox]]），结论注明绕过方式与版本
|
||||
- **ECH（扩展 65037 加密 ClientHello）与延迟测代理**：现象——JA3/JA4 指纹正常但请求仍被拒，或指纹能仿但代理一挂就被识别；原因——反爬升级：①ECH（Encrypted Client Hello，扩展 65037）把 SNI/扩展加密进 ClientHello，指纹分析拿不到 SNI（2025+ 已出现在反爬检测链 verify=3）；②代理检测不用黑白名单/信誉分/行为分析，直接**测量请求延迟**（服务器往返时间差）识别 VPN/代理——因为走代理/隧道必然引入额外延迟，指纹可伪造但延迟无法消除。评估数据要看指标口径：常规条件下单连接分类的精确率/召回率可达 99%，其综合 **F1 约 92%**（F1 是精确率与召回率的调和平均，不等于"检出率"，也不是"准确率"）；而简单的流量调度类规避能把传统 RTT 检测的召回率从 99% 压到 8%——这正是延迟类检测需要更鲁棒方法的原因；对策——分析侧：抓包工具/中间人需要支持 ECH 解密（密钥在服务端与浏览器 ECH key 配置）；规避侧：延迟类检测无法靠伪造指纹绕过，只能换直连/低延迟隧道，分析时先确认目标用的是指纹还是延迟检测
|
||||
Reference in New Issue
Block a user