最近在读《Incident Response & Computer Forensics（第3版）》[1]，作者是来自 Mandiant（现FireEye）的两位资深安全专家—Luttgens, Jason T. 和 Pepe, Matthew。本书出版于2014年，作者在这一版中专注于介绍如何在企业范围内、以快速而彻底的方式进行从检测到修复的入侵事件响应。
今天这则读书笔记来自第5章，主要介绍事件调查过程中如何将线索（Leads）转化为失陷指标（Indicators of Compromise）。在这部分内容之前，首先会介绍出自第2章的相关概念和定义，事件响应过程以及事件调查生命周期、线索、IOC以及 IOC部署。
基本概念和定义
文中定义了事件响应（IR）过程包括初始响应、事件调查和修复。初始响应通常意味着整个 IR 过程的启动。一旦 IR 团队确认事件正在进行并执行了初始的收集和响应步骤，那么调查和修复工作也开始同步执行。初始响应工作的目标包括组建响应团队、检查网络和其他可获得的数据、确定事件类型以及评估潜在影响。
而事件调查的目标则是确定如下事实：发生了什么、如何发生的，在一些情况下还需要回答“谁”为此负责。作者开发和提炼了一套由5个步骤组成的事件调查流程（见下图）。这是一个可迭代的过程，因此又称为事件响应生命周期。
在整个调查过程中，负责调查的团队会持续生成作者称之为“线索”（leads）的列表。线索是可指导行动的项目，它与失窃数据、网络指标、潜在主体的身份标识、导致失陷或安全事件的问题相关。
“Leads are actionable items about stolen data, network indicators, identities of potential subjects, or issues that led to the compromise or security incident.”
作者认为没有线索的事件调查无异于捕鱼探险。因此，收集初始线索对于任何事件调查都是至关重要的步骤。作者注意到许多组织在事件调查中会犯一个常见错误，仅关注如何发现恶意软件。从攻击者的意图来说，安装恶意软件并非其唯一目标。一旦入侵网络成功并获得有效的身份凭证，攻击者将不再需要使用恶意软件访问其他系统。另外，作者从实战经验出发，包括接手在他们之前所获不多的事件调查以及他们自己的成功经验，建议应聚焦在线索上，而且应该有必要投入时间去评估新的线索。好的线索通常有3个特征：
- 相关的：与事件相关，这点看起来显而易见。但很多组织通常会陷入的问题在于，会将任何看似可疑的信息都视为当前事件的一部分。而且，由于事件的触发，组织会以前所未有的方式审视自身的环境，由此会发现大量可疑的活动，而事实上却是正常的。这会给调查团队带来极大工作量甚而阻碍调查工作的开展。
- 详细的：线索应具有与潜在调查过程相关的详情。举例来说，某个外部团体可能提供了一条线索，表明你的环境中有一台电脑在和外部网站通信，而这个网站被植入了恶意代码。这样的信息并不够详细，还需要额外了解更多细节，比如事件发生的日期和时间、IP地址等，考虑 “who”、“what”、“when”、“where”、“why”以及“how”，否则就可能是浪费时间。
- 可行的：线索应包含你能使用的信息，而且你的组织应该具备能跟进这条线索所需的手段。举例来说，现在有一条线索表明大量数据传送到与 botnet 相关的一个外部网站。你也有准确的日期、时间以及目标IP，但是企业内部没有对应的网络流数据或者防火墙日志，用以识别内部资源正是数据源。因此这条线索是不可操作的，因为没有办法发现网络中特定电脑的活动。
失陷指标（Indicators of Compromise，IOC）的生成，是以结构化的方式记录事件的特征和证物的过程。IOC包含从主机和网络角度的所有内容，而不仅仅是恶意软件。它可能是工作目录名、输出文件名、登录事件、持久性机制、IP地址、域名甚至是恶意软件网络协议签名。
IOC部署：IOC 被用于有效地描述、交流和查找与事件相关的证物，但如何发挥 IOC 真正的价值在于帮助 IR 团队以自动化的方式去发现问题。调查的成功取决于是否有能力在整个企业中搜索 IOC、并以自动化的方式报告它们，这就是作者所说的“IOC 部署"。
如何将线索转化为 IOC
前面介绍了好的线索应具备的3个特征：相关的、详细的、可行的。当我们已经掌握了大量的好线索之后，我们还需要将这些线索转化为可行的指标，即能够检测进行中的事件以及将来的攻击。IR 团队生成的大多数线索包括恶意操作的可检测特征。它们可以用两类指标来表示。第一类是基于属性的指标，描述了一组已知的恶意软件或操作的特性，例如注册表、MD5 哈希或具有唯一名称的互斥体。而某些线索不太具体，需要通过一组特征组合定义恶意或可疑的行为，比如在 /Windows/help 目录下非预期的可执行文件。这称之为基于方法的、或基于异常的指标。它们都可以转化为可用于单次运行或企业范围实时响应的指标，以帮助确定事件范围。使用指标的目的在于界定事件范围：发现一次，全面搜索。
“Discover once, search everywhere.”
IOC 开发生命周期
IOC 的开发是一个迭代过程，旨在生成可靠的、可持续的签名，从而能够提供可靠的信息用于搜索和匹配。负责生成 IOC 的团队成员必须遵循 IOC 开发生命周期流程，如下图所示。
初始信息输入可能是来自高精度源（如取证检查、有质量的恶意软件分析报告）的最有用结果，也有可能仅包含可疑攻击的简单特征。收集完初始信息后，进入指标创建/编辑（Create/ Edit）阶段。该阶段工作不仅仅是打开一个TXT 或者 XML 编辑器，将 MD5 哈希值拷贝进去，还需要很好地理解 IOC 语言以及使用处理器的限制和细微差别，比如 snort 平台预处理器针对进入数据流操作所需的时间，任何变量的改变（如报文抵达率、分片报文的数量等）都可能导致其他传感器丢包或者丢失信息。另一个例子则是几个取证分析套件中使用的索引引擎需要注意特殊字符的处理。
指标生成以后，在进入循环或者直接使用之前需要进行验证，有两种验证方法：与指标相关的数据（Data Relevant to Indicator）、以及环境通用的数据（Data Common to Environment）。
验证获得的信息会被反馈并用于指标细化。该循环会一直持续到指标已经充分形成，这样调查者才能可靠地使用指标。此过程可确保指标生成预期结果。接下来就可以考虑IOC 部署和使用，进入发布阶段。
主机 IOC
线索可以转化为基于主机或基于网络的IOC，也可以是两者的组合。接下来将以主机IOC为例，介绍指标创建/编辑（Create/ Edit）的方法和思路。
作者认为：一个好的主机IOC 由观测到的一些特定活动特征组成, 但又足够通用能适用于该活动的衍生物。这可能较难平衡，特别是线索不够完整或者质量不佳的时候。
“A good host-based indicator is composed of a number of observables that are specific to a particular activity, yet general enough to apply to a derivative of the activity.”
基于属性的 IOC
大家如果还有印象，前文介绍过：线索可以用两类指标来表示，一类是基于属性的，另一类是基于方法/异常的。作者分别对这两类指标做了举例介绍。
第一个例子用到了《Practical Malware Analysis (No Starch Press, 2012)》一书中第3章实验里面的二进制文件 Lab03-02. dll。
- 第一步可以基于该文件的 MD5 hash 值作为 IOC 指标。无疑这项指标具有极高的精度，同时非常单一、受限，因为攻击者极为容易更改文件内容同时也还保留其功能，如仅仅更改内置的IP地址，这会导致基于 MD5 hash 检测的指标失效。
- 接下来从 PE 文件数据结构角度进行拓展和优化，可以在指标中加入两个判断条件，即 PE 头部包含的编译时间戳以及文件大小。之所以补充后者，主要是考虑到攻击者有时会在编译之后对其进行手工修改，这样尽可能降低误报。值得注意的是，如果攻击者增删二进制文件里面的数据，文件大小这个条件就无法匹配上。因此，需要进一步优化 IOC。
- 在分析该二进制文件时，我们能发现其在系统上执行了大量的操作，比如安装 Windows 服务、或者链接互联网上的站点。从这里开始，其实是转换思路了，从寻找文件本身到查找执行文件后的效果。这样即使系统上不再存在这个二进制文件或者如前两步所述，文件属性发生变化时，IOC 里面仍然包含文件被执行后留下的证物（artifacts），可用于搜索匹配。作为示例，作者补充了两项条件，二进制文件创建的特定服务以及与该恶意软件外联的主机名相关的DNS 缓存信息。
针对这个场景的IOC，另一种优化的方法则是描述该二进制文件能做什么。通常会去检查导入表（import table），但同时也需要考虑手工导入函数的不适用情况。在这个样例中，作者发现有大量的输入，同时也考虑到了大多数恶意软件会使用许多其他类软件通用的函数，这里独特的一点是：通常不会在单个二进制文件一起找到这些函数的子集。因此需要构造一个具有多个模糊或松散的、可归因属性的 IOC。下图显示的 IOC 捕获了所导入函数相对独特的组合。这种思路的好处在于即使攻击者修改代码的主要部分或者配置选项，该 IOC 仍然可以识别到它。
基于方法的 IOC
上述都是在描述如何创建用于描述给定文件属性的 IOC，下面则介绍如何创建用于描述攻击者行为的 IOC，因为这里没有相关的恶意软件。这些 IOC 被称为基于方法的指标，可将基于属性的指标与活跃的攻击者留下的证物信息结合起来。作者在此以 sethc.exe 替换攻击为例。Windows 平台上的 sethc.exe 应用程序是一种辅助各种残疾人士使用 Windows 的增强功能。通过五次快速连续按 SHIFT 键进行调用，并可以在成功登录之前启动。攻击者使用该功能、进行替换后可以启动以系统权限运行的 cmd.exe 会话。有两种主要的攻击执行方法。可以通过 5 次按键将启动位于 c: \windows\system32\sethc.exe 的任何可执行映像。还可以将 cmd.exe 添加到注册表中 sethc 可执行文件的调试句柄，因为 Windows 不会对此做检查。
针对这类攻击，以Win 7 SP0为例，IOC 会首先校验 sethc.exe 的 MD5 hash以及存储在PE文件头部的时间戳。如果要考虑遍历所有系统版本及补丁包，上述校验将变得难以管理、不可控。根据作者经验，通常 sethc.exe 会被替换为 cmd.exe，且文件大小存在差异，cmd的文件大小总是至少比最大的 sethc 二进制大 10%。因此，IOC 判断条件可以这样编写：
考虑到替换文件还可能是小于文件大小阈值的其他应用，所以需要使用其他半唯一（semi-unique）属性来降低误报。针对前面提到的第2种攻击方法，通过在注册表中搜索相关key的存在，确定是否使用了特定映像的调试器。如果用于链接命令到 sethc 的映像执行调试器，其注册表有任何键值设置，则应检查该系统。判断条件如下图所示：
最后，作者将上述两个片段以 OpenIOC（Mandiant采用的IOC格式）语言组合成失陷指标，并对两者做了对比，建议读者回想关于了解所使用工具局限性的讨论。这里主要有两种不同之处值得注意。首先是 OpenIOC 格式的部分路径。作者希望此检测与卷无关, 因此在文件的完整路径上使用“包含”术语。第2个不同在于OpenIOC 使用了范围而非不等式。这是受限于使用的查询工具，匹配引擎不会评估不等式。
文中作者还列举了网络 IOC 的例子，此外，作者对 IOC 的验证也做了很多经验分享，主要还是考虑 IOC 在企业内的部署规模，除了对相关性、通用性进行充分验证，还需要考虑指标的性能以及影响。这里因为篇幅原因，就不再赘述。
写在文末
笔者主要就线索如何转化为 IOC 以及涉及的相关概念做了介绍。作者将实战经验进行系统思考和总结，充分体现了上佳的理论素养。另外，笔者作为这方面的小白，通过学习也算是揭开一点点 IOC 的神秘面纱，开拓了眼界和思路。相信于业界有经验的安全分析师或者响应人员而言，这正是他们的日常工作之一。随着读书进度，越发觉得确如 FireEye自己所说，Helix是一个多年积累的产物。
[1] Luttgens, Jason T.; Pepe, Matthew; Mandia, Kevin. Incident Response & Computer Forensics, Third Edition (p. 100). McGraw-Hill Education.