第一次尝试恶意代码分析就遇到了虚拟机检测,于是就想着先学习一下检测的技术然后再尝试绕过。学习后最终发现,似乎最好的方法不应该是去patch所有检测方法,而是直接调试并定位检测函数再绕过。但既然已经研究了两天,索性将收集到的资料整理一下,方便后人查找。
相关 API :GetFileAttributes
、etModuleHandle
通常,各种 hypervisor 会在虚拟机上安装驱动程序和其他软件,以使客户机能够利用 hypervisor 提供的功能。恶意软件可以搜索这些文件、目录或进程的存在。VMware 虚拟机中可能会有如下的文件列表:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
|
相关API:CreateFile
在Windows虚拟机中,虚拟机通常拥有独特命名的 “devices”。
\\.\HGFS
,主机和虚拟机之间共享的文件系统\\.\vmci
,虚拟机和主机之间的通信管道相关API:GetAdaptersAddresses
、GetAdaptersInfo
、Netbios
Hypervisors 通常为虚拟机提供虚拟化的网卡(NICs),具有独占于hypervisor供应商的MAC地址。
已知的 VMware 虚拟机的 MAC地址有:
相关API:RegOpenKeyEx
、RegQueryValueEx
虚拟化产品通常会附带一个基本输入/输出系统(BIOS),其中包含虚拟机特有的字符串。可以通过检查Windows注册表来查看。
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System
中键值 “SystemBiosVersion” 包含 “VMware, Inc.”HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS
中包含键值HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SystemInformation
中也有类似的信息VMware中,以下注册表项会带有 “VMWARE” 或者 “VM” 字符串
1 2 3 4 5 6 |
|
相关API:GetSystemFirmwareTable
System Management BIOS 是由BIOS读取的一组数据结构。虚拟机会带有有特殊的字符串。VMware 虚拟机会带有 “VMware”。
相关API:GetSystemFirmwareTable
Advanced Configuration and Power Interface (ACPI) 是操作系统通过 BIOS 或 UEFI 与各种硬件组件进行通信的接口。VMware 虚拟机会带有 “VMware”。
相关API:CreateToolhelp32Snapshot
、Process32First
、Process32Next
一些虚拟机利会有特殊的后台进程。这些进程主要提供一些方便的功能,例如自动配置屏幕分辨率和配置网络设置等。
VMware虚拟机中可能会有以下进程:
有些恶意软件还会通过进程数来检测虚拟环境,比如 ”EvilBunny“ 会检测是否存在至少15个进程。
相关API:SetupDiGetClassDevs
、SetupDiGetDeviceRegistryProperty
Win32/Winwebsec的一些变种使用了一种通过 Setup API来检查硬盘设备名的方法。类似的也可以检测硬盘硬件ID。
Windows Management Instrumentation(WMI),提供了一种标准化的接口,允许程序获取系统信息并执行管理任务。WMI是基于COM(Component Object Model)技术构建的,并使用WQL(WMI查询语言)来查询数据。
可以通过 WMI 获取 BIOS 序列号并查看是否带有类似“VMWARE”的字符串。类似的还可以检测 Win32_ComputerSystem 下的 Model 以及 Manufacturer 字段。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
|
可以通过返回结果的条目数,检查是否存在一些物理机应该有的硬件,比如:
1 2 3 4 5 6 7 8 9 |
|
某些CPU指令在虚拟机中执行时返回值与在物理机机上执行时返回值不同。恶意软件可以执行这些指令,并尝试根据返回值推断虚拟机的存在。虽然这些检测方法不普遍适用于所有虚拟机,且随着虚拟机的迭代也已经部分失效,但仍然有必要了解。下面列出已知的用于虚拟机检测的指令。
IN指令从指定的I/O端口读取值到指定的内存地址。I/O端口是操作系统和I/O设备(如磁盘控制器和声音设备)之间的通信手段。基于VMware的虚拟机具有端口号为 0x5658 的I/O设备,允许hypervisor 和虚拟机之间通信。通常,在非特权用户模式下运行IN指令将触发特权指令异常。但在 VMware 中,不会引发此类异常。VMware 公司甚至将此作为官方检测 VMware hypervisor 的手段。VMware 也提供了一个接口,允许用户“关闭”此方法。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
CPUID是一种x86指令,用来获取CPU的各种信息。该指令通过输入 EAX 中的值来确定要在EAX,EBX,ECX和EDX寄存器中返回的信息。下面给出三种基于 CPUID 指令的检测方法。
当 EAX=0 时, CPUID 将按EBX,EDX和ECX寄存器的顺序返回一个12个字符的制造商ID字符串。Intel CPU返回“GenuineIntel”,而AMD CPU在K5型号之后返回“AuthenticAMD” 。当在虚拟机中运行时,ID将被专属于某些虚拟机的自定义字符串替换。VMware虚拟机中理论上将返回 “VmwareVmware”。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
当 EAX=1 时,CPUID将返回有关处理器功能的信息,例如处理器支持的指令。返回值 ECX 中的第 31 位确定是否存在 hypervisor。在物理机中此值为 0,在虚拟机中为 1。
1 2 3 4 5 6 7 8 9 10 |
|
在虚拟机中执行 CPUID 还会触发 VM-Exit Event,使得进程从 guest 切换到 VMM。可以用 RDTSC 指令来计算这个开销。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
SIDT是 Intel x86 指令,用于检测旧单核处理器上的虚拟机存在。这个指令被 “ScoopyNG” 以及 “Redpill” 使用,来检测虚拟机的存在。该命令将中断描述符表寄存器 (IDTR)的内容存放到指定内存地址中。中断描述符表(IDT)是一种重要的操作系统数据结构,用于处理来自硬件(如键盘和鼠标)的中断命令。hypervisor 会将虚拟化操作系统的 IDT 的地址移动到 hypervisor 可预测的地址。Klein 和 Rutkowska 都发现VMware在当时将 IDT 存储在地址0xFFXXXXXX上,从而在单核处理器上检测 VMware 虚拟机。
然而,随着多核处理器的引入,这种虚拟机检测技术不再可靠,因为处理器内的每个核心都具有唯一的中断描述符表,而每个表的地址都不同。此外,在我们对 VMware 的虚拟机测试SIDT命令时,即使只分配了一个处理器核心,IDT 的地址也从未出现在0xFFXXXXXX的地址上。因此,这种虚拟机检测方法已失效。
SGDT是 Intel x86 指令,用于将全局描述符表寄存器(GDTR)的内容存放到指定内存地址中。GDT 是处理器使用的数据结构,用于定义有关进程内存的详细信息,例如基址、大小和内存权限。这种虚拟机检测方法曾被“ScoopyNG”使用。与SIDT指令类似,当在基于VMware的虚拟机中运行时,该指令会返回0xFFXXXXXX的值。然而,这个指令也面临着 SIDT 指令引入多核处理器后遇到的同样问题。在使用 VMware Workstation 测试这种检测方法时,返回的值并不是0xFFXXXXXX。因此,这种检测方法已失效。
SLDT 是 Intel x86 指令,用于将本地描述符表寄存器(LDTR)的内容存放到指定内存地址。LDT包含有关进程内存段的信息,例如代码段、数据段以及堆。当在虚拟机中执行此命令时,将返回非零值,而在非虚拟化环境中返回0。“ScoopyNG”和恶意软件“Conficker”曾使用过这种虚拟机检测方法。我们在 VMware Workstation、VirtualBox、XEN、HyperV 和 KVM/QEMU 虚拟机上测试了此命令,发现所有虚拟机都返回0。这种检测方法已失效。
STR是 Intel x86 指令,它返回当前执行进程的任务状态寄存器(TSR)内容到指定内存地址。任务状态段 TSS 用于存放操作系统用于任务切换的数据,其中包括进程 threads 和 registry 信息,供处理器操作系统处理线程调度。Klein 发现在虚拟机内运行此命令时,它返回格式为 0x0040XXXX 的地址。对VMware Workstation、VirtualBox、XEN、HyperV和KVM/QEMU虚拟机上测试此命令,发现这种检测方法已失效。
SMSW是 Intel x86命令之一,用于将机器状态字返回到指定的内存地址。机器状态字的信息来自CR0寄存器,与 CPU 用于指示是否启用某些功能(如内存分页)的 flags 有关。Quist 发现,在VMware虚拟机内运行此命令,当 EAX=0xCCCCCCCC 时,将返回 0x8001XXXX。经测试在VMware虚拟机内和物理机上测试此命令都会返回值 0x8005XXXX。因此这种检测方法已失效。
Traut在2003年提出了一种使用“合成CPU指令”的虚拟机检测方法。这些指令仅被虚拟机支持,在物理机上执行时会触发无效指令异常。由于这些是无效的CPU指令,因此它们未在Intel或AMD的程序员手册中记录。这些指令的格式为“0FC7C8XXXX”。其中最“VMCPUID”指令被“Necurs”僵尸网络用于检查虚拟机的存在。
Mnemonic | Opcode | Mnemonic | Opcode |
---|---|---|---|
VMCPUID | 0F C6 28 01 00 | VMPOPFD | 0F C6 28 02 01 |
VMGETINFO | 0F C6 28 00 00 | VMCLI | 0F C6 28 02 02 |
VMSETINFO | 0F C6 28 00 01 | VMSTI | 0F C6 28 02 03 |
VMDXDSBL | 0F C6 28 00 02 | VMIRETD | 0F C6 28 02 04 |
VMDXENBL | 0F C6 28 00 03 | VMSGDT | 0F C6 28 03 00 |
VMHLT | 0F C6 28 01 01 | VMSIDT | 0F C6 28 03 01 |
VMSPLAF | 0F C6 28 01 02 | VMSLDT | 0F C6 28 03 02 |
VMPUSHFD | 0F C6 28 02 00 | VMSTR | 0F C6 28 03 03 |
VMSDTE | 0F C6 28 04 00 | - | - |
在 VMware Workstation、VirtualBox、XEN、HyperV 和 KVM/QEMU 虚拟化平台上测试 “VMCPUID” 指令的代码如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
结果所有测试的虚拟化平台都不支持 VMCPUID 命令。实际上,这个命令被错误地解释为两个命令:
1 2 |
|
恶意软件“Win32/gravityRAT”采用了一种通过检测系统 thermal zone 来检测虚拟机存在的方法。通过使用下面的powershell脚本,可以轻松检查机器是否支持“MSAcip_ThermalZoneTemperature”对象。如果此脚本没有返回结果,则假定该计算机在虚拟机中,因为虚拟机默认不支持热力监控。由于Thermal zone sensors 可以在系统的BIOS或UEFI中禁用和启用,在多个物理机上测试结果不一致,所以该方法并不可靠。
1 2 3 4 5 6 7 8 9 10 11 |
|
Ref:
Anti-VM Technique with MSAcpi_ThermalZoneTemperature
这种虚拟机检测方法是由Noorafize等人发现的 ,它基于虚拟机无法像物理机一样保持准确的时间。虚拟机通常通过与主机计算机共享时间来进行时间同步,以尝试伪装成物理机,但来自虚拟机的IP报文时间戳存在不一致性。研究人员发现,由于虚拟机需要与 hypervisor 进行交互,导致虚拟机的时间戳信息略有不同。为了使用此检测方法,攻击者需要向目标系统发送大量的IP / ICMP 数据包以获取足够的信息,以推断目标机器是否为虚拟机。
Ref:
M. Noorafiza, H. Maeda, T. Kinoshita and R. uda, "Virtual Machines Detection Methods using IP Timestamps pattern Characteristic," vol. 8, 2016
通过检查CPU物理核心数、逻辑核心数和cache容量与实际产品配置的不一致性来检测虚拟机。
Ref:Mettrick D. Virtual machine detection through Central Processing Unit (CPU) detail anomalies[D]. , 2022.
在 Windows 中,设备驱动程序需要访问硬件资源(如内存、I/O 端口、中断等),这些资源的地址通常是硬件相关的,因此在不同的系统上地址可能会发生变化。为了方便驱动程序的编写和移植,Windows 内核提供了资源映射机制,将硬件相关的地址转换为系统相关的地址,从而使驱动程序可以在不同的系统上运行而不需要进行修改。内存翻译就是其中一种资源映射类型,它将硬件设备的物理内存地址映射为系统中的虚拟内存地址,使驱动程序可以通过虚拟地址来访问设备内存。
可以通过比对虚拟地址的不同检测虚拟机环境。测试发现Hyper-V虚拟机具有与 00001000-000a0000 匹配的物理内存映射区域。VirtualBox虚拟机具有与 00001000-009f000 匹配的物理内存映射区域。
Ref:
VM Detection Tricks, Part 1: Physical memory resource maps
驱动程序可能创建一定数量的线程,并具有可预测的属性,因此这些属性可以用于指纹识别并构建有用的检测启发式算法。
Ref:
VM Detection Tricks, Part 2: Driver Thread Fingerprinting
恶意软件 Win32/Okrum 使用了基于行为的一些方法来检测沙箱: