針對Office宏病毒的高級檢測

前言

攻擊者可能發送帶有惡意附件的釣魚郵件，誘導受害者點擊從而獲取對方的系統控制權限

期間會借助 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 來達到差不多的效果

威脅分析

行為檢測

根據前面整理出的這些 office 宏病毒相關的可疑活動或者高危操作的行為特征，先寫一些簡單的規則給它們定個性

這一步可以借助 splunk 給符合特定行為的 sysmon 日志打上不同的標簽，或者進行危害評分，便于后續做關聯分析

比如攻擊者可能會利用宏代碼調用 cmd、powershell 等進程，進一步完成惡意命令執行的操作

或者攻擊者會將 payload 寫入磁盤，以特定后綴形式的文件在受害者主機落地

風險判定

放在平時，或許很多人會直接拿著這些行為特征輸出成告警

但是針對 office 郵件釣魚這類頻發場景，我們不妨深入研究下，加入一些算法以提高告警置信度

以下演示中，我會為不同的行為簡單地指定風險評分，最后進行求和匯總，將超過特定閾值的一系列行為視作高危操作

為方便讀者自行對比，找了一篇友商近期的分析文章：https://mp.weixin.qq.com/s/1L7o1C-aGlMBAXzHqR9udA

然后上 ANYRUN 拿了份樣本：https://app.any.run/tasks/300229f4-dd97-42d8-bbce-72274ef8b9e9

實驗過程中的檢測效果如下：

演示代碼放在這里：https://github.com/Moofeng/DemoCode/blob/main/office_detection_spl

結合上述文章和檢測結果，可以看到攻擊過程幾個異常點都能很好的標識出來，例如 background.dll 文件的落地和通過 COM 對象執行計劃任務等關鍵步驟

最后的判定結果還是具備一定參考意義的，當然，具體的評分體系需要自行設置和優化