IoC 整理与共享
把事件中发现的 IP、域名、哈希整理成结构化清单，每条包含值、类型、上下文、发现时间与置信度，便于全网检索与对外共享。孤立的地址列表很难被其他团队复用，必须带上下文才能落地到封禁与检索。
基本信息
| 字段 | 类型、值、上下文、发现时间、置信度 |
|---|---|
| 来源 | 日志、样本、内存、邮件头 |
| 用途 | 全网检索、边界封禁、情报上报 |
| 脱敏 | 对外共享前清理内部资产信息 |
| 格式 | 机读用 CSV/JSON，人读用表格 |
| 版本 | 随新发现滚动更新并标注版本与时间 |
典型使用场景
- 把事件中发现的地址交给边界设备封禁
- 上报给行业情报平台或安全厂商
- 在同批主机中检索是否出现相同地址
- 建立本组织自己的常用 IoC 库
- 与威胁情报比对，确认是否命中已知家族
- 复盘时说明封禁范围与判断依据
- 观察期持续监控这些地址是否再次出现
生成 IoC 清单
生成 IoC 清单
grep -h 'Failed password' /var/log/auth.log | grep -oE 'from [^ ]+' | awk '{print $2}' | sort -u > /evidence/ioc_ip.txt
sha256sum /evidence/suspect.bin >> /evidence/ioc_hash.txt # 样本哈希入库
grep -aE 'https?://' /evidence/mem.raw 2>/dev/null | sort -u | head -n 20 > /evidence/ioc_url.txt
wc -l /evidence/ioc_ip.txt # 统计条目数
sort -u /evidence/ioc_ip.txt | head -n 40 # 复核清单内容字段设计
| 字段 | 示例 | 为什么需要 |
|---|---|---|
| 类型 | ip、domain、url、hash | 决定下游如何使用该条数据 |
| 值 | 具体地址或哈希 | 检索与封禁的输入 |
| 上下文 | 来源主机与日志行片段 | 判断可信度的依据 |
| 发现时间 | 精确时间戳 | 关联事件时间线 |
| 置信度 | 高、中、低 | 决定是否直接封禁 |
IoC 必须带时间窗：同一个地址在不同时间段的含义完全不同，缺了时间维度，后续检索无法定位到具体活动。
对外共享前先脱敏：内部主机名、账号、路径都属于不该外传的信息，共享范围按对方实际需要裁剪。
清单里的每一条最好能指向具体证据行：来源日志文件、时间与主机三要素写全，别人复核时才能一路追溯到底。