FLARE精英团队近期刚完成了对MassLogger的分析，MassLogger是一个非常新的凭据盗取手机软件。虽然MassLogger缺乏新奇的作用，但或是选用了一种错综复杂的技术性，该工艺在运作时替代了Microsoft正中间语言表达(MSIL)，进而影响了静态数据分析。截止到发文时，仅有一篇文章详解过MassLogger的搞混技术性。文中，看一下FLARE精英团队是怎样深入分析MassLogger凭据盗取程序流程和.NET运作时的。
MassLogger的基本情况
MassLogger是一个.NET凭据盗取手机软件，它从运行程序流程(6b975fd7e3eb0d30b6dbe71b8004b06de6bba4d0870e165de4bde7ab82154871)逐渐进行进攻，该运行程序流程应用简易的反调节技术性，在鉴别时可以轻轻松松避开监控系统。此第一阶段载入程序流程最后会对第二阶段程序流程集开展XOR解决，随后破译、载入并实行名叫Bin-123.exe的最后MassLogger有效载荷(bc07c3090befb5e94624ca4a49ee88b3265a3d1d288f79588be7bb356a0f9fae)。最终的有效载荷可以轻轻松松获取并单独实行。因而，大家将专业关心应用关键反分析技术性的最终有效载荷。
基本上的静态数据分析是不容易发现什么有價值的東西的，但是大家留意到了一些有意思的字符串数组，但他们不能为大家给予关于该恶意软件作用的一切提醒。在控制环镜中实行有效载荷说明，该实例删除了一个日志文件，该文件标志了恶意软件大家族，其版本号及其最重要的一些配备选择项。图1中叙述了一个实例日志文件，伴随着实例的运作，大家也可以从运行内存中获取一些有意思的字符串数组。可是，基本上的动态性分析不能获取全部根据服务器的指标值(HBI)，根据互联网的指标值(NBI)和完全的恶意软件作用。大家务必实现更深层次的分析，以更好的了解样版以及作用。
MassLogger日志样版
反汇编解决
与很多别的.NET恶意软件一样，MassLogger搞混了其全部方法名字乃至方法控制流。我们可以应用de4dot全自动对MassLogger有效载荷开展搞混解决。可是，查询通过搞混解决的有效载荷后，大家迅速看到了一个关键问题：大部分方法几乎不包含逻辑性，如下图2所显示。
表明空方法的dnSpy
在dnSpy的中心语言表达(IL)主视图中查询初始的MassLogger有效载荷，可以确定大部分方法不包含一切逻辑性，仅仅不回到一切內容。这明显并不是真正意义上的恶意软件，由于大家已根据动态性分析观查到该样版的确在实行故意主题活动并纪录到日志文件中。大家只剩余好多个方法，最显著的是主控制模块构造方法中最先启用的含有标识0x0600049D的方法。
表明该方法详细资料的dnSpy IL主视图
方法0x0600049D的控制流已被搞混为一系列switch句子，在dnSpy做为程序调试的幫助下，大家依然可以在某种意义上遵循该方法的高級逻辑性。可是，全方位分析该方法将十分用时。反过来，当第一次分析此有效载荷时，我能挑选迅速扫描仪全部控制模块以找寻提醒。幸运的是，我发现一些在基本上静态数据分析期内被忽视的有意思字符串数组：clrjit.dll，VirtualAlloc，VirtualProtect和WriteProcessMemory，如下图4所显示。
分散化在全部控制模块中的有意思字符串数组
网上快速查询“clrjit.dll”和“VirtualProtect”，可以快速掌握一种通常称之为“JIT挂勾( Just-In-Time Hooking)”的技术性。实质上，JIT挂勾涉及到在compileMethod()函数公式上安裝挂勾，JITc语言编译器将在该函数公式上把MSIL编译程序为程序流程集(x86，x64等)。拥有挂勾，恶意软件就可以轻轻松松用包括初始恶意软件逻辑性的真正MSIL更换每一个方法体。为了更好地全方位掌握此全过程，使我们先探寻一下.NET可执行程序，.NET方法及其MSIL怎样变为x86或x64程序流程集等问题。
.NET可实行方法
.NET可执行程序仅仅具备可实行(PE)文件格式的另一个二进制文件，如今网络上有很多資源详细说明PE格式文件，.NET数据库和.NET动态口令表。但是这种并非文中解读的关键，这书大家会将核心放到.NET方法上。
.NET程序流程集中化的每一个.NET方法都由一个动态口令标志，事实上，.NET程序流程集中化的任何內容，不论是控制模块，类，方法原形或是字符串数组，都由动态口令标志。使我们看一下由动态口令0x0600049D标志的方法，如下图5所显示。最有效字节数(0x06)告知大家，这一标识是一个方法标记(种类0x06)，而不是控制模块标识(种类0x00)、TypeDef标识(种类0x02)或LocalVarSig标识(种类0x11)。三个最少合理字节数告知大家该方法的ID，在本实例中为0x49D(decimal为1181)。此ID也称之为方法ID(MID)或方法的Row ID。rowid是一个用于唯一标识表中国银行的伪列。它是物理学表中国银行数据信息的内部结构详细地址，包括2个详细地址，其一为偏向数据分析表中包括这家银行的块所存取数据文档的详细地址，另一个是可以同时精准定位到数据信息行本身的这一行在数据信息块中的详细地址。
方法0x0600049D的方法关键点
要搜索相关此方法的其他信息，请查询.NET数据库文件目录中.NET元数据流分析的“#~”流的表中搜索，如下图6所显示。大家解析xml此条目地序号1181或0x49D用以搜索方法数据库的方法表，该方法元数据包含方法体的相对性虚拟注册地址(RVA)，各种各样标示，偏向方法名字的表针，偏向方法签字的表针，最终是这类方法偏向用以下列主要参数的参数标准的表针。一定要注意，MID从1而不是0逐渐。
来源于PE文件头的方法关键点
针对方法0x0600049D，方法体的RVA为0xB690。该RVA归属于.text一部分，其RVA为0x2000。因而，此方法体从.text一部分中的0x9690(0xB690 – 0x2000)字节数逐渐。 .text一部分依据文章标题文本文件的0x200字节数逐渐。結果，我们可以在文档中偏位0x9890(0x9690 0x200)字节数的部位寻找方法体。我们可以在图7中见到方法体。
十六进制编辑软件中的方法0x0600049D体
NET方法体
NET方法体以方法体标头开始，后跟MSIL字节数。 .NET方法有三种种类：小方法和大方法。查询方法体标头的第一个字节数，这两个最少合理位会告知大家该方法是小的(最终二位为10)或是大的(最终二位为11)。
NET 小方法
使我们看一下方法0x06000495，依照前边所讲的同样流程，大家查验方法表的行号0x495(decimal为1173，对SQL Server来讲，Decimal可以用来储存具备小数位并且标值明确的标值，它并不像float和real是用于储存近似值。)，发觉方法体RVA为0x7A7C，它转化为0x5C7C做为文档的偏移。在这里偏移下，方法体的第一个字节数为0x0A(二进制文件格式为10 1010)。
方法0x06000495数据库和体
因为2个最少合理位是10，因而我们知道0x06000495是一个小的方法。针对一个小方法，方法文章正文标头只有一个字节长。2个最少合理位是10，表明这也是一个小方法，六个最有效位告知我们要追踪的MSIL的尺寸(即MSIL的长短)。在本例中，六个最有效的位是000010，这提醒大家方法体有两个字节长。0x06000495的全部方法行为主体是0A 16 2A，后跟一个NULL字节，该字节已由dnSpy溶解，如下图9所显示。
dnSpy IL主视图中的方法0x06000495
NET大方法
回到到偏移为0x9890到文档(RVA 0xB690)中的方法0x0600049D(内容号1181)，方法体的第一个字节为0x1B(或二进制数0001 1011)。最少二位是11，表明0x0600049D是大方法。 大方法体标头的尺寸为12个字节，但是对其构造的详细介绍超过了本网络文章的范畴。大家真真正正在意的字段名是此大标头中偏移为0x04字节的四字节字段名。该字段特定此方法文章正文标头以后的MSIL的长短。针对方法0x0600049D，全部方法体标头为“1B 30 08 00 A8 61 00 00 75 00 00 11”，后边的MSIL长短为“A8 61 00 00”或0x61A8(decimal为25000)字节。
十六进制编辑软件中的方法0x0600049D体
JIT编译程序
无论一个方法是小的或是大的，它都并不是按原状实行的。当.NET运作时必须运行一个方法时，它将彻底依照前边所讲的全过程搜索方法体，该体包含方法体标头和MSIL字节。假如这是第一次运作该方法，则.NET运行时将启用及时c语言编译器，该编译器将MSIL字节获取并将其编译程序为x86或x64程序流程集，实际在于现阶段过程是32位或是64位。通过一些提前准备，JITc语言编译器最后将启用compileMethod()函数公式。全部.NET运作时新项目是开放源码的，可以在GitHub上得到。我们可以非常容易地发觉compileMethod()函数公式具备下列原形(图11)：
compileMethod()函数原型
下面的图展示了CORINFO_METHOD_INFO构造。
CORINFO_METHOD_INFO结构
ILCode是偏向要编译程序的方法的MSIL的表针，而ILCodeSize告知大家MSIL的具体时间。 compileMethod()的传参是一个错误码，标示取得成功或不成功。假如取得成功，nativeEntry表针将应用包括从MSIL编译程序的x86或x64命令的可实行运行内存地区的详细地址添充。
MassLogger JIT挂勾
使我们返回MassLogger，一旦主控制模块复位运作，它将最先破译别的方法的MSIL。随后，它安裝一个挂勾以实行自身的compileMethod()版本号(方法0x06000499)。此方法将现实的恶意程序的MSIL字节更换为初始compileMethod()的info主要参数的ILCode和ILCodeSize字段名。
除开更换MSIL字节外，MassLogger仍在控制模块复位时修复方法体标头。从图13中能够看见，硬盘上的方法0x060003DD的方法体标头(文档偏位为0x3CE0)与运行内存中的标头(RVA 0x5AE0)不一样。唯一保持一致的几件事是最不重要的2个位，它表明方法是小的或是大的。要顺利地战胜这类反剖析技术性，大家务必修复真正的MSIL字节及其合理的方法体标头。
停留在硬盘上与载入到运行内存里时具备不一样标头的同样方法体
战胜JITM的JIT方法体更换
为了更好地全自动修复MSIL和方法体标头，另一位FLARE精英团队组员提议的一种很有可能方法是在载入并容许MassLogger控制模块构造方法运作以前，在compileMethod()函数公式上安裝我们自己的挂勾。应用代管挂勾(新的compileMethod()是用C#撰写的代管方法)和远程服务器挂勾(新的compileMethod()是用C或C 撰写的远程服务器挂勾)，有很多有关挂勾compileMethod()的步骤和开源软件。可是，因为MassLogger挂勾compileMethod()的与众不同方法，我们无法应用很多以上新项目完成的vtable挂勾技术性。除挂勾外，JITM还包含.NET载入程序流程。此载入程序流程最先载入远程服务器挂勾DLL(jitmhook.dll)并安裝该挂勾。随后，载入程序流程载入MassLogger有效载荷并实行其通道点。这将造成MassLogger的控制模块复位执行命令并安裝自身的挂勾，可是缠住的是jitmhook.dll编码而不是初始的compileMethod()。实行MassLogger通道点的另一种方法是启用RuntimeHelpers.PrepareMethod()API强制性JITc语言编译器在全部方法上运作。这类方法更强，因为它防止了运作恶意程序，而且有可能修复样版当然编码途径中未启用的方法。可是，这必须附加的作业来强制性全部方法恰当编译程序。
要载入和修复MassLogger方法，请运作下列指令(图14)：
运作jitm的指令
请求超时完毕后，你应该见到在当前目录中建立的文档jitm.log和jitm.json。 jitm.json包括从Bin-123.exe修复的全部方法的方法动态口令，方法体标头和MSIL。剩余要做的唯一事儿便是复建.NET数据库，便于我们可以实行静态数据剖析。
实例jitm.json
再次搭建
因为破译的方法体标头和MSIL很有可能不适宜初始.NET程序流程集，因而非常简单的方法是向MassLogger加上一个新一部分和相对应的标头。JITM还包含下列Python 2.7协助程序流程脚本制作以全自动实行此全过程：Script\pydnet.py。
根据将方法体标头和每一种方法的MSIL加上到新的PE一部分(如XXX所显示)，我们可以轻轻松松地分析.NET数据库并修补每一种方法的RVA以偏向新一部分中的恰当方法体。遗憾的是，我并没有寻找一切Python库来轻轻松松分析.NET数据库和MethodDef表。因而，JITM还包含一部分完成的.NET数据库在线解析：Script\pydnet.py。该脚本制作应用pefile和vivisect控制模块，并将PE文档分析到Method表，以获取全部方法以及关系的RVA。
在加上名叫FLARE的其余一部分以前和以后的Bin-123.exe
最终，为了更好地将全部內容捆缚在一起，JITM给予了Script \ fix_assembly.py来实行下列每日任务：
1.将在jitm.json中修复的每一个方法的方法体标头和MSIL载入一个名叫“section.bin”的临时性二进制文件中，与此同时记牢有关的方法标识和到section.bin中的偏移。
2.应用addsection.py将section.bin加上到Bin-123.exe中，并将数据信息储存到新文档中，例如Bin-123.fixed.exe。
3.应用pydnet.py分析Bin-123.fixed.exe并升级MethodDef表中每一个方式项的RVA字段名，以将指向恰当的RVA指向新一部分。
最后结论是一部分重构的.NE程序流程集，虽然要使程序流程集恰当运作还必须开展别的工作中，但足够开展静态剖析以掌握恶意软件的高端作用。
使我们看一下重构的方式0x0600043E，该办法为恶意软件配备完成了破译逻辑性。与初始MSIL对比，复建的MSIL可以展现出，该恶意软件在CBC方式下应用含有PKCS7添充的AES-256。根据动态变化和静态剖析的组成，大家还能够轻轻松松地将密匙标志为“ Vewgbprxvhvjktmyxofjvpzgazqszaoo”，并将IV作为做为传参的Base64编号缓冲区域的一部分。
在修补程序流程集以前和以后的方式0x0600043
拥有这种专业知识，大家就可以撰写一个简便的设备来破译恶意软件配备并修复全部HBI和NBI(图18)。
破译的配备
汇总
应用JITc语言编译器挂勾更换MSIL是一项强劲的反剖析技术性，安全性工作人员几乎没法对它进行静态剖析。虽然此项技术性并不是新技术应用，但我都没见到许多.NET恶意软件应用它。期待借助这篇文章，剖析工作人员将有着剖析MassLogger或应用相似技术性的一切恶意软件。
文中翻譯自：https://www.fireeye.com/blog/threat-research/2020/08/bypassing-masslogger-anti-analysis-man-in-the-middle-approach.html倘若转截，请标明全文详细地址。