kevoreilly/CAPEv2
GitHub: kevoreilly/CAPEv2
源自 Cuckoo 的高级恶意软件沙箱，专注自动脱壳与配置提取，支持反沙箱绕过和可编程调试器。
Stars: 3045 | Forks: 538
## CAPE：恶意软件配置与载荷提取 - [文档](https://capev2.readthedocs.io/en/latest/#)
### CAPE 是一个恶意软件沙箱。
沙箱用于在隔离环境中执行恶意文件，
同时监测其动态行为并收集取证数据。
CAPE 源自 Cuckoo v1，其在 Windows 平台上具备以下核心功能：
* 基于 API hooking 的行为监测
* 捕获执行期间创建、修改和删除的文件
* 以 PCAP 格式捕获网络流量
* 基于行为和网络特征的恶意软件分类
* 恶意软件执行期间截取的桌面截图
* 目标系统的完整内存转储
CAPE 在 Cuckoo 传统沙箱输出的基础上增加了以下关键功能：
* 自动动态恶意软件脱壳
* 基于脱壳后载荷的 YARA 特征恶意软件分类
* 静态和动态恶意软件配置提取
* 可通过 YARA 特征编程的自动调试器，支持：
* 自定义脱壳/配置提取器
* 动态反沙箱对抗措施
* 指令跟踪
* 交互式桌面
有一个供任何人使用的免费演示实例在线：
https://capesandbox.com - 如需激活账户，请联系 https://twitter.com/capesandbox
### 一些历史
Cuckoo Sandbox 最初是 2010 年 The Honeynet Project 中的一个
Google Summer of Code 项目。它最初由 Claudio Guarnieri 设计和开发，
第一个测试版于 2011 年发布。2014 年 1 月，Cuckoo v1.0 发布。
2015 年是关键的一年，Cuckoo 的历史发生了重大分歧。
原始 monitor 和 API hooking 方法的开发在 Cuckoo 主项目中
被停止。它被 Jurriaan Bremer 创建的[替代 monitor](https://github.com/cuckoosandbox/monitor)
取代，该 monitor 使用通过 Linux 工具链编译的基于 ``restructuredText`` 的特征格式。
大约在同一时间，Brad 'Spender' Spengler 创建了一个名为 [Cuckoo-modified](https://github.com/spender-sandbox/cuckoo-modified) 的分支，
继续开发原始 monitor，并进行了重大改进，包括 64 位支持，重要的是
引入了 Microsoft 的 Visual Studio 编译器。
同年，Context Information Security 的 Kevin O'Reilly 开始开发一个名为 CAPE 的动态命令行配置和载荷提取工具。
这个名字是 'Config And Payload Extraction'（配置与载荷提取）的首字母缩写，最初的
研究侧重于使用 Microsoft [Detours](https://github.com/microsoft/Detours) 库提供的 API hooks
来捕获脱壳后的恶意软件载荷和配置。然而，很明显
仅靠 API hooks 提供的能力和精度不足以从任意恶意软件中
提取载荷或配置。
出于这个原因，研究开始转向一种新颖的调试器概念，以允许恶意软件被
精确控制和监测，同时避免使用 Microsoft 调试接口，以便
尽可能隐蔽。该调试器被集成到基于 Detours 的概念验证命令行工具中，结合 API hooks
并产生了非常强大的功能。
当初步工作表明可以用 Cuckoo-modified 的 [API hooking 引擎](https://github.com/spender-sandbox/cuckoomon-modified) 替换 Microsoft Detours 时，
CAPE Sandbox 的想法诞生了。随着调试器、自动脱壳、基于 YARA 的分类和集成配置提取的加入，CAPE Sandbox 于 2016 年 9 月在 44con 上首次公开发布：[CAPE](https://github.com/ctxis/CAPE) 版本 1。
2018 年夏天，该项目有幸迎来了 Andriy 'doomedraven' Brukhovetskyy 开始的巨大贡献，他是长期的 Cuckoo
贡献者。2019 年，他开始了将 CAPE 移植到 Python 3 的艰巨任务，
同年 10 月 [CAPEv2](https://github.com/kevoreilly/CAPEv2) 发布。
CAPE 一直在不断开发和改进，以跟上恶意软件和操作系统能力的进步。
2021 年，增加了在引爆期间通过动态 YARA 扫描对 CAPE 调试器进行编程的能力，允许
为反沙箱技术创建动态绕过。Windows 10 成为默认操作系统，
其他重要的新增功能包括交互式桌面、AMSI (Anti-Malware Scan Interface) 载荷捕获、基于 Microsoft Nirvana 的 'syscall hooking' 以及基于调试器的直接/间接 syscall 对抗措施。
### 分类
在 CAPE 中，恶意软件可以通过三种机制进行分类：
* 对脱壳后载荷进行 YARA 扫描
* 对网络捕获进行 Suricata 扫描
* 扫描 API hook 输出的行为特征
### 配置提取
解析可以使用 CAPE 自己的框架完成，或者支持以下框架：[RATDecoders](https://github.com/kevthehermit/RATDecoders)、[DC3-MWCP](https://github.com/Defense-Cyber-Crime-Center/DC3-MWCP)、[MalDuck](https://github.com/CERT-Polska/malduck/tree/master/malduck/) 或 [MaCo](https://github.com/CybercentreCanada/maco)
#### 关于配置解析框架的特别说明：
* 由于恶意软件的性质，因为它在任何新版本发布时都会不断变化，某些东西可能会损坏！
* 我们建议使用 CAPE 的框架，它只是纯 Python，带有入口点 `def extract_config(data):`，将被 `cape_utils.py` 调用，零复杂度。
* 作为奖励，你可以在其他项目中重用你的提取器。
### 自动脱壳
CAPE 利用许多恶意软件的技术或行为来允许脱壳后的载荷捕获：
- 进程注入
- Shellcode 注入
- DLL 注入
- Process Hollowing
- Process Doppelganging
- 内存中可执行模块或 shellcode 的提取或解压
这些行为将导致注入、提取或解压的载荷被捕获以供进一步分析。此外，CAPE 会自动为每个进程创建进程转储，或者在 DLL 的情况下，转储内存中 DLL 的模块映像。这对于使用简单加壳工具加壳的样本很有用，其中模块映像转储通常已完全脱壳。
除了 CAPE 默认的“被动”脱壳机制外，还可以启用“主动”脱壳，它使用断点来检测对新分配或受保护的内存区域的写入，以便在执行前尽早捕获脱壳后的载荷。这可以通过 web 提交复选框启用，或者通过指定选项 `unpacker=2` 启用，默认情况下它是关闭的，因为它可能会影响引爆质量。
CAPE 可以通过 YARA 特征编程来脱壳特定的加壳工具。例如，UPX 类型的加壳工具非常常见，虽然 在 CAPE 中这会导致脱壳后的载荷被被动捕获，但默认捕获是在脱壳后的载荷开始执行之后进行的。因此，通过自定义 YARA 特征动态检测源自 UPX 的加壳工具，并在最后的加壳工具指令上设置断点，可以在载荷开始执行之前在其原始入口点 (OEP) 捕获它。
`dump-on-api` 选项允许在模块调用可以在 web 界面中指定的特定 API 函数时转储该模块（例如 `dump-on-api=DnsQuery_A`）。
### [调试器](https://capev2.readthedocs.io/en/latest/usage/monitor.html)
调试器允许 CAPE 继续进化，超越其最初的功能，现在包括动态反规避绕过。由于现代恶意软件通常试图逃避沙箱内的分析，例如通过对虚拟化使用时间陷阱或 API hook 检测，CAPE 允许开发动态对抗措施，结合 Yara 特征中的调试器动作，在规避型恶意软件引爆时检测它，并执行控制流操作以强制样本完全引爆或跳过规避动作。
通过提交选项 `bp0` 到 `bp3` 可以快速访问调试器，这些选项接受 RVA 或 VA 值来设置断点，届时将输出一条简短的指令跟踪，由 `count` 和 `depth` 选项控制（例如 `bp0=0x1234,depth=1,count=100`）。
要在模块入口点设置断点，使用 `ep` 代替地址（例如 `bp0=ep`）。或者，`break-on-return` 允许在 hooked API 的返回地址上设置断点（例如 `break-on-return=NtGetContextThread`）。可选的 `base-on-api` 参数允许通过 API 调用设置 RVA 断点的映像基址（例如 `base-on-api=NtReadFile,bp0=0x2345`）。
选项 `action0` - `action3` 允许在命中断点时执行操作，例如转储内存区域（例如 `action0=dumpebx`）或更改执行控制流（例如 `action1=skip`）。CAPE 的文档包含此类操作的更多示例。
### capemon
包含 CAPE monitor 代码的仓库是独立的。
### 更新摘要 [更新日志](https://github.com/kevoreilly/CAPEv2/blob/master/changelog.md)
### [社区贡献](https://github.com/CAPESandbox/community)
有一个由 CAPE 社区开发的包含数百个特征的特征社区仓库。所有新的社区功能都应推送到该仓库。如果开发人员有能力并且愿意维护它们，以后可以将它们移至核心。
请通过帮助为更多恶意软件家族创建新的特征、解析器或绕过来为这个项目做出贡献。目前有许多正在进行中，请密切关注。
非常感谢 @D00m3dR4v3n 独自将 CAPE 移植到 Python 3。
## 安装建议和脚本以获得最佳性能
* Python3
* agent.py 已使用 python (3.7.2|3.8) x86 进行测试。__你应该在 VM 内部使用 x86 python 版本！__
* 主机已使用 python3 版本 3.10、3.12 进行测试，但更新的版本也应该可以使用
* __只有 rooter 应该以 root 身份执行__，其余以 __cape__ 用户身份运行。以 root 身份运行会搞乱权限。
1. 熟悉[文档](https://capev2.readthedocs.io/en/latest/)并__务必阅读__ `conf` 文件夹内的所有配置文件！
2. 为了获得最佳兼容性，我们强烈建议安装在 [Ubuntu 24.04 LTS](https://ubuntu.com/#download) 上，并使用 Windows 10 21H2 作为目标。
3. `kvm-qemu.sh` 和 `cape2.sh` __应该__从 `tmux` 会话执行，以防止 ``ssh`` 连接中断时出现任何操作系统问题。
4. 推荐使用 [KVM](https://github.com/kevoreilly/CAPEv2/blob/master/installer/kvm-qemu.sh) 作为虚拟机管理程序。
* 将 `` 替换为真实模式。
* 你需要替换里面的所有 ``！
* 阅读它！你必须理解它的作用！它在脚本头部有配置。
* `sudo ./kvm-qemu.sh all 2>&1 | tee kvm-qemu.log`
4. 要安装 CAPE 本身，使用 [cape2.sh](https://github.com/kevoreilly/CAPEv2/blob/master/installer/cape2.sh) 并进行所有优化
* 阅读并理解它的作用！这不是解决你所有问题的万能药！它在脚本头部有配置。
* `sudo ./cape2.sh base 2>&1 | tee cape.log`
5. 安装完所有内容后，将两个安装日志保存为黄金备份！
6. 通过修改 `conf` 文件夹内的配置文件来配置 CAPE。
7. 重启所有 CAPE 服务以获取配置更改并正确运行 CAPE！
* CAPE 服务
* cape.service
* cape-processor.service
* cape-web.service
* cape-rooter.service
* 要重启任何服务，请使用 `systemctl restart `
* 要查看服务日志，请使用 `journalctl -u `
* 要调试任何问题，停止相关服务并手动运行该服务运行的命令以查看更多日志。检查 `-h` 获取帮助菜单。在调试模式 (`-d`) 下运行服务也有帮助。
8.启并享受！
* 所有脚本都包含__帮助__ `-h`，但请检查脚本以__理解__它们在做什么。
### 如何使用 virt-manager 创建虚拟机，请参阅文档进行配置
* [分步指南](https://www.doomedraven.com/2020/04/how-to-create-virtual-machine-with-virt.html)
## 虚拟机核心依赖
* [choco.bat](https://github.com/kevoreilly/CAPEv2/blob/master/installer/choco.bat)
## 如何更新
* CAPE：`git pull`
* community：`python3 utils/community.py -waf`，请先查看 `-h` 以确保你理解
## 如何在有大量无法公开的自定义小修改的情况下进行升级？
#### 使用 rebase
```
git add --all
git commit -m '[STASH]'
git pull --rebase origin master
# 如有需要，修复冲突 (rebase)
git reset HEAD~1
```
#### 使用 merge
```
# 确保 kevoreilly repo 已作为 remote 添加（只需执行一次）
git remote add kevoreilly https://github.com/kevoreilly/CAPEv2.git
# 确保您的所有更改已提交到您将要合并的 branch
git commit -a -m ''
# 从 kevoreilly repo fetch 更改
git fetch kevoreilly
# 将 kevoreilly master branch merge 到您当前的 branch
git merge kevoreilly/master
# 如有需要，修复 merge 冲突
# 根据需要 push 到您的 repo
git push
```
### 如何引用这项工作
如果你在工作中使用 CAPEv2，请按照 "Cite this repository" GitHub 菜单中的说明进行引用。
### 关于第三方依赖项的特别说明：
* 它们正变得令人头疼，特别是那些使用 `pefile` 的依赖，因为每个都固定了它们想要的版本。
* 我们的建议是克隆/分叉它们，删除 `pefile` 依赖，因为你已经安装了它。问题解决，不再痛苦。
### 文档
* [ReadTheDocs](https://capev2.readthedocs.io/en/latest/#)
* [DeepWiki](https://deepwiki.com/kevoreilly/CAPEv2/1-overview) - AI 生成，有些可能是错的，但通常相当准确。
标签：API Hooking, Beacon Object File, CAPE, Conpot, Cuckoo, DAST, DNS 反向解析, DNS枚举, IP 地址批量处理, Metaprompt, PCAP, SecList, Windows安全, YARA, 云安全监控, 云资产可视化, 云资产清单, 内存取证, 威胁情报, 开发者工具, 恶意软件分析, 沙箱, 沙箱逃逸检测, 流量嗅探, 网络信息收集, 网络安全审计, 网络安全工具, 自动化分析, 自动化解包, 行为检测, 跨站脚本, 身份验证强制, 载荷提取, 逆向工程, 配置提取, 静态分析