Paper Note - SLEUTH：基于COTS审计数据的实时攻击场景重构

最新推荐文章于 2022-10-21 20:31:47 发布

Alst0n

最新推荐文章于 2022-10-21 20:31:47 发布

阅读量2.2k

点赞数 8

分类专栏：学术 APT

本文链接：https://blog.csdn.net/Sc0fie1d/article/details/104273798

版权

学术同时被 2 个专栏收录

8 篇文章 4 订阅

订阅专栏

APT

4 篇文章 1 订阅

订阅专栏

原文标题：SLEUTH: Real-time Attack Scenario Reconstruction from COTS Audit Data

原文作者：Md Nahid Hossain, Stony Brook University; Sadegh M. Milajerdi, University of Illinois at Chicago; Junao Wang, Stony Brook University; Birhanu Eshete and Rigel Gjomemo, University of Illinois at Chicago; R. Sekar and Scott Stoller, Stony Brook University; V.N. Venkatakrishnan, University of Illinois at Chicago

原文来源：USENIX 2017

原文链接：https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/hossain

1 摘要

本文提出了一种可以在企业主机上实时重构攻击场景的方法和系统——SLEUTH，开发了一种平台无关、基于主存的审计日志数据依赖图抽象。

本文提出了一种基于标签的技术来分析攻击行为，包括源识别和影响分析。同时本文通过构建简洁、可视的攻击步骤来揭示攻击的总体情况。系统所用的评估数据仍然来自DARPA组织的红队攻击。

2 介绍

像IDS和SIEM这样的工具会产生大量的信息，安全分析人员从中辨别出真正的攻击变得十分困难；而且，对于跨越多个应用、主机以及时间跨度很长的攻击行为，分析人员缺乏工具将这些片段拼凑起来。因此，分析人员所需要的工具不仅能够检测攻击，而且能够产生基于因果的攻击链的简单总结。据此，分析人员可以快速判断系统是否遭受了入侵、了解攻击者是如何发动攻击的以及确定攻击带来的影响。

实时检测相对于取证分析（Forensic Analysis）而言，存在下面几个挑战：

事件（Event）存储和分析：如何高效地存储上百万条记录，并在几秒钟的时间内筛选这些数据
将实体（Entities）按优先级排序：如何协助分析人员，在大量的数据中优先选出并放大最有可能是攻击行为的场景。
场景重构：如何从攻击者的入口点开始，简洁地总结攻击场景，并识别整个攻击行为的影响
处理常见的使用场景：如何处理类似于攻击期间活动的正常行为，如软件下载
快速地交互式推理：如何让分析人员通过数据有效地进行推理，比如在“可选择性假设”的情况下。

2.1 方法概览

来自不同操作系统的审计数据被处理成平台独立的图，其中顶点表示subjects（进程）和objects（文件、sockets）；边表示审计事件（读、写、执行等操作；连接）。这个图作为攻击检测、关联分析和场景重构的基础。

2.2 贡献

2.2.1 基于内存的依赖图表示

为了应对第一个挑战，本文开发了简洁的基于内存的依赖图表示，解决了如何高效地存储和分析事件的问题。基于主存的图算法可以比基于硬盘快几个数量级，这是本文能做到实时分析的一个重要因素。在实验中能够在14秒内处理79小时的FreeBSD审计数据，内存消耗84MB，该速度比数据生成速度快20K倍。

2.2.2 基于标签

为了应对第二个挑战，本文开发了基于标签（tag-based）的方法来识别最有可能涉及攻击的subjects、objects和events。标签代表对数据（objects）和进程（subjects）的**可信度（trustworthiness）和敏感度（sensitivity）**的评估。

2.2.3 利用标签进行溯源和影响性分析

为了应对第三个挑战，本文开发的算法可以使用标签来对攻击进行溯源和影响性分析。从告警产生的位置来时，回溯分析算法可以根据图中的依赖性识别攻击的源头；从攻击源头开始，前向搜索算法可以进行全面的影响分析。同时，本文提出了一些准测用来修剪这些搜索过程，从而生成简洁的图。实验结果表明，SLEUTH可以将38.5M的事件转换为包含130个事件的攻击场景图，其大小降低了5个数量级。

2.2.4 可定制的策略框架

为了应对最后两个挑战，本文提出了可定制的策略框架，用于标签的初始化和传播。本文的框架给出了合理的默认值，但也可以根据特定的操作系统或应用来进行调整，从而避免误报。

分析人员还可以测试攻击的“可选择性假设”，如果分析人员怀疑某个行为是攻击的结果，可以使用策略捕获这些行为，然后重新运行分析以发现其原因和影响（重放）。由于其处理和分析比数据的生成快上万倍，所以可以对假设进行高效、并行、实时的测试。

2.2.5 实验评估为DARPA TC项目

在此次评估中，攻击活动模拟现代的APT组织在Windows、FreeBSD和Linux上展开了为期两周的攻击。在评估中，SLEUTH可以做到：

在几秒钟的时间内，处理包含数千万事件的审计日志
成功地检测和重构攻击细节，包括攻击入口点、在系统中的活动和逃逸点
过滤与攻击不相关的事件（削减率可以到达100K倍），从而可以提供一个关于攻击的几乎没有噪声的语义表示
较低的误报率和漏报率

该系统设计的目的不在于检测出最高级的APT攻击，而是在给定许多未知可能性的情况下，不需要人工干预，该系统就能够实时的给出一个按照威胁程度排列的结果。

3 主存依赖图

为了支持快速检测和实时分析，本文以图作为数据结构存储依赖关系。一种可行的方法是使用图数据库，例如Neo4J、Titan，但是除非内存足够大，否则这些数据库在运行许多图算法时会受到限制；另外，对于我们的问题来说，一般的图数据库内存消耗太高，即便是进行过内存优化的两个图数据库STINGER和NetworkX，存储一条边也要消耗250 bytes和3 KB。因此，本文提出了一种更加节省内存的依赖图设计，每条边仅占10 bytes，在实验中存储38M的事件仅需要329MB的内存。

依赖图包含两种类型的实体：

Subjects：
- 表示进程；
- 属性值包括：process id（pid）、命令行、所有者（owner）以及代码和数据的标签
Objects：
- 表示实体，例如文件、pipes、网络连接
- 属性值包括：名称、类型（文件、pipe、socket等）、所有者和标签

事件：subjects和objects之间或者两个subjects之间带标签的边，用 $r e a d 、 c o n n e c t 、 e x e c v e$ 来表示

为了减少依赖图的存储需求，在所有可能的地方，使用32-bit的标识符而不是64-bit的指针，这使得单台主机的依赖图可以存储40亿的subjects和objects，我们所使用的数据集远小于该数字。

本文的设计强调实体的简洁数据结构，然而事件的简洁性更为重要。因为事件的数量要比实体大两个数量级，而且事件和实体的比例随着时间而增加。因此我们需要为事件设计一个更加简洁的表示，使许多事件仅用6 bytes就能表示。

事件存储在subjects中，从而消除了subject-event的指针、事件标识符（event id）的需求。他们的表示采用可变长编码，在通常情况下可以采用4 bytes，当需要时可以扩展到8、12或者16 bytes。

（不懂）大多数事件是对objects进行操作，并且有时间戳。由于每个subject的事件顺序保持不变，因此我们无需为时间戳设置微秒级的粒度，而是选择了毫秒级的粒度。另外，我们仅存储同一subject中自上一个事件以来的相对时间，这使得我们在通常情况下可以使用16-bits来表示时间戳。

object使用索引指向object标识符的per-subject表。这些索引可以看作文件描述，他们通常都是一些较小的值，因为大多数的subjects使用了相对较少的objects，这使得object引用（索引？？）可以用8 bits或更少来表示。

我们用3 bits或更少对经常出现的事件名称进行编码，如open、close、read和write。这给我们留下了几位用于存储事件变量信息的摘要，同时仍在32位之内。

（重要）对于取证分析来说，需要我们从object追溯subject。鉴于此，我们需要使用object-event记录来维护objects中的事件信息。该记录仅维护事件的一部分子集，具体而言，比如像read和write这样会导致数据流的事件。object-event记录可以通过存储一个指向对应subject-event记录的引用来进一步收缩，而不是复制完全一样的信息。

类似于subject-event记录，我们对object-event记录也采用可变长编码，使得他们在通常情况下只需要16 bits来存储。我们注意到，object一次仅被一个subject操作，这个subject可能会在该object上进行一系列的动作，比如打开、读、写、关闭。每个动作都对应一个subject-event记录和object-event记录，由于这些记录的subject和object是相同的，所以我们可以在object-event记录中重用subject，从而在大多数记录中可以不存储subject标识符。

接下来，我们允许object-event记录为subject中的事件记录存储一个相对索引，subject中两个连续的事件记录可能比较接近，一般会是几十或者几百个。这意味着存储在object-event记录中的相对索引大多数情况下12 bits就够了，所以我们分配16 bits足矣。

（总结）这种设计使我们使用6 bytes就可以存储双向的带时间戳的边，subject-event记录占4 bytes，object-event记录占2字节。在实验中使用更大的数据集时，平均每个事件占用内存也在10 bytes以内。可变长编码还使得我们可以表示重要但出镜率比较少的事件，比如 $r e n a m e 、 c h m o d 、 e x e c v e 等$ 。

4 标签和攻击检测

问题：标签是什么？？

我们使用标签来描述objects和subjects的可信度和敏感度。对可信度和敏感度的评估基于以下三个因素：

起源（Provenance）：依赖图中，subject或object直接祖先的标记
系统先验知识：我们对一些重要应用行为的了解，比如远程接入服务器、软件安装程序和重要的文件（/etc/passwd 和 /dev/audio）
行为：观察subject的行为，并将其与预期行为进行比较

一个默认的策略被用从从input到output传播标签：为output分配input的可信度标签中的最低值，以及机密性标签的最大值（也就是说，入口点的行为是危险的，出口点的行为也被标注为危险；入口点的数据是机密的，出口点的数据也被标注为是机密的）。这是一种保守的策略，该策略可能会导致一些良性事件被错误地识别为恶意事件（over-tainting），但绝不会漏掉攻击。

标签在SLEUTH中扮演了核心角色。它为攻击检测提供了重要的上下文信息，每个事件都在这些标记组成的上下文中进行解释，以确定其导致攻击的可能性。此外，标签对我们的前向和回溯分析的速度也很有用。最后，标签为消除大量与攻击无关的审计数据也起到了关键作用。

4.1 标签设计

如下定义可信度标签（trustworthiness tags，t-tags），可信度依次降低：

良性可信标签（Benign authentic tag）：为数据和代码分配该标签，其来源（source）为良性且可靠性可被验证的
良性标签（Benign tag）：为数据和代码分配该标签，其来源为良性，但是来源可靠性未被充分验证
未知标签（Unknown tag）：为数据和代码分配该标签，但是其来源未知

策略（policy）定义了那些来源是良性的，哪些来源验证时充分的；策略的最简单情况是白名单。如果对于某个源，没有策略应用在它上面，那么这个源则被打上未知标签。

如下定义机密性标签（confidentiality tags，c-tags），机密性依次降低：

Secret：高度敏感的信息，例如登陆凭证、私钥
Sensitive：数据的披露可能会对安全产生重大影响，例如，披露了系统中的漏洞，但没有为攻击者提供访问系统的直接途径。
Private：资料的披露涉及私隐，但未必构成安全威胁。
Public：可以被公开的数据

我们设计的一个重要方面是分离代码和数据的t-tag。具体而言，即一个subject给定两个t-tag，一个表示其代码可信度（code trustworthiness，code t-tag），另一个表示其数据可信度（data trustworthiness，data t-tag）。这样的设计可以削减重建场景的规模，加快取证分析的速度。而机密性标签仅仅与数据相关联。

（重要）已经存在的objects和subjects使用标签初始化策略分配初始标签。在系统执行过程中还会产生新的objects和subjects，它们由标签传播策略分配标签。最后，基于行为的检测策略来检测攻击。

4.2 基于标签的攻击检测

检测方法不应该要求知晓特定应用的一些细节，因为这需要有关应用程序的专家知识，而在动态环境中，应用程序可能会频繁更新。

我们不把着眼点放在变化的应用行为上，而是着眼于攻击者的高级别目标，比如后门插入和信息窃取。具体而言，我们结合了攻击者的动机和手段的推理，注意到我们提出的标签就是用来捕获攻击者的手段：如果一段数据或代码有 $未知标签$ ，那么它就是由不受信任的源产生的。

根据攻击者的攻击步骤，我们定义了下面包含攻击者目标和手段的策略（Detection Policy）：

不受信任的代码执行：当一个拥有高code t-tag的subject执行或加载拥有低t-tag的object时，便会引发警报
被拥有低code t-tag的subject修改：当拥有低code t-tag的subject修改一个拥有高t-tag的object时，便会引发警报。修改的可能是文件内容或者文件名、文件权限等。
机密文件泄露：当不可信的subjects泄漏敏感数据时，将触发警报。具体地说，也就是具有sensitive c-tag 和 unkonwn code t-tag的subject在网络中执行写操作时会触发警报。
为执行准备不可信的数据：该策略由一个拥有unknown t-tag的subject的操作触发，该操作使一个object可执行。这样的操作会包含chmod和mprotect

一点优势：值得注意的是，攻击者的手段并不会因为数据或代码经过了多个中间媒介之后而被“稀释”。啥意思呢？举个栗子：对于不受信任的代码执行策略来说，如果直接从未知网站加载数据的话，当然会触发警报。但是，当这些数据是被下载、提取、解压缩，甚至有可能是编译之后再加载的，在经过了重重转化之后，只要数据被加载，该策略仍然能够被触发。随后再进行回溯分析，就可以找到漏洞利用的第一步。

（与其它探测器合作的能力）另外，其它检测器的输入可以很容易地被集成到SLEUTH中。比如说，某个外部的检测器将一个subject标为可疑，这个时候再SLEUTH中可以将该subject的code t-tag标为unknown，从而后面的分析都会受益。此外该操作也会保留图节点之间的依赖关系。

被不受信的代码执行所触发的策略，不应该被认为工作在静态环境中（需要动态匹配策略），静态环境意味着不允许新代码产生。实际上，我们期望可以连续地更新和升级，但在企业环境中，我们不希望用户下载未知代码。因此，下面会叙述如何支持标准化的软件更新机制。

5 策略框架

本文开发了一个灵活的策略框架（policy framework），用于标签的分配、传播和攻击检测。我们使用基于规则的记法来描述策略，例如：

$\operatorname{exec}(s, o): o.ttag < benign \rightarrow alert ("UntrustedExec")$

这条规则被触发的条件是：当一个subject $s$ 执行了一个object $o$ （比如文件），而 $o$ 的t-tag要小于良性。

在该策略框架中，规则通常与事件关联，并且包含objects或subjects的属性的一些条件，这些属性包括：

name：使用Perl正则表达式来匹配object name和subject命令行
tags: 条件中可以放置objects或subjects的t-tags或者c-tags。对于subjects来说，代码和数据的t-tag可以分别使用
所有权和权限：条件中可以放置objects和subjects的所有权，或者objects和事件权限

不同类型的策略有不同的作用：

检测策略：引发警报
标签初始化和传播策略：修改标签

（干嘛的？）触发点（trigger points）：为了更好地控制不同类型策略的匹配，我们将策略与触发点联系起来。此外，触发点允许有相似目的的不同事件共享策略。

在这里插入图片描述

上图展示了策略框架中定义的触发点， $d e f i n e$ 表示一个新的object，比如一个新网络连接的建立、首次提及一个已经存在的文件、新文件的创建等。

（检测策略匹配过程）当事件出现时，检测策略就会被执行。后面，除非手动配置，否则仅当目标subject或object（某个信息流的终点，Target）发生变化时，检测策略才会被再次执行。

（标签策略）然后，标签策略按照指定的顺序进行尝试，一旦规则匹配，被规则指定的标签将会被分配给目标事件（Target，也就是subject/object）

5.1 标签初始化策略

该策略被init trigger唤醒，然后将初始化标签应用于新的objects（subject呢？），或者早已存在但是在审计数据中第一次提及的objects。回顾一下，当一个subject创建了一个object的时候，默认object会继承该subject的标签，但是用标签初始化策略会将其覆盖。

仍使用正则表达式来为object定义初始化标签：
在这里插入图片描述

5.2 标签传播策略

该策略可以覆盖默认标签。

该策略还可以防止“过度污染”，例如某应用每次被唤醒的时候，都会读写 $bash\_history$ 文件，但是该操作是正常的，下面的策略对该文件不进行任何操作：

$propRd (s, o): match (o.name,^{\prime\prime}\backslash. bash_history$^{\prime\prime}) \rightarrow skip$

下面的策略将bash读取文件的行为视为加载（load）：

$\begin{aligned}\text{propRd}(s,o):&\text{match}\left(s.cmdline,^{\prime\prime}/\text{bin}/\text{bash }$^{\prime\prime}\right)\rightarrow\\text{s.code_ttag}=\text{s.data_ttag}=o.t tag,s.ctag=o.ctag\end{aligned}$

下面的策略对sshd的行为进行任何操作。虽然受信任的服务，比如sshd会与不受信的站点进行交互，但是这些服务被认为可以自我保护，并且仅允许授权用户访问系统，因此这样的服务不应该给他们的数据可信度降级。同样从不受信站点下载的软件安装包或更新包，但是在安装之前会验证受信的软件提供商前面。

$propRd (o, s): match (s.cmdline,{\prime\prime}\hat{}/sbin/sshd${\prime\prime}) \rightarrow skip$

另外，当登录阶段完成之后，通常通过执行setuid操作来标识，所以应该为进程分配适当的标签：

在这里插入图片描述

6 基于标签的双向分析

6.1 回溯分析

回溯分析的目标是识别攻击的入口点，入口点是图中入度为0的节点，并且被标记为untrusted。通常是网络连接，但有时也会是其他形式，比如U盘中的文件。

回溯分析的起点是检测策略产生警报的地方。每个警报都与一个或多个实体相关，这些实体在图中被标记为可疑节点。反向搜索涉及对图的反向遍历，从而识别由可疑节点连接到入口点的路径。我们注意到，在这样的遍历和接下来的讨论中，依赖关系边的方向是相反的。反向搜索带来了几个重大挑战:

性能：依赖图可能包含数亿条边。警报数可以达到数千。在这么大的图上执行反向搜索，会消耗大量的计算资源。
多路径：通常，从可疑节点向后可访问多个入口点。然而，在APT攻击中，通常只有一个真正的入口点。因此，简单的反向搜索可能会导致大量的误报

标签可以用来解决这两个挑战。一方面，标签的计算和传播本来就是一种简洁的路径计算。另一方面，如果节点的标签值是unknown，那么该节点很有可能会构成攻击路径。如果节点A的标签是unknown，这意味着至少存在一条路径，从不受信任的入口点指向节点A，这样节点A就比其他拥有良性标签的邻居节点更有可能是攻击的一部分。使用标签来进行反向搜索，消除许多无关节点，极大地减少了搜索空间。

基于此，我们将反向分析当作最短路径问题的一个实例，标签被用来定义边的代价（cost）。一方面，标签能够“引导”搜索沿着攻击相关的路径，并远离不相关的路径。这使得搜索可以在不必遍历整个图的情况下完成，从而解决了性能方面的挑战。另一方面，最短路径算法通过选择最接近可疑节点的入口点（以路径成本衡量）来解决多个路径的挑战。

计算最短路径使用Dijkstra算法，当入口点被加入到路径中时，算法就停止。

代价函数设计：对于那些表示节点依赖关系的边，如果其标签是**“未知”，则为其分配较低的开销**；其它节点分配较高的开胶，具体地说：

从一个“未知”数据/代码 t-tag 的节点，到一个“良性”代码/数据 t-tag 节点的边，为其分配代价为0
从一个“良性”代码/数据 t-tag 的节点引出的边，为其分配一个较高的代价
从已有“未知” tag 的节点之间引入边，为其分配代价为1

与未知 subject/object 直接相关的良性 subject/object 表示图中恶意和良性部分之间的边界。因此，它们必须包含在搜索中，因此这些边的代价是0。

良性实体之间的信息流动不是攻击的一部分，因此我们将它们的代价设置得非常高，以便将它们排除在搜索之外。

不可信节点之间的信息流可能是攻击的一部分，因此我们将它们的代价设置为一个较低的值。它们将被包括在搜索结果中，除非由较少边组成的可选路径可用。

6.2 前向分析

前向分析的目的是为了评估攻击的影响。通过从一个入口点开始，发现所有依赖于入口点的可能影响。与反向分析类似，主要的挑战是图的大小。一种简单的方法是，标记所有从入口点可到达的 subject/object，这些 subject/object 是通过反向分析得到的。不幸的是，这种方法将导致影响图太大。

在实验中，利用这种方法得到的影响图包含数百万条边，利用我们的简化算法可以降低100到500倍。

一个降低其大小的方法是使用距离阈值 $d_{t h}$ ，来排除那些距离可疑节点太远的点，分析人员可以调节该阈值。我们使用在回溯分析时使用到的 cost 。

（为什么回溯分析不考虑？？）不同于回溯分析的是，我们考虑机密性。特别的，一条边两端的节点，一个由高机密性标签，另外一个具有低代码 integrity（可信度？？）标签（如未知进程）或者低数据 integrity 标签（如未知socket），那么为这条边分配代价为0；而当另一个节点由良性标签时，为其分配较高代价值。

7 实验评估

（请求公开源码）

7.1 数据集

在这里插入图片描述

数据集同样来自DARPA TC项目，时间跨度为358小时，包含7300万事件。最后一行是历经3-5天从4台Linux服务器上收集到的良性数据，是本文作者在其实验室中自己生成的。

7.2 重建结果

（1）下图是W-2的攻击场景图：

在这里插入图片描述

（2）下图是F-3的攻击场景图，攻击者使用窃取的ssh凭证

scp：secure copy，用于远程文件拷贝

在这里插入图片描述

7.3 总体效果

（1）经典APT攻击阶段汇总

在这里插入图片描述

除了上述阶段，其它比较重要的APT阶段包括后门植入、C&C服务器、痕迹清除（包括攻击过程中投放的可执行文件和创建的文件）和数据窃取。

下图通过计数关键文件、网络连接、攻击涉及的程序数量，将攻击场景重建结果分割：

在这里插入图片描述

其中，入口实体包括入口点以及与入口点进行通信的进程。Exit Points用于逃逸，比如网络套接字。

7.4 误报

评估SLEUTH在良性环境下的表现，用到了作者在自己的实验室中生成的良性数据。四台服务器上的数据主要来源于软件的更新和升级：

在这里插入图片描述

正如前面所提到的，策略应该配置为：允许使用企业中批准的标准方法进行软件更新和升级。对于Linux来说，我们有一个策略规则允许这样的操作：当使用apt命令或者unattended-upgrades执行dpkg时。因此，所有10K+的文件下载被标注为良性，而SLEUTH也没有产生警报

7.5 运行时间和内存使用

测试环境是搭载2.8GHz AMD Opteron 62xx 处理器和48GB主存的Ubuntu 16.04

在这里插入图片描述
例如L-2，SLEUTH使用了大约329MB内存来存储跨越3.5天所产生的38.5M的事件。在大数据集中，SLEUTH只需要8 bytes内存来存储每个事件；而小数据集中需要20 bytes.（why ？）

第四行展示了总运行时间，包括消耗数据集、构建依赖图、检测攻击、重建攻击场景。由于我们使用了标记，因此分析所需的大部分信息都可以在本地获得。这是我们性能提升的主要原因。

“Speed-up”一栏说明了SLEUTH的性能优势。它是SLEUTH可以同时处理的数据流的数量，如果CPU的使用是唯一的限制的话。

7.6 为数据和代码分别分配标签的好处

通过在代码可信度上进行检测和前向分析，可以削减掉大量的警报，极大减小前向分析输出的规模。

下图展示了使用单个的可信度标签和分离可信度标签（code/data）时，所产生报警数目的不同，注意到在一些情况下，报警数量减少了100-1000倍：

在这里插入图片描述

下图展示了因为标签的分割，前向分析所达到的提升。前向分析的输出被输入到简化引擎中，结果如第六行所示；Total列是Split t-tag和SLEUTH Simplification共同作用的结果。

在这里插入图片描述

Alst0n

关注

8
点赞
踩
10

收藏

觉得还不错? 一键收藏
3
评论
Paper Note - SLEUTH：基于COTS审计数据的实时攻击场景重构

原文标题：SLEUTH: Real-time Attack Scenario Reconstruction from COTS Audit Data原文作者：Md Nahid Hossain, Stony Brook University; Sadegh M. Milajerdi, University of Illinois at Chicago; Junao Wang, Stony Broo...
复制链接

扫一扫