Stoica-Cristian/Fulcrum
GitHub: Stoica-Cristian/Fulcrum
Fulcrum 是一款用于红队安全研究的模块化 C2 框架,集成了自动化 loader 生成、分阶段交付、加密通信与规避能力,专为受控实验室环境设计。
Stars: 0 | Forks: 0
# Fulcrum C2 框架
## 概述
Fulcrum 是一个模块化的命令与控制 (C2) 及 Windows loader 研究框架,作为关于恶意软件 loader 架构的学士论文的实践部分而开发。该项目模拟了现代 loader 如何生成、交付、staging、执行和管理 payload,重点在于受控实验、防御性理解和可重复的技术分析。
该框架专为隔离的实验室环境和授权的安全研究而设计。它包含可以生成可执行 loader 产物的组件,因此在运行、分享或发布该项目的输出之前,请查阅[安全策略与授权使用](#security-policy--authorized-use)。
生成的产物不包含在此代码仓库中。
## 目录
- [研究目标](#research-goals)
- [系统组件](#system-components)
- [核心功能](#key-capabilities)
- [架构](#architecture)
- [支持的产物工作流](#supported-artifact-workflows)
- [技术清单](#technique-inventory)
- [运行时流程](#runtime-flow)
- [仓库布局](#repository-layout)
- [快速入门](#quickstart)
- [配置说明](#configuration-notes)
- [可重复性](#reproducibility)
- [测试](#testing)
- [范围与限制](#scope-and-limitations)
- [学术背景](#academic-context)
- [安全策略与授权使用](#security-policy--authorized-use)
- [许可证](#license)
## 研究目标
此实现通过提供一个工作平台来支持该论文,用于:
- 为 loader 和分阶段交付架构建模;
- 比较单体式、分阶段、自定义 payload 和 DLL 自动迁移流程;
- 研究加密的 C2 流量、任务分配、重放保护和密钥轮换;
- 分析构建时的 payload 保护、每次构建的随机化以及 PE 封装决策;
- 在受控的 Windows 实验室中收集用于检测、遥测和防御性分析的可重复证据。
## 系统组件
| 组件 | 技术 | 角色 |
|-----------|------------|------|
| API Server | Go 1.26 | 管理 API、C2 监听器、agent/任务编排、分阶段交付 |
| Build Worker | Go 1.26, CMake, MinGW/OLLVM | 隔离的交叉编译和产物生成服务 |
| Windows Implant | C++17 | Stage 1 stager、Stage 2/单体 beacon、自定义 payload loader、DLL 自动迁移模式 |
| Web UI | React 19, Vite, Tailwind | 操作员仪表板、构建工作流、分阶段目标审查、agent 工作区 |
| Storage | SQLite, Neo4j, 文件支持的 blob | 权威运行时状态、派生图投影、产物、下载 |
## 核心功能
- 多模式 implant 构建:Stage 1 stager、单体 beacon、一次性 payload loader、DLL loader 和宿主 EXE 侧载捆绑包。
- 分阶段目标审查:Stage 1 主机调查、操作员批准/拒绝、模块选择、定制的 Stage 2 构建以及加密的 Stage 2 交付。
- 构建时配置:生成的 C++ 头文件、CMake 标志、PE 资源元数据、payload 封装以及每次构建的随机化材料。
- 加密的 C2 运行时:X25519 会话建立、XChaCha20-Poly1305 消息封装、HMAC 路由 token、序列检查和密钥棘轮。
- 操作员工作区:agent 概览、控制台任务分配、快照、文件/进程视图、分阶段目标队列、构建历史、事件时间线和操作地图。
- 容器化部署:分离的 API、UI、build-worker、图、secrets、持久化状态和构建工作区。
## 架构

API server 拥有外部可见的管理和 C2 接口,而 build worker 与面向操作员的运行时状态保持隔离。SQLite 是构建、任务、agent、调查、审计事件和产物的权威存储;Neo4j 仅用作派生图投影,用于运营分析。
## 支持的产物工作流
| 工作流 | 输出 | 目的 |
|----------|--------|---------|
| 多阶段 | Stage 1 stager + 生成的 Stage 2 运行时 | 具备主机感知的交付,在生成完整 agent 之前进行调查审查 |
| 单体式 | 完整的 beacon 产物 | 用于直接 C2 注册和任务分配的单产物基线 |
| 自定义 Payload | 带有提供的 payload 材料的 EXE/DLL loader | 对原始 shellcode 或转换后的 PE 输入进行受控的本地执行 |
| DLL Loader | DLL 产物 | 用于操作员控制的外部启动上下文的 Loader 形式 |
| 侧载捆绑包 | 宿主可执行文件 + 生成的代理 DLL 包 | 带有记录的宿主、代理和 payload 元数据的代理 DLL 工作流 |
多阶段路径是主要的研究工作流:一个小型的 Stage 1 产物提交主机上下文,操作员审查目标,然后服务器生成带有选定模块和放置策略的 Stage 2 运行时。单体式和自定义 payload 构建为评估 staging 的成本和行为提供了比较基线。
## 技术清单
本节从架构层面总结了框架实现的技术。其目的是使研究贡献更加明确,而不是提供在授权实验室之外使用的说明。
### 运行时强化与规避建模
| 领域 | 实现技术 |
|------|-----------------------|
| API 解析 | 运行时 PEB/模块遍历以及通过带密钥的 DJB2 哈希进行导出查找,而不是静态导入敏感的 Win32 API |
| 每次构建的签名 | 随机化的 DJB2 种子、生成的滚动 XOR 密钥、编码的静态字符串、生成的 `config.hpp` 以及可选的 OLLVM/Pluto 混淆传递 |
| 间接系统调用 | 通过 `ntdll` 系统调用 gadgets 进行 VEH + 硬件断点分派;implant 避免发出自己的内联 `syscall` 指令 |
| 系统调用发现 | Hell's Gate、Halo's Gate 和 FreshyCalls 风格的系统调用号恢复,用于选定的 NT 调用 |
| 运行时保护 | 紧凑的、专注于调试器的检查,包括 `IsDebuggerPresent` 和 `NtQueryInformationProcess` 调试指示器 |
| 实例控制 | 每次构建、每个角色的命名互斥锁,以避免重复的 stager、beacon 或一次性 loader |
| 故障行为 | 对格式错误的 payload、缺失的加密材料、无效的放置状态和不支持的执行路径进行故障关闭验证 |
### 内存放置与执行
| 流程 | 放置 / 执行模型 |
|------|-----------------------------|
| 本地自定义 payload loader | 嵌入的 shellcode 被解密、进行完整性检查、封装在执行 blob 中、放置在映像支持的载体中,并通过 Thread Pool 工作项进行调度 |
| 模块踩踏 | 本地执行可以覆盖选定的映像支持的模块区域,恢复 RX 保护,刷新指令缓存,并通过共享执行 blob 运行 |
| 节映射放置 | 对于根据策略选择的 staging 交接和注入路径,可以使用 SEC_IMAGE 支持的节映射 |
| Stage 1 -> Stage 2 交接 | Stage 1 在批准后接收加密的 Stage 2 PIC shellcode,然后通过通用的映像支持放置和交接引擎启动它 |
| 显式注入任务分配 | 可选的 `process_inject` 模块通过共享的放置原语启用对现有进程和派生并注入的 shellcode 任务分配 |
| 交接原语 | 远程/启动路径根据工作流支持策略选择的交接目标、PIC 跳板、Early Bird APC 风格启动、直接线程启动或定时 APC 模式 |
| DLL 自动迁移 | 代理 DLL 捆绑包将生成的运行时交接给派生的进程,而不是将 payload 保留在侧载宿主进程内 |
### Staging、任务分配与持久化
| 领域 | 实现技术 |
|------|-----------------------|
| Stage 1 调查门 | 最小化的 stager 收集主机上下文,提交加密的调查数据,等待操作员批准,并在拒绝时干净地退出 |
| Stage 2 定制 | 已批准的目标会收到生成的 Stage 2 payload,包含选定的模块和放置/交接策略 |
| Beacon 循环 | 带有抖动的休眠、签入、任务执行、结果发布、故障退避以及在多次授权失败后重新注册 |
| 原生任务分配 | `whoami`、`sleep`、`pwd`、`ls`、`cat`、有限制的下载、主机快照、shellcode 注入/派生、退出和自毁 |
| 侦察模块 | 针对主机、用户、服务、进程、网络、软件、注册表、目录和安全产品的可选调查/快照收集器 |
| 持久化 | 带有生成的安装路径处理的 HKCU Run 键和计划任务持久化方法 |
| 清理 | 自毁和 Stage 1 交接后清理路径,尽可能移除拥有的产物和持久化记录 |
### 加密与协议控制
| 层级 | 实现控制 |
|-------|---------------------|
| HTTPS 身份 | 每个回调目标强制执行 TLS SPKI 固定 |
| 注册 | 每次构建的引导材料,带有不透明的 HMAC 路由 token 和加密的注册封装 |
| 会话设置 | X25519 密钥协商和 HKDF-SHA256 会话密钥派生 |
| 消息安全 | 带有经过身份验证的路由元数据的 XChaCha20-Poly1305 封装 |
| 重放控制 | 针对签入和任务结果的单调序列验证 |
| 密钥生命周期 | 每 100 次签入进行一次基于 HKDF 的会话密钥棘轮,并带有待定密钥恢复 |
| 嵌入式 payload | IETF ChaCha20-Poly1305 payload 加密以及在执行前强制执行的 SHA-256 明文哈希验证 |
| 敏感内存 | 在适用的清理路径中,派生密钥、解密缓冲区和中间材料将被清零 |
### 构建与产物流水线
| 领域 | 实现技术 |
|------|-----------------------|
| 构建隔离 | API 通过内部 mTLS 将产物生成委托给隔离的 build-worker 服务 |
| 产物形式 | EXE loader、DLL loader、分阶段构建、单体 beacon、自定义 payload loader 和宿主 EXE 侧载捆绑包 |
| Payload 标准化 | 原始 x64 shellcode 可以直接嵌入;PE 输入可以在封装之前转换为 shellcode |
| 生成的构建状态 | 构建请求生成 C++ 配置、CMake 选项、PE 资源、静态字符串、payload 密钥、回调路由和 TLS 固定 |
| 完整性证据 | 构建 metadata、哈希、有限制的日志、可下载产物以及 worker 与 API 之间的产物签名 |
| 操作图谱 | SQLite 存储权威状态;Neo4j 接收派生的操作图谱,用于血缘和关系分析 |
## 运行时流程
端到端操作遵循以下形式:
1. 操作员通过 Web UI 或管理 API 创建构建请求。
2. API 验证请求,解析回调目标和 TLS 固定,并持久化构建作业。
3. Build worker 通过内部 mTLS 接收请求,生成配置材料,编译产物,对 worker 响应进行签名,并返回哈希、日志和输出 metadata。
4. API 将产物和构建证据存储在 SQLite/文件支持的存储中。
5. 生成的运行时通过 HTTPS 和加密的协议封装联系 C2 监听器。
6. 服务器注册 agent 或分阶段目标,分派任务,接收结果,并为 Web UI 发出实时事件。
7. 操作关系从权威的 SQLite 记录投影到 Neo4j 中,以进行面向图的分析。
## 仓库布局
| 路径 | 描述 |
|------|-------------|
| [cmd/](cmd/) | 用于 API server、build worker 和工具的 Go 入口点 |
| [internal/](internal/) | 用于 C2、加密、存储、构建、交付、绘图和管理 API 的后端包 |
| [implant/](implant/) | C++ Windows implant、CMake 构建逻辑、模块和 vendored 加密依赖 |
| [web/](web/) | React 管理界面 |
| [configs/](configs/) | 默认配置和重定向器示例 |
| [docker/](docker/) | 容器构建文件和 nginx 运行时配置 |
| [scripts/](scripts/) | 安装、部署、状态和配置脚本 |
## 快速入门
###前置条件
| 工具 | 最低要求 |
|------|---------|
| Docker Engine + Compose | v24+ |
| Git | 任何最新版本 |
| Go | 1.26+ |
| Node.js | 22+ |
| OpenSSL | 1.1+ |
### 部署
```
git clone fulcrum
cd fulcrum
make deploy
```
`make deploy` 配置运行时路径,生成本地证书和 secrets,构建容器,并启动 stack。
部署完成后,打开:
```
http://localhost
```
如果您再次需要生成的 API 密钥:
```
make show-api-key
```
### 默认服务
| 服务 | 默认绑定 | 备注 |
|---------|-----------------|-------|
| Web UI | `127.0.0.1:80` | 由 UI 容器提供的浏览器界面 |
| 管理 API | `127.0.0.1:8080` | UI 和工具使用的本地 REST/WebSocket API |
| C2 HTTPS | `0.0.0.0:443` | 面向 implant 的 HTTPS 监听器 |
| Build Worker | 内部 `:8090` | 受 mTLS 保护的构建服务,未在宿主上暴露 |
| Neo4j | 仅限内部 | API 使用的派生操作图谱 |
### 常用命令
```
make status # show service and runtime status
make logs # follow Docker Compose logs
make stop # stop running services
make start # start existing services
make test # run the project test gate
make help # list available Make targets
```
通常的第一个工作流是部署 stack,打开 Web UI,配置 HTTPS 回调目标,通过构建器页面构建产物,并在构建历史中查看生成的构建记录。
## 配置说明
Fulcrum 将部署设置与产物设置分开:
- `.env` 控制宿主端的 Docker 绑定、运行时路径、用户映射、worker 工作区位置和 Neo4j 凭据。
- `configs/config.yaml` 控制服务器路由、日志记录、构建默认值、可选签名和可选的混淆默认值。
- 每个产物的行为通过 Web UI 或 API 选择:payload 模式、回调目标、模块选择、PE 身份、staging、持久化和自定义 payload 材料。
- 运行时 secrets、引导密钥、payload 密钥、nonce、TLS 固定以及生成的 C++ 配置是在部署/构建流程中生成的,而不是作为静态项目文件存储。
Build worker 在 Docker 内部交叉编译 Windows 产物,因此 Linux 宿主上不需要原生的 Windows 工具链。
## 可重复性
构建记录保留产物 metadata、哈希、有限制的日志、选定的配置、回调材料和血缘信息,以便将生成的输出追溯到其输入。仓库的 `VERSION` 文件是项目的发布版本,`make version` 会打印它以及 Git metadata。
由于 Fulcrum 有意生成每次构建的密钥、nonce、路由材料、字符串编码和随机化的编译时值,因此并非每次构建都能实现字节对字节的产物可重复性。
## 测试
主要的验证命令是:
```
make test
```
它运行 Go vet、启用竞态的 Go 测试、构建器集成测试、前端 lint/单元/构建检查、Docker Compose 验证、shell 语法检查和空白字符规范。详细的日志写入 `build/test-logs/` 下。
仅限 Windows 的 implant 行为在受控的实验室场景中单独验证,包括分阶段交付、TLS 固定、任务执行、进程交互、持久化方法和产物证据捕获。
## 范围与限制
| 领域 | 当前范围 |
|------|---------------|
| 目标平台 | Windows x64 产物 |
| 宿主平台 | 带有 Docker Compose 的 Linux 部署宿主 |
| 执行环境 | 隔离的实验室、防御性研究或明确授权的测试 |
| 图存储 | Neo4j 派生自 SQLite 状态,不是事实来源 |
| 混淆 | OLLVM/Pluto 支持是可选的,并取决于构建/部署 |
| 可重复性 | 证据和配置是可重复的;最终字节可能不同,因为每次构建的随机化是有意为之 |
| 生成的输出 | Payload、证书、API 密钥、日志、运行时数据库和回调材料属于敏感信息,不应发布 |
## 学术背景
该论文研究恶意软件 loader 作为一种架构类别:它们如何准备 payload、分阶段执行、与 C2 基础设施通信,以及试图减少最终 payload 的暴露。Fulcrum 将这些想法实现为一个受控的研究平台,以便可以从攻击建模和防御分析的角度来检查、测量和讨论 loader 行为。
该实现的结构旨在使这些论文贡献在代码库本身中可见:分离的运行时组件、明确的构建计划、记录的产物 metadata 以及可重复的部署/测试命令。
## 安全策略与授权使用
Fulcrum 仅用于学术研究、防御性研究、恶意软件分析教育以及授权的实验室或红队/紫队测试。未经明确的书面许可,请勿将其用于第三方系统、网络、账户或基础设施。
请勿发布生成的 payload、API 密钥、私有证书、运行时数据库、build-worker secrets、回调材料或包含敏感值的日志/截图。
完整策略请参见 [SECURITY.md](SECURITY.md)。
## 许可证
该项目在 Apache License 2.0 下获得许可。详情请参见 [LICENSE](LICENSE)。
Research framework for malware-loader generation, staged delivery, and command-and-control workflows
Bachelor's thesis implementation for cybersecurity research and controlled laboratory evaluation
标签:Bash脚本, C2框架, DNS 反向解析, EVTX分析, Go, Gophish, IP 地址批量处理, React, Ruby工具, Syscalls, 安全, 安全学习资源, 恶意软件, 日志审计, 版权保护, 网络信息收集, 超时处理