在实际生产环境中，对于行为基线之外的活动，仍然可能包含大量业务相关的正常行为，这时还可以运用长尾分析法，关注特定阈值之下的少数可疑行为
或者我们也可以检查下有哪些不规范的文件或者函数名，比如这里我只简单设置条件为未包含关键字 “.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 发起高权限的进程间访问
小结最后，这篇文章中贴的相关链接比较多，大部分都需要翻出去才能访问，所以如果遇到无法访问的情况其实是正常现象
有些地方的贴图不方便展示真实数据，只能贴网图或者在实验环境下截图，显示的数据样本会比较小，但是文中的结论实际上有大量样本支撑，基本可以放心食用
如有纰漏之处，或者其他有意思的发现，欢迎私信交流~~
本文由慕长风原创发布
转载，请参考转载声明，注明出处： https://www.anquanke.com/post/id/263193
安全客 - 有思想的安全新媒体
