2021陇剑杯线上——机密内存取证

这学期已经告一段落，这篇博客记录一下这学期电子取证专业课的大作业成果，仅供参考。（因为事情真的太多😢😢，之前博客下面的评论就不一一回复了，还请xdm见谅🥺🥺🥺）

Windows内存取证（陇剑杯线上——机密内存取证）

检材来源于陇剑杯2021线上赛的压轴题——机密内存

给了我们三个文件，有一个vmem文件，vmem即虚拟机的内存文件，首先尝试直接用volatility分析

使用volatility进行直接分析发现无法识别profile

1. 识别文件类型

另外两个文件的文件类型不明，需要我们自行判断，但可以肯定的是其它类型的虚拟机文件

查阅了相关资料了解了一下虚拟机文件类型及其作用

下面是vmware官方文档中给出的虚拟机文件类型说明

文件	使用情况	描述
.vmx	vmname.vmx	虚拟机配置文件
.vmxf	vmname.vmxf	其他虚拟机配置文件
.vmdk	vmname.vmdk	虚拟磁盘特性
-flat.vmdk	vmname-flat.vmdk	虚拟机数据磁盘
.nvram	vmname.nvram 或 nvram	虚拟机 BIOS 或 EFI 配置
.vmem	vmname.vmem	虚拟机分页备份文件
.vmsd	vmname.vmsd	虚拟机快照
.vmsn	vmname.vmsn	虚拟机快照数据文件
.vswp	vmname.vswp	虚拟机交换文件
.vmss	vmname.vmss	虚拟机挂起文件
.log	vmware.log	当前虚拟机日志文件
-#.log	vmware-#.log（其中 # 表示从 1 开始的编号）	旧的虚拟机日志文件
.VMX.LCK		磁盘锁文件。

再观察一下两个文件的内容，bin02有个很明显的特征就是这个文件一半是可打印字符，一半是乱码，注意到乱码区域开头部分有个显眼的标识码——lsilogic

bin01就是一个二进制文件

我们将一个虚拟机所有的文件用010 editor比对，发现没有匹配度很高的，然后从bin02入手，因为bin02是有可打印字符串，且内容有一定的特征，比如以key/list/(pair/(phrase/...的URL字符串开头，在线解码了一下发现这一串是VMware加密算法用到的密钥还有salt、轮数等等

google搜索了一下这串URL得出结论这是一个加密后的虚拟机文件，从搜索结果初步推测bin02是vmx

于是我们进一步推测这是一个加密后的虚拟机文件组，现在整体思路就是给这个虚拟机进行移除加密，最终得到明文形式的内存文件，再用volatility分析。

我们将手头上的虚拟机加密后再与其一一进行比对。

首先是vmx文件加密后的比对，很明显bin02开头部分缺失了一些东西，而结尾处的乱码似乎是另一个文件的拼接（因为正常对vmx文件加密后内容依旧是可打印字符，并不会出现二进制数据）。

google一下了解到乱码区域的开头那个显眼的lsilogic指代的是虚拟磁盘类型。

于是与虚拟磁盘文件vmdk做对比，发现与密文部分的格式基本吻合，但缺少了文件头还有填充字段，因而得出结论bin02后半部分是一个残缺的vmdk文件，且内容就是该虚拟机虚拟磁盘的密文字段。

关于bin02文件是vmdk和vmx文件的拼接的发现，由于我们先前没有分析过虚拟机内存文件，所以这颠覆了我们一开始分析时的认知，因为一般人往往会觉得vmdk一般都很大，而两个bin文件都很小，所以我们一开始并未将vmdk文件考虑在内，这是也我们考虑不周之处。

bin01可以一下子比对出来是vmss文件，即虚拟机挂起文件。

小结一下：

• bin01：vmss
• bin02：vmx（需修复）+vmdk（需修复）
• vmem：运行状态虚拟机的内存页面文件

在进行解密之前需要修复所给的文件。

2. 分离与修复

用010 editor分离bin02，下图选中部分导出为vmdk_from_bin02.vmdk，导出后bin02中该部分删除。

首先修复前半部分，即加密后的vmx，正常加密后的vmx内容包括.encoding、displayName、encryption.keySafe和encryption.data字段，

顺便查阅了解一下这些字段的含义

• .encoding指定编码格式，
• encryption.keySafe是安全密匙（Url 编码的密匙信息+ Base64 编码的密匙）
• encryption.data是Base64 编码的加密数据。

因而需要在损坏的vmx文件的基础上再加上.encoding（编码）和displayName（文件名），对比发现还有encryption.keySafe中的一些关键内容也被篡改。具体修复内容如下：

这是损坏的vmx

修复之后如下

displayName字段代表名称，可以随意修改。该字段的值会显示在VMware标签页上。

修复时插入的字符也对应了VMware加密用到的加密算法：HMAC-SHA-1、PBKDF2-HMAC-SHA-1，密匙长度：AES-256。此外还加了盐。

修复完毕后，重命名改后缀.vmx

将Encryption.bin01文件重命名为mem_secret-963a4663.vmss，vmss文件的文件名一定要和vmem文件名对应，否则无法读取挂起的状态。

我们在修复了vmss和vmx的情况下就已经可以用VMware打开

3. 密码破解

首先在VMware中导入该虚拟机

需要获取打开的密码，此题关于密码无任何提示信息，只能通过暴力破解的方式获取了，网上找到一个破解脚本——pyvmx-cracker。

得到密码1q2w3e4r，成功打开挂起状态的虚拟机，可以看出这是一个Win10虚拟机，同时还获取到了该虚拟机的一些配置（如60G的NVMe虚拟磁盘类型，2G内存，2个处理器……）

4. 修复vmdk

接着着手修复vmdk文件。

通过之前的比对我们现在需要一个合法的文件头与填充。所以重新创建一个win10虚拟机，此时并不需要去安装win10系统（因为我们的目的只是获取到正确的vmdk文件，VMware在我们安装系统前便已经为我们生成），再用任意的密码加密这个win10虚拟机得到同一密码加密后的完整的vmdk文件，试着用得到的完整的vmdk文件修复原来那个分离出来的残缺vmdk

新建一个Win10虚拟机（配置不需要严格与上图的一致，因为我们只是为了获取到正确的磁盘文件）

但这里有个坑，记录一下：我们发现这里不能选择拆分成多个文件，否则会导致有多个vmdk，同时内部格式也会与单个vmdk有所不同，最后也试过无法移除加密。

在虚拟机“设置-选项-访问控制”中加密后，找到新生成的vmdk，获取到的vmdk外壳长这样（如下图）

我们已经知道残缺的vmdk内容其实是加密后的磁盘内容，那么就只需要用这个内容去覆盖Windows 10.vmdk相应部分的信息即可（其实vmdk的加密并不会对文件整体加密，只是对文件内容加密了）

具体操作：从位于Windows 10.vmdk中0x200偏移处的0x18开始覆盖写入vmdk_from_bin02.vmdk文件中同样从字符0x18开始的内容（如下）

这里有个坑：是覆盖写入，并非插入，原因是为了保证新的vmdk的文件大小修改前后必须一致，否则后面解密的时候会出现虚拟磁盘损坏的报错

• 用winhex：复制完要覆盖的数据之后，光标移至开始覆盖的部分，选择 “编辑-剪切板数据-写入”即可完成覆盖
• 或用010 editor：需要在覆盖之前删除vmdk_from_bin02.vmdk在字符0x18之前的部分，然后通过 “编辑-插入/覆盖-覆盖文件”选择vmdk_from_bin02.vmdk即可完成覆盖

覆盖之后还要在下面的位置覆盖上vmware字串

接着重命名此vmdk文件，此时虚拟机修复完成，将其放到被加密的虚拟机目录下。

在访问控制中移除加密

这里还有个坑：修复完成后不要试图开启虚拟机，否则vmem文件会被删除。

自此得到明文内存文件

5. 问题与探究

在修复文件与解密过程中我们产生了一些疑问，并通过查阅资料与自己动手实践得到有效解决。

① 为什么不直接用完整的vmdk去替换那个残缺的vmdk？

我们查阅网上资料得知，加密vmdk的密钥与vmx的密钥有着某种关系，并不直接就是之前爆破出来的密码1q2w3e4r，而vmx的密钥也是有随机性的，从前面的URL解码、vmx的修复这些蛛丝马迹中也可以看到加了盐，因而每次即便是用一样的密码加密也会得到不一样的vmdk（问题 ② 中会验证），这样毫无疑问安全性也得到了提升。

且我们重新创建一个虚拟机只是为了获得vmdk的合法外壳，再包上残缺vmdk内的密钥最终就可以恢复vmdk。

② 是否真的要采用同样的密码加密

关于至今为止全网写了该题wp的几个博主都说要输入同样的密码加密，但我们后来的实践发现这是没有必要的。

下面来验证一下用同样的密码加密是否会得到一样的vmdk。如下图所示，两个文件都是用的同样的密码加密的，只是加密的时间节点不一样，但密钥部分（如下图）有些地方发生了改变，因而我们可以证实，输入的密码与vmdk的加密没有直接联系，也就是说我们在自行创建虚拟机获取vmdk的时候，密码可以是任意值。

③ 不加密虚拟机是否也可以？

后来我们发现不只是密码设置任意值，不加密也是可以的，加密不会使vmdk的文件头改变，只是改变的关键内容，所以只需要找准覆盖点覆盖依旧能正常解密。

覆盖点如下，依旧是偏移为0x200处开始覆盖

6. 内存取证

介绍：Volatility3是对Volatility2的重写，它基于Python3编写，对Windows 10的内存取证很友好，且速度比Volatility2快很多。对于用户而言，新功能的重点包括：大幅提升性能，消除了对–profile的依赖，以便框架确定需要哪个符号表（配置文件）来匹配内存示例中的操作系统版本，在64位系统（例如Window的wow64）上正确评估32位代码，自动评估内存中的代码，以避免对分析人员进行尽可能多的手动逆向工程等。【来源于网络】

先采用volatility 3查看OS和内核详细信息（volatility 2分析win10的profile实在太慢）获取profile，后面手动指定profile用volatility 2进行具体分析

查看获知操作系统版本为win10，版本号为15.18362，Is64Bit为True，代表64位系统，因此profile=Win10x64_18362

python vol.py -f B19031216-B190312131.vmem windows.info

（1）取证人员首先对容器的基本信息进行核实，经过确定该容器的基本信息为___。（答案为32位小写md5(容器操作系统系统的版本号+容器主机名+系统用户名），例如：操作系统的版本号为10.0.22449，容器主机名为DESKTOP-0521,系统登录用户名为admin，则该题答案为32位小写md5(10.0.22449DESKTOP-0521admin) 的值ae278d9bc4aa5ee84a4aed858d17d52a)

Windows下的volatility版本是2.6，并不支持win10，所以在Ubuntu中用2.6.1的volatility

要获取基本信息需要从注册表中查看，先dump下内存中的注册表项

python2 vol.py -f mem_secret-963a4663.vmem --profile=Win10x64_18362 dumpregistry -D ./

然后用WRR分析SYSTEM.reg注册表，找到主机名称DESKTOP-4N21ET2

版本号在SOFTWARE.reg中10.0.18363

下面找系统用户名，只需要filescan扫描一下文件，直接从路径中找到用户名为Ado

用volatility 2.6.1的filescan报不知名的错误，因而又改用volatility3了

python vol.py -f mem_secret-963a4663.vmem windows.filescan

（2）黑客入侵容器后曾通过木马控制端使用Messagebox发送过一段信息，该信息的内容是______。（答案为Messagebox信息框内内容）

这个就是之前的快照可以看到的Best_hacker

（3）经过入侵分析发现该容器受到入侵的原因为容器使用人的违规进行游戏的行为，该使用人进行游戏程序的信息是_____。（答案为“32位小写md5(游戏程序注册邮箱+游戏程序登录用户名+游戏程序登录密码)，例如：注册邮箱为adol@163.com,登录用户名为user,密码为user1234，则该题答案为” adol@163.comuseruser1234”的小写md5值5f4505b7734467bfed3b16d5d6e75c16)

从上面的快照可以看出来使用者打开了steam

在Ubuntu中用strings配合egrep用正则表达式过滤一下可以很快找到邮箱，或者直接在010 Editor中打开，搜索mail找到邮箱为john@uuf.me

strings mem_secret-963a4663.vmem | egrep "[0-Z_]+\@[0-Z]+\.[0-Z]+"

在找用户名的时候，参考网上的博主用的方法直接搜user等等字符串去一个个看，发现匹配出来的太多，效率不高

后来我们推测用户名和密码这两个信息一定是紧靠在一起的，所以先用string和egrep匹配password字符串作为第一层过滤，并把结果重定向到txt文件中（命令如下）

strings mem_secret-963a4663.vmem -n 10 |egrep "password">mem_secret-963a4663_output.txt 

用notepad++打开重定向文件，再用account、user、username、steamuser等用户名的关键字符作第二层过滤来进一步缩小范围，很快就能找出来用户名为jock_you1密码为jock.2021，效率很高

合并邮箱和用户名密码为john@uuf.mejock_you1jock.2021，计算md5小写32为值为：39a9ac5a37f4a4ce27b1227cf83700a6

（4）经过入侵分析发现该容器曾被黑客植入木马控制的信息是______。（答案为“32位小写md5(木马程序进程名+木马回连ip地址+木马回连ip端口）”，例如：木马程序进程名为svhost.exe，木马回连ip为1.1.1.1，木马回连端口为1234，则该题答案为“svhost.exe1.1.1.11234”的32位小写md5值f02da74a0d78a13e7944277c3531bbea)

既然是分析可疑进程那就先pstree罗列进程

python vol.py -f mem_secret-963a4663.vmem windows.pstree

我们发现分析到这儿有两个steam，抱着怀疑的态度我们就在自己电脑上打开steam登录后，打开任务管理器看后台发现一般正常打开只有一个steam.exe（如下）

毫无疑问，多出来的steam.exe有问题，推测可能就是木马，

——问题记录与最终方案

在确认steam.exe是否为木马的时候出现了一些问题，这里记录了一下探究过程和最终方案

一开始想到把两个steam.exe都dump下来然后用杀毒软件扫描

python vol.py -f mem_secret-963a4663.vmem windows.memmap.Memmap --pid 5004 --dump && python vol.py -f mem_secret-963a4663.vmem windows.memmap.Memmap --pid 6864 --dump

为了以防万一用vol2也导出了一下，但用Windows Defender、火绒、360扫描都没扫出来报毒

于是改用filescan直接根据偏移dump文件（前面提到过，vol2.6.1的filescan分析win10的时候出现一堆报错，又改用vol3的filescan），但发现Volatility2无法成功导出内存中映射的steam.exe文件

python2 vol.py -f mem_secret-963a4663.vmem --profile=Win10x64_18362 dumpfiles -Q 0x.... --dump-dir=./ 

最后选择先根据pid使用windows.cmdline.CmdLine获得启动参数，可以看到pid为6864的steam正常使用steamwebhelper连接，而Download文件夹下面的pid为5004的steam.exe并没有（首先我们觉得这个路径就很可疑），所以5004的steam.exe大概率为木马。

这步分析有些牵强，但目前能力有限（泪目。。），没有找到更好的方法。

回连ip和端口号只需要netscan一下即可（我们发现pid号痕迹都被清除了。。。）

python vol.py -f mem_secret-963a4663.vmem windows.netscan

（5）经过入侵分析，发现黑客曾经运行过痕迹清除工具，该工具运行的基本信息是_____。（答案为“32为小写md5”(痕迹清除工具执行程序名+最后一次运行时间)，例如：黑客运行工具执行程序名为run.exe，运行时间为2021-07-10 10:10:13，则本题的答案为小写的32位md5(run.exe2021-07-10 10:10:13) 值为82d7aa7a3f1467b973505702beb35769，注意：本题中运行时间的格式为yy-mm-dd hh:mm:ss，时间时区为UTC+8）

分析软件的运行用userassist（它可以提取出内存中记录的当时正在运行的程序有哪些，运行过多少次，最后一次运行的时间等信息）

python2 vol.py -f mem_secret-963a4663.vmem --profile=Win10x64_18362 userassist

翻到了无影无踪的运行痕迹

无影无踪WYWZ是一款用于擦除WINDOWS和常用软件运行过程所产生的痕迹的清理工具，WYWZ能够全面、快速、自动地擦除WINDOWS中常用软件使用痕迹以及你自己定义的擦除。

程序的运行时间结合userassist可以发现为2021-09-10 21:10:13 UTC+8（注意时区的转换）

北京(Beijing)时间=UTC（世界协调时间）+ 8:00

则该题答案为小写32位md5(Wywz.exe2021-09-1021:10:13)=d46586ca847e6be1004037bc288bf60c