cybercop-arch/Malware-Analysis-with-XAI

# XAIGuard — 恶意软件分析 XAI 平台 **本项目运行在 localhost 上。目前尚未部署——模型文件（700MB+）不包含在此代码库中。本 README 记录了该系统的架构、相关说明和运行结果。** ## 演示截图 ### 仪表盘 !([仪表盘](https://raw.githubusercontent.com/cybercop-arch/Malware-Analysis-with-XAI/main/screenshots/Screenshot%202026-05-07%20105322.png)) *实时 KPI 卡片：总扫描次数、恶意、可疑、干净、已隔离、MTTD、MTTR、模型准确率。所有数值均根据扫描历史实时计算。* ### 文件扫描 — 检测到恶意软件 !([扫描恶意软件](https://raw.githubusercontent.com/cybercop-arch/Malware-Analysis-with-XAI/main/screenshots/Screenshot%202026-05-07%20111009.png)) *文件上传后，通过 RF+XGBoost 集成模型进行处理。显示判定结果、风险评分 (0–100)、置信度、字节熵和 70 引擎检测计数。* ### 管理面板 !([管理面板](https://raw.githubusercontent.com/cybercop-arch/Malware-Analysis-with-XAI/main/screenshots/Screenshot%202026-05-07%20111330.png)) *受限的管理控制台，提供完整的用户监督功能——凭据、登录活动、上传的文件、审计日志以及仅对特权管理员账户可见的基于角色的访问数据。* ### 管理员报告 !([管理员报告](https://raw.githubusercontent.com/cybercop-arch/Malware-Analysis-with-XAI/main/screenshots/Screenshot%202026-05-07%20111348.png)) *特权访问仪表盘，展示了用户凭据、登录活动、上传的工件、角色权限、保密协议 (NDA) 状态，以及仅限管理员账户访问的完整审计可见性。* ### 70 引擎模拟 !([引擎网格](https://raw.githubusercontent.com/cybercop-arch/Malware-Analysis-with-XAI/main/screenshots/Screenshot%202026-05-07%20111018.png)) *基于 SHA-256 作为种子的确定性逐文件引擎模拟。分为三个敏感度层级：激进、正常 和保守。* ### 扫描历史 !([扫描历史](https://raw.githubusercontent.com/cybercop-arch/Malware-Analysis-with-XAI/main/screenshots/Screenshot%202026-05-07%20111029.png)) *基于 SHA-256 链式审计日志。受角色控制的 CSV 导出。基于文件哈希去重。* ### 全局特征洞察 !([洞察](https://raw.githubusercontent.com/cybercop-arch/Malware-Analysis-with-XAI/main/screenshots/Screenshot%202026-05-07%20111303.png)) *来自训练期间保存的 `shap_global_importance.npy` 的首要特征重要性。模型性能基准测试。* ## 项目功能 XAIGuard 回答了安全运营 中一个至关重要的问题： 标准的防毒软件只会给出一个二元的判定结果。而 XAIGuard 可以提供： - 来自校准后集成模型的**概率分数**（0–100 风险等级） - **SHAP 解释**，展示具体是哪些 PE 特征驱动了该判定结果 - **置信带**（基于等渗回归校准的统计学依据） - **按紧急程度排序的剧本**（隔离 → 封锁 IOC → 追查横向移动） - **70 引擎检测网格**，展示哪些 AV 厂商会标记该文件 ## 模型架构 ``` Binary File (.exe / .dll / .bin) │ ▼ feature_extractor.py 31 static PE features: • Byte entropy (normalised Shannon entropy) • Section entropy (avg + max across all sections) • Virtual size ratio (unpacking signal) • Import count, import library flags (ws2_32, wininet, ntdll) • Suspicious string count (VirtualAllocEx, CreateRemoteThread etc.) • PE header fields (has_signature, has_tls, has_debug, subsystem) • File type magic bytes │ ▼ ┌─────────────────────────────────────────────┐ │ Random Forest (400 trees) │ │ CalibratedClassifierCV (isotonic) │ │ class_weight = "balanced" │ │ → p_rf (calibrated true probability) │ └──────────────────┬──────────────────────────┘ │ ┌──────────────────────────────────────┐ │ │ XGBoost (500 trees) │ │ │ learning_rate = 0.05 │ │ │ max_depth = 7 │ │ │ scale_pos_weight = 4.7 │ │ │ tree_method = "hist" │ │ │ → p_xgb │ │ └──────────────┬───────────────────────┘ └──────────┬─────────────┘ ▼ prob = p_rf × 0.35 + p_xgb × 0.65 │ ▼ prob_to_verdict() ≥ 0.85 → MALICIOUS ≥ 0.55 → SUSPICIOUS ≥ 0.20 → LIKELY CLEAN < 0.20 → CLEAN │ ▼ SHAP TreeExplainer Top-15 feature contributors per file (named, not indexed) ``` ## 训练数据集 — EMBER 2018 | 属性 | 数值 | |----------|-------| | 总训练样本数 | 721,986 | | 恶意 | 126,421 (17.5%) | | 良性 | 595,565 (82.5%) | | 测试样本数 | 200,000 | | 每个文件的特征数 | 31 (手工设计的静态 PE 特征) | | 来源 | EMBER 2018 + MalwareBazaar + Windows System32 | 类别不平衡（82.5% 为良性）反映了真实世界的 SOC 环境状况。XGBoost 通过设置 `scale_pos_weight = 595565 / 126421 = 4.71` 来对此进行补偿。 ## 真实模型结果 这些数据来自训练期间生成的 `model/metadata.json`，而非硬编码。 | 指标 | 数值 | 含义 | |--------|-------|---------| | **AUC-ROC** | **0.9931** | 99.3% 的情况下能将恶意软件排在良性软件之前 | | **F1 分数** | **0.9516** | 精确率和召回率的调和平均值 | | **误报率** | **7.96%** | 在 0.50 阈值下，每 12 个良性文件中就有 1 个被错误标记 | | **漏报率** | **2.01%** | 每 50 个恶意软件文件中会有 1 个被漏报 | | **精确率** | ~72% | 当模型判定为恶意时，有 72% 的情况是正确的 | | **召回率** | ~98% | 能够捕获每 100 个恶意软件中的 98 个 | **关于误报率的说明：** 在 0.50 阈值下为 7.96%。在 `prob_to_verdict()` 中将阈值提高到 0.65–0.70，可以在牺牲极小召回率的情况下将其降低到 ~2–3%。 ## 7 项研究挑战 本项目旨在解决恶意软件检测生产级 XAI 中的 7 个具体问题： | # | 挑战 | 状态 | 解决方案 | |---|-----------|--------|-----| | 1 | 无攻击面泄露 | ✅ 已解决 | 受角色控制的 SHAP 深度——终端用户只能看到抽象标签，而非原始特征名 | | 2 | 局部 + 全局 XAI | ✅ 已解决 | 源自 TreeExplainer 的逐文件 SHAP + 提供 `shap_global_importance.npy` 的 `/insights` 接口 | | 3 | 数据漂移与泛化 | ⚠️ 部分解决 | EMBER 2018 (160K 样本) 提供了强大的基线——漂移监控管道尚在开发中 | | 4 | 动态分析延迟 | ✅ 已解决 | 不到 3 秒完成全面静态分析——ByteEntropyHistogram 近似实现了动态加壳检测 | | 5 | 误报与上下文 | ✅ 已解决 | CalibratedClassifierCV (等渗回归) 提供真实的概率——连续的风险评分而非二元判定 | | 6 | 解释的可用性 | ✅ 已解决 | SHAP 特征名被映射为人类可读的标签——按判定结果提供按紧急程度排序的剧本 | | 7 | 日志安全与合规性 | ✅ 已解决 | 每次扫描提供真实的 SHA-256，受角色控制的 CSV 导出，3 级保留策略 | ## API 接口 ``` POST /scan Body: multipart/form-data, field "file" Returns: verdict, riskScore, prob, conf, confLow, confHigh, shap[{feature, impact, value}×15], engines[70], model{auc_roc, f1_score, fp_rate} GET /insights Returns: top_features[{feature, importance}×20] from shap_global_importance.npy + model metadata GET /health Returns: status, models_ready, features=31, model_auc ``` ## 角色系统 | 角色 | 扫描 | SHAP 名称 | 引擎网格 | 导出 CSV | 设置 | |------|------|-----------|-------------|------------|----------| | Admin | ✅ | ✅ | ✅ | ✅ | ✅ | | Security Analyst | ✅ | ✅ | ✅ | ✅ | ✅ | | Threat Hunter | ✅ | ✅ | ✅ | ✅ | ❌ | | End User | ✅ | ❌ | ❌ | ❌ | ❌ | End User（终端用户）只能看到抽象标签（如“导入模式 — 高影响”），而非原始特征名（`pe_imports_VirtualAllocEx: 0.412`）。这正是挑战 1——防止模型的攻击面通过 UI 泄露给攻击者。 ## 本地运行 **后端：** ``` cd backend pip install -r requirements.txt # 训练模型（需要 EMBER 2018 数据集） python train_model.py --ember ./ember2018 # 启动 API python api.py # → http://localhost:5000 ``` **前端：** ``` # 在 xaiguard-v5.jsx 第 458 行设置 API_URL： const API_URL = "http://localhost:5000"; # 然后使用您首选的方法（Vite, CRA, 等）进行 serve ``` **前端：** ``` cd streamlit streamlit run app.py ``` **演示账号：** ``` analyst@sec.io / analyst123 → Security Analyst admin@sec.io / admin123 → Admin hunter@sec.io / hunter123 → Threat Hunter user@example.com / user123 → End User ``` ## 关键技术决策 **为什么选择 RF + XGBoost 集成模型而不是 CNN+LSTM？** 基于 31 个手工设计特征的静态 PE 特征分析具有更好的可解释性，速度更快（耗时 <3s，而动态分析需 60–300s），并能生成经过校准的概率。CNN 需要将字节级数据转换为图像，但对于此特征空间而言，在可解释性上并无增益。 **为什么使用带有等渗回归的 CalibratedClassifierCV？** 原始随机森林 的 `predict_proba` 输出并非真实的概率——它反映的是决策树的投票比例，通常聚集在 0.4–0.6 之间。等渗回归拟合了一个单调校正函数，使得当模型输出 0.85 时，这类文件中实际上约有 85% 确实是恶意的。这使得置信带在统计学上更为诚实可靠。 **为什么选择 SHAP TreeExplainer 而不是 LIME？** 对于树模型而言，TreeExplainer 是精确的（非采样），无论特征数量如何，都能在几毫秒内运行完毕，并生成一致的解释。LIME 是近似算法，在不同的运行中对同一文件可能会给出不同的解释。 **为什么要进行确定性引擎模拟？** `simulate_engines()` 使用 `int(sha256[:8], 16)` 作为种子——相同的文件始终会产生相同的 70 引擎结果。三个敏感度层级（激进/正常/保守）反映了真实的 AV 厂商行为，例如 Kaspersky 和 ESET 会比 ClamAV 或 Baidu 更早地进行标记。 ## 项目结构 ``` backend/ ├── api.py Flask REST API — /scan, /insights, /health ├── feature_extractor.py 31 static PE features from raw bytes ├── train_model.py RF+XGBoost training on EMBER 2018 └── requirements.txt frontend/ └── xaiguard-v5.jsx React dashboard — 5 pages, role-gated, responsive streamlit/ └── app.py Streamlit port — full faithful migration model/ (excluded — 700MB+) ├── rf_calibrated.joblib Calibrated Random Forest ├── xgboost.ubj XGBoost model ├── metadata.json Real AUC-ROC, F1, FP/FN rates from training └── shap_global_importance.npy Mean |SHAP| across test set ``` ## 我学到了什么 - **经过校准的概率至关重要** —— 原始 RF 分数并非真正的概率。等渗校准将它们转化为具有统计意义的数值，使您可以真正信任它们来进行风险评估。 - **类别不平衡是导致误报率 (FP rate) 的主要因素** —— 82.5% 的良性训练数据在 0.50 阈值下会产生 7.96% 的误报。调整阈值比更改模型架构的影响更大。 - **在树模型上使用 SHAP 既精确又快速** —— 在一个拥有 31 个特征的 500 棵树的 XGBoost 模型上运行 TreeExplainer，每个文件耗时不到 10 毫秒。解释成本几乎可以忽略不计。 - **基于角色控制的 XAI 是一项真正的安全决策** —— 公开 SHAP 特征名（具体权衡了哪些导入函数）相当于给攻击者提供了一份规避检测的蓝图。为非特权用户抽象这些信息不仅是用户体验 (UX) 层面的考量，更是威胁建模的一部分。 - **Streamlit 会独立封装每个组件** —— 您不能将 Streamlit 组件包裹在 HTML `