Stoica-Cristian/Fulcrum

GitHub: Stoica-Cristian/Fulcrum

Fulcrum 是一款用于红队安全研究的模块化 C2 框架,集成了自动化 loader 生成、分阶段交付、加密通信与规避能力,专为受控实验室环境设计。

Stars: 0 | Forks: 0

# Fulcrum C2 框架

Research framework for malware-loader generation, staged delivery, and command-and-control workflows

Bachelor's thesis implementation for cybersecurity research and controlled laboratory evaluation

License: Apache 2.0 Go 1.26 React 19 Docker Compose Academic research

## 概述 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、持久化状态和构建工作区。 ## 架构 ![Fulcrum 平台架构](https://static.pigsec.cn/wp-content/uploads/repos/cas/12/1264200780fb3efac2f71db7d856e515fe6fc7406a2b3d250a431eede1dc0d22.svg) 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)。
标签:Bash脚本, C2框架, DNS 反向解析, EVTX分析, Go, Gophish, IP 地址批量处理, React, Ruby工具, Syscalls, 安全, 安全学习资源, 恶意软件, 日志审计, 版权保护, 网络信息收集, 超时处理