失陷指标（IoC）基础：定义、分类与检测价值

各位同学，咱们今天聊点实在的。做IoT安全，你手里得有几把“尺子”，用来量一量设备是不是已经被人动了手脚。这把尺子，就是失陷指标——IoC。

我刚开始接触安全分析那会儿，总觉得IoC就是几个IP地址、几个文件哈希。后来在真实项目里吃过亏，才明白这东西远没那么简单。你想想看，一个智能灯泡被控了，它留下的痕迹可能是一段异常的流量模式，也可能是一个从未见过的域名请求。这些痕迹，就是我们要找的IoC。

什么是失陷指标（IoC）

失陷指标，英文叫Indicator of Compromise，简称IoC。说白了，就是能证明你的系统已经被入侵、被控制、被篡改的“物证”。

举个例子。你家里的智能摄像头突然开始往一个陌生IP发数据包。这个IP地址，就是一个IoC。再比如，你在一台IoT网关的日志里发现了一个从未见过的恶意软件哈希值。这个哈希值，也是一个IoC。

我个人习惯把IoC分成两类：

• 原子指标：不可再分的最小单位，比如一个IP、一个哈希、一个域名。
• 计算指标：需要分析才能得出的，比如行为模式、流量特征、时间序列。

嗯，这里要注意。原子指标好理解，但计算指标才是真正考验功力的地方。我在一个智慧路灯项目里遇到过，攻击者用了动态域名，IP一直在变，但请求的时间间隔模式是固定的。靠原子指标根本抓不到，最后是靠行为模式才揪出来的。

IoC的五大分类

咱们做IoT入侵检测，最常用的IoC就这五类。我按实战中的使用频率排个序：

分类	说明	IoT场景举例
文件哈希	恶意固件、脚本、二进制文件的MD5/SHA1/SHA256	被篡改的摄像头固件包
IP地址	C2服务器、恶意扫描源、数据回传目标	智能门锁外连的可疑IP
域名	恶意域名、DGA生成域名、仿冒域名	传感器上报数据的伪造域名
URL	恶意下载链接、钓鱼页面、API端点	路由器固件更新的劫持URL
行为模式	异常流量、非正常时间操作、权限提升序列	智能电表在凌晨3点的批量数据外传

这张表你最好记在心里。每次做规则的时候，我都会对着这五类问自己：这个场景下，哪种IoC最可能留下痕迹？

1. 文件哈希

哈希是最直接的证据。你拿到一个恶意固件，算一下SHA256，然后全网去匹配。匹配上了，基本实锤。

但有个坑。我曾经在分析一款智能插座时，发现恶意固件每次编译都会生成不同的哈希。攻击者用了简单的代码混淆，哈希天天变。这时候光靠哈希就不够了，得结合行为模式。

2. IP地址

IP地址是最常见的IoC。C2服务器、恶意扫描源、数据回传目标，都离不开IP。

但IP有个致命弱点——它太容易变了。攻击者用CDN、用代理、用动态IP，今天用的IP明天就废了。我在一个车联网项目里追踪过一组C2，48小时内换了17个IP，分布在5个国家。

所以，IP地址IoC适合做短期检测，不适合做长期规则。你最好给它加个时间戳，过期就失效。

3. 域名

域名比IP稳定一些。攻击者注册一个域名，至少能用几周甚至几个月。而且很多IoT设备硬编码了域名，改起来麻烦。

这里有个经典手法——DGA（域名生成算法）。僵尸网络用DGA每天生成上千个域名，你封都封不完。我记得有个案例，Mirai变种就用了DGA，感染了大量摄像头。

对付DGA，靠静态域名列表不行，得分析域名的字符分布、熵值、注册时间这些特征。

4. URL

URL比域名更精细。它能定位到具体的资源路径。比如一个恶意固件的下载链接：http://malicious.com/firmware/update.bin。

URL的优点是精确，缺点是太长了容易被截断或编码。我在分析智能门锁的日志时，发现攻击者把恶意URL做了Base64编码，藏在正常的API请求里。光看URL路径根本发现不了，得解码后才能匹配。

5. 行为模式

这是最复杂、也最有价值的一类IoC。行为模式不是静态的，它是从多个维度计算出来的。

举个例子。一个正常的温度传感器，每5分钟上报一次数据。如果某天它突然变成每30秒上报一次，而且数据包大小翻了三倍。这就是行为模式异常。

行为模式IoC包括：

• 流量频率异常（比如心跳间隔突变）
• 协议使用异常（比如MQTT设备突然用HTTP）
• 时间序列异常（比如凌晨批量操作）
• 权限提升序列（比如从普通用户提权到root）

IoC在威胁检测中的作用

IoC不是万能的，但没有IoC是万万不能的。它在威胁检测中扮演三个角色：

1. 证据锁定：告诉你“有东西进来了”。一个匹配的哈希，一个可疑的IP，就是最直接的证据。
2. 溯源追踪：帮你回答“从哪进来的、去了哪”。通过关联多个IoC，可以还原攻击链。
3. 规则构建：IoC是检测规则的原材料。你把IoC转化成规则，就能自动化检测。

我举个例子你就明白了。有一次，一个智能网关设备频繁重启。日志里发现了一个陌生域名请求。我把这个域名作为IoC，去威胁情报平台查了一下，发现它关联了三个恶意IP和两个已知的恶意软件哈希。然后我基于这些IoC构建了一条检测规则：如果设备请求该域名，且同时向任意一个关联IP发送数据，则告警。这条规则上线后，又抓到了两次同类攻击。

你看，IoC的作用就是“以点带面”。一个点触发，整个面就浮出水面了。

IoC的生命周期

IoC不是永恒的。它有生命周期。我一般把IoC分成三个阶段：

阶段	特征	处理方式
活跃期	IoC仍在被攻击者使用，检测价值高	立即加入检测规则，高优先级
衰减期	IoC可能已被弃用，但仍有参考价值	降低优先级，保留在库中
失效期	IoC已确认不再使用，或已被合法化	从活跃规则中移除，归档

我曾经犯过一个错。一条基于IP的检测规则用了半年没更新，结果那个IP被CDN回收后分配给了正常业务。误报率飙升，运维同事差点没把我拉黑。从那以后，我养成了定期清理IoC的习惯。

知识体系总览

下面这张图，把咱们这章的核心逻辑串起来了。你可以把它当成一个思维导图来用。

这张图把IoC的定义、分类、作用和生命周期串在了一起。你把它存下来，后面做规则的时候随时可以回来对照。

小结

这一章咱们把IoC的底子打好了。文件哈希、IP、域名、URL、行为模式——这五类IoC，是构建IoT入侵检测规则的原材料。你理解了它们各自的特点和局限，后面写规则的时候才能有的放矢。

记住一句话：好的IoC，能让你的检测规则事半功倍；烂的IoC，只会让你的告警台变成噪音工厂。