alexverboon/microsoft-defender-threat-intelligence-toolkit

GitHub: alexverboon/microsoft-defender-threat-intelligence-toolkit

这是一个专为管理 Microsoft Sentinel 威胁情报指标设计的 PowerShell 工具集,旨在通过脚本化手段解决指标膨胀导致的管理难题和存储成本上升问题。

Stars: 0 | Forks: 0

# Microsoft Defender 威胁情报 Toolkit [![License: MIT](https://img.shields.io/badge/License-MIT-green.svg)](LICENSE) ![PowerShell 7+](https://img.shields.io/badge/PowerShell-7%2B-5391FE?logo=powershell&logoColor=white) ![Az.Accounts required](https://img.shields.io/badge/Az.Accounts-required-0078D4) 一个用于管理 **Microsoft Sentinel 威胁情报指标** 的社区 PowerShell 工具包。 ## 概述 该工具包旨在为安全运营团队和安全工程师提供支持,用于管理威胁情报(TI)指标,包括从 Microsoft Sentinel 工作区进行批量删除。 ## Microsoft Sentinel 中的威胁情报 威胁情报描述了关于现有或潜在威胁的信息,既包括高层次的洞察(如威胁行为者和技术),也包括低层次的指标,如 IP 地址、域名、URL 和文件哈希。 在 Microsoft Sentinel 中,最常用的形式是威胁指标(IoC),它将观察到的工件与已知的恶意活动联系起来,用于检测威胁并丰富调查。 ### 引入威胁情报 Microsoft Sentinel 提供了多种受支持的方法来引入和管理威胁情报: - **数据连接器** 从外部平台和源引入情报,包括 Microsoft Defender Threat Intelligence 和 STIX/TAXII 源 - **上传 API** 通过 REST API 直接从自定义应用程序或 TIP 解决方案发送精选的威胁情报(STIX 对象) - **TAXII 连接器(STIX/TAXII 标准)** 使用内置的 TAXII 客户端从行业标准源引入情报 - **威胁情报平台连接器(旧版)** 基于 API 的引入,仅限于指标,目前正被弃用以支持上传 API 这些引入选项允许组织在工作区中集中威胁情报,以便存储、管理,并用于检测、搜寻和分析。 更多详情请参阅:[Microsoft Sentinel 中的威胁情报](https://learn.microsoft.com/en-us/azure/sentinel/understand-threat-intelligence) ### 问题:指标膨胀 随着时间的推移,Microsoft Sentinel 工作区可能会积累大量的威胁情报指标(IoC)。 虽然通常期望指标会自动过期,但在实践中这可能并不总是得到一致的执行。一个常见的根本原因是 IoC 缺少过期日期,这通常源于测试活动。 结果是,过时或不相关的指标保留在工作区中,而新指标不断被添加,导致 IoC 总数稳步增加。 下面的屏幕截图显示了一个拥有超过 **630 万个指标** 的示例工作区: ![Sentinel 指标总计数](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/315ff5c95a031800.png) 在这种规模下,通过门户管理指标变得不切实际。搜索缓慢,筛选繁琐,并且对于大量数据没有内置的批量删除功能。 ### 确定来源 要了解哪些源导致了高数量,请在 Microsoft Defender 门户中的 **Intel management** 下使用 **Source** 筛选器。按源筛选可以让您快速查看每个源贡献了多少指标: ![按源筛选以查找大量指标计数](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/e027a4d833031802.png) 在上面的示例中,按 `ThreatViewURLBlockList` 和 `ThreatViewIPBlockList` 筛选显示仅这两个源就有近 **967,000 个指标**。一旦知道了源名称,就拥有了进行批量定向删除所需的一切。 ### 对 Log Analytics 成本的影响 高指标数量不仅影响门户的可用性,还会直接增加 Log Analytics 中 `ThreatIntelIndicators` 和 `ThreatIntelObjects` 表的大小,从而导致引入和保留成本上升。 下面的屏幕截图(来自 Microsoft Sentinel 工作区使用情况工作簿)显示了 TI 相关表如何贡献于总数据量: ![来自工作簿的 TI 表使用情况](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/d3c8aab1d9031803.png) 要量化每个源的成本贡献,请在 Log Analytics 工作区中运行以下 KQL 查询: ``` ThreatIntelIndicators | where TimeGenerated > ago(360d) | where _IsBillable == true | summarize TotalVolumeGBLog = round(sum(_BilledSize / 1024 / 1024 / 1024), 2), Count = count() by SourceSystem //| summarize round((sum(TotalVolumeGBLog)),2) ``` 这将返回按源分解的计费数据量(GB)和指标计数——这使得识别哪些源是最大的成本贡献者以及优先清理哪些源变得简单明了。 ### 使用此脚本进行清理 确定了源名称后,在 `Invoke-RemoveSentinelThreatIndicator.ps1` 中将 `$SourceFilter` 设置为一个或多个源值并运行脚本。脚本随后统计所有匹配的指标,提示进行确认,并在批量删除时自动处理分页、令牌刷新和速率限制。 下面的屏幕截图显示了在批量清理运行期间使用的指标删除进度视图: ![指标删除进度](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/121e39a9e4031804.png) ## 脚本 | 脚本 | 描述 | |--------|-------------| | `Scripts\Common\Toolkit.Logging.ps1` | 可跨脚本重用的共享日志记录助手(`Initialize-ToolkitLogger`、`Write-Log`)。 | | `Scripts\Remove-SentinelThreatIndicators.ps1` | 包含 `Remove-SentinelThreatIndicators` 函数。使用专为大型数据集设计的计数和排空工作流,具有严格的飞行前计数检查、速率/退避控制和运行结束时的协调。完整的工作流和操作详情:[docs/remove-sentinel-threat-indicators.md](docs/remove-sentinel-threat-indicators.md)。 | | `Scripts\Invoke-RemoveSentinelThreatIndicator.ps1` | 用于运行指标删除的执行脚本。首先编辑顶部的配置参数,然后运行此文件。 | ## 先决条件 | 要求 | 详情 | |-------------|---------| | PowerShell | 7.0 或更高版本(必需)。 | | Az.Accounts 模块 | `Install-Module Az.Accounts` | | Azure RBAC | 目标工作区上的 **Microsoft Sentinel Contributor**(或同等权限)。 | ## 快速开始 1. **在本地获取仓库**(推荐): git clone https://github.com/alexverboon/microsoft-defender-threat-intelligence-toolkit.git cd microsoft-defender-threat-intelligence-toolkit 如果您愿意,也可以从 GitHub 下载仓库 ZIP 并将其解压。 2. **安装所需的模块**(如果尚未安装): Install-Module Az.Accounts -Scope CurrentUser 3. **登录到 Azure:** Connect-AzAccount ### 批量指标删除 1. **在 `Invoke-RemoveSentinelThreatIndicator.ps1` 中编辑配置**: 速率换算参考:`req/hour = req/s * 3600`(例如:`1.0 -> 3600/hour`,`10.0 -> 36000/hour`)。 $SubscriptionId = "" # 必需:包含 Sentinel 工作区的 Azure 订阅 GUID $ResourceGroupName = "" # 必需:包含工作区的 Azure 资源组名称 $WorkspaceName = "" # 必需:链接到 Sentinel 的 Log Analytics 工作区名称 $BatchSize = 100 # 每批删除的指标数量 $SourceFilter = @("") # 安全所需;一个或多个源,例如 @("ThreatViewIPBlockList","ThreatViewURLBlockList")。空值/缺失值将中止运行。 $ConcurrentWorkers = 5 # 最大并发 DELETE 工作线程;持续速率由 TargetDeleteRatePerSecond 单独控制 $TargetDeleteRatePerSecond = 10.0 # 所有工作线程的持续 DELETE 速率。以 1.0 req/s 作为安全基准(约 3600/小时)开始。 较高的值(例如 10.0 req/s)可以加快整体处理速度,但会增加受限(HTTP 429)的可能性,具体取决于租户和订阅限制。 $ShowAPIWarnings = $false # 设置后,将每个请求的 401/429 限制诊断信息写入控制台。默认情况下,这些消息被抑制。 $Confirm = $true # $true = 确认提示;对于无人值守运行,设置 $false $WhatIf = $false # $true = 模拟而不删除指标 $LogFile = "" # 可选的完整文件路径;保留 "" 以使用默认值(脚本文件夹\Logs) 2. **运行调用脚本:** .\Scripts\Invoke-RemoveSentinelThreatIndicator.ps1 操作员注意:`ConcurrentWorkers=1` 为顺序运行,大于 `1` 的值为并行删除。在这两种模式下,持续吞吐量都受到 `TargetDeleteRatePerSecond` 的全局速率限制。 ## 日志记录 该工具包为每次运行写入结构化的 logfmt 输出。日志包括运行级别关联(`run_id`)、事件名称、进度以及警告/错误上下文。 - 格式参考:https://brandur.org/logfmt - 当前清理脚本的默认位置:`