单纯地分析样本其实是最简单的事情，属于手工作业，手工作业大部分情况下不符合现代社会发展规律，成本很高。一味地专注技术与反思积累最终肯定会成为技术专家，但国内的情况是技术专家往往会变成大头兵角色（技术也很重要是基石，但是要根据环境变化），因为安全行业核心技术是非常少的，所以在往技术专家职业规划前进的过程中要多关注业务等软技能的培养。两个多月的时间学到了很多东西，不仅仅是技术方面的，技术仍然是工具，思维方法是种子，最难的是设计解决方案与落地和业务价值思考并付诸行为，我觉得挺难的。在阅读文章前请问下自己几个问题，再次整理以前研究的时候记录的笔记，我也经常问自己这些问题，时刻保持职业危机感。
1、如何批量查杀这类的恶意文件？
2、在企业网络环境中如何精准查杀这类木马且低误报率？
3、终端安全防御中如何拦截与清除？
4、取证场景中如何自动化快速发现威胁？
5、未知驱动文件如何快速分析与提取特征与复用？
6、除了终端防御，企业整体防御中还有哪些地方需要补齐来阻止这种事情？
紫狐木马是最近几年很流行的木马，本身携带了不少对抗策略与底层攻防技术，但整体来说都是可以利用工具或技巧而发现，要在Windows环境做到极致地隐藏确实难度很大。例子最初的文件为MSI安装包，内部嵌入了恶意文件。
当然，黑客对自己的恶意木马通常会加壳处理，这里没有使用代码虚拟化技术，因此比较容易脱壳。
在仔细分析过程中发现使用了Delphi语言编写相关的木马， 使用特定语言编写木马对脱壳时找到程序原始入口点比较重要，可以利用相关语言的特征找到OEP。
如果双击执行后，会出现如下提示，并且要求用户重启系统，属于伪装的信息。
执行过程中会对注册表项PendingFileRenameOperations进行修改，属于一个异常行为，作用是利用系统配置来绕过 Windows 文件保护 (WFP) 以覆盖受保护的文件。
HKLMSystemCurrentControlSetControlSession ManagerPendingFileRenameOperations
具体写入注册表项PendingFileRenameOperations的内容，如下。
第一行是源文件，第二行是最终的文件，如果为空则是删除源文件，以此类推重启过程中就会绕过系统限制覆写文件，这种技术经常被用于卸载安装过程中残留文件。
在测试环境实验过程中，出于取证的目的，我们可以发现此处的sens.dll文件的属性中访问时间变动了，这是一个异常点，因为系统目录下的文件基本上不会存在属性信息变动的情况，除非是安装了更新等情况，因此如果以后在取证过程中遇到时如何快速找到这类异常点并分析原因呢？从防御者的角度确实值得思考。
测试过程中发现存在对抗行为，例如木马文件“C:WindowsAppPatchAcpsens.dll”无法复制到其余位置，该文件存在文件保护策略，且该目录下还存在隐藏文件，例如下图中的红色部分。
出于取证检测的目的，我们发现在路径C:Windows下的PFRO.log文件中记录了注册表项PendingFileRenameOperations实现后相关的行为痕迹，属于一个可以取证的异常点，而且修改日期是木马执行时间前后。
再次重启系统，依然会记录系统相关的行为痕迹，最新更新的一行记录里MpJskDrv.sys是系统自带的组件。
除了Windows10系统环境外，在Windows7中也存在对应的日志文件。
木马执行且系统重启后会删除PendingFileRenameOperations注册表项，所以后续取证的时候是找不到对应的注册表项的。
在脱壳VMP时发现无反调试反虚拟机机制，因此比较简单，且没有部分代码虚拟化，不然脱壳完对于部分虚拟化代码是比较麻烦的。
通过对VirtualProtect函数下软件断点等到代码段解密，权限恢复成只读之后（text与itext段可执行只读权限），下text与itext代码段的内存执行断点（x64dbg），F9运行直到中断在这两个节区范围来找到oep，于是最后重新在itext节区找到了疑似oep地址273210h（偏移为13210h），基址为260000h。
十六进制数据558BEC83的这种特征疑似是Delphi程序dll文件的入口点，如下。
疑似OEP地址为内存地址29685Ch（偏移为685Ch），基址为290000h。
VMP2的壳采用API混淆调用，会进入VM代码内部。
实现了rootkit功能，隐藏保护了C:WindowsSystem32MsCFA943C2App.dll，无法复制且无法查看。
通过系统回调的入口地址以及minifilter的过滤器函数地址发现可疑的地址0xfffff8008e9f0000，CmpCallback回调属于注册表回调监控，如下。
利用OpenARK通过该地址偏移逐步寻找PE文件头部特征，发现在地址0xfffff8008e9ef000出现PE头部特征，经过与已加载内核模块的地址比对发现不符合，断定该处为rootkit模块地址，换个角度思考一下，如果黑客去掉了rootkit模块的PE头部特征如何找到恶意模块呢？
也可以利用开源工具Volatility进行内存分析，虽然内存取证是比较好的方式，但是需要考虑真实的一线情况，例如如果在服务器上取证，服务器的内存肯定比桌面系统大，取证时文件体积过大不利于后续的分析，现在的场景多见于Windows环境，因此解决安全问题要因地制宜。此时使用driverscan插件无法检测到隐藏模块，但可以利用modscan插件找到可疑的模块dump_STORAHCI.sys，路径为??C:WindowsSystem32driversdump_STORAHCI.sys。
使用工具也需要了解工具背后的原理，为啥使用modscan插件可以找到隐藏驱动模块呢？
在一个正常的Windows系统上，会发现数百个内核模块，因此要找到恶意的内核模块需要做一些工作。利用modules插件可列出内核模块，原理是通过PsLoadedModuleList双向链表遍历KLDR_DATA_TABLE_ENTRY结构体，此时简单的对抗是断链隐藏模块法，但解决起来比较简单。列出内核模块可以用来发现可疑指标如内核驱动程序有一个奇怪的名字，或内核模块加载从非标准路径或临时路径。modules插件列出了内核模块的顺序加载，这意味着如果rootkit驱动程序是最近安装的，很可能发现它位于模块列表的最后，这里的前提条件是模块不是隐藏以及需要系统中招后没有重新启动的内存数据。为了克服DKOM攻击（DKOM是一种涉及到修改内核数据结构的技术。使用DKOM，可以隐藏一个进程或一个驱动程序。要隐藏进程，攻击者会找到自己要隐藏的恶意进程的_EPROCESS结构，并修改ActiveProcessLinks字段，也就是断链隐藏的手法，将某进程的_EPROCESS结构从双链表中剥离出来，同理实现驱动隐藏也类似。）的问题，可以使用另一个名为modscan的插件。modscan插件依赖于池标签扫描方法，由于modscan使用池标签扫描方法，它可以检测卸载的模块（如果内存没有被覆盖），因此可以找到内存中存在隐藏驱动模块的区域。
利用公开的ARK工具无法找到恶意模块，下图中红框标注的两个模块内存地址空间之前存在一个隐藏模块。
对于隐藏的恶意驱动模块可以利用Volatility进行内存分析后给dump下来，也可以利用上述的OpenARK工具直接dump内存文件（需要确定加载的内核模块内存镜像大小）。
在清除与分析驻留过程中会有一些麻烦（如果能重装系统其实没有这么多麻烦需要处理，而且重装系统是比较好的方式），例如我们可以使用Windows自带的安全模式来阻止非系统必须的驱动的加载，这样子会去掉rootkit实现的文件保护与隐藏功能。
也可以利用句柄搜索找到可疑的痕迹，这里的话是已经知道了会有类似的特征，如果是初步排查需要比较一些技巧。
svchost.exe（908）会创建驱动文件dump_VSOCK.sys（9D341B98101D6DEA92A93A3A3258D439）并删除，如下。
恶意驱动被svchost.exe进程（被进程注入的进程，pid为908）释放加载dump_VSOCK.sys，使用安全模式启动之后还是会找不到具体的恶意驱动文件，因为是随安全模式或者网络模式启动的驱动，存在一点小对抗，这里也是一个取证点。
解除上述的对抗后拿到木马文件，依然是加壳VMP2的木马，需要中断的地址23F9FB，最终找到的入口点中断的地址1C4C210h，基址为1C30000h，偏移地址为1C210h，没有使用代码虚拟化，比较简单。
MsCFA943C2App.dll释放的驱动，本地分析出现携带的pdb路径（X:Gad2019x64ReleaseHidden.pdb），表明是存在恶意功能，目前大部分rootkit会考虑采用开源代码来二次开发，符合黑产团伙投入产出性价比的模式，针对底层的攻防技术的研究与开发需要兼顾多个系统，而且会因为编写不当导致系统蓝屏因此风险很大，投入大但产出少，最终还是会被发现。
原文始发于微信公众号（OnionSec）：流行木马紫狐取证分析和反思
