前言
攻擊者可能發(fā)送帶有惡意附件的釣魚郵件拦赠，誘導受害者點擊從而獲取對方的系統(tǒng)控制權限
期間會借助 Atomic 工具完成攻擊復現，再對具體的過程細節(jié)進行分析取證捻脖，然后深入研究含懊、剖析其行為特征
最后輸出檢測規(guī)則或者 dashboard，作為本次威脅狩獵活動的產出
PS：注意，這里只是提供一種檢測思路范抓，測試過程均在實驗環(huán)境下完成，并不代表實際工作效果
分析取證
在對特定攻擊活動做數字取證(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 文件也可以建立一份白名單楞抡，當然也別忘了多加留意它們的簽名狀態(tài)(SignatureStatus)
最后伟众，分析、匯總上述成果召廷，建立一份新的配置文件凳厢，用于過濾 office 辦公軟件的正常行為，將其命名為 OfficeShush.xml
過濾正常行為
關于 OfficeShush.xml 文件的迭代竞慢，其實也就是我們對 office 軟件相關進程建設行為基線的過程
這一步需要我們在實驗環(huán)境下考量全面数初，夯實基礎，再去生產環(huán)境中慢慢打磨優(yōu)化
然后梗顺，便得引入豐富的惡意樣本泡孩，分析其在過濾正常行為后的特征表現
這里其實就是攻擊復現的過程了，以 T1204.002 為例寺谤，跑完攻擊腳本仑鸥，看看會有哪些有意思的發(fā)現：
—— 一些腳本文件的創(chuàng)建
—— 一些異常的命令執(zhí)行和父子進程關系
—— 一些特定行為(例如運行宏吮播、XMLDOM、WMI等)才會加載的 DLL
聚焦可疑特征
通過對各類惡意樣本或者具體攻擊方式做深入分析眼俊，我們可以簡單梳理一些常見攻擊行為會表現出來的特征：
— 可疑文件的落地(釋放腳本或可執(zhí)行文件)
— 涉及敏感注冊表位置的修改
— 可疑DLL文件的加載行為(加載COM意狠、WMI、或.NET功能所必需的DLL文件)
— 可疑的網絡請求行為(與云服務商或者奇怪的域名通信)
— 異常的父子進程關系(office軟件調用powershell疮胖、cmd命令行)
— …
整理好這些特征點环戈，我們可以憑此生成新的日志采集配置文件，或者給相應的遙測數據打上標簽澎灸，或者直接加工后轉換成檢測規(guī)則
但是在此之前呢院塞，我想先介紹一種告警手段 —— Risk-Based Alerting(RBA)
一些安全運營人員可能對“元告警”(Meta-Alert)的概念并不陌生，這類告警通常由其它安全設備上報而來
比如在 SIEM 上消費由 EDR 產生的病毒或后門類的告警性昭，這種可以稱之為 “meta alert”
在此基礎之上拦止，我想談論的情況是：在一段時間內，有兩條及以上針對同一主機(事件)的檢測規(guī)則糜颠，組合產生了一條告警
什么時候應該使用這種告警方式呢汹族？
在很多場景中，SIEM 或 SOC 平臺上的規(guī)則檢出只能被視為一種弱信號(weak signals)
它們更適宜被歸類成 observable 或 indicator其兴，而不適合直接用作告警顶瞒，否則會引起運營人員的告警疲勞
此時如果我們通過一種檢測方式對這些信號做關聯(lián)分析，最后產出告警元旬，這一思路就被稱作 RBA
受限于手頭的工具和平臺搁拙，本文我只能借助 splunk 演示一種類似的檢測方式，通過生成一段 Hyper Queries 來達到差不多的效果
威脅分析
行為檢測
根據前面整理出的這些 office 宏病毒相關的可疑活動或者高危操作的行為特征法绵，先寫一些簡單的規(guī)則給它們定個性
這一步可以借助 splunk 給符合特定行為的 sysmon 日志打上不同的標簽箕速，或者進行危害評分，便于后續(xù)做關聯(lián)分析
比如攻擊者可能會利用宏代碼調用 cmd朋譬、powershell 等進程盐茎，進一步完成惡意命令執(zhí)行的操作
或者攻擊者會將 payload 寫入磁盤，以特定后綴形式的文件在受害者主機落地
風險判定
放在平時徙赢，或許很多人會直接拿著這些行為特征輸出成告警
但是針對 office 郵件釣魚這類頻發(fā)場景字柠，我們不妨深入研究下，加入一些算法以提高告警置信度
以下演示中狡赐，我會為不同的行為簡單地指定風險評分窑业，最后進行求和匯總，將超過特定閾值的一系列行為視作高危操作
為方便讀者自行對比枕屉，找了一篇友商近期的分析文章：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 對象執(zhí)行計劃任務等關鍵步驟
最后的判定結果還是具備一定參考意義的，當然西潘，具體的評分體系需要自行設置和優(yōu)化
