工具|NaX源码深度评估：工程纪律一流的PICBeacon及其硬伤

admin
admin
admin
0
文章
0
评论
2026-08-09 05:06:31 网络安全文章 来源：ZONE.CI 全球网 0 阅读模式

文章总结： NaX是面向AdaptixFramework的PICC2beacon，工程纪律一流，采用StardustUDRL加载器、模块踩踏和可塑C2Profile，代码结构清晰。其PIC实现细节处理到位，如秘密字符串逐字节写入、随机性使用CNG。但存在CFG白名单不完整、无崩溃隔离等严重缺陷，BOF子系统风险密集。适合作为学习范本，但生产使用需谨慎。 综合评分： 75 文章分类： 红队,安全工具,渗透测试,实战经验

cover_image

工具 | NaX 源码深度评估：工程纪律一流的 PIC Beacon 及其硬伤

原创

GLM-5.2 GLM-5.2

赛博生存指南

2026年7月27日 17:58 浙江

在小说阅读器读本章

去阅读

NaX（NoNameAx）是面向 Adaptix Framework 的位置无关代码(PIC)C2 beacon，采用 Stardust 模式 UDRL 加载器 + 模块踩踏(module stomping)+ 可塑 C2 profile + BOF 执行，技术路线与 Havoc、Kharon 同属”Adaptix 上的 C/C++ beacon”一代，但 PIC 工程纪律明显高出平均。本文分析基于 main 分支 commit bd032d9(public release)，代码规模约 beacon C 3.45 万行、loader 真实逻辑约 1.1 千行(Native.h 的 2.25 万行是 vendored ntdll 头)、sleepmask 约 212 行、Go 服务端插件约 8800 行、wiki 文档约 6500 行。本文侧重架构、对抗面与工程优缺点评估，不构成使用指引。

地址：https://github.com/MaorSabag/NaX

目录

  1. 整体概览
  2. 架构与状态模型
  3. PIC 工程纪律：第一梯队的实现
  4. 可塑 C2 Profile 引擎
  5. 模块踩踏与 Stardust UDRL 加载器
  6. BOF 子系统：COFF 加载器与踩踏池
  7. 加密体系：基元正确，完整性缺席
  8. 服务端 Go 插件
  9. 工程化、测试与文档
  10. 优点总览
  11. 缺点与风险：按严重度分级
  12. 蓝队检测视角
  13. 评估结论

1. 整体概览

仓库按职责切成四个组件，构建链是”loader + beacon → pack → nax.x64.bin”，再由服务端 Go 插件按需包成 EXE/DLL/SVC：

src_loader/# Stardust UDRL：PEB walk、模块踩踏、CFG、转交执行
src_beacon/# PIC beacon 主体：Core / Transport / Commands / Bof
src_sleepmask/# sleepmask BOF(COFF .o，运行时由 beacon 加载)
src_server/# Adaptix 的 Go 插件
  agent_nonameax/# 载荷构建、命令、结果、AxScript UI
  listener_nonameax_http/# profile 驱动的 HTTP、AES、可塑变换
  listener_nonameax_smb/# SMB pivot 前端
  service_nax_store/# 只读数据查看服务

几个量化事实：

  • 目标平台只有 Windows x64。beacon 是单 .text 段 PIC shellcode，无 CRT、无导入表、无静态数据，所有 Win32 API 经 PEB walk + FNV1a-32 哈希在运行时解析。
  • 状态全部堆分配。单一 NAX_INSTANCE 结构承载所有 DLL 函数指针束与运行时状态，指针存于 TEB->NtTib.ArbitraryUserPointer，经 G_INSTANCE 宏取回，全程无文件级可变全局。
  • 传输在编译期切换。Transport.h 用宏把 NaxSend 映射到 NaxHttpPost/NaxSmbPost，零运行时派发开销，但也意味着无法运行时回退 HTTP→SMB。
  • 协议是 6 字节帧头type(1)|flags(1)|bodylen(4 LE)，支持单响应多帧，全部 AES-128-CBC 加密。
  • README 的”26 个内置命令”已过期。Wire.h 实际定义了 54 个 NAX_CMD_* 常量(含 tunnel/token 子命令)。

2. 架构与状态模型

NAX_INSTANCE(Instance.h)是整个 beacon 的”大脑”，每个函数都通过它访问状态。结构里按 DLL 切分函数指针束(NAX_NTDLL、NAX_KERNEL32、NAX_WINHTTP……)，每个束只装从该 DLL 解析出的函数指针。

API 解析的类型安全设计值得单独点名(Macros.h:21)：

#define D_API(x) __typeof__(x) *x

D_API(VirtualAllocEx) 会展开成 __typeof__(VirtualAllocEx)* VirtualAllocEx，于是 Bootstrap.c 里上百个 API 解析构成一张编译期类型检查的 vtable——调用方传错参数类型直接编译失败。这在 PIC C2 代码里相当少见，多数实现用的是无类型 PVOID 配手工强转。

执行流程是经典的 bootstrap → register → heartbeat：

  1. NaxBootstrap() 走 PEB 拿 ntdll/kernel32 基址，导出表 FNV1a 匹配解析 API，建私有堆，分配 NAX_INSTANCE 存进 TEB，再懒加载 winhttp/bcrypt/advapi32 等，初始化配置与 BOF 踩踏池，收集主机信息。
  2. REGISTER 帧含全部系统信息，POST 给 C2；服务端回 PROFILE 帧(运行时可塑 profile)与 NO_TASKS。注册失败按 sleep 间隔无限重试。
  3. 心跳循环：Sleep(±jitter) → 构造 HEARTBEAT → 加密 → GET/POST → 解密响应 → 逐 TASK 派发 → 构造 RESULT → 加密回传。

传输抽象、帧编解码、profile 编解码三层解耦干净。NaxFrameEncode/Decode(Packer.c:33-65)对 6 字节头与 6+bodyLen 都做了显式边界检查。

3. PIC 工程纪律：第一梯队的实现

这是 NaX 最强的部分，也是它值得作为学习范本的原因。

秘密字符串的逐字节写入。 AES key、C2 URL、profile 字节、BOF 踩踏 DLL 名全部通过 volatile 指针逐字节赋值，强制 GCC 生成立即数 MOV，而不是把 char[] 初值池化进 .rdata。Config.c:4-8 有一段极为坦诚的注释解释原因：GCC -Os 会把任何局部 char[]/byte[] 初值优化进 .rdata，而”通过 volatile 指针对整数常量做索引赋值，总会生成 .text 里的立即数 MOV”。这种”知其然且知其所以然”的纪律，在开源 implant 里属于少数。

所有函数归位 .text$B。FUNC = __attribute__((section(".text$B")))，debug 串固定到 .text$Bd，linker script(Linker.ld)显式排序 .text$A → .text$B* → ...。__builtin_memcpy/memset 内联为 rep movs，无 CRT 调用。

unity-build 的必要性被写进注释。Loader.c:1-18 解释了为什么 BOF 加载器、Beacon API、踩踏实现必须放在同一个翻译单元：避免 GCC 生成 .refptr.* 跳板逸出 .text。这是 PIC shellcode 的真实坑，作者不仅做对了，还把它讲透了。

随机性走 CNG。 所有随机值(IV、session id、jitter、URI 轮换、XOR mask key)都用 BCryptGenRandom(BCRYPT_USE_SYSTEM_PREFERRED_RNG)，全仓库没有任何自研 PRNG、没有 rand()、没有 GetTickCount 凑数。

对照 emp3r0r 那种”端点对抗接近空白”的 Go beacon，NaX 在 implant 本体的 PIC 与内存卫生上明显更下功夫。

4. 可塑 C2 Profile 引擎

NAX_OUTPUT_CFG(Instance.h:38-49)把传输编码与载荷彻底解耦：独立的 Format(raw/base64/base64url/hex)、Mask(4 字节随机 XOR)、Placement(body/header/cookie/parameter)，再加 Prepend/Append/EmptyResp 垃圾字段。v1/v2 格式在 PackerProfile.c:104-322 分流实现，条目数被钳到固定上限(>4 钳到 4、>8 钳到 8)。

服务端的实现同样成熟。变换流水线 mask → encode → prepend/append，解码严格逆序(pl_http_transform.go:79-144)。最巧妙的是多 profile 试解：listener 对每个请求尝试 [当前 override, 上次 override, 默认] 三套 profile，直到 decode 成功(pl_http.go:346-409)。这优雅地覆盖了”运行时下发新 profile 后、beacon 还在用旧 profile 编码”的过渡窗口——成功的那个 tx 直接复用于响应，保证响应与 beacon 当前预期一致。

随附三个 profile(jQuery CDN / AWS CloudFront / MS Graph)是 Cobalt-Strike 级质量：CloudFront profile 用了真实的 x-amz-cf-pop、Via、X-Cache 头和 APKA key-pair 前缀；Graph profile 用了 OData 的 $select/$top/api-version 参数。对细节的考究程度在开源 C2 里少见。

5. 模块踩踏与 Stardust UDRL 加载器

loader 的真实逻辑只有约 1100 行(Native.h 那 2.25 万行是公开的 ntdll 定义头，vendored，不计入)。两段式设计：Stardust.asm 对齐栈、留 shadow space 后尾调用 PreMain → Main。

真 PIC，无 writable 数据段。 全局变量用 TLS egghunter 解决：PreMain.c 分配最多 20 个 TLS 槽，保留两个连续的，把 NtCurrentPeb() 当 egg 存进前一个、instance 指针存进下一个；Macros.h:55-63 的 __TlsFindInstance 扫描 TlsSlots[0..62] 找 egg。这样既不需要 .data/.global，也不必对自己 loader 的页面做 NtProtectVirtualMemory——消除了一个常见的 loader 指纹。

IMG 背书执行 + 无 RWX。Stomp.c 用 LoadLibraryExW(DONT_RESOLVE_DLL_REFERENCES) 加载牺牲 DLL，找到 .text 段(校验 SizeOfRawData >= BeaconSize)，RW → 写入 beacon → RX。全树 grep 确认没有任何 RWX。

DLL 加载通知抑制。NaxPatchLdr(Stomp.c:22-41)置 EntryPoint 并 OR 进 LDRP_IMAGE_DLL | LDRP_LOAD_NOTIFICATIONS_SENT | LDRP_PROCESS_STATIC_IMPORT | LDRP_ENTRY_PROCESSED。其中 LDRP_LOAD_NOTIFICATIONS_SENT 正是用来骗过 EDR 的 LdrRegisterDllNotification 回调——beacon 这边还有个 dll-notify list/remove 命令专门在运行时摘除这类回调。两个方向都堵，OPSEC 意识到位。

导出转发(forwarder)解析。Ldr.c:75-105 正确处理了 KERNELBASE.VirtualAlloc 这类导出转发，还用 0x006C006C0064002Eull 这种 uint64 字面量打包 .dll 来避免 4 次 mov-word——既正确又省字节。多数玩具 UDRL 会直接跳过 forwarder。

但 loader 有两个实打实的正确性缺口(详见 §11)：

  • CFG 白名单不完整。Main.c:150-161 调 SetProcessValidCallTargets 时 count 字面量是 1，只登记了 beacon 的 entry。README/wiki 宣称的”登记 entry / go / sleep_mask”与代码不符。CFG 进程下，对 beacon 内部其他地址的间接调用会触发 trap。
  • OrigTextRva 是死参数。Stomp.c:53 声明但函数体从不引用，.pdata 重定位(Stomp.c:126-130)静默假设 beacon 的 .text RVA == 0。一旦 beacon 以 .text 在非零 RVA 的方式构建，栈展开数据就会错位。

6. BOF 子系统：COFF 加载器与踩踏池

Loader.c 是一个手写的 COFF 链接器，REL32/ADDR64/ADDR32NB + REL32_1..5 变体重定位都有，__imp_ 前缀剥离、为 REL32 stub 服务的 mapFunctions 间接层也都在。Beacon API 表 33 项(Loader.c:49-86)对齐 beacon.h 语义，还加了 Adaptix 扩展(AxAddScreenshot、AxDownloadMemory)。

踩踏池(Stomp.c + BofStomp.c)用牺牲 DLL 的 image-backed .text 跑 BOF，.pdata 注进 DLL 的异常目录尾部，CFG 位图登记 BOF entry。这是 Keen Engine 路线的扎实改编，清理顺序与 NaxBofStompFree 的还原路径都正确。

异步 job 管理器结构良好：每 job 临界区、流式 drain 用 try-lock 而最终 drain 用阻塞锁、看门狗带宽限期、abandoned 线程延迟回收(Jobs.c:251,274,284-304)。输出缓冲记账几乎处处检查 cap/space/need 再 MmCopy——在 PIC C2 代码里少见的纪律。

但 BOF 子系统也是 NaX 风险最密集的区域，有两个严重问题(详见 §11)：

  • 无崩溃隔离。Loader.c:504-505 直接调用 BOF 入口 go()，没有 __try/__except 或 VEH 包裹。一个有 bug 或被篡改的 BOF 的访问违例会带崩整个 beacon。Cobalt Strike 的 BeaconExecute 是包了 VEH 的。
  • COFF 元数据被盲信。 见 §11，这里直接关系内存安全。

7. 加密体系：基元正确，完整性缺席

基元用对了：AES-128-CBC，每消息 BCryptGenRandom 生成的随机 IV 前置(Crypto.c:21-47)，解密严格校验 PKCS#7；服务端 DecryptCBC 在解密前校验封装长度与块对齐(pl_crypto.go:81-95)，有 OpenSSL 金标准向量测试。这一层没问题。

问题在完整性缺席，而且不是小问题：

  • 线路无 MAC / 无 AEAD。 每个帧都是 IV || AES-CBC(padding)，没有任何完整性校验。CBC 本身可被 bit-flipping，且暴露 padding oracle 语义。
  • TLS 校验全关。Http.c:32-35 一次性关掉了 IGNORE_UNKNOWN_CA | IGNORE_CERT_DATE_INVALID | IGNORE_CERT_CN_INVALID | IGNORE_CERT_WRONG_USAGE，且无证书 pinning。

这两条叠加的后果是：路径上的防守者不仅能做 padding-oracle 解密，还能直接伪造 task 帧让 beacon 执行命令。BCrypt 原生支持 AES-GCM，切换即可同时补上机密性+完整性+抗伪造。

  • 静态每构建 AES key，无会话级派生/隔离/轮换。Config.h:20-23 编译期硬编码 16 字节 key；服务端 session key == listener 静态 key == 构建内嵌 key(pl_http.go:152、pl_agent.go:182-189、pl_main.go:249-266)。REGISTER 阶段 beacon 手里有 Pid/Tid/hostname 熵却未参与派生。攻陷单个 beacon 或 listener 配置即可解密其全部历史流量。对照 emp3r0r 的 ECDH+HKDF 每会话 PFS，差距明显。

8. 服务端 Go 插件

四个插件按 Adaptix 模型干净分离，各有独立 config.yaml/Makefile/go.mod，编译成独立 .so。单一 ProfileConfig 模型驱动三个独立消费者：listener 的 HTTP 变换、下发 beacon 的 wire 编码、构建期嵌入 PIC 的 Config_profile.h。

构建管线周到：writeIfChanged(pl_build.go:80-85)写配置时保 mtime，让 Make 的自动依赖跳过未变重编；sentinel 门控的 loader 重建跳过是贴心优化；buildMu 串行化构建避免 Make flag 文件竞态。setup_nax.sh 会从 teamserver 二进制 strings 出 GOEXPERIMENT 标志以匹配插件 ABI——这是解决”插件加载失败”的正确姿势。

wire/结果/tunnel 解码器每个长度前缀字段都校验后再切片，tunnel 子载荷二次校验(pl_tunnels.go:93-189)。这一点很扎实。

服务端也有几处值得点名的问题(详见 §11)：操作者可控字符串未经校验就插进编译器 -D/.def(pl_build.go:331,339)可注入 define；AES key 非 16 字节时静默退化为明文(pl_main.go:250-253)；pl_crypto.go/pl_wire.go 在 agent 与 listener 间逐字节重复却无护栏保证不变量。

9. 工程化、测试与文档

文档是这个项目的强项。 14 篇 wiki 带图、带表、带源文件交叉引用。抽查 NaxHeader v2 布局(wiki/Module-Stomping.md vs Defs.h:26-54)、命令 ID(wiki/Wire-Protocol.md vs Wire.h:17-75)、FNV 常量(wiki/Beacon-Architecture.md vs Ldr.c:30,35)全部对得上。Stardust-Loader-Guide.md 从零写自定义 loader 的 11 步教程极其友好。开源 implant 里有这种文档密度的极少。

测试是最大的工程债。 Go 服务端有单元测试(crypto 金标准向量、wire 往返、构建配置生成)，但 C beacon / loader / sleepmask 零自动化测试，且全仓库无 CI。最脆弱的 PIC 流水线(linker script、pe_text_rva.py、pack_nax.py)毫无回归覆盖，每次提交靠 Windows VM 手验。更糟的是 pl_main_test.go:136-158 的 TestExtenderEncryptIsIdentity/TestExtenderDecryptIsIdentity 记录的是旧的”listener 拥有 AES”行为，现已不成立——它们仅因传入 11 字节 key 触发静默退化而仍通过，主动掩盖了真实 crypto 路径。

仓库卫生总体干净：无硬编码密钥/token/真实 URL，profile 用假数据，提交者用匿名 GitHub 邮箱。但 src_loader/scripts/loader.x64.exe、stomper.exe 两个 Windows 二进制自首提交入库，.gitignore 未排除 *.exe——可从 .c 重建、无法 diff、构成供应链完整性疑问。另外 pack_nax.py:183 的 .xdata RVA 推算用 text_rva+align4(...)+align4(...) 而非读 PE 真实 VA，正确性完全依赖 Linker.ld 保持 ALIGN(4)，一旦有人把段改成页对齐就会静默坏掉。

10. 优点总览

| 维度 | 评价 | | — | — | | PIC 工程纪律 | 逐字节 volatile 写秘密、FUNC 段归位、unity-build 必要性写进注释、无 CRT、无全局——教科书级 | | API 解析 | D_API(__typeof__) 编译期类型安全 vtable，少见 | | 可塑 C2 | format/mask/placement 矩阵 + v1/v2 + 多 profile 试解过渡窗口 | | 模块踩踏 | IMG 背书、无 RWX、LDR 通知抑制、forwarder 解析、CFG 框架在位 | | 密码学基元 | CBC 随机 IV、CNG 随机性、严格 PKCS#7、金标准向量测试 | | 协议健壮性 | 帧/结果/REGISTER/tunnel 解码器边界检查严谨 | | 命令实现 | 输出缓冲记账保守、异步 job 管理结构良好、CS 兼容 Beacon API | | 文档 | 14 篇 wiki，抽查准确，onboarding 友好 | | 仓库卫生 | 无泄密，匿名提交，部署脚本周到 |

一句话：在开源 C2 beacon 里，NaX 的 PIC 纪律、可塑 C2、文档 三块足以作为学习与二次开发的高质量参考。

11. 缺点与风险：按严重度分级

严重(安全/可靠性，投入前必修)

1. 线路无完整性 + TLS 全关 = 可被 MITM 伪造任务。IV || AES-CBC(padding) 无 MAC/AEAD(Crypto.c:13-68)，叠加 Http.c:32-35 关闭所有证书校验且无 pinning。路径上的防守者可 padding-oracle 解密、bit-flip 密文，直接伪造 task 让 beacon 执行。切 AES-GCM 一处改动同时补三个洞。这是全项目最严重的缺陷。

2. COFF 加载器盲信所有元数据 → 可利用的越界读写。Loader.c 对 PointerToSymbolTable(:363)、PointerToRelocations(:236)、PointerToRawData+SizeOfRawData(:189)、SymbolTableIndex(:240)、VirtualAddress(:241) 均无范围校验。一个被篡改的 BOF(损坏下载/中继/恶意操作者)能通过重定位补丁读写 beacon 任意内存。无论威胁模型如何都是内存安全紧急项。

3. BOF 无崩溃隔离。Loader.c:504-505 直接调 go()，无 SEH/VEH。单个有 bug 或敌意的 BOF 访问违例带崩整个 beacon。一行 __try/__except 即可修，性价比极高。

4. 踩踏槽位分配竞态。Stomp.c:186-193 的 slot->InUse check-and-set 无锁非原子，而异步 BOF 在线程池并发跑(Jobs.c:122-137)。同一任务帧两个 BOF 可同时选中同一槽、各自 MmCopy，第二个踩坏可能仍在执行的第一个 BOF 的 .text。需临界区或 interlocked 预留。

5. 静态每构建 AES key，无派生/隔离/轮换。 见 §7。攻陷一个 beacon 即可解密其全部流量；DEBUG 构建还会 NaxDbg 打印全部 16 字节 key(Main.c:55-59)。

6. 每请求带硬编码 X-NaX-Public: 1 头。HttpCodec.c:168-170 与 Http.c:197-199, 324-326，profile 与 fallback 路径都发。一条 Surata 规则即终结植入体——最显眼的网络指纹。

中等(正确性/OPSEC)

7. abandoned 异步 BOF 永久泄漏踩踏槽。Jobs.c:142-152 被杀线程路径不调 NaxBofCleanupSections/NaxBofStompFree，InUse 永置 TRUE。积累后槽池耗尽，踩踏静默回退到私有 RWX(Loader.c:156-191)——既是资源泄漏又是 OPSEC 退化。

8. CFG 白名单只登记 entry(Main.c:158)，与文档宣称的”entry/go/sleep_mask”不符。CFG 进程下对其他内部地址的间接调用会 trap，崩溃本身就是 OPSEC 信号。

9. 操作者字符串注入编译器 -D/.def。pl_build.go:331(-DNAX_SVC_NAME=L"%s")、:339(.def EXPORTS)。svcName/dllExport 含 "/\n 可注入额外 define/导出。建议加 ^[A-Za-z_][A-Za-z0-9_]*$ 校验。

10. 无界信任 Content-Length。Http.c:351-358 按服务端控制长度 RtlAllocateHeap 无上限——结合 SSL 已关，MITM 可每次心跳逼出最高约 4 GB 分配。

11. Token 句柄生命周期 bug。CmdTokenRm(Token.c:332-344)关闭句柄不检查是否即当前 ActiveToken，留下悬垂句柄被后续 job 线程用于 ImpersonateLoggedOnUser(Jobs.c:134)。

12. CmdTokenPrivs 输出缓冲溢出。Token.c:471 预留 guard 是 pos+40，实写 2+slen+4，LookupPrivilegeNameA 名最长 63 字符 → 可溢出约 29 字节。

13. AES key 非 16 字节时静默退化为明文。pl_main.go:250-253, 261-265``if len(key)!=16 { return data, nil }——配置或上游出错会无声走明文，应报错。

14. 死参数 OrigTextRva(Stomp.c:53)。.pdata 重定位静默假设 beacon .text RVA==0。

15. sleepmask 是 PoC 而非真 sleep 混淆。src_sleepmask/src/main.c:1-5 自承为 PoC：仅把 Sleep 换成 NtWaitForSingleObject(系统调用分流)，无内存加密、无权限翻转、无线程劫持；NAX_SM_INFO 的 BeaconBase/BeaconSize/CleanTextBuf/ActiveJobCount 字段全未使用；WaitForMultipleObjects 甚至没被分流。BeaconGate 代理架构本身设计合理可扩展，但”sleepmask 技术”目前缺席。

工程化/卫生

16. C 侧零自动化测试、无 CI——影响最大的工程缺口。

17. 过期测试反向掩盖 crypto 回归(pl_main_test.go:136-158)。

18. Go 侧大量未测面:ProcessData 的 560 行结果 switch、所有结果解码器、可塑变换、packNaxBin、profile v2 线格式、profile store、SMB listener、整个 store 服务均无测试。

19. pl_crypto.go/pl_wire.go 在 agent 与 listener 间逐字节重复却无护栏保证不变量，漂移不可避免且不可测。

20. 提交了 Windows 二进制(loader.x64.exe/stomper.exe)，.gitignore 未排除 *.exe。

21. pack_nax.py:183 的 .xdata RVA 推算脆弱(依赖 Linker.ld 保持 ALIGN(4))。

22. Nax.h:81-87 的 NaxBuildRegBody 原型过期:与实现参数语义错位，编译通过但对新调用者是陷阱。

23. loader CMakeLists.txt 过期(只列 4 源，实际 7);Makefile 用 || true 吞链接失败，可产出 0 字节 .bin。

24. 文档滞后:cp/mv 命令(0x1A/0x1B)未入 wiki、README “26 commands” 已过期、Module-Stomping.md 少写 2 个 LDR flag。

12. 蓝队检测视角

基于源码可直接提取的检测面：

  1. 网络侧(最高价值):
  • X-NaX-Public: 1 头——profile 与 fallback 路径都发，一条 IDS 规则即可批量识别;
  • 每请求携带静态 16-hex SessionId，是贯穿 beacon 全生命周期的关联句柄;
  • 无 profile 时默认 User-Agent: NoNameAx/0.1;
  • AES-CBC 无 MAC，被动抓包可做 padding-oracle 解密(配合 SSL 未验，主动 MITM 可伪造 task)。
  1. 主机侧:
  • 启动即 LoadLibraryW(user32/gdi32)(即使永不截图)，产生 module-load 遥测;
  • LoadLibraryExW(DONT_RESOLVE_DLL_REFERENCES) 加载牺牲 DLL，再 OR 进 LDRP_PROCESS_STATIC_IMPORT——这是已知 EDR 启发式;
  • 每个 BOF 跑一次对 image-backed 内存做 VirtualProtect(MemProtectSource/TargetImage 经典检测点);
  • SMB beacon 命名管道 DACL 授 Everyone 读写(Smb.c:26-31);
  • 所有缓解经 hooked 用户态 API(LoadLibraryExW/VirtualProtect/SetProcessValidCallTargets)，无 direct/indirect syscall——NtProtectVirtualMemory 已解析却未用，user-mode hook 即可覆盖。
  1. 行为侧:
  • CreateProcessA 跑 shell/ps run 后快速 NtTerminateProcess——create+terminate 急促序列;
  • NtSetInformationProcess(ProcessAccessToken) 全进程 token 替换 + ImpersonateLoggedOnUser，token 操作是 EDR 内核回调的高信号点;
  • 持有大量指向其他进程用户的 token 句柄(NtQuerySystemInformation(SystemHandleInformation) 可枚举)。

值得注意的是:NaX 的网络指纹(X-NaX-Public 头)比其主机侧对抗更容易被抓,这与 emp3r0r”流量难抓、主机好打”的格局正好相反。

13. 评估结论

把 NaX 拆开看，它是一个工程素养明显高于平均水平的开源 PIC beacon。

PIC 与可塑 C2 层是教学级优秀。 逐字节 volatile 写秘密、__typeof__ 类型安全 vtable、unity-build 必要性写进注释、IMG 背书踩踏无 RWX、LDR 通知抑制、多 profile 试解过渡窗口、CNG 随机性——这套 PIC 纪律与文档密度，在开源 C2 里属于第一梯队，足以作为 Windows shellcode 开发的学习范本。

但作为实战工具，它有几个投入前必须堵掉的硬伤。 按优先级：① 线路加 AEAD(AES-GCM 或 HMAC)并启用 TLS pinning，堵住 MITM 伪造 task 与 padding oracle；② COFF 加载器补全所有偏移的边界校验；③ go() 包 SEH/VEH；④ 踩踏槽分配加锁；⑤ 去掉 X-NaX-Public 头、AES key 非法时报错；⑥ 给 PIC 流水线补回归测试与 CI。前三项是安全与可靠性的”必选项”。

与同类对比：NaX 的 implant 本体(PIC/踩踏/可塑 C2)强于多数开源同类，但密码学严谨度落后于 emp3r0r(无 PFS、无身份固定、无完整性)，BOF 内存安全弱于 Cobalt Strike(无崩溃隔离、盲信元数据)。它的定位接近”一份高质量的 PIC beacon 教学实现，距生产可用还差一次安全加固”。

对红队：适合用来学习 PIC/模块踩踏/可塑 C2 的工程做法，或在受控研究环境复现；不建议在 TLS 可被拦截或 BOF 来源不可信的场景直接用于实战。对蓝队：它是一个网络侧好抓(X-NaX-Public 头)、主机侧有固定抓手(DLL 通知抑制行为、image 内存 VirtualProtect、hooked 用户态 API)的目标——检测资源应优先压在网络指纹与 module-load/VirtualProtect 遥测上。

能把这个完成度做成开源公开，本身值得尊重；它的 PIC 工程做法即使不用于对抗场景，对 Windows 系统编程学习者也是高质量参考。

本文仅用于安全研究与防御能力建设。分析对象为其公开仓库源码，所有结论以代码为准。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：赛博生存指南 GLM-5.2 GLM-5.2《工具 | NaX 源码深度评估：工程纪律一流的 PIC Beacon 及其硬伤》

版权声明

本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。

ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
ZONE.CI 全球网
安全领域涉猎者-乌云独行地带
ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
安全领域涉猎者-乌云独行地带
ZONE.CI 全球网
评论：0   参与：  0