虚拟机检测技术整理
2023-5-10 17:59:41 Author: 看雪学苑(查看原文) 阅读量:27 收藏

本文为看雪论坛优秀文章

看雪论坛作者ID:gmhax

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


基于特征的检测

1.1 文件以及目录

相关 API :GetFileAttributesetModuleHandle
通常,各种 hypervisor 会在虚拟机上安装驱动程序和其他软件,以使客户机能够利用 hypervisor 提供的功能。恶意软件可以搜索这些文件、目录或进程的存在。VMware 虚拟机中可能会有如下的文件列表:
C:\Program Files\VMware\
C:\Windows\System32\vm3dc003.dll
C:\Windows\System32\vm3ddevapi64-debug.dll
C:\Windows\System32\vm3ddevapi64-release.dll
C:\Windows\System32\vm3ddevapi64-stats.dll
C:\Windows\System32\vm3ddevapi64.dll
C:\Windows\System32\vm3dgl64.dll
C:\Windows\System32\vm3dglhelper64.dll
C:\Windows\System32\vm3dservice.exe
C:\Windows\System32\vm3dum64-debug.dll
C:\Windows\System32\vm3dum64-stats.dll
C:\Windows\System32\vm3dum64.dll
C:\Windows\System32\vm3dum64_10-debug.dll
C:\Windows\System32\vm3dum64_10-stats.dll
C:\Windows\System32\vm3dum64_10.dll
C:\Windows\System32\vm3dum64_loader.dll
C:\Windows\System32\vmGuestLib.dll
C:\Windows\System32\vmGuestLibJava.dll
C:\Windows\System32\vmhgfs.dll
C:\Windows\System32\VMWSU.DLL
C:\Windows\System32\vsocklib.dll
C:\Windows\System32\drivers\vm3dmp.sys
C:\Windows\System32\drivers\vm3dmp_loader.sys
C:\Windows\System32\drivers\vm3dmp-debug.sys
C:\Windows\System32\drivers\vm3dmp-stats.sys
C:\Windows\System32\drivers\vmnet.sys
C:\Windows\System32\drivers\vmmouse.sys
C:\Windows\System32\drivers\vmusb.sys
C:\Windows\System32\drivers\vmci.sys
C:\Windows\System32\drivers\vmhgfs.sys
C:\Windows\System32\drivers\vmmemctl.sys
C:\Windows\System32\drivers\vmx86.sys
C:\Windows\System32\drivers\vmrawdsk.sys
C:\Windows\System32\drivers\vmusbmouse.sys
C:\Windows\System32\drivers\vmkdb.sys
C:\Windows\System32\drivers\vmnetuserif.sys
C:\Windows\System32\drivers\vmnetadapter.sys

1.2 Devices

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

\\.\HGFS,主机和虚拟机之间共享的文件系统

\\.\vmci,虚拟机和主机之间的通信管道

1.3 MAC 地址

相关API:GetAdaptersAddressesGetAdaptersInfoNetbios
Hypervisors 通常为虚拟机提供虚拟化的网卡(NICs),具有独占于hypervisor供应商的MAC地址。
已知的 VMware 虚拟机的 MAC地址有:

◆00:50:56:XX:XX:XX

◆00:1C:14:XX:XX:XX

◆00:0C:29:XX:XX:XX

◆00:05:69:XX:XX:XX

1.4 BIOS 字符串

相关API:RegOpenKeyExRegQueryValueEx
虚拟化产品通常会附带一个基本输入/输出系统(BIOS),其中包含虚拟机特有的字符串。可以通过检查Windows注册表来查看。
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System中键值 “SystemBiosVersion” 包含 “VMware, Inc.”
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS中包含键值
  • “BIOSVendor” 为 “VMware, Inc.”

  • “BIOSVersion” 的起始字符串为 “VM.”

  • “SystemManufacturer” 为 “VMware, Inc.”

  • “SystemProductName” 包含 “VMware.”

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SystemInformation中也有类似的信息

1.5 其他 Windows 注册表项

VMware中,以下注册表项会带有 “VMWARE” 或者 “VM” 字符串
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 1\Scsi Bus 0\Target Id 0\Logical Unit Id 0
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port 2\Scsi Bus 0\Target Id 0\Logical Unit Id 0
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\Enum
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\IDE
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\SCSI

1.6 SMBIOS 字符串

相关API:GetSystemFirmwareTable
System Management BIOS 是由BIOS读取的一组数据结构。虚拟机会带有有特殊的字符串。VMware 虚拟机会带有 “VMware”。

1.7 ACPI 字符串

相关API:GetSystemFirmwareTable
Advanced Configuration and Power Interface (ACPI) 是操作系统通过 BIOS 或 UEFI 与各种硬件组件进行通信的接口。VMware 虚拟机会带有 “VMware”。

1.8 进程

相关API:CreateToolhelp32SnapshotProcess32FirstProcess32Next
一些虚拟机利会有特殊的后台进程。这些进程主要提供一些方便的功能,例如自动配置屏幕分辨率和配置网络设置等。
VMware虚拟机中可能会有以下进程:

◆Vmtoolsd.exe

◆Vmwaretray.exe

◆Vmwareuser.exe

◆VGAuthService.exe

◆Vmacthlp.exec

有些恶意软件还会通过进程数来检测虚拟环境,比如 ”EvilBunny“ 会检测是否存在至少15个进程。

1.9 硬盘硬件ID以及名称

相关API:SetupDiGetClassDevsSetupDiGetDeviceRegistryProperty
Win32/Winwebsec的一些变种使用了一种通过 Setup API来检查硬盘设备名的方法。类似的也可以检测硬盘硬件ID。

1.10 通过 WMI 获取硬件信息

Windows Management Instrumentation(WMI),提供了一种标准化的接口,允许程序获取系统信息并执行管理任务。WMI是基于COM(Component Object Model)技术构建的,并使用WQL(WMI查询语言)来查询数据。
◆可以通过 WMI 获取 BIOS 序列号并查看是否带有类似“VMWARE”的字符串。类似的还可以检测 Win32_ComputerSystem 下的 Model 以及 Manufacturer 字段。
VOID CheckBIOSSerialNumberWMI(){  IWbemServices* pSvc = NULL;  IWbemLocator* pLoc = NULL;  IEnumWbemClassObject* pEnumerator = NULL;  BOOL bFound = FALSE;  HRESULT hRes;   // Init WMI  if (!InitWMI(&pSvc, &pLoc, _T("ROOT\\CIMV2")))      return;   // If success, execute the desired query  if (!ExecWMIQuery(&pSvc, &pLoc, &pEnumerator, _T("SELECT * FROM Win32_BIOS")))      return;   // Get the data from the query  IWbemClassObject* pclsObj = NULL;  ULONG uReturn = 0;  VARIANT vtProp;   while (pEnumerator)  {      hRes = pEnumerator->Next(WBEM_INFINITE, 1, &pclsObj, &uReturn);      if (0 == uReturn)          break;       // Get the value of the Name property      VariantInit(&vtProp);      hRes = pclsObj->Get(_T("SerialNumber"), 0, &vtProp, 0, 0);      if (SUCCEEDED(hRes)) {          if (vtProp.vt == VT_BSTR) {              if (StrStrI(vtProp.bstrVal, _T("VMWare")) != 0)              {                  bFound = TRUE;                  VariantClear(&vtProp);                  pclsObj->Release();                  break;              }          }          VariantClear(&vtProp);      }       // release the current result object      pclsObj->Release();  }   // Cleanup  pSvc->Release();  pLoc->Release();  pEnumerator->Release();  CoUninitialize();   PrintResult(bFound, _T("Checking SerialNumber from BIOS using WMI"));}
◆可以通过返回结果的条目数,检查是否存在一些物理机应该有的硬件,比如:
SELECT * FROM Win32_Fan // 风扇SELECT * FROM Win32_CacheMemory //SELECT * FROM Win32_VoltageProbe // 电压探针SELECT * FROM Win32_PerfFormattedData_Counters_ThermalZoneInformation // 热区信息SELECT * FROM CIM_Memory // 物理内存SELECT * FROM CIM_Sensor // 传感器设备SELECT * FROM CIM_NumericSensor // 数字传感器SELECT * FROM CIM_TemperatureSensor // 温度传感器SELECT * FROM CIM_VoltageSensor // 电压传感器

基于指令的检测

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

2.1 IN

IN指令从指定的I/O端口读取值到指定的内存地址。I/O端口是操作系统和I/O设备(如磁盘控制器和声音设备)之间的通信手段。基于VMware的虚拟机具有端口号为 0x5658 的I/O设备,允许hypervisor 和虚拟机之间通信。通常,在非特权用户模式下运行IN指令将触发特权指令异常。但在 VMware 中,不会引发此类异常。VMware 公司甚至将此作为官方检测 VMware hypervisor 的手段。VMware 也提供了一个接口,允许用户“关闭”此方法。
bool isVmwarePresent()
{
__try {
_asm {
mov eax, 0x564d5868 // 'VMXh'
mov ebx, 0
mov cx, 1
mov dx, 0x5658 // 'VX'
in eax, dx
}
return true;
}
__except (GetExceptionCode() == EXCEPTION_PRIV_INSTRUCTION) {
return false;
}
}

2.2 CPUID

CPUID是一种x86指令,用来获取CPU的各种信息。该指令通过输入 EAX 中的值来确定要在EAX,EBX,ECX和EDX寄存器中返回的信息。下面给出三种基于 CPUID 指令的检测方法。
1.当 EAX=0 时, CPUID 将按EBX,EDX和ECX寄存器的顺序返回一个12个字符的制造商ID字符串。Intel CPU返回“GenuineIntel”,而AMD CPU在K5型号之后返回“AuthenticAMD” 。当在虚拟机中运行时,ID将被专属于某些虚拟机的自定义字符串替换。VMware虚拟机中理论上将返回 “VmwareVmware”。
BOOL CheckCPUIDVendor(){ INT CPUInfo[4] = { -1 }; CHAR szHypervisorVendor[0x40];  __cpuid(CPUInfo, 0x40000000); SecureZeroMemory(szHypervisorVendor, sizeof(szHypervisorVendor)); memcpy(szHypervisorVendor, CPUInfo + 1, 12);  if (_strcmpi(szHypervisorVendor, "VMwareVMware") == 0)     return TRUE;     return FALSE;}
2.当 EAX=1 时,CPUID将返回有关处理器功能的信息,例如处理器支持的指令。返回值 ECX 中的第 31 位确定是否存在 hypervisor。在物理机中此值为 0,在虚拟机中为 1。
BOOL CheckCPUIDVendor(){ INT CPUInfo[4] = { -1 };  __cpuid(CPUInfo, 1);  if ((CPUInfo[2] >> 31 ) & 1)     return TRUE;     return FALSE;}
3.在虚拟机中执行 CPUID 还会触发 VM-Exit Event,使得进程从 guest 切换到 VMM。可以用 RDTSC 指令来计算这个开销。
BOOL rdtsc_diff_vmexit(){ ULONGLONG tsc1 = 0; ULONGLONG tsc2 = 0; ULONGLONG avg = 0; INT cpuInfo[4] = {};  // Try this 10 times in case of small fluctuations for (INT i = 0; i < 10; i++) {     tsc1 = __rdtsc();     __cpuid(cpuInfo, 0);     tsc2 = __rdtsc();      // Get the delta of the two RDTSC     avg += (tsc2 - tsc1); }  // We repeated the process 10 times so we make sure our check is as much reliable as we can avg = avg / 10; return (avg < 1000 && avg > 0) ? FALSE : TRUE;}

2.3 SIDT(已失效)

SIDT是 Intel x86 指令,用于检测旧单核处理器上的虚拟机存在。这个指令被 “ScoopyNG” 以及 “Redpill” 使用,来检测虚拟机的存在。该命令将中断描述符表寄存器 (IDTR)的内容存放到指定内存地址中。中断描述符表(IDT)是一种重要的操作系统数据结构,用于处理来自硬件(如键盘和鼠标)的中断命令。hypervisor 会将虚拟化操作系统的 IDT 的地址移动到 hypervisor 可预测的地址。Klein 和 Rutkowska 都发现VMware在当时将 IDT 存储在地址0xFFXXXXXX上,从而在单核处理器上检测 VMware 虚拟机。
 
然而,随着多核处理器的引入,这种虚拟机检测技术不再可靠,因为处理器内的每个核心都具有唯一的中断描述符表,而每个表的地址都不同。此外,在我们对 VMware 的虚拟机测试SIDT命令时,即使只分配了一个处理器核心,IDT 的地址也从未出现在0xFFXXXXXX的地址上。因此,这种虚拟机检测方法已失效。

2.4 SGDT(已失效)

SGDT是 Intel x86 指令,用于将全局描述符表寄存器(GDTR)的内容存放到指定内存地址中。GDT 是处理器使用的数据结构,用于定义有关进程内存的详细信息,例如基址、大小和内存权限。这种虚拟机检测方法曾被“ScoopyNG”使用。与SIDT指令类似,当在基于VMware的虚拟机中运行时,该指令会返回0xFFXXXXXX的值。然而,这个指令也面临着 SIDT 指令引入多核处理器后遇到的同样问题。在使用 VMware Workstation 测试这种检测方法时,返回的值并不是0xFFXXXXXX。因此,这种检测方法已失效。

2.5 SLDT(已失效)

SLDT 是 Intel x86 指令,用于将本地描述符表寄存器(LDTR)的内容存放到指定内存地址。LDT包含有关进程内存段的信息,例如代码段、数据段以及堆。当在虚拟机中执行此命令时,将返回非零值,而在非虚拟化环境中返回0。“ScoopyNG”和恶意软件“Conficker”曾使用过这种虚拟机检测方法。我们在 VMware Workstation、VirtualBox、XEN、HyperV 和 KVM/QEMU 虚拟机上测试了此命令,发现所有虚拟机都返回0。这种检测方法已失效。

2.6 STR(已失效)

STR是 Intel x86 指令,它返回当前执行进程的任务状态寄存器(TSR)内容到指定内存地址。任务状态段 TSS 用于存放操作系统用于任务切换的数据,其中包括进程 threads 和 registry 信息,供处理器操作系统处理线程调度。Klein 发现在虚拟机内运行此命令时,它返回格式为 0x0040XXXX 的地址。对VMware Workstation、VirtualBox、XEN、HyperV和KVM/QEMU虚拟机上测试此命令,发现这种检测方法已失效。

2.7 SMSW(已失效)

SMSW是 Intel x86命令之一,用于将机器状态字返回到指定的内存地址。机器状态字的信息来自CR0寄存器,与 CPU 用于指示是否启用某些功能(如内存分页)的 flags 有关。Quist 发现,在VMware虚拟机内运行此命令,当 EAX=0xCCCCCCCC 时,将返回 0x8001XXXX。经测试在VMware虚拟机内和物理机上测试此命令都会返回值 0x8005XXXX。因此这种检测方法已失效。

2.8 VM “Synthetic Instructions”(已失效)

Traut在2003年提出了一种使用“合成CPU指令”的虚拟机检测方法。这些指令仅被虚拟机支持,在物理机上执行时会触发无效指令异常。由于这些是无效的CPU指令,因此它们未在Intel或AMD的程序员手册中记录。这些指令的格式为“0FC7C8XXXX”。其中最“VMCPUID”指令被“Necurs”僵尸网络用于检查虚拟机的存在。
在 VMware Workstation、VirtualBox、XEN、HyperV 和 KVM/QEMU 虚拟化平台上测试 “VMCPUID” 指令的代码如下:
bool IsVmcpuidSupported()
{
bool supported = true;
void* mempool;
char vmcpuid[] = "\x0F\xC7\xC8\x01\x00"; // VMCPUID OPCODE
mempool = malloc(sizeof(vmcpuid));
memcpy(mempool, &vmcpuid, sizeof(vmcpuid));
DWORD prevAccess;
VirtualProtect(mempool, sizeof(vmcpuid), PAGE_EXECUTE_READ, &prevAccess);

__try {
((void(*)())mempool)();
}
__except(EXCEPTION_EXECUTE_HANDLER) {
supported = false;
}
return supported;
}

结果所有测试的虚拟化平台都不支持 VMCPUID 命令。实际上,这个命令被错误地解释为两个命令:
CMPXCHG8B EAX
ADD DWORD PTR DS:[EAX],EAX


其他检测方法

3.1 Thermal Zone Temperature

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

$valorTempKelvin = $t.CurrentTemperature / 10
$valorTempCelsius = $valorTempKelvin - 273.15

$valorTempFashrenheit = (9/5) * $valorTempCelsius + 32

return $valorTempCelsius.ToString() + " C : " + valorTempFashrenheit.ToString() + \
" F : " + $valorTempKelvin.ToString() + "K"
}

Ref:
Anti-VM Technique with MSAcpi_ThermalZoneTemperature
https://debugactiveprocess.medium.com/anti-vm-techniques-with-msacpi-thermalzonetemperature-32cfeecda802

3.2 IP Timestamp Patterns

这种虚拟机检测方法是由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

3.3 CPU Detail Anomalies

通过检查CPU物理核心数、逻辑核心数和cache容量与实际产品配置的不一致性来检测虚拟机。
 
Ref:Mettrick D. Virtual machine detection through Central Processing Unit (CPU) detail anomalies[D]. , 2022.

3.4 Physical memory resource maps

在 Windows 中,设备驱动程序需要访问硬件资源(如内存、I/O 端口、中断等),这些资源的地址通常是硬件相关的,因此在不同的系统上地址可能会发生变化。为了方便驱动程序的编写和移植,Windows 内核提供了资源映射机制,将硬件相关的地址转换为系统相关的地址,从而使驱动程序可以在不同的系统上运行而不需要进行修改。内存翻译就是其中一种资源映射类型,它将硬件设备的物理内存地址映射为系统中的虚拟内存地址,使驱动程序可以通过虚拟地址来访问设备内存。
 
可以通过比对虚拟地址的不同检测虚拟机环境。测试发现Hyper-V虚拟机具有与 00001000-000a0000 匹配的物理内存映射区域。VirtualBox虚拟机具有与 00001000-009f000 匹配的物理内存映射区域。
 
Ref:
VM Detection Tricks, Part 1: Physical memory resource maps
https://labs.nettitude.com/blog/vm-detection-tricks-part-1-physical-memory-resource-maps/

3.5 Driver Thread Fingerprinting

驱动程序可能创建一定数量的线程,并具有可预测的属性,因此这些属性可以用于指纹识别并构建有用的检测启发式算法。
 
Ref:
VM Detection Tricks, Part 2: Driver Thread Fingerprinting
https://labs.nettitude.com/blog/vm-detection-tricks-part-2-driver-thread-fingerprinting/

3.6 基于鼠标行为的方法

恶意软件 Win32/Okrum 使用了基于行为的一些方法来检测沙箱:

◆GetTickCount函数调用两次,间隔20秒休眠。如果GetTickCount值没有改变(即时间已经加速),恶意软件将终止自身。

◆连续两次调用GetCursorPos函数。如果鼠标在X轴上的位置发生了变化(即鼠标位置是随机生成的),恶意软件将终止自身。

◆调用GetGlobalMemoryStatusEx。如果实际物理内存的数量小于1.5GB,恶意软件将终止自身

◆只有左键(物理)鼠标按钮按下至少三次后(在无限循环中查询GetAsyncKeyState),负载才开始。

Ref:
ESET_Okrum_and_Ketrican.pdf
https://www.welivesecurity.com/wp-content/uploads/2019/07/ESET_Okrum_and_Ketrican.pdf
1.https://www.cynet.com/attack-techniques-hands-on/malware-anti-vm-techniques/
2.https://www.ptsecurity.com/ww-en/analytics/antisandbox-techniques/
3.https://artemonsecurity.com/vmde.pdf
4.https://github.com/LordNoteworthy/al-khaser
5.https://github.com/a0rtega/pafish

看雪ID:gmhax

https://bbs.kanxue.com/user-home-950495.htm

*本文由看雪论坛 gmhax 原创,转载请注明来自看雪社区

# 往期推荐

1、APP去广告技术分析

2、2023·腾讯游戏安全大赛-安卓赛道决赛题解

3、使用Triton框架分析混淆代码

4、X-Bogus vmp分析

5、记一次试岗实战项目

6、关于Nokelock蓝牙锁破解分析

球分享

球点赞

球在看


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458504276&idx=1&sn=cb5276a6bdd94a51fec44f1db391221e&chksm=b18efcde86f975c8513c407fd96cf81669bbf42b1ddae9e1f2164b4400f613c3199fbbe85056#rd
如有侵权请联系:admin#unsafe.sh