pard0p/Remote-BOF-Runner

# 远程 BOF Runner 一个用于远程执行 Beacon Object Files (BOFs) 的 Havoc 扩展框架，使用 Crystal Palace 制作的 PIC loader 实现。 ## 概述 Remote BOF Runner 通过利用 Crystal Palace PIC loader，实现在任意进程中安全执行 BOF。该框架通过命名管道 (named pipes) 实现了复杂的进程间通信 (IPC) 机制，以便将注入进程中的 beacon 输出透明地转发回命令与控制 (C2) 服务器。 ## 设置与安装 ### 扩展安装 确保扩展已安装在 Havoc 扩展目录中： ``` YOUR_HAVOC_FOLDER + /data/extensions/ ``` ### 依赖项 要编译 PIC loader，您的系统必须安装以下工具和库： - **MinGW-w64**: Windows 目标的交叉编译器 - **Make**: 构建自动化工具 - **OpenJDK 11**: Java Development Kit（Crystal Palace 编译所需） - **Zip**: 压缩实用程序 有关详细的设置说明，请参阅 [WSL 设置指南](https://tradecraftgarden.org/wslsetup.html)。 #### 安装命令 ``` sudo apt-get update sudo apt-get install mingw-w64 sudo apt-get install make sudo apt-get install openjdk-11-jdk sudo apt-get install zip ``` ## 架构 ### 组件 #### 1. BOF Injector BOF 组件负责： - 创建并挂起一个虚拟进程。 - 将 Crystal Palace loader + 目标 BOF 注入到虚拟进程中。 - 建立用于输出通信的 IPC 通道（命名管道）。 - 接收并聚合来自远程 BOF 执行的输出。 #### 2. PIC Loader (Crystal Palace) PIC loader 包含： - **Crystal Palace Loader**: 处理内存分配、BSS 节管理和安全执行上下文初始化。 - **Remote BOF Payload**: 实际要执行的 BOF 代码（whoami、ipconfig、cacls、reg-query 等）。 - **Argument Marshalling**: 通过 loader 传递的序列化参数，用于远程 BOF 执行。 ### 执行流程 ``` ┌───────────────────────────────────────────────────────────────────┐ │ 1. Beacon Process (Havoc) │ │ ├─ Execute BOF Injector │ │ ├─ Create dummy process (suspended) │ │ ├─ Inject PIC Loader + Remote BOF │ │ └─ Create IPC named pipe │ └────────────┬──────────────────────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────────────┐ │ 2. PIC Loader Execution │ │ ├─ Crystal Palace loader │ │ ├─ Performs BSS section allocation │ │ ├─ Initializes UI context (for .NET compatibility) │ │ └─ Hooks beacon functions (BeaconPrintf, BeaconOutput, etc.) │ └────────────┬──────────────────────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────────────┐ │ 3. Remote BOF Execution │ │ ├─ Execute target BOF (whoami, ipconfig, etc.) │ │ ├─ BOF calls hooked beacon functions │ │ ├─ Hooked functions redirect output to IPC pipe │ │ └─ Output accumulates in beacon process via pipe │ └────────────┬──────────────────────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────────────┐ │ 4. Output Collection & Transmission │ │ ├─ Beacon waits for remote process termination │ │ ├─ Accumulates all output from IPC pipe │ │ ├─ Aggregates fragmented messages (8KB buffer) │ │ ├─ Filters protocol delimiters (@START@, @END@) │ │ └─ Transmits consolidated output to Team Server │ └───────────────────────────────────────────────────────────────────┘ ``` ## 主要特性 ### 1. 进程隔离 - BOF 执行发生在独立的隔离进程中。 - 最大限度地减少对 beacon 进程稳定性的影响。 - 允许在任意进程上下文中执行。 ### 2. IPC 输出转发 - 基于命名管道的通信通道。 - 远程 BOF 的透明输出重定向。 - 消息分片处理（8KB 累积缓冲区）。 - 协议分隔符过滤。 ### 3. .NET 进程执行 主要用例是在原生 .NET 进程中执行 BOF： **为何在 Beacon 中直接加载 CLR 有风险：** 在 beacon 进程中直接加载 .NET assemblies 本质上是不安全且可检测的： - beacon 进程（通常是原生二进制文件，如 cmd.exe 或 rundll32.exe）通常不会启动 CLR。 - 当 CLR 被加载到非 .NET 进程时，会立即触发 EDR/XDR 警报。 **一种可能的解决方案：原生 .NET 进程注入：** 与其将 CLR 加载到 beacon 中，不如将我们的 inline-execute-assembly BOF 注入并执行到一个已经是 .NET 原生的进程中： ``` // ❌ DETECTABLE: Direct execution in beacon beacon.exe (native) → load ClrCreateInstance → load .NET assembly → EDR ALERT // ✅ STEALTHY: Execution in native .NET process dotnet.exe (native .NET) → inject BOF → inline-execute-assembly → execute .NET assembly in already-CLR context → normal behavior ``` 这种方法利用了这样一个事实：在 .NET 进程内执行 .NET 与正常的应用程序行为无法区分。 ### 4. Crystal Palace 集成 - 位置无关的代码执行。 - 通过基于哈希的函数查找进行动态 API 解析。 - 无导入地址表依赖。 - 适用于深度注入场景。 ## 执行模式 ### 本地执行 ``` remote-bof-runner whoami remote-bof-runner ipconfig remote-bof-runner cacls C:\Windows\System32 ``` ### 远程主机执行 ``` remote-bof-runner reg-query DC01 HKLM SYSTEM\CurrentControlSet ``` ### 注册表查询 ``` remote-bof-runner reg-query HKLM SYSTEM\CurrentControlSet\Control\Lsa remote-bof-runner reg-query HKLM SYSTEM\CurrentControlSet\Control\Lsa RunAsPPL ``` ### .NET Assembly 执行 ``` remote-bof-runner execute-assembly --dotnetassembly "/Payloads/Rubeus.exe" --assemblyargs "triage" ``` **示例输出：**  ## 可用的 BOF - **whoami** - 显示当前用户和组信息。 - **ipconfig** - 显示网络适配器配置。 - **cacls** - 列出文件权限。 - **reg-query** - 查询 Windows 注册表。 - **execute-assembly** - 将 .NET assembly 加载到实际进程中。 - **bof** - 执行自定义 BOF 二进制文件。 ## 操作安全考量 ⚠️ **重要**：本项目是一个 **概念验证 (Proof-of-Concept)**，默认情况下**不**优先考虑 OPSEC。 ### 建议的修改 BOF Injector 和 PIC Loader 都需要进行大量加固才能用于对手模拟： #### BOF Injector 加固 - 实施自定义进程创建方法（而非 CreateProcessW）。 - 使用标准 WriteProcessMemory 之外的替代注入技术。 - 混淆 IPC 管道命名（随机化标识符）。 #### PIC Loader 加固 - 加密通信协议（管道消息）。 - 实施针对已知签名的 YARA 规则规避。 - 添加规避进程钩子的方法（间接系统调用、脱钩方法等）。 - 添加加密方法以存储目标 BOF + Args。 ## 参考 - [Crystal Palace](https://tradecraftgarden.org/) - [LibIPC](https://github.com/pard0p/LibIPC) - Crystal Palace 共享库，用于基于命名管道的进程间通信。 - [PatchlessInlineExecute-Assembly](https://github.com/VoldeSec/PatchlessInlineExecute-Assembly) - BOF InlineExecute-Assembly，用于在进程中加载 .NET assembly，但利用硬件断点实现无补丁的 AMSI 和 ETW 绑过。 - [CS-Situational-Awareness-BOF](https://github.com/trustedsec/CS-Situational-Awareness-BOF) - 使用 Beacon Object Files 实现的态势感知命令。 ## 免责声明 本工具仅供教育和授权安全测试目的使用。未经授权访问计算机系统是非法的。用户有责任确保遵守所有适用法律和法规。

标签：Beacon Object Files, BOF, C2框架, Crystal Palace, EDR绕过, Havoc, IPC, MinGW, PIC Loader, SSH蜜罐, UML, 中高交互蜜罐, 位置无关代码, 命名管道, 安全学习资源, 客户端加密, 恶意软件开发, 数据展示, 欺骗防御, 红队, 跨进程通信, 进程注入, 远程执行, 高交互蜜罐