VisionSecurityLabs/binary-analysis-toolkit
GitHub: VisionSecurityLabs/binary-analysis-toolkit
一款面向 CERT/SOC 分析师的自动化二进制静态分析命令行工具,整合多层检测引擎并输出结构化的威胁判定和 IOC 报告。
Stars: 0 | Forks: 0
# Binary Analysis Toolkit (BAT)
一款用于自动化静态分析二进制文件的命令行工具。目前支持 Windows PE (Portable Executable) 二进制文件,其架构已为 ELF 和 Mach-O 格式做好准备。该工具在不运行可执行文件的情况下对其进行检查,识别恶意行为模式,提取可操作的失陷指标,并对威胁进行分类——为 CERT 和 SOC 分析师提供快速、结构化的分类调查起点。
使用 Python 编写。依赖项通过 `uv sync` 自动安装。外部工具(Radare2、Ghidra、ilspycmd)为可选项,在安装后可启用反编译功能。
## 免责声明
本工具包仅供防御安全、事件响应和教育目的使用。旨在帮助分析师检查经授权调查的系统内存转储。
- 请勿使用本工具分析您不拥有或未获得明确授权检查的系统或数据。
- 作者对误用或因使用本软件造成的任何损害不承担任何责任。
- 检测攻击性工具(如 Cobalt Strike、Sliver)旨在帮助防御者——而非助长攻击。
- 本项目通过 AI 辅助编码开发,旨在快速编排多个分析引擎。虽然功能完备且经过测试,但尚未经过正式的安全审计——在集成到生产工作流之前,请自行判断。
使用本工具包即表示您同意遵守您所在司法管辖区内的所有适用法律法规。
## 目录
- [免责声明](#disclaimer)
- [快速开始](#quick-start)
- [为什么选择此工具](#why-this-tool)
- [功能概览](#features-at-a-glance)
- [恶意软件家族覆盖范围](#malware-family-coverage)
- [安装说明](#installation)
- [使用示例](#usage-examples)
- [CLI 参考](#cli-reference)
- [配置文件](#configuration-file)
- [解读输出结果](#understanding-the-output)
- [报告](#reports)
- [架构](#architecture)
- [贡献指南](#contributing)
- [许可证](#license)
## 快速开始
```
# 安装
git clone && cd binary-analysis-toolkit
uv sync
# 分析二进制文件(仅基础分析)
uv run binanalysis suspicious.exe
# 使用 YARA 社区规则(首次使用时自动下载)
uv run binanalysis suspicious.exe --yara
# 使用 capa 能力检测(首次使用时自动下载规则)
uv run binanalysis suspicious.exe --capa
# 使用 LLM 驱动的分析报告(远程主机上的 Ollama)
uv run binanalysis suspicious.exe --llm-report --yara --llm-url http://ollama:11434 --llm-model qwen3.5 --llm-timeout 600 --debug
# 完整分析:反编译 + 所有集成
uv run binanalysis suspicious.exe --decompile ghidra --yara --capa --llm-report --llm-url http://ollama:11434 --llm-model qwen3.5 --llm-timeout 600 --debug
```
该工具会将结构化的分析结果打印到终端,并给出最终的 **MALICIOUS(恶意) / LIKELY MALICIOUS(可能恶意) / SUSPICIOUS(可疑) / No strong indicators(无强烈指标)** 判定。JSON 和 HTML 报告会自动保存为 `_analysis.json` 和 `_analysis.html`,与二进制文件位于同一目录。添加 `--llm-report` 可通过本地 LLM 生成自然语言调查报告。使用 `--yara` 和 `--capa` 标志可启用可选的签名和行为能力检测(首次使用时会自动下载规则)。
## 为什么选择此工具
当可疑可执行文件出现在分析师案头时,第一个问题总是:**这东西是做什么的?** 动态分析(在沙箱中运行)需要时间设置,并且可能会遗漏仅在特定条件下触发的行为。静态分析——在不执行文件的情况下检查它——可以在几秒钟内得出答案。
此工具自动化了静态分析中繁琐的部分:计算用于查找的哈希值、检查加壳情况、编目可疑的 API 导入、提取嵌入的 URL 和文件路径、将行为模式与已知攻击技术匹配,并生成结构化的判定。输出设计为可供非逆向工程专家的分析师从头到尾阅读。
## 功能概览
| 功能 | 作用 | 重要原因 |
| ------- | ----------- | -------------- |
| **哈希计算** | MD5, SHA1, SHA256 | 在 VirusTotal 上查找样本,跨案例追踪 |
| **导入哈希** | 基于导入函数的指纹 | 使用相同工具/构建器构建的样本共享同一个 imphash——有助于聚类相关样本 |
| **Rich header 分析** | 识别编译器工具链和构建环境 | 异常的编译器(例如从 Linux 交叉编译的 MinGW)在定制恶意软件中很常见 |
| **PE header 分析** | 时间戳、架构、子系统、安全特性 (ASLR, DEP) | 伪造的时间戳或禁用的安全功能是危险信号 |
| **节区熵值分析** | 列出每个 PE 节区并测量其随机性(熵) | 熵值高于 7.0 强烈暗示该节区被加壳或加密——一种常见的规避技术 |
| **导入表分析** | 将导入的 Windows API 映射到 17 个可疑类别(约 138 个 API) | 按攻击技术(注入、凭据窃取、规避等)对导入进行分组,以便您一目了然地了解意图 |
| **导出表分析** | 列出导出函数 | 与 DLL 相关;异常的导出可能揭示插件或注入能力 |
| **资源分析** | 枚举嵌入的资源(图标、清单、数据块) | 恶意软件经常在资源中隐藏 payload 或配置数据 |
| **版本信息提取** | 读取声明的产品名称、公司、描述 | 伪装——一个声称是“Microsoft Excel”但导入注入 API 的二进制文件是可疑的 |
| **TLS 回调检测** | 检查线程本地存储回调 | TLS 回调在程序主入口点之前执行,这是一种用于尽早运行反分析代码的技术 |
| **Overlay / 附加数据** | 检测 PE 结构后附加的数据 | 嵌入的 PE 文件、归档文件或隐藏在 overlay 中的加密数据块 |
| **编译器和加壳检测** | 识别 MSVC, MinGW, Go, Borland;检测开发语言线索 | 有助于归因样本并识别交叉编译 |
| **.NET 分析** | 元数据提取(类、方法、程序集引用),通过 `ilspycmd` 进行 IL 反编译 | 可以深度检查 .NET 二进制文件;标记混淆的类名和可疑的方法名 |
| **字符串提取** | ASCII 和宽字符(UTF-16)字符串与 105 个威胁类别中的 115 个正则表达式模式匹配 | 显示 URL、文件路径、注册表键、凭据、勒索信、矿池地址等 |
| **动态 API 解析检测** | 查找通过 `GetProcAddress` 在运行时解析的 API 名称 | 通过动态解析隐藏导入的恶意软件——这能捕捉到导入表遗漏的内容 |
| **行为规则** | 105 条规则(98 条通用 + 7 条特定样本)映射到 MITRE ATT&CK 技术 | 将导入分析、字符串发现和节区特征结合成高级判定,如“进程注入”或“勒索软件加密循环” |
| **IOC 提取** | 9 个提取器,用于 URL、域名、凭据/令牌、User-Agent、文件路径、注册表键、OAuth 端点、UUID 和环境变量 | 生成可操作的指标列表,可输入到您的 SIEM、防火墙或威胁搜寻查询中 |
| **YARA 签名扫描** | 捆绑规则 + 自定义规则目录 | 基于签名的检测,补充行为规则 |
| **capa 集成** | FLARE capa 能力检测与 ATT&CK 映射 | 识别二进制文件*能做什么*(例如,“发送 HTTP 请求”,“加密数据”),独立于签名 |
| **UPX 自动解包** | 检测 UPX 加壳二进制文件并在分析前解包 | 加壳二进制文件隐藏其字符串和导入——解包揭示真实 payload,供所有下游分析阶段使用 |
| **反编译** | Radare2 (`r2pipe`) 伪代码或具有智能过滤的 Ghidra headless | Ghidra 输出会自动评分和过滤,仅显示包含可疑逻辑的函数,按攻击类别组织 |
| **LLM 分析师报告** | 将分析结果发送到本地 LLM (Ollama) 进行自然语言解读 | 生成结构化的调查报告,包含执行摘要、MITRE 映射和建议行动 |
| **威胁分类** | 结合所有分析层的最终判定 | 清晰的 MALICIOUS / LIKELY MALICIOUS / SUSPICIOUS / No strong indicators 评估 |
## 恶意软件家族覆盖范围
行为规则和字符串模式旨在检测广泛恶意软件家族的指标。该工具不识别具体的家族名称(例如,“这是 Emotet”),而是检测与每个类别相关的*技术和工件*:
### 信息窃取器
浏览器凭据数据库(Login Data、cookies、Web Data),浏览器主密钥提取,加密货币钱包(Electrum、Exodus、MetaMask、Atomic、Coinomi、Phantom 等),Discord 和 Telegram 会话数据,FTP/SSH 客户端(FileZilla、WinSCP、PuTTY),邮件客户端(Outlook、Thunderbird),VPN 凭据(NordVPN、OpenVPN、ProtonVPN),密码管理器(KeePass、LastPass、Bitwarden、1Password、Dashlane),以及游戏平台(Steam、Minecraft)。
### 勒索软件
卷影副本删除(`vssadmin`、`wmic`),Windows 恢复禁用(`bcdedit`),备份目录删除(`wbadmin`),勒索信文本模式,勒索软件文件扩展名(`.encrypted`、`.locked`、`.crypt`),加密货币支付地址(Bitcoin、Ethereum、Monero),批量文件加密循环(文件枚举 + crypto API),安全模式启动操纵,以及驱动器枚举。
### RAT 和后门
反向 Shell 构建(cmd.exe + socket/pipe),网络摄像头捕获 API,录音,键盘记录(`GetAsyncKeyState`、键盘钩子),屏幕截图捕获(GDI `BitBlt`),剪贴板监控,远程桌面/VNC 引用,远程输入模拟(`SendInput`、`keybd_event`),以及命名管道 C2 通道。
### 加载器和投放器
嵌入的 PE 文件(字符串或 overlay 中的 MZ header),反射 DLL 注入模式,进程镂空(`NtUnmapViewOfSection` + 挂起进程创建),shellcode 执行(VirtualAlloc + VirtualProtect),以及释放到 Temp/AppData 目录。
### Rootkit
内核驱动加载(`NtLoadDriver`),SSDT(系统服务描述符表)挂钩,直接物理内存访问(`\\.\PhysicalMemory`),物理驱动器访问,以及驱动程序路径/注册表引用。
### 蠕虫
Autorun.inf 创建,网络共享传播(ADMIN$、IPC$、`net share`),USB/可移动介质传播(`GetDriveType`),网络服务器枚举,UNC 路径访问,以及邮件蠕虫指标(SMTP 命令)。
### 挖矿程序
Stratum 协议 URL(`stratum+tcp://`),挖矿软件名称(xmrig、cpuminer、cgminer、ethminer),矿池域名(minexmr、nanopool、2miners、f2pool、hashvault),挖矿算法(CryptoNight、RandomX、Ethash),Monero 钱包地址,以及矿工 CLI 参数。
### 银行木马
Web 注入配置(set_url、data_before、data_inject),表单抓取,用于流量拦截的 HTTP 请求挂钩,银行/金融机构名称引用,以及用于中间人攻击的证书安装。
### 擦除器
通过直接物理驱动器访问覆盖 MBR(主引导记录),批量文件删除命令(`del /s /f`、`Remove-Item -Recurse`),安全覆盖工具(cipher /w、SDelete),驱动器格式化,以及强制系统关机。
## 安装说明
### 基本安装
```
# 克隆仓库
git clone
cd binary-analysis-toolkit
# 使用 uv 安装(推荐)
uv sync
```
所有 Python 依赖项都包含在基本安装中——`uv sync` 会安装所需的一切。无需额外标志。
### 外部工具
这些是在 Python 之外安装的独立程序:
| 工具 | 用途 | 安装方式 |
| ---- | ------- | ------- |
| **UPX** | 在分析前自动解包 UPX 加壳二进制文件 | `brew install upx` 或 [upx.github.io](https://upx.github.io) |
| **Radare2** | 原生函数的伪代码反编译 | `brew install radare2` 或 [radare.org](https://rada.re) |
| **Ghidra** | 具有智能函数过滤的高级反编译 | `brew install ghidra` 或 [ghidra-sre.org](https://ghidra-sre.org) |
| **ilspycmd** | .NET IL 反编译为 C# 源代码 | `dotnet tool install -g ilspycmd` |
### capa 和 YARA 规则
规则在首次使用时自动下载。当您运行时:
- `--capa` — capa 规则自动下载到 `~/.local/share/binanalysis/capa-rules`
- `--yara` — 6 个社区 YARA 规则仓库自动克隆到 `~/.local/share/binanalysis/yara-rules`
稍后更新规则,请使用:
```
# 更新 capa 规则
uv run binanalysis file.exe --update-capa
# 更新社区 YARA 规则
uv run binanalysis file.exe --update-yara
```
## 使用示例
```
# 基础分析 — 将结果打印到终端,自动保存 JSON + HTML 报告
uv run binanalysis suspicious.exe
# 启用 YARA 签名扫描
uv run binanalysis suspicious.exe --yara
# 启用 capa 能力检测
uv run binanalysis suspicious.exe --capa
# YARA 和 capa
uv run binanalysis suspicious.exe --yara --capa
# 使用 Radare2 反编译
uv run binanalysis suspicious.exe --decompile r2
# 使用 Ghidra 反编译(仅筛选可疑函数)
uv run binanalysis suspicious.exe --decompile ghidra
# 使用两种后端反编译
uv run binanalysis suspicious.exe --decompile both
# 除社区规则外使用自定义 YARA 规则
uv run binanalysis suspicious.exe --yara --yara-rules /path/to/custom-rules
# 使用特定的 capa 规则目录
uv run binanalysis suspicious.exe --capa --capa-rules /opt/capa-rules
# 扫描前刷新社区 YARA 规则仓库
uv run binanalysis suspicious.exe --update-yara --yara
# 扫描前刷新 capa 规则
uv run binanalysis suspicious.exe --update-capa --capa
```
## CLI 参考
```
binanalysis [-h] [--decompile {r2,ghidra,both}]
[--capa] [--yara] [--update-capa] [--update-yara]
[--capa-rules CAPA_RULES] [--yara-rules YARA_RULES [YARA_RULES ...]]
[--llm-report] [--llm-url URL] [--llm-model MODEL] [--llm-timeout SECONDS]
[--config CONFIG] [--debug]
file
```
| 参数 | 描述 |
| -------- | ----------- |
| `file` | 要分析的二进制文件路径(必需,位置参数) |
| `--decompile {r2,ghidra,both}` | 启用反编译。`r2` 使用 Radare2 生成快速伪代码。ghidra` 使用 Ghidra headless 并进行智能过滤。`both` 同时运行两者。 |
| `--capa` | 启用 capa 能力检测(首次使用时自动下载规则,约 100MB) |
| `--yara` | 启用 YARA 签名扫描(首次使用时自动下载 6 个社区规则仓库) |
| `--update-capa` | 分析前下载/更新 capa 规则 |
| `--update-yara` | 分析前下载/更新社区 YARA 规则仓库 |
| `--capa-rules` | capa 规则目录的路径(覆盖配置文件和默认值) |
| `--yara-rules` | 一个或多个额外的 YARA 规则目录(添加到社区规则中) |
| `--llm-report` | 生成 LLM 驱动的分析报告(需要 Ollama 或兼容 API) |
| `--llm-url` | LLM API 基础 URL(默认:`http://localhost:11434`) |
| `--llm-model` | LLM 模型名称(默认:`llama3`) |
| `--llm-timeout` | LLM 请求超时时间(秒)(默认:300) |
| `--config` | YAML 配置文件的路径(见下文) |
| `--debug` | 将 LLM 提示词写入 `_llm_prompt.md` 以供检查。可独立工作(无需 `--llm-report`)——用于在不运行 Ollama 的情况下验证提示词内容 |
## 配置文件
对于重复使用的设置,可以创建 YAML 配置文件,而不是每次都传递标志。工具按以下顺序查找配置:
1. 通过 `--config` 传递的路径
2. 当前目录中的 `binanalysis.yaml`
3. `~/.config/binanalysis/config.yaml`
首次运行时,会在 `~/.config/binanalysis/config.yaml` 自动创建默认配置文件。配置包括:
```
paths:
# Where capa rules are stored (auto-downloaded here if missing)
capa_rules: ~/.local/share/binanalysis/capa-rules
# Where community YARA rules are stored (fetched via --update-yara)
yara_community_dir: ~/.local/share/binanalysis/yara-rules
# Additional YARA rule directories scanned on every run
# yara_extra_dirs:
# - /path/to/rules
# Path to Ghidra headless analyzer (auto-discovered if empty)
# ghidra_headless: ""
# 由 --update-capa 克隆/更新的 capa 规则仓库。
capa_repos:
capa-rules:
repo: https://github.com/mandiant/capa-rules.git
description: "Official capa rules (Mandiant/Google)"
# 由 --update-yara 克隆/更新的社区 YARA 仓库。
# subdir:仓库中包含 .yar 文件的子目录("." = 仓库根目录)。
# 注释掉或删除任何不需要的仓库。
yara_repos:
signature-base:
repo: https://github.com/Neo23x0/signature-base.git
subdir: yara
description: "Cobalt Strike, Go implants, webshells (Neo23x0)"
yara-rules:
repo: https://github.com/Yara-Rules/rules.git
subdir: "."
description: "Broad malware families, packers, exploits"
gcti:
repo: https://github.com/chronicle/GCTI.git
subdir: YARA
description: "APT-focused, high quality (Google)"
reversinglabs:
repo: https://github.com/reversinglabs/reversinglabs-yara-rules.git
subdir: yara
description: "Large malware family signature set"
eset:
repo: https://github.com/eset/malware-ioc.git
subdir: "."
description: "ESET research publications"
elastic:
repo: https://github.com/elastic/protections-artifacts.git
subdir: yara/rules
description: "Elastic threat research"
features:
capa: false # opt-in via --capa flag (slow, downloads ~100MB rules on first use)
yara: false # opt-in via --yara flag (auto-downloads community rules on first use)
# decompile: "" # "", "r2", "ghidra", or "both"
llm:
url: http://ollama:11434 # point to your Ollama instance (remote or localhost)
model: qwen3.5
timeout: 600
report: false
# debug: false # write _llm_prompt.md after every analysis (no Ollama needed)
```
CLI 标志始终覆盖配置文件设置。例如,即使配置文件设置 `capa: false`,`--capa` 也会启用 capa。您可以在 `yara_repos` 部分自定义仓库 URL(例如,用于镜像或私有分叉)。
## 解读输出结果
这是本文档最重要的部分。工具产生大量信息;以下是如何阅读它以及如何处理它。
### 判定系统
每次分析的最后一部分是一个**分类判定**,将行为规则、capa 发现和 YARA 匹配结合为单一评估:
| 判定 | 含义 | 应对措施 |
| ------- | ------------ | ---------- |
| **MALICIOUS** | 检测到关键指标(进程注入、凭据窃取、勒索软件行为等) | 立即升级。隔离文件。如果在生产系统上发现,开始事件响应。提取 IOC 进行封锁。 |
| **LIKELY MALICIOUS** | 存在多个高严重性指标 | 进一步调查。在 VirusTotal 上交叉引用哈希。检查系统上是否预期有该二进制文件。考虑在沙箱中进行动态分析。 |
| **SUSPICIOUS** | 检测到中等严重性指标 | 结合上下文审查。某些合法软件会触发中等严重性规则(例如,安装程序可能会枚举文件并修改注册表)。考虑文件来源及其行为是否符合其声明的目的。 |
| **No strong indicators** | 没有高严重性的行为规则触发 | 并不意味着文件是安全的。高度加壳或混淆的恶意软件可能会规避静态分析。考虑在沙箱中运行样本进行动态分析。 |
判定是故意保守的。加壳二进制文件上的“No strong indicators”结果本身就是一种发现——这意味着恶意软件可能正在使用需要动态分析才能攻破的规避技术。
### 严重性级别
每个行为规则都有一个严重性级别,反映其指示恶意意图的强烈程度:
| 严重性 | 含义 | 示例 |
| -------- | ------- | -------- |
| **Critical** | 强烈、直接的恶意软件指标。在合法软件中很少见。 | 进程镂空、反射 DLL 注入、凭据数据库窃取、勒索信文本、卷影副本删除、MBR 覆盖 |
| **High** | 值得调查的重大可疑行为。 | 通过 NT API 的反调试、直接系统调用(EDR 绕过)、PowerShell 执行、URL 文件下载、浏览器配置文件路径访问 |
| **Medium** | 潜在可疑,但也见于合法软件。 | Crypto API 使用、文件枚举、COM 对象创建、计划任务字符串、动态 API 解析 |
| **Low** | 信息性。值得注意但本身并不令人担忧。 | 计时函数、base64 编码、标准加密 API |
### 关键输出部分说明
#### 哈希值
```
MD5 d41d8cd98f00b204e9800998ecf8427e
SHA1 da39a3ee5e6b4b0d3255bfef95601890afd80709
SHA256 e3b0c44298fc1c149afbf4c8996fb924...
```
**应对措施:** 复制 SHA256 哈希并在 [VirusTotal](https://www.virustotal.com) 上搜索。如果样本之前被见过,您将立即获得上下文。使用哈希在案例管理系统中追踪样本。
#### 导入哈希
根据导入的函数名称及其顺序计算的哈希。具有相同 imphash 的两个文件几乎可以确定共享相同的代码库,或者是使用相同的恶意软件构建器工具包构建的。
**应对措施:** 在 VirusTotal 或您的威胁情报平台中搜索 imphash 以查找相关样本。
#### Rich Header
Rich header 由 Microsoft Visual Studio 链接器嵌入,记录构建二进制文件所使用的编译器版本和工具。工具将其解码为人类可读的产品名称和构建号。
**应对措施:** 检查异常。声称是现代应用程序但使用古老工具链编译的二进制文件是可疑的。全为零或只有一个条目的 Rich header 可能已被伪造。MinGW(GCC 交叉编译器)经常用于在 Linux 上编译 Windows 恶意软件。
#### 节区
```
Name VirtAddr VirtSize RawSize Entropy Flags
.text 0x1000 0x5000 0x5000 6.40 EXEC|READ
.data 0x6000 0x1000 0x1000 7.85 READ|WRITE
```
**应对措施:**
- **熵值高于 7.0**(标记为红色):该节区极有可能被加壳或加密。这是一个强烈的指标,表明二进制文件试图隐藏其真实内容。
- **熵值在 6.5 到 7.0 之间**(标记为黄色):升高但不确定。可能是压缩数据或资源。
- **同时具有 WRITE + EXECUTE 标志**:既可写又可执行的节区是可疑的。合法软件很少需要这个;恶意软件使用它在同一内存区域中写入然后运行 shellcode。
- **原始大小为零但虚拟大小非零**:节区的内容在运行时生成,常见于加壳二进制文件。
#### 导入
导入的 Windows API 函数按攻击技术类别分组。出现的类别越多,二进制文件拥有的功能就越多。
**应对措施:** 关注“Suspicious API Usage”子部分。如果您看到来自 `injection`、`credential_theft` 或 `process_hollowing` 等类别的导入,该二进制文件几乎可以确定具有攻击能力。网络 API(`WinHTTP`、`WinINet`、sockets)表明具有通信能力。文件枚举 + crypto API 结合是强烈的勒索软件信号。
#### 字符串
字符串分析部分显示从二进制文件原始数据中提取的模式,按类别组织(URL、注册表键、文件路径、凭据等)。
**应对措施:** 这是您找到可操作 IOC 的地方。URL 和域名可以在防火墙上封锁。注册表键揭示持久化机制。文件路径显示恶意软件的目标。嵌入的凭据或令牌(GitHub PAT、Bearer token)是关键发现,应立即撤销。
#### 行为规则
每个触发的规则包括严重性级别、MITRE ATT&CK 类别和关于检测到内容的简明英语描述。规则结合多个信号——例如,“进程注入”规则仅在同时导入 `VirtualAllocEx`、`WriteProcessMemory` *和* `CreateRemoteThread` 时触发。
**应对措施:** 阅读描述。它们的编写是为了告诉您*二进制文件能做什么*,而不仅仅是它导入了什么 API。使用类别名称(injection、credential_theft、impact、lateral_movement 等)将发现映射到您的事件响应剧本。
#### IOC (失陷指标)
去重后的提取指标列表:URL、域名、嵌入凭据、User-Agent 字符串、Windows 文件路径、注册表键、OAuth 端点、UUID 和环境变量。
**应对措施:** 将这些输入您的 SIEM 或 SOAR 平台。在代理/防火墙处封锁 URL 和域名。在终端群集中搜索注册表键和文件路径以查找其他受损系统。撤销任何暴露的令牌或凭据。
#### Capa
如果启用 capa,此部分显示映射到 MITRE ATT&CK 技术的检测能力。Capa 的工作方式与行为规则不同——它分析二进制文件的实际代码模式,而不仅仅是导入和字符串。
**应对措施:** 关注攻击性命名空间的能力:`anti-analysis`、`collection`、`impact`、`persistence`、`exploitation` 和 `communication`。单个二进制文件中有五个或更多攻击性能力是强烈的恶意信号。
#### YARA
来自 YARA 规则的基于签名的匹配。结果包括规则名称、标签和源文件。
**应对措施:** `packer.yar` 或 `antidebug_antivm.yar` 上的 YARA 匹配会输入到判定计算中。来自自定义规则集的匹配可能识别特定的恶意软件家族或活动。
#### 反编译(启用时)
如果您使用 `--decompile ghidra`,工具不会简单地转储数千个反编译函数。相反,它根据分析过程中已经发现的可疑指标对每个函数进行评分,然后仅过滤和分类有趣的函数。函数按攻击类别分组(例如,“浏览器数据窃取”、“网络/C2”、“进程注入”),并带有相关性分数。
**应对措施:** 关注得分最高的函数。`_ghidra_analysis.c` 输出文件按类别组织,便于找到负责行为规则标记的特定行为的代码。
## 报告
每次分析都会自动将完整的结构化报告保存为 `_analysis.json`,并将 HTML 报告保存为 `_analysis.html`,位于被分析二进制文件的同一目录中。
JSON 报告包含机器可读形式的每个分析结果:哈希、PE header、节区、导入、导出、资源、版本信息、TLS 数据、overlay 分析、编译器检测、字符串发现、动态 API、行为规则匹配、IOC、capa 能力和 YARA 匹配。
### 示例:使用 jq 提取 IOC
```
# 提取所有 URL
jq '.iocs.urls[]' sample_analysis.json
# 提取所有触发的严重性级别关键的行为规则
jq '.behavior.behaviors[] | select(.severity == "critical")' sample_analysis.json
# 获取裁决相关统计信息
jq '{hashes: .hashes, behavior_count: (.behavior.behaviors | length), capa_count: (.capa | length)}' sample_analysis.json
```
JSON 格式适用于摄入到 SIEM 平台(Splunk、Elastic)、SOAR 剧本或自定义分析流水线。
## 架构
分析器使用可插拔的格式分发架构。二进制格式检测自动路由到适当的 `FormatHandler`:
```
Binary File
↓
Format Detection (PE / ELF / Mach-O architecture)
↓
Format-Specific Handler (PE today, ELF/Mach-O ready)
↓
Shared Pipeline (all formats)
```
对于 PE 二进制文件,分析流水线为:
```
1. Hash computation (MD5, SHA1, SHA256)
2. Import hash (imphash)
3. PE header analysis (timestamps, architecture, security features)
4. Rich header analysis (compiler toolchain)
5. Section analysis (entropy, permissions)
6. Import table analysis (suspicious API categorization)
7. Export table analysis
8. Resource analysis
9. Version info extraction
10. TLS callback detection
11. Overlay / appended data analysis
12. Compiler / packer detection
13. .NET analysis (if applicable: metadata + IL decompilation)
14. String extraction and pattern matching (115+ patterns)
+-- Dynamic API resolution detection
+-- Generic behavioral rules (98 rules)
+-- PE-specific specimen rules (7 rules)
+-- IOC extraction (9 extractors)
+-- capa capability detection (optional, --capa flag)
+-- YARA signature scanning (optional, --yara flag)
+-- Decompilation with intelligent filtering (optional)
15. Threat classification and verdict
```
步骤 1-13 收集特定格式的数据。步骤 14 构建一个 `AnalysisContext`,将所有发现聚合到单个对象中,然后将其传递给行为规则引擎、IOC 提取器和(如果启用)Ghidra 反编译器的智能过滤器。过滤器使用上下文动态派生搜索关键字,因此它能够适应任何被分析的恶意软件家族,而无需任何硬编码的家族特定逻辑。
## 贡献指南
### 添加行为规则
行为规则分为两类:
**通用规则**(所有二进制类型)——位于 `binanalysis/formats/pe/rules/generic.py`:
```
Rule("my_new_rule", "category", "high",
"Description of what this detects",
lambda ctx: ctx.has_import("SomeAPI") and ctx.has_finding("some_string_category"))
```
**特定样本规则**(PE 家族检测)——位于 `binanalysis/formats/pe/rules/specimen.py`,用于 PE 特定的恶意软件家族检测。
`AnalysisContext` 提供这些便捷方法:
- `ctx.has_import("APIName")` -- 检查是否有任何导入函数匹配
- `ctx.has_all_imports("API1", "API2")` -- 检查是否导入了所有列出的 API
- `ctx.has_string_containing("substring")` -- 搜索所有提取的字符串
- `ctx.has_finding("category")` -- 检查字符串模式匹配器是否发现此类别
- `ctx.any_section(predicate)` -- 对所有 PE 节区测试条件
### 添加字符串模式
字符串模式在 `binanalysis/config.py` 中定义为 `StringPattern` 数据类实例。每个模式包括:
```
StringPattern(pattern, category, score, requires=[...])
```
- `pattern`:要匹配的正则表达式模式
- `category`:发现类别的名称
- `score`:用于严重性评分的整数权重
- `requires`:必须存在才能激活此规则的类别可选列表
行为规则通过 `ctx.has_finding("category_name")` 引用类别。
### 添加 YARA 规则
将 `.yar` 或 `.yara` 文件放在 `binanalysis/yara_rules/` 中作为捆绑规则,或配置自定义目录:
- 通过 `--yara-rules` CLI 标志
- 通过 `~/.config/binanalysis/config.yaml` 中的 `yara_extra_dirs`
- 使用 `--yara` 时,社区规则会自动下载到 `~/.local/share/binanalysis/yara-rules`
### 添加 IOC 提取器
IOC 提取器在 `binanalysis/ioc.py` 中定义为 `IOCExtractor` 实例。每个提取器从分析上下文中提取特定指标类型:
```
IOCExtractor("key", "Display Name", "severity", lambda ctx: [...])
```
添加新的二进制格式
框架已为 ELF 和 Mach-O 支持做好准备。添加新格式:
1. 创建 `binanalysis/formats//` 目录
2. 实现带有 `analyze(filepath) -> dict` 的 `FormatHandler`
3. 注册它:`register_format(FormatHandler(...))`
4. 在 `binanalysis/formats//rules/` 中添加特定格式的规则
## 许可证
*许可证信息待补充。*
标签:AI风险缓解, Amass, CERT, DNS 反向解析, ELF, Ghidra, IOC提取, IP 地址批量处理, Mach-O, PE文件分析, Python, Radare2, SOC分析工具, TLS指纹, URL提取, 二进制分析, 云安全监控, 云安全运维, 云资产清单, 反编译, 可执行文件分析, 妥协指标, 威胁分类, 威胁情报, 库, 应急响应, 开发者工具, 数据包嗅探, 无后门, 漏洞分析, 网络信息收集, 网络安全, 网络安全审计, 自动化分析, 跨站脚本, 路径探测, 逆向工具, 逆向工程, 隐私保护, 静态分析