针对Office宏病毒的高级检测

前言

在之前的文章——《威胁狩猎的最佳实践》里提到过一个针对钓鱼邮件的检测场景，本文会详细分享下当时使用的技巧

遵循前文提到的威胁狩猎流程，让我们从威胁假设(hypothesis)出发：

攻击者可能发送带有恶意附件的钓鱼邮件，诱导受害者点击从而获取对方的系统控制权限

期间会借助 Atomic 工具完成攻击复现，再对具体的过程细节进行分析取证，然后深入研究、剖析其行为特征

最后输出检测规则或者 dashboard，作为本次威胁狩猎活动的产出

PS：注意，这里只是提供一种检测思路，测试过程均在实验环境下完成，并不代表实际工作效果

分析取证

在对特定攻击活动做数字取证(Digital Forensics)的过程中，通常我会采用漏斗状的思维模型，一步步缩小观测范围，聚焦目标行为特征

简单做了张图，大概是这么个意思：

采集全量日志

针对威胁假设的场景，首先我们需要尽可能地保证 office 办公软件的所有行为无处遁形

为了实现图中的逐层分析，还是拿出我惯用的 sysmon，借助其配置文件来完成，千万别小瞧了这些配置，里面可是有宝藏的！

第一步，建立 OfficeWatch.xml 的配置文件，部分内容示例如下：

<Sysmon schemaversion="4.70">
  <HashAlgorithms>md5</HashAlgorithms>
  <CheckRevocation/>
  <EventFiltering>
    <RuleGroup name="Process Creation-Include" groupRelation="or">
        <ProcessCreate onmatch="include">
          <Image name="" condition="end with">WINWORD.EXE</Image>
          <ParentImage name="" condition="end with">WINWORD.EXE</ParentImage>
          <Image name="" condition="end with">EXCEL.EXE</Image>
          <ParentImage name="" condition="end with">EXCEL.EXE</ParentImage>
        </ProcessCreate>
    </RuleGroup>
    <RuleGroup name="Process Creation-Exclude" groupRelation="or">
        <ProcessCreate onmatch="exclude">
        </ProcessCreate>
    </RuleGroup>
    <RuleGroup name="Network Connect-Include" groupRelation="or">
        <NetworkConnect onmatch="include">
          <Image name="" condition="end with">WINWORD.EXE</Image>
          <Image name="" condition="end with">EXCEL.EXE</Image>
        </NetworkConnect>
    </RuleGroup>
    <RuleGroup name="Network Connect-Exclude" groupRelation="or">
      <NetworkConnect onmatch="exclude">
      </NetworkConnect>
    </RuleGroup>
    <RuleGroup name="File Create - Include" groupRelation="or">
      <FileCreate onmatch="include">
          <Image name="" condition="end with">WINWORD.EXE</Image>
          <Image name="" condition="end with">EXCEL.EXE</Image>
      </FileCreate>
    </RuleGroup>
    <RuleGroup name="File Create - Exclude" groupRelation="or">
      <FileCreate onmatch="exclude">
      </FileCreate>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

指定 office 软件相关的文件名，保证其进程、文件、网络、DLL 加载和注册表等日志均能被全量采集，同时避免干扰信息

另外，这一步的主要目的不仅是为了保持观测目标的可见性，更是为了下一步缩小观测范围而建立遥测数据的白名单

例如，平常我们在打开 word 文档的过程中，会产生与微软服务器间的通信，这些是我们需要进行加白处理的

同样的，这些加载的 DLL 文件也可以建立一份白名单，当然也别忘了多加留意它们的签名状态(SignatureStatus)

最后，分析、汇总上述成果，建立一份新的配置文件，用于过滤 office 办公软件的正常行为，将其命名为 OfficeShush.xml

过滤正常行为

关于 OfficeShush.xml 文件的迭代，其实也就是我们对 office 软件相关进程建设行为基线的过程

这一步需要我们在实验环境下考量全面，夯实基础，再去生产环境中慢慢打磨优化

然后，便得引入丰富的恶意样本，分析其在过滤正常行为后的特征表现

这里其实就是攻击复现的过程了，以 T1204.002 为例，跑完攻击脚本，看看会有哪些有意思的发现：

—— 一些脚本文件的创建

—— 一些异常的命令执行和父子进程关系

—— 一些特定行为(例如运行宏、XMLDOM、WMI等)才会加载的 DLL

聚焦可疑特征

通过对各类恶意样本或者具体攻击方式做深入分析，我们可以简单梳理一些常见攻击行为会表现出来的特征：

— 可疑文件的落地(释放脚本或可执行文件)
— 涉及敏感注册表位置的修改
— 可疑DLL文件的加载行为(加载COM、WMI、或.NET功能所必需的DLL文件)
— 可疑的网络请求行为(与云服务商或者奇怪的域名通信)
— 异常的父子进程关系(office软件调用powershell、cmd命令行)
— …

整理好这些特征点，我们可以凭此生成新的日志采集配置文件，或者给相应的遥测数据打上标签，或者直接加工后转换成检测规则

但是在此之前呢，我想先介绍一种告警手段 —— Risk-Based Alerting(RBA)

一些安全运营人员可能对“元告警”(Meta-Alert)的概念并不陌生，这类告警通常由其它安全设备上报而来

比如在 SIEM 上消费由 EDR 产生的病毒或后门类的告警，这种可以称之为 “meta alert”

在此基础之上，我想谈论的情况是：在一段时间内，有两条及以上针对同一主机(事件)的检测规则，组合产生了一条告警

什么时候应该使用这种告警方式呢？

在很多场景中，SIEM 或 SOC 平台上的规则检出只能被视为一种弱信号(weak signals)

它们更适宜被归类成 observable 或 indicator，而不适合直接用作告警，否则会引起运营人员的告警疲劳

此时如果我们通过一种检测方式对这些信号做关联分析，最后产出告警，这一思路就被称作 RBA

受限于手头的工具和平台，本文我只能借助 splunk 演示一种类似的检测方式，通过生成一段 Hyper Queries 来达到差不多的效果