APT检测论文分享——CONAN: A Practical Real-Time APT Detection System With High Accuracy and Efficiency

文章来源:TDSD’20


前言

  本篇论文是关于APT检测的文章,不同于大部分以往的APT检测模型,本文模型是一种启发式的模型,并不需要系统存储大量长时性的溯源图或者审计日志,其使用具有记忆性的类似状态机的模型来对当前与历史的事件进行综合处理与检测,想法十分新颖。但是同时我认为作者在写论文的时候在部分地方表述并不清晰,很多地方我读了又读才能勉强推测理解作者的意思,因此撰写此文章将我的想法与大家交流。(PS:请大家结合原论文与本篇解读一起食用,这样效果会更好哦!)


提示:以下是本篇文章正文内容

一、问题描述

1.需解决的问题与目前的该领域研究现状

  近些年来,APT攻击盛行,其复杂多变的攻击技巧以及巨大的危害性使得APT实时检测系统变得越来越重要。
  目前针对APT检测已经有了一些解决办法,但是相应的其也存在一些缺陷:
  (1)基于上下文与learning的方法(StreamSpot、Unicorn等)通过分析溯源图等信息对异常活动进行打分与聚类,其只能提供恶意分数或分类结果,并不能对其有很好的解释。
  (2)基于启发式的方法(Holmes)对APT攻击的多个阶段进行不同攻击技术的检测并计算可疑分数,但对于部分APT攻击来说其中很多阶段并不是实施攻击的必需环节,并且先验知识随着APT攻击的迭代进化会慢慢失效。
  (3)除此之外,由于APT攻击可以持续数月甚至数年,基于溯源图等信息的检测方法在数据存储上难免会遇到内存与效率方面的问题。

2.本文方法概述

  本文从检测的准确率和效率方面出发,构建了CONAN检测模型:
  (1)在准确率方面,CONAN在APT攻击完整的11个阶段中选取3个最必要的阶段进行攻击检测,将他们进行组合从而区分恶意与良性行为。
  (2)在效率方面,作者提出了一种基于状态的检测框架,针对系统的进程或文件进行状态的赋予与追踪,内存中仅仅保留当前存在进程的状态,无需保留完整的溯源图或审计日志信息。
  (3)针对APT攻击的具体行为,CONAN可以利用系统中存储的极少数重要事件进行APT重建与语义解释,从而能够完整构建APT攻击的各个步骤的信息,无需对恶意行为进行赋分判断。

3.威胁模型

   在本文中,我们假设事件日志是可信的。评估中使用的所有攻击都无法被传统的反病毒系统检测到。相反,我们不需要假设整个攻击发生在我们系统安装之后。因此,可以检测到预装的恶意软件和恶意代码。


二、CONAN检测模型

1.模型总览

在这里插入图片描述
   上述为本文的完整模型,其在客户端通过多级数据收集器获得审计日志、堆栈调用等数据。之后根据其中部分的数据进行启发式的规则以及进程或文件语义状态的定义,通过该定义对事件信息进行处理,获得事件状态图以及相关联的文件信息。一旦某一进程的状态进入恶意状态,则引发警报,从数据库中获取相关事件进行攻击重建。

提示:我在阅读API调用那块的时候并没有完全理解作者想描述的意思,因此可能分析不到位,但是这并不影响对于整个模型框架的整体把握。


2.三阶段检测模型

   作为一个APT检测模型,我们要考虑究竟要以什么为标准检测攻击,什么样的行为我们认为是攻击,因此在模型介绍的开端,我首先介绍本文作者提出的他们认为的APT攻击三个最重要的阶段,以其为依据进行APT攻击的检测。

2.1 三阶段产生想法与内容

   在另一种启发式的方法“HOLMES”中,其根据MITRE ATT&CK的7个APT攻击阶段分别制定了检测方法,检测到的阶段越多,攻击可能性越大。但是其会存在一些问题,比如每个阶段有数百种技术,检测会有高开销;攻击技术容易发生变化,较难检测到未知攻击;同时存在一种情况,就是检测的攻击阶段多不能说明存在攻击,阶段少也不能证明行为的合法性。
   因此,在调研了数百次APT攻击后,作者发现其中大部分攻击会存在一些共有阶段,列举如下:(1)部署和执行攻击代码;(2)收集隐私信息或造成伤害;(3)泄露数据。
  详细来说,三个阶段描述如下:
  (1)部署和执行攻击代码:任何进程行为背后都是代码执行的结果,攻击者首先要部署其恶意代码到受害者主机后才能执行攻击。针对该阶段,CONAN监控不可信数据流(包含网络与可移动设备的数据)以及不可信控制流(包含代码执行或进程产生的原因),结合用以检测该阶段。
  (2)收集隐私信息或造成伤害:攻击者的攻击目的无非为窃取数据或对服务器造成伤害,本阶段可以通过检测数据流观察隐私数据的流向,从而进行检测。
  (3)泄露数据:现实中经典的APT攻击主要通过网络向恶意服务器泄露数据,该阶段作为(2)的后续步骤,也是APT攻击中必不可少的阶段。
  最后,将三个阶段总结为:检测“执行可疑代码与恶意行为的进程”,用以精确地检测APT攻击。

2.2 三阶段检测的挑战

检测“执行可疑代码与恶意行为的进程” 的三个挑战:
  (1)哪个代码被执行了?
  (2)这段代码是从哪来的?
  (3)它是怎么被执行的?
解决挑战一—哪段代码被执行了:
在这里插入图片描述
  使用上面堆栈结构数据,调用堆栈中存储的是不同代码块的返回地址,各个代码块属于系统中正在执行的线程,根据返回地址对应目标是否安全决定所属线程是否可信。
解决挑战2—执行的代码是从哪里来的:
  追踪不可信的数据流,例如某个进程存在与互联网的连接,那么该进程写入本地的文件中就可能会包含互联网的数据,如果是我们系统未授权的文件下载,我们将类似的文件置为不可信数据。
解决挑战3—代码是怎么被执行的:
  追踪不可信的控制流,特别是一些被可疑进程或线程创建出的新进程,这些进程可能当前没有恶意行为,但之后会有风险。
提示:那么具体来说,对于上述挑战2与3,究竟是怎么实现的呢,且看下文的叙述,我也认为是本文最关键的部分,其用状态描述系统实体,从而方便检测


3.基于状态的检测框架

3.1 状态检测框架简述

在这里插入图片描述

  那么到底在模型中实现上述挑战的解决方法,怎么追踪数据流、控制流呢?
  本文提出了基于状态的框架,其中的实体(包含进程、文件)类似于状态机,能够聚合上下文信息,表示该实体当前所处状态。最终我们可以根据系统中实体的状态判定攻击。同时,该框架无需像溯源图检测等方式随之累积保存大量数据,效率较高。
  具体如上图3所示,对于左侧的溯源图其中的某个进程notepad.exe,本文模型会像右侧图所示为其赋予语义,其中会包含该进程的行为、是否有互联网连接、进程是否包含恶意代码等等

3.2 状态定义

  根据我们之前总结的检测APT攻击的三个阶段,即(1)部署和执行攻击代码;(2)收集隐私信息或造成伤害;(3)泄露数据。我们将其总结成如下的多种不同类型的状态(本文中语义状态也被称为ASI—atomic suspicious indicators),每个ASI被用来定义实体:
  (1)攻击者为实现其目标执行的恶意行为,通常由私密数据流推断。
  (2)可疑代码的来源,即为何进程可以执行恶意行为,通常由不可信数据流推断。
  (3)主机对外交流的能力,通过网络活动推断。
  (4)为何某个进程会被执行,通常由不可信控制流推断。
  (5)一些可以描述攻击的额外特征
  那么具体每个类型中都包含什么呢,表1有一些示例,其中包含恶意行为、代码来源,网络情况和特征:在这里插入图片描述
  作者列出的部分ASI,其根据对应实体的种类(进程或文件)以及对应行为进行分类,从而表示数据流、控制流和流程行为的高级语义。这些ASI可以代表对应实体当前的状态,依据状态进行攻击检测。
  ASI的来源:作者认为分析系统审计日志可以推断出部分ASI,同时作者也分析了现实中大量的APT攻击,根据其行为与现有ASI进行对比,做了相应的补充。同时作者根据系统调用的API也完善了部分的ASI。

3.3 ASI的产生规则与携带ASI的数据结构

在这里插入图片描述
  根据实体的ASI与行为执行方向总结的规则(Rules),其中描述了进程或文件的产生以及相关数据的流向,具体如表2所示。该规则定义了新的实体应该赋予怎样的ASI以及对于现有实体根据不同的行为进行ASI的添加
  下面对于表2进行详细分析:针对系统进行的行为,一定是有源实体(主实体)和目的实体(客实体)的,比如系统某个进程写入新内容到文件里,此时主实体为进程,客实体为文件,方向为正向(forward),就如同表2中第四条所示。只不过表2表示的是主实体与客实体所包含的ASI都有哪些,如果主实体包含对应的ASI且有对应行为,则客实体就被赋予上述新的ASI。
在这里插入图片描述

  图5表示了带有ASI的实体的数据结构是什么样。下面解释一下蓝色箭头,其余箭头原理类似。对于父进程(Parent Process),其本身携带的ASI为P1(从表1中可查到是什么含义),其进行了写文件的行为,与规则4(R4,如表2第四行所示)对应,因此新的写入的文件则带有的ASI为F1,这是有规则定义的。
提示:对于上述数据结构,可以看到实体中还包含实体本身的信息,比如进程包含进程ID、名称等,文件包含文件路径和ID,这是属于实体本身自带的属性。

3.4 可以状态与攻击重建

  恶意状态是多个独立状态的组合,是对单个实体进行判断的。例如某个进程包含从网络下载不可信文件、执行恶意行为、与网络再连接等状态(每个行为都会对应一个ASI),那么我们会将其识别为”下载&执行”攻击。这些攻击定义是启发式的,人为分析出的。
  当每个进程被赋予除了Fea.类型以外的ASI时,则会引起警报,通过预先人为设定的攻击场景分析是否满足攻击条件,进而判断攻击。
  若为攻击,则通过之前存储的事件信息以及对应实体的ASI进行攻击重建,通过回溯ASI以及对应行为,可以在线性时间重建攻击。这里存储的事件为对任何实体的ASI进行改变的事件(也就是能与规则匹配的事件),相对于系统中所有事件,本类事件占比非常非常少,所占内存或磁盘空间基本可以忽略不计。


4.CONAN攻击检测示例

在这里插入图片描述
下面根据图7(a)所示的溯源图来详细分析该攻击本文CONAN检测模型是如何工作的,(a)中编号为系统执行的事件顺序:
  (1)当用户通过firefox浏览网页,该进程会定向到假IP,此时firefox进程会包含P1(ASI)。
  (2)之后攻击者利用firefox的脆弱性成功执行未知代码,动态调用堆栈检测到并将该线程从firefox进程中分离,将该线程标记为P12(ASI)。
  (3)firefox被攻陷,攻击者执行新的实体并且读取私密文件。对应实体文件会被ASI标记。
  (4)警报响起,根据实体ASI与规则定义攻击类型为“对良性应用程序的利用”。
  (5)之后,二进制文件cloud.exe被firefox下载,该文件被标记为F1,意味着是通过网络下载的。
  (6)firefox创建新进程,cloud.exe,其首先加载了firefox下载的cloud.exe,后该进程执行了截屏,并且将该不可信图片传送到了新的IP地址,被标记为执行了”来自网络的不可信代码”以及“由可疑进程创建”,赋予对应ASI,最终经过分析cloud.exe进程被确认为攻击,定义为“下载和执行恶意软件”。


三、总结

  以上就是我对本篇文章的总结,其中我没有分析实验结果,因为这个实验的结果其实挺短的,大家看一看图一乐就好,而且感觉很多实验结果说的很草率,也并没有横向和其他检测系统对比,如果后续大家有强烈要求我再补上。
  对于本工作,是一种启发式的APT检测模型,其中对于ASI、规则、恶意状态组合的定义都是人为的,这也是启发式模型的一大特点,如果后面有新的攻击也可以拓展,但是同样是人为拓展并不是自动的。
(PS:本篇文章我深知有些地方我也没有理解到位,但是感觉其中的逻辑我还是推敲出了一部分,因此发上来供大家参考并且和大家一起讨论,如果其中有不对的地方求轻喷!)

  • 4
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值