第一次尝试恶意代码分析就遇到了虚拟机检测，于是就想着先学习一下检测的技术然后再尝试绕过。学习后最终发现，似乎最好的方法不应该是去patch所有检测方法，而是直接调试并定位检测函数再绕过。但既然已经研究了两天，索性将收集到的资料整理一下，方便后人查找。

相关 API ：GetFileAttributes、etModuleHandle
通常，各种 hypervisor 会在虚拟机上安装驱动程序和其他软件，以使客户机能够利用 hypervisor 提供的功能。恶意软件可以搜索这些文件、目录或进程的存在。VMware 虚拟机中可能会有如下的文件列表：

相关API：CreateFile
在Windows虚拟机中，虚拟机通常拥有独特命名的 “devices”。

相关API：GetAdaptersAddresses、GetAdaptersInfo、Netbios
Hypervisors 通常为虚拟机提供虚拟化的网卡(NICs)，具有独占于hypervisor供应商的MAC地址。
已知的 VMware 虚拟机的 MAC地址有：

相关API：RegOpenKeyEx、RegQueryValueEx
虚拟化产品通常会附带一个基本输入/输出系统（BIOS），其中包含虚拟机特有的字符串。可以通过检查Windows注册表来查看。

VMware中，以下注册表项会带有 “VMWARE” 或者 “VM” 字符串

相关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 字段。

可以通过返回结果的条目数，检查是否存在一些物理机应该有的硬件，比如：

某些CPU指令在虚拟机中执行时返回值与在物理机机上执行时返回值不同。恶意软件可以执行这些指令，并尝试根据返回值推断虚拟机的存在。虽然这些检测方法不普遍适用于所有虚拟机，且随着虚拟机的迭代也已经部分失效，但仍然有必要了解。下面列出已知的用于虚拟机检测的指令。

IN指令从指定的I/O端口读取值到指定的内存地址。I/O端口是操作系统和I/O设备（如磁盘控制器和声音设备）之间的通信手段。基于VMware的虚拟机具有端口号为 0x5658 的I/O设备，允许hypervisor 和虚拟机之间通信。通常，在非特权用户模式下运行IN指令将触发特权指令异常。但在 VMware 中，不会引发此类异常。VMware 公司甚至将此作为官方检测 VMware hypervisor 的手段。VMware 也提供了一个接口，允许用户“关闭”此方法。

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”。

当 EAX=1 时，CPUID将返回有关处理器功能的信息，例如处理器支持的指令。返回值 ECX 中的第 31 位确定是否存在 hypervisor。在物理机中此值为 0，在虚拟机中为 1。

在虚拟机中执行 CPUID 还会触发 VM-Exit Event，使得进程从 guest 切换到 VMM。可以用 RDTSC 指令来计算这个开销。

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”僵尸网络用于检查虚拟机的存在。

在 VMware Workstation、VirtualBox、XEN、HyperV 和 KVM/QEMU 虚拟化平台上测试 “VMCPUID” 指令的代码如下：

结果所有测试的虚拟化平台都不支持 VMCPUID 命令。实际上，这个命令被错误地解释为两个命令：

恶意软件“Win32/gravityRAT”采用了一种通过检测系统 thermal zone 来检测虚拟机存在的方法。通过使用下面的powershell脚本，可以轻松检查机器是否支持“MSAcip_ThermalZoneTemperature”对象。如果此脚本没有返回结果，则假定该计算机在虚拟机中，因为虚拟机默认不支持热力监控。由于Thermal zone sensors 可以在系统的BIOS或UEFI中禁用和启用，在多个物理机上测试结果不一致，所以该方法并不可靠。

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 使用了基于行为的一些方法来检测沙箱：

Ref：
ESET_Okrum_and_Ketrican.pdf

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！