逃避博弈：剖析恶意软件在加壳器、沙箱和调试器中的规避技术

《ACM Transactions on Privacy and Security》：Evasion Games: Dissecting Malware Evasive Techniques Across Packers, Sandboxes, and Debuggers

　　摘要恶意软件作者越来越多地利用规避技术来掩盖恶意行为，逃避动态分析工具的检测。尽管已有研究对这些技术进行了分类，但现有分析环境——沙箱和调试器——对抗这些技术的能力仍未得到充分探索。在本工作中，我们提供了一个更新和扩展的规避技术分类体系，识别出55种新记录的技术。随后，我们评估了25种商业和公开可用的加壳工具将规避行为嵌入混淆二进制文件的程度。最后，我们评估了7个在线沙箱和4个调试器应对这些技术的准备程度。实验结果显示存在显著差距：虽然沙箱在应对反调试和反虚拟化技术方面普遍表现出较高的准备度，但它们仍然容易受到各种规避手段的攻击，尤其是基于时间的攻击。相比之下，调试器的整体效果较差，仅能成功应对27%的规避技术。这些发现凸显了当前分析环境的持续局限性，并推动开发更强大的反规避策略。1 引言恶意软件是计算机安全领域最重大的挑战之一。其传播持续增长，网络犯罪分子通过各种形式的恶意软件（如勒索软件、银行木马和僵尸网络）越来越多地针对个人、企业和政府机构[11]。为了应对这些威胁，研究界开发了基于两种主要方法——静态分析和动态分析——的恶意软件检测工具[21]。静态分析通过检查程序的静态内容（如程序字节或二进制结构）来检测恶意软件，而动态分析则通过观察程序的执行行为来识别恶意模式。然而，静态检测恶意软件已变得越来越困难，甚至几乎不可能。高级混淆技术如多态[71]和变形[80]已使许多静态工具失效。多态恶意软件在每次迭代中动态改变其代码，变形恶意软件则完全重写其代码，从而击败依赖已知字节序列的自动检测系统。这些技术也使手动分析变得复杂，显著增加了使用逆向工程工具理解程序行为所需的工作量[46]。另一方面，动态分析已成为一种更稳健的替代方案，因为它观察恶意软件在执行过程中的行为[1]。手动动态分析涉及在调试器中执行程序，使分析人员能够逐步监控其动作和系统交互。然而，这种方法耗时且资源密集。为应对这些挑战，研究人员已将关注点转向自动化动态分析方法。沙箱已成为这项工作的重要工具，提供隔离环境，使程序能够安全执行并得到详细监控[73]。这些环境捕获全面的行为数据，包括网络流量、执行的命令以及与操作系统API的交互。数据随后使用外部工具（如机器学习模型）进行分析，以确定观察到的行为是否具有恶意性。然而，恶意软件作者已开发出复杂的反分析技术来检测和规避动态分析环境[24]。因此，动态分析工具的有效性取决于它们处理高级规避技术的能力，即隐藏可能被恶意软件检查以识别其是否正在被分析的人工痕迹。恶意软件作者利用动态环境的固有可检测性，设计恶意软件在执行过程中识别此类设置。如果恶意软件检测到分析的迹象，它可以停止执行、表现出良性行为，或调整其操作以逃避检测。相反，如果环境看起来合法（即，用于真实用途而非分析的环境），恶意软件则继续其恶意活动。为了应对这些复杂的规避策略，现代分析环境必须复制合法系统行为，例如模拟用户交互、生成真实的系统活动，以及混淆与分析相关的人工痕迹，如虚拟机指示器或调试器进程。为此，研究界开始研究规避行为，并为Windows[24]和Android恶意软件[60]生成了分类体系，确定了最常见的规避技术，以便在分析环境中制定对策。其他工作专注于开发隐藏分析人工痕迹的沙箱或调试器，使恶意软件在分析过程中能够暴露其行为。据我们所知，尚未有研究对分析环境在处理规避技术方面的覆盖范围进行全面评估，评估其对抗规避策略的能力。据我们所知，我们是首个进行此类评估的研究。此外，由于许多恶意软件作者不直接保护其恶意软件，而是依赖商业加壳工具来混淆它们或保护它们免受动态分析环境的检测，我们将评估范围扩展至分析这些工具所使用的技术。为实现目标，我们首先更新现有的规避技术分类体系。然后，我们评估了25种公开可用的加壳工具在生成的混淆二进制文件中所引入的规避技术。最后，我们测试了7个公开可访问的在线沙箱和4个针对Windows操作系统的调试器，以确定它们是否主动隐藏分析人工痕迹，或者规避技术是否能有效检测它们的存在，特别关注加壳工具所实现的技术。实验结果表明，调试器在对抗反调试规避技术方面尚不有效，仅能成功应对约27%的技术。然而，在应对杂项和反虚拟化技术时，它们表现出更强的能力，平均成功率均达到85%。相比之下，沙箱在对抗反调试和反虚拟化技术方面更为有效，分别成功处理了平均69%和57%的技术。然而，它们在应对杂项技术时更为脆弱，仅能成功应对42%的技术。我们的贡献如下：——我们在总计191种技术的基础上，扩展和更新了先前的规避技术分类体系，新增了55种新技术。——我们识别了25种可用加壳工具最常使用的规避技术。——我们研究了7个在线沙箱和4个调试器针对更新分类体系所实现的反规避能力。——我们识别了加壳工具实现的最有效的规避技术，这些技术对研究的分析环境具有最强的对抗效果。本文其余部分的结构如下。第2节提供了理解本工作所需的技术背景。在第3节中，我们确定了想要回答的研究问题。在第4节中，我们介绍了更新后的分类体系，概述了不同类别并强调了新识别的技术。第5节描述了用于测试的方法论。最后，在第6节中，我们报告了针对加壳工具、沙箱和调试器进行的实验结果。2 规避技术与分析方法背景在本节中，我们介绍理解本文内容所需的背景知识。首先，我们描述恶意软件分析的两种主要方法——静态和动态——并概述与每种方法相关的可用工具。最后，我们介绍什么是规避软件，以及为什么在恶意软件分析背景下研究针对规避技术的对策具有重要意义。2.1 静态与动态分析静态分析和动态分析是用于对编译二进制文件（例如，原始源代码不可用的程序）进行逆向工程的两种不同方法。在本节中，我们介绍静态和动态分析的技术细节。2.1.1 静态分析。这是一组在不执行程序的情况下检查程序的分析技术，依赖于直接从程序字节序列中提取的信息。一个典型的例子是特征码分析，它将二进制文件与已知恶意软件特征——即已知威胁特有的不同字节序列——进行比对，以将其分类为恶意或良性[5]。除了简单的特征码匹配外，静态分析还包括旨在提取更深层语义信息的更复杂方法。这些方法包括识别二进制文件中的单个函数、生成伪C代码表示、计算控制流图（CFG）[3]，以及执行污点分析以跟踪程序中的数据传播[7]。通过利用语义理解，这些先进技术与基于特征码的基本方法相比，显著提高了恶意软件检测的准确性[8, 76]。然而，尽管有这些进步，静态分析方法仍然容易受到混淆技术的攻击[46]。恶意软件作者通常使用多态——一种加密或以其他方式混淆可执行字节的技术，仅在运行时揭示其真实形态[71]——以及变形，后者生成多个功能相同但字节码模式完全不同的恶意软件变种[80]。混淆方法带来的分析挑战促使研究人员探索能够克服静态方法固有局限的新型动态分析技术。2.1.2 动态分析。与静态分析相反，动态分析技术通过执行二进制可执行文件并提取其运行时行为来对其进行分析。在恶意软件检测任务中，此类信息用于通过分析程序的动态行为来确定程序是良性软件还是恶意软件。调试器是开发人员和安全分析师用于检查、分析和操纵恶意软件执行的软件工具。它们使用底层操作系统提供的API来监控和控制执行，例如访问内存、在特定点停止执行（即断点）、拦截信号以及跟踪对操作系统API的调用。最著名的Windows调试器包括WinDbg[14]、OllyDbg[78]、Immunity Debugger[26]、x64dbg[74]和HyperDbg[33]。在Linux上，最广泛使用的调试器是LLDB[37]和GDB[25]，而诸如libdebug项目[19]等近期工作旨在为调试工作流引入更强的脚本能力和可配置性。动态二进制插桩（DBI）是一种允许在运行时分析和修改二进制文件行为的技术。DBI在无需访问源代码的情况下，将自定义插桩代码插入运行中的程序。插桩代码可用于提取程序的运行时行为。最著名的DBI框架包括Pin[40]、Valgrind[49]和Frida[54]。Valgrind通过将二进制的机器码动态翻译为称为VEX的中间表示（IR）来执行分析，该表示独立于底层硬件架构。Valgrind随后在将结果IR即时（JIT）重新编译回机器码之前，对IR应用插桩。Pin提供两种插桩模式：JIT模式和探测模式。JIT模式使用即时编译器动态重新编译正在执行的代码并插入插桩。探测模式使用探针挂钩函数调用，该技术将例程的第一条指令替换为对替换例程的无条件跳转。Frida通过JavaScript和Python提供强大的脚本能力，支持快速原型设计和适应不同环境。它开销极小，支持跨多个平台的用户态和内核态自省。另一种广泛使用的运行时分析技术是API钩子[38]，它允许拦截应用程序内的函数调用，以监控、修改或抑制其执行。此技术常用于恶意软件分析、安全监控和逆向工程。API钩子可以使用多种方法实现，包括内联钩子、导入地址表（IAT）钩子和导出地址表（EAT）钩子。内联钩子涉及修改函数的前几个字节以将执行重定向到自定义处理程序，而IAT和EAT钩子则操纵Windows用于解析动态链接函数调用的表。诸如Microsoft Detours、MinHook和Frida等工具便于实现API钩子，允许分析师实时检查应用程序与操作系统之间的交互。沙箱是在隔离环境中执行程序的自动化工具，并使用动态技术（如DBI、调试或API钩子）来提取程序的行为，例如网络流量和操作系统API使用情况。这些信息通过输入到基于人工智能的恶意软件分类器[66]中，用于确定样本是否具有恶意性。然而，本节介绍的所有工具都会在系统中留下可被恶意软件在执行前检测到的人工痕迹。调试器修改被分析进程内存中的某些字段，而沙箱可以通过查询运行中CPU的信息被轻易地指纹识别。2.2 规避软件规避软件检查人工痕迹的存在以确定其是否正在被分析，例如，是否运行在虚拟化环境、沙箱或调试器中。根据这些检查的结果，它可能改变其行为，例如提前终止。此类规避策略既被商业软件用于防止对受版权保护代码的逆向工程，也被恶意软件使用。后者希望隐藏恶意行为，以免被动态分析工具发现，否则这些工具可能生成行为指纹以支持静态检测方法。3 动机尽管在理解和分类恶意软件规避行为方面已投入大量研究，但大多数研究集中在分类学或开发旨在规避检测的沙箱和调试器上。我们的目标是评估分析环境在检测和缓解规避技术方面的有效性，特别强调加壳工具所采用的技术，这些技术可以自动化规避过程。为了实现我们的目标，我们定义了一系列旨在本文中回答的研究问题：—RQ1：自先前发表的逃避技术分类法发布以来，引入了哪些新技术？—RQ2：现有商用加壳器在生成的混淆二进制中加入了哪些逃避技术？—RQ3：公开可用的分析环境（即沙箱和调试器）在处理逃避技术方面的覆盖范围如何？—RQ4：加壳器所添加的技术对被测分析环境的有效性如何？我们在第4节回答RQ1，在第6.1节回答RQ2，在第6.2节和第6.3节回答RQ3和RQ4。4 分类法在本节中，我们介绍用于开展研究的分类法，并展示我们对先前工作更新所做的贡献。先前最先进的逃避技术分类法是由Galloro等人提出的[24]。尽管它是最新的逃避恶意软件系统化研究，但它只涵盖了截至2020年发现的逃避技术。遵循其搜索方法论，我们从总共191种新的逃避技术中识别出55种，并一致地更新了系统化体系，以更好地适应新引入的技术。这些技术在表1中以粗体标出。表1。类别参考文献技术TPS1S2S3S4S5S6S7D1D2D3D4CPU指纹识别[15] [64]CPUID (EAX=0x00000001)V8INV0CPUID (EAX=0x40000000)V1STRV0SMSWV0驱动信息[18]EnumDeviceDrivers和GetDeviceDriverBaseNameV0异常处理[55] [22]DebugBreakD0SetUnhandledExceptionFilterD16POPF/D - TRAP FLAGD7--NtClose(INVALID_HANDLE)D1CTRL异常处理D0OutputDebugStringD1仿真[39]检查Virtual PCV0检查QEMUV0检查XenV0检查WineV0文件系统[56] [61] [29] [27]GetModuleFileNameAV8GetProcessImageFileNameAV5-QueryFullProcessImageNameV0MsiGetProductInfoAM0-枚举最近文件M0-NtOpenFileM1NtQueryAttributesFileM0NtCreateFileM1NtQueryDirectoryFileExM0人类交互[42] [65] [23]GetForegroundWindowV5GetAsyncKeyStateV0SetWindowsHookExAV1MessageBoxV0GetCursorPosV2GetLastInputInfoV0SetWindowsHookScrollingV0进程列表[27]NtQSI(SYSTEM_PROCESS_INF)M0EnumProcesses和GetModuleBaseNameM1GetProcessIdFromNameD0服务列表[27]OpenSCManager和EnumServicesStatusV1OpenServiceV0GetServiceDisplayNameV0GetServiceKeyNameV0系统环境[15] [36] [43] [72] [64]PEB->BeingDebuggedD1PEB->NtGlobalFlagD0PEB->Heap->FlagsD0PEB->Heap->ForceFlagsD0KUSER_SHARED->KdDebuggerEnabledD0其他[56] [59]WNetGetProviderNameV0GetLogicalDriveTypeV2NtSetDebugFilterStateD0IsParentExplorerExeM0指令前缀D0IsHookedM1dbgExcpD0VirtualAlloc_WriteWatch_BufferOnlyM0VirtualAlloc_WriteWatch_APICallsM0VirtualAlloc_WriteWatch_IsDebuggerPresentD0VirtualAlloc_WriteWatch_CodeWriteM0hideDesktopV0CanOpenCsrssM5内存断点_PageGuardD0NtYieldExecutionD0SetHandleInformation_ProtectedHandleD0query_license_valueV0power_capabilitiesV0pirated_windowsV0check_loadLibraryM0进程环境[56] [22], [35] [64]GetModuleHandleM3NtSetContextThread$CONTEXT_DEBUG_REGISTERS)D0NtQueryInformationProcess(0x07)D3NtSetInformationThread(0x11)D4NtQueryInformationProcess(0x1e)D0NtQueryInformationProcess(0x1f)D2NtGetContextThread$CONTEXT_DEBUG_REGISTERS)D0DebugActiveProcess on ParentD3NtCreateThreadEx$HIDE_FROM_DEBUGGER)D0注册表[27]NtOpenKey/ExM1NtEnumerateKeyM0NtQueryValueKeyM0NtEnumerateValueKeyM0系统环境[39] [17] [62] [47] [67] [16] [68] [41] [61] [56] [31] [57] [58] [13] [15] [36] [43] [72] [64]GetUsernameAV1GetSystemInfoV2IsNativeVhdBootV0EnumWindowsV1EnumDisplayMonitorsV1GetSystemMetricsV8GetDesktopWindowRectV6EnumDisplaySettingsV0GetProcessAffinityMaskV2SetupDi_DiskDriveV0EnumPrintersV0GetSystemDefaultLangIDV0GetUserDefaultLangIDV4GetKeyboardLayoutListV5GetKeyboardLayoutV5IsProcessorFeaturePresentV0NtSystemDebugControlD0--CreateMutexD0OpenMutexD0WudfIsAnyDebuggerPresentD0--WudfIsUserDebuggerPresentD0--WudfIsKernelDebuggerPresentD0GetMonitorInfoV0GetVolumeInformationV0GetSystemFirmwareTableV1NtQuerySystemInformation$PHYSICAL_MEMORY_INFO)V0NtQuerySystemInformation(0x23)D2DeviceIoControlV6PEB->NumProcessorsV1NtQueryObject after NtCreateDebugObjectD0FindWindowM3GetLocaleInfoV2GetComputerNameV1GetUserDefaultUILanguageV1GetSystemDefaultUILanguageV0IsDebuggerPresentD9GetAdaptersInfoV2GetDiskFreeSpace/ExV0CheckRemoteDebuggerPresentD3GetAdaptersAddressesV0GlobalMemoryStatusExV1拖延[30] [69] [56] [34] [50]PingM0BeepM0WaitForMultipleObjectsM0waitForSingleObject/ExM1BeepLoopM0Sleep/SleepExM3SetTimerM1SetWaitableTimer/ExM0CreateTimerQueueTimerM0NtDelayExecutionM1timeSetEventM0icmpSendEcho/2/ExM0SleepLoopM0表描述符[64]SLDTV0SGDTV0计时[43] [52] [64]GetTickCountM4timeGetSystemTimeM0KUSER_SHARED->TickCountQuadM2NtGetTickCountM0QueryInterruptTimeM0NtQueryPerformanceCounterM6QueryUnbiasedInterruptTimePreciseM0QueryInterruptTimePreciseM0GetTickCount64M0QueryUnbiasedInterruptTimeM0RDTSC/DM2QueryPerformanceCounterM9GetLocalTimeM1timeGetTimeM1NtQuerySystemTimeM10GetSystemTimeM0KUSER_SHARED->SystemTimeM2KUSER_SHARED->InterruptTimeM1陷阱[22] [27] [35] [64]INT 3D0VPCEXTV0INT 1D2ICEBPD1INT 2DD0WMI[32] [56] [42] [63] [39] [30] [44] [23]LogicalDiskV0NetworkAdapterConfigurationV0PnPEntityV0MSAcpi_ThermalZoneTemperatureV0PointingDeviceV0DiskDriveV0BaseBoardV0VideoControllerV0NetworkAdapterV0OperatingSystemV0BusV0ComputerSystemProductV0SecurityCenter2_AntiVirusProductV0ProcessorV0MemoryDeviceV0MemoryArrayV0VoltageProbeV0PortConnectorV0SMBIOSMemoryV0PerfFormattedData_Counters _ThermalZoneInformationV0MemoryV0SensorV0NumericSensorV0TemperatureSensorV0VoltageSensorV0PhysicalConnectorV0SlotV0BIOSV0ComputerSystem (model)V0ComputerSystem (manufacturer)V0ComputerSystem (ProcessorId)V0FanV0CacheMemoryV0PhysicalMemoryV0所有测试环境中的实验结果以粗体显示的实验代表我们更新后的分类法中新识别的技术。列T表示技术类型，其中V代表反虚拟化，D代表反调试，M代表杂项。列P显示有多少加壳器使用了特定的逃避技术。表示某技术在特定环境中成功逃避检测，而表示未成功。与先前的工作相比，我们引入了两个新的逃避技术家族：地理围栏和仿真。地理围栏技术通过检查区域设置来检测分析环境，其中异常的区域设置是分析环境的指示器。仿真家族包括检查已安装的仿真软件（如QEMU）的技术。我们进一步将这些家族划分为技术宏类别，根据系统工件、侧信道测量或进程的当前执行行为的使用情况来对系统进行分类。4.1 系统工件这类检查搜索可能表明分析环境存在的系统工件。例如，它包括检查人类活动的痕迹[45]，如最近访问的文件、已安装的应用程序或浏览器历史记录。由于沙箱通常从全新的Windows安装开始，此类工件通常不存在。另一种方法是检查进程内存中的工件，这可能会揭示有关调试状态、父进程或其他运行时属性的信息[24]。最后，逃避软件可以检查系统信息以识别与虚拟机监控程序相关的硬件组件，例如特定的CPU特性或虚拟化设备。更具体地说，技术家族包括：—系统环境：利用系统API调用来查询操作系统的特定属性和配置，旨在检测表明分析环境存在的工件。这包括RAM、硬盘、CPU和网络适配器等硬件组件，以及系统主机名等软件元素。—内存指纹识别 此类别中的逃避技术会在运行进程的内存空间中寻找分析环境的痕迹。例如，进程环境块（PEB）或KUSER_SHARED_DATA等进程相关结构包含有关附加到进程的任何调试器的信息，包括用户空间和内核空间。—CPU指纹识别 这些技术使用特定的汇编指令（如CPUID）从运行进程的CPU中查询信息，以确定处理器是真实的还是程序正在通过虚拟机监控程序运行。—表描述符：恶意软件使用表描述符中的值来检查虚拟机或沙箱中通常存在的异常值。然而，这类技术仅适用于单核机器，现已过时。特别是，这些技术会在本地描述符表（LDT）、全局描述符表（GDT）和中断描述符表（IDT）中寻找分析指示器。—陷阱 这些技术执行一些CPU陷阱或中断指令，这些指令可能被分析环境拦截，从而阻止程序处理它们。—注册表 此类别中的技术查询Windows系统注册表中与虚拟机、沙箱或已安装调试器相关的已知键。—WMI Windows管理规范（WMI）是一个强大的框架，为管理和与Windows操作系统各种组件交互提供标准化方式。其提供的功能包括WMI查询语言（WQL），该语言具有类似SQL的语法，允许用户获取当前Windows安装的信息，如进程列表、已安装硬件和机器信息。此类别中的技术使用WMI来检测进程是否在分析环境中运行。—进程环境 这种检查会查看进程环境数据结构，以寻找任何分析环境的证据，如进程信息、任何已加载的调试或分析模块，或当前线程上下文的操作，因为这通常是调试器拦截的操作。—文件系统 此类别中的技术检查磁盘上与虚拟化或分析工具相关的文件。此外，还有关于当前进程路径的检查，因为许多自动化沙箱会从包含“sandbox”字符串的文件夹中运行样本。—进程列表 枚举活动进程，查找已知的调试器或沙箱相关进程。—服务列表 与驱动程序、进程、文件和其他虚拟化相关工件类似，恶意软件可能会枚举服务以检查它们是否与虚拟化软件相关。这可以通过诸如EnumServicesStatus、GetServiceDisplayName或GetServiceKeyName等方法获取每个服务的名称，然后与预定义黑名单进行比较，或通过使用黑名单名称调用OpenService来实现。—驱动信息 虚拟机通常安装驱动程序以改善客户机与主机操作系统之间的交互。一些逃避技术会查找与虚拟机相关的驱动程序，一旦发现此类驱动程序便停止恶意软件的执行。—其他 不属于其他类别但能有效检测分析环境的各种检查的集合。4.2 执行行为这类逃避技术分析进程的执行行为，以确定其是在合法系统上运行还是在分析环境内运行。典型策略包括检测人类交互的缺失、延迟执行以超过沙箱超时，以及引发异常以干扰调试器的控制流。—人类交互 大多数高级逃避技术执行反向图灵测试，以检测进程是自动在沙箱内运行还是由真实用户在合法机器上启动。这些技术在暴露恶意行为之前检查人类活动。如果反向图灵测试失败，例如恶意软件未检测到任何人类活动，则终止执行。—拖延 这些技术执行阻塞操作以超出动态分析系统的监控窗口。诸如WaitForMultipleObjects、WaitForSingleObject(Ex)、timeSetEvent、SetTimer、SetWaitableTimer和CreateTimerQueueTimer等技术将内核级等待与基于计时器或事件的信号相结合，使其更难加速或绕过。此外，执行可以通过基于循环的延迟（SleepLoop、BeepLoop）反复暂停来阻塞，或通过网络/IO操作（Ping、icmpSendEcho）引入外部等待。—异常处理 此类别下的技术引发异常以测试它们是否被正确传递给程序。事实上，许多分析工具默认拦截异常，并且不会将其传递给运行中的程序。4.3 侧信道检查这类攻击检测分析环境引入的计算开销。沙箱和调试器都会减慢进程执行：前者通常在资源受限的虚拟机中运行，而后者因人类交互而引入延迟。最近的研究表明，此类攻击可以通过使用工作量证明算法[48]显著提高恶意软件的逃避率。我们的工作表明，大多数加壳器将侧信道测量引入输出二进制文件，并且沙箱对此类检查高度脆弱。—计时 这类技术通过检查预期执行时间的差异来识别分析环境。我们评估两种具有代表性的基于计时的检查：CPUID指令的执行开销和Sleep函数行为的一致性。CPUID指令在虚拟机监控程序内执行速度明显更慢，因为它通常触发向宿主机的VM-exit转换，与裸机执行相比引入额外延迟。通过测量重复CPUID调用的执行时间，程序可以推断虚拟化的存在。为了定义阈值，我们在裸机机器上进行多次测量，并计算不同执行时间的平均值。基于Sleep的检查验证观察到的挂起时间不短于请求的时间间隔。这允许检测钩住或修改sleep相关API以避免休眠行为的分析环境。预期睡眠持续时间与观察到的睡眠持续时间之间的差异是处于分析中的标志。除了对技术进行分组外，我们还将它们进一步分为三类：反虚拟化、反调试和杂项。反虚拟化技术旨在检测程序是否在虚拟化环境中运行。反调试技术旨在确定程序是否在调试器下执行。最后，杂项技术通过执行对虚拟机和调试器都有效的检查来针对通用分析环境，例如揭示执行开销的计时分析。表1展示了我们分类法中包含的技术，以及针对每个被测分析环境获得的结果。P列表示将特定技术添加到混淆程序中的加壳器数量，而T列指定技术类型，其中D代表反调试，V代表反虚拟化，M代表杂项。其他列对应特定的分析工具：前缀为S的列代表沙箱，前缀为D的列代表调试器。对于每个技术-环境对，我们使用表示成功逃避（即技术绕过了工具的检测），表示逃避失败（即工具成功检测到该技术），以及—表示技术与工具之间不兼容。例如，使用Wudf系列Windows API的技术与32位系统不兼容。5 方法论在本节中，我们介绍用于开展研究的方法论。特别是，我们解释了如何收集商业加壳器在混淆二进制中引入的逃避技术。最后，我们展示了用于评估沙箱和调试器的二进制数据集，以及我们如何研究它们对所识别逃避技术的准备程度。5.1 加壳器我们采用动态方法识别加壳器在生成的混淆二进制中引入的逃避技术。图1描绘了整个识别过程。图1. 沙箱逃避评估过程。我们编译一个基线程序，执行最小操作，目的是不影响评估结果。该程序使用每个被测加壳器进行加壳，并对生成的二进制进行动态分析以识别运行时引入的逃避技术。在此阶段，我们排除合成数据集和真实世界恶意软件。该评估的目标是隔离和表征加壳器引入的逃避技术。使用数据集二进制或真实世界恶意软件会将载荷级逃避行为与加壳器引入的机制混合，导致无法可靠归因，并损害分析的有效性。在动态分析阶段，我们在两个最广泛使用的选项Intel Pin [40]和Frida [54]之间选择后者，因为前者在恶意软件研究中被广泛使用，并且经常被逃避技术明确针对。使用Frida，我们提高了工具对此类对抗措施的韧性。插桩在函数和指令粒度上执行，以拦截逃避检查的执行。在函数级别，我们使用Frida的Interceptor API跟踪对Windows API的调用，这允许我们在目标函数的入口或出口点插入跳板。为了对抗规避行为，我们修改了可能泄露分析环境存在的返回值。在指令级别，我们监控常用于反分析技术的特定x86指令，例如暴露CPU特性的CPUID。Frida的Stalker引擎通过动态重编译实现这一点：它不是在内存中修改原始代码，而是在独立的内存区域生成重写副本。这使得插入的检测代码能够运行，同时绕过代码完整性检查。因此，我们的方法降低了被使用完整性验证来规避分析的恶意软件检测的风险。

5.2 数据集

我们用于验证方法的数据集是合成的，包含针对我们分类中每个规避技术的一个测试二进制文件，以及针对每个研究的加壳器的一个测试二进制文件。

如图2所示，生成过程包括围绕一组规避技术包装一个专门的日志记录操作。每个测试程序执行相应的规避检查，并模仿真实恶意软件的行为，有条件地执行日志记录操作，这使我们能够记录测试的结果。此操作因评估环境（例如沙箱和调试器）而异，并由被测工具的输出决定，如6.2节所述。我们进行了双重评估。首先，我们单独评估规避技术，这使我们能够评估分析环境对每种特定技术的准备程度。在这个阶段，单独评估是必要的，以防止可能扭曲多技术分析结果的混淆副作用。

图2. 合成测试生成过程。

然后，对于每个被分析的加壳器，我们生成一个包含该特定加壳器实现的所有技术的二进制文件。这使我们能够评估分析环境对商业加壳器使用的多种规避技术组合的准备程度。我们刻意避免使用真实恶意软件样本，因为它们对实验有效性构成两个主要挑战。首先，建立可靠的真实情况需要预先了解每个样本的规避机制和恶意行为。其次，如果样本已知，通常会被现代沙箱的静态过滤阶段阻止，从而完全阻止动态执行。我们使用真实恶意软件的初步实验证实了这一限制。最后，由于我们的目标是评估分析环境对特定规避技术的鲁棒性，而不是其检测恶意软件的能力，使用合成二进制文件不影响我们结果的有效性：被评估的规避机制保持不变，无论它们嵌入在真实还是合成程序中。

5.3 沙箱和调试器

图3说明了分析环境中使用的测试方法。沙箱通常在分析样本期间记录各种细节，包括其网络活动和执行的进程树。由于这些日志作为分析输出的一部分返回，我们的测试二进制文件执行可从输出日志中观察到的操作，以帮助识别规避尝试是否失败。如果沙箱提供网络活动日志，当规避尝试失败时，测试二进制文件会在TCP端口443上打开到公共服务器的连接。如果此连接出现在输出中，我们将规避尝试记为失败；否则，我们将其视为成功。如果网络活动在输出中不可用，二进制文件则使用C系统函数执行dir C:命令。如果此命令出现在记录的进程树中，我们再次将规避尝试标记为失败。我们测试的所有沙箱至少提供这些日志之一（网络或进程），我们手动验证了网络连接和命令执行在分析期间都被可靠捕获。

图3. 我们评估过程的图形表示：将规避技术添加到程序中并在测试环境中执行。如果程序未能检测到执行环境，它会执行特定操作。如果此操作稍后在执行日志中被观察到，我们认为该环境能够处理所测试的规避技术。

与沙箱不同，调试器默认不生成执行日志。然而，由于我们的测试程序是良性的，我们在本地运行实验，并允许每个程序在规避尝试失败时在磁盘上创建文件。如果执行后文件存在，我们将规避尝试记为失败；否则，我们将其视为成功。我们分两个部分呈现结果：一个用于调试器（6.3节），一个用于沙箱（6.2节）。对于每类分析工具，我们明确评估其应对反虚拟化、反调试和其他杂项技术的准备程度。

为了定量评估测试环境如何处理识别的规避技术，我们估计一个准备度概率。该值表示从测试的沙箱中随机选择一个沙箱，能够应对给定家族中随机技术的可能性。我们通过以下公式定义准备度概率（RP）：

其中， 是该家族中观察到的失败规避总数， 是该家族中实验的总数， 是测试的沙箱或调试器总数。

6 实验结果

在本节中，我们分析针对加壳器、沙箱和调试器获得的实验结果。首先，我们报告加壳器在混淆过程中引入的规避技术。然后，我们评估沙箱和调试器对我们分类中识别的技术的准备程度，评估加壳器采用的技术是否有效。最后，我们展示加壳器采用的规避技术对测试的调试器和沙箱的有效性。即使我们披露了评估的沙箱和调试器的名称，我们也不会将结果与任何特定工具关联。我们的目标是为分析工具应对规避技术的当前准备状态提供一般性概览，而不是排名或挑出特定解决方案。同样，即使我们披露了测试中使用的加壳器的名称，我们也不会将特定规避技术与个别加壳器关联。我们的目标不是根据它们规避沙箱的能力来排名，而是评估加壳器引入的规避技术的整体存在。

6.1 加壳器规避能力评估

在本节中，我们分析加壳器采用的规避技术，回答：

RQ2：现有商业加壳器在生成的混淆二进制文件中添加了哪些规避技术？

表2报告了我们实验中评估的加壳器，以及它们的版本和测试是否使用试用许可证。

表2. 测试的加壳器列表及版本
Packer | Version | Trial | Packer | Version | Trial | Packer | Version | Trial
Alienyze | 1.4 | Y | PCGuard | 6.00.0928 | N | Obsidium | 1.8.1.2 | Y
Alternate | 2.5 | 10 | N | PECompact | 3.03 | N | Mew | 11 | 1.2 | N
ASPack | 2.43 | Y | PELock | 2.11 | Y | Mpress | 2.19 | N
ASProtect | 2.78 | Y | Petite | 2.4 | N | NSPack | 3.7 | N
Bero | 1.00 | N | RLPack | 1.17 | N | Themida | 3.1.3.0 | N
EnigmaProtector | 7.40 | Y | Telock | 0.99 | N | UPX | 4.2.1 | N
EnigmaVM | 10.50 | N | VMProtect | 3.8.5 | Y | YodaProtector | 1.03 | N
Exe32 | 1.42 | N | ExeStealth | 4.21 | N | HXOR | 0.1 | N
Kkrunchy | 0.23 | N | | | | | | |

试用列中的Y表示使用了试用版。

6.1.1 反调试

图4(a)说明了测试的加壳器在混淆期间引入的反调试技术类别的分布。结果表明，大多数加壳器主要依赖与异常处理、系统环境和进程环境相关的技术来检测调试器的存在。表3提供了反调试技术使用的详细统计，报告了每种技术的加壳器数量，以及它对其有效的沙箱和调试器数量。

表3. 加壳器使用的反调试技术摘要
技术名称 | 类别 | 加壳器 | 沙箱 | 调试器
SetUnhandledExceptionFilter | 异常处理 | P1, P3, P6, P9, P11, P12, P13, P14, P15, P16, P17, P19, P20, P22, P23, P24 | 6/7 | 0/4
IsDebuggerPresent | 系统环境 | P1, P4, P5, P7, P8, P10, P18, P21, P23 | 7/7 | 0/4
POPF/D - TRAP FLAG | 异常处理 | P2, P4, P5, P7, P8, P10, P13, P20, P23 | 6/7 | 2/4
NtQueryInformationProcess(0x07) | 进程环境 | P5, P8, P13, P18, P21, P23 | 7/7 | 0/4
NtSetInformationThread(0x11) | 进程环境 | P8, P13, P21, P23 | 0/7 | 0/4
DebugActiveProcess on Parent | 进程环境 | P7, P8, P16 | 7/7 | 4/4
NtQueryInformationProcess(0x1e) | 进程环境 | P13, P21, P23 | 7/7 | 0/4
CheckRemoteDebuggerPresent | 系统环境 | P5, P8, P23 | 7/7 | 0/4
NtQueryInformationProcess(0x1f) | 进程环境 | P8, P21 | 6/7 | 0/4
NtQuerySystemInformation(0x23) | 系统环境 | P13, P21 | 6/7 | 4/4
INT 1 | 陷阱 | P2, P7 | 6/7 | 0/4
ICEBP | 陷阱 | P2 | 6/7 | 0/4
OutputDebugString | 异常处理 | P21 | 7/7 | 0/4
NtClose(INVALID_HANDLE) | 异常处理 | P13 | 7/7 | 2/4
PEB->BeingDebugged | 内存指纹 | P13 | 7/7 | 0/4

对于每种技术，该表报告其类别、实现该技术的加壳器数量，以及分析工具对其的准备程度——表示为成功应对规避的沙箱和调试器数量（例如，3/7表示7个沙箱中有3个中和了该技术）。

图4. 按类型划分的加壳器引入的规避技术类别分布。

6.1.2 反虚拟化

图4(b)说明了测试的加壳器采用的反虚拟化技术的类别分布。结果表明，大多数加壳器试图使用系统环境、文件系统和CPU指纹类别的技术来检测虚拟化环境。此外，一些加壳器有限地使用了反向图灵测试技术。表4总结了加壳器引入的反虚拟化技术以及每个分析工具的准备度比率。聚合数据显示，很少有加壳器使用反虚拟化技术，对于最常用的技术最多只有八个。

表4. 加壳器使用的反虚拟化技术摘要
技术名称 | 类别 | 加壳器 | 沙箱 | 调试器
GetModuleFileNameA | 文件系统 | P1, P5, P8, P10, P13, P20, P21, P23 | 6/7 | 0/4
GetSystemMetrics | 系统环境 | P1, P4, P5, P8, P10, P18, P21, P23 | 5/7 | 4/4
CPUID (EAX=0x00000001) | CPU指纹 | P4, P5, P13, P14, P19, P20, P21, P24 | 4/7 | 4/4
GetDesktopWindowRect | 系统环境 | P4, P5, P8, P10, P21, P23 | 5/7 | 4/4
DeviceIoControl | 系统环境 | P1, P7, P8, P10, P20, P21 | 7/7 | 4/4
GetProcessImageFileNameA | 文件系统 | P4, P5, P10, P21, P23 | 6/7 | 0/4
GetKeyboardLayout | 系统环境 | P4, P5, P8, P10, P21 | 0/7 | 0/4
GetKeyboardLayoutList | 系统环境 | P4, P5, P8, P10, P21 | 0/7 | 0/4
GetForegroundWindow | 人机交互 | P4, P5, P10, P21, P23 | 4/7 | 4/4
GetUserDefaultLangID | 系统环境 | P4, P5, P10, P21 | 0/7 | 0/4
GetLogicalDriveType | 其他 | P8, P20 | 7/7 | 4/4
GetLocaleInfo | 系统环境 | P8, P18 | 0/7 | 0/4
GetProcessAffinityMask | 系统环境 | P13, P18 | 7/7 | 4/4
GetSystemInfo | 系统环境 | P13, P18 | 7/7 | 4/4
GetAdaptersInfo | 系统环境 | P10, P13 | 7/7 | 4/4
GetCursorPos | 人机交互 | P1, P8 | 4/7 | 4/4
OpenSCManager和List Services | | P8 | 6/7 | 4/4
EnumServicesStatus | | | | |
GetSystemFirmwareTable | 系统环境 | P23 | 7/7 | 4/4
GetUserDefaultUILanguage | 系统环境 | P23 | 7/7 | 0/4
EnumDisplayMonitors | 系统环境 | P8 | 7/7 | 4/4
EnumWindows | 系统环境 | P8 | 7/7 | 4/4
GetUsernameA | 系统环境 | P8 | 7/7 | 4/4
PEB->NumProcessors | 系统环境 | P4 | 7/7 | 4/4
GlobalMemoryStatusEx | 系统环境 | P23 | 3/7 | 4/4
GetComputerName | 系统环境 | P8 | 0/7 | 4/4
SetWindowsHookExA | 人机交互 | P8 | 1/7 | 4/4
CPUID (EAX=0x40000000) | CPU指纹 | P13 | 4/7 | 4/4

对于每种技术，该表报告其类别、实现该技术的加壳器数量，以及分析工具对其的准备程度——表示为成功应对规避的沙箱和调试器数量（例如，3/7表示7个沙箱中有3个中和了该技术）。

6.1.3 杂项

图4(c)呈现了加壳器使用的杂项技术的分布，突出测量执行开销作为检测分析环境手段的趋势。具体而言，计时技术最为普遍，占总数的63.3%。表5报告了采用每种技术的加壳器数量，进一步证实加壳器在此类别中主要依赖基于计时的方法。

表5. 加壳器使用的杂项技术摘要
技术名称 | 类别 | 加壳器 | 沙箱 | 调试器
NtQuerySystemTime | 计时 | P4, P11, P13, P14, P15, P16, P19, P21, P22, P23 | 0/7 | 0/4
QueryPerformanceCounter | 计时 | P8, P11, P13, P14, P15, P16, P21, P22, P23 | 0/7 | 4/4
NtQueryPerformanceCounter | 计时 | P1, P4, P5, P17, P18, P21 | 0/7 | 3/4
CanOpenCsrss | 其他 | P5, P8, P10, P18, P21 | 5/7 | 4/4
GetTickCount | 计时 | P8, P10, P13, P16 | 3/7 | 4/4
GetModuleHandle | 进程环境 | P7, P13, P16 | 6/7 | 4/4
FindWindow | 系统环境 | P8, P21, P23 | 7/7 | 3/4
Sleep/SleepEx | 停顿 | P8, P20, P23 | 4/7 | 4/4
KUSER_SHARED->TickCountQuad | 计时 | P4, P8 | 5/7 | 4/4
KUSER_SHARED->SystemTime | 计时 | P4, P8 | 6/7 | 4/4
RDTSC/D | 计时 | P13, P23 | 0/7 | 4/4
IsHooked | 其他 | P7 | 7/7 | 4/4
EnumProcesses和List Process | | P8 | 6/7 | 4/4
GetModuleBaseName | | | | |
NtCreateFile | 文件系统 | P8 | 4/7 | 4/4
NtOpenFile | 文件系统 | P13 | 6/7 | 4/4
NtOpenKey/Ex | 注册表 | P13 | 3/7 | 0/4
NtDelayExecution | 停顿 | P13 | 4/7 | 4/4
SetTimer | 停顿 | P8 | 2/7 | 4/4
waitForSingleObject/Ex | 停顿 | P19 | 2/7 | 4/4
KUSER_SHARED->InterruptTime | 计时 | P4 | 6/7 | 4/4
timeGetTime | 计时 | P23 | 3/7 | 4/4
GetLocalTime | 计时 | P8 | 0/7 | 1/4

对于每种技术，该表报告其类别、实现该技术的加壳器数量，以及分析工具对其的准备程度——表示为成功应对规避的沙箱和调试器数量（例如，3/7表示7个沙箱中有3个中和了该技术）。

分析显示，最常见的引入规避技术来自异常处理、系统环境和进程环境类别。这些主要用于反调试和反虚拟化目的。具体而言，诸如SetUnhandledExceptionFilter、IsDebuggerPresent和NtQueryInformationProcess等技术是最常采用的反调试方法。在反虚拟化方面，常用的技术包括GetModuleFileNameA、GetSystemMetrics和CPUID。此外，计时类别在杂项规避中最为普遍，诸如NtQuerySystemTime、QueryPerformanceCounter和NtQueryPerformanceCounter等技术被广泛实现以检测模拟或减速的环境。

6.2 沙箱对规避技术处理能力的评估

我们针对沙箱进行的实验结果使我们能够回答：

RQ3：公开可用的分析环境（即沙箱和调试器）对规避技术的覆盖范围是什么？
RQ4：加壳器添加的技术对测试的分析环境的有效性如何？

我们在7个公开可用的沙箱中进行了实验，这些沙箱是作为最著名的沙箱[79]的子集选择的。具体而言，这些沙箱按无特定顺序为：Triage [70]、Intezer [28]、Hybrid Analysis、Pikker [51]、C2AE [10]（通过VirusTotal）、Qianxin [53]、Any.run [4]。表1包含实验的完整结果，显示每对技术和沙箱，如果t在s上规避了执行。由于所有测试的沙箱都支持64位可执行文件，我们使用64位二进制文件进行测试，因为大多数Windows API在32位兼容模式下不可用。

6.2.1 反调试

图5(a)和表6中显示的结果突显了在线沙箱对反调试技术的高准备度，平均73%的此类技术被测试沙箱成功应对。我们在表6中报告了规避率最高的技术。NtSetInformationThread(0x11)是最突出的规避技术，成功规避了所有测试的沙箱。然而，即使这种技术也代表了一种异常值而非一致趋势，因为沙箱可以规避大多数技术的规避尝试。

表6. 最具规避性的反调试技术
实验名称 | 类别 | 计数
NtSetInformationThread(0x11) | 进程环境 | 7
NtYieldExecution | 其他 | 5
NtSetContextThread(CONTEXT_DEBUG_REGISTERS) | 进程环境 | 3
POPF/D - TRAP FLAG | 异常处理 | 2
INT 1 | 陷阱 | 2
NtCreateThreadEx(HIDE_FROM_DEBUGGER) | 进程环境 | 2
CTRL Exception Handling | 异常处理 | 2
GetProcessIdFromName | 列表进程 | 2
DebugBreak | 异常处理 | 1
SetUnhandledExceptionFilter | 异常处理 | 1

该表列出了最常绕过测试沙箱检测的反调试技术。对于每种技术，该表显示了其类别以及它成功规避的沙箱数量。图5展示了受测沙箱针对我们分类法中规避技术的应对准备程度。每条柱形表示沙箱成功应对的技术百分比，相对于适用的技术总数。表7详细概述了沙箱针对各类反调试技术的应对准备程度。“列出进程”类别中的技术表现出最低的准备概率（71.43%），表明沙箱处理与进程枚举相关查询时存在明显弱点。类似地，“进程环境”类别中的技术显示出中等准备程度（76.79%），凸显了在完全隐藏进程内部结构中调试器工件方面的持续困难。相反，沙箱对“系统环境”和“内存指纹识别”类别表现出强大的抵抗力，其准备概率分别高达97.14%和94.29%。值得注意的是，针对“异常处理”（88.10%）和“陷阱”（85.71%）类别观察到的高准备概率表明，大多数沙箱能透明地处理信号和异常，通常会直接将其传递给被分析的程序而不加干扰。这些结果与表3中呈现的结果一起表明，沙箱对加壳程序所采用的反调试技术具有高水平的抵抗力：大多数技术未能成功规避检测。唯一能够规避所有受测沙箱的技术是NtSetInformationThread(0x11)，而在25个被评估的加壳程序中，只有4个实施了该技术。平均而言，每种反调试技术几乎被所有沙箱有效中和，每种技术仅影响0.57个沙箱——这凸显了这些分析环境的强大防御能力。表7.类别成功失败技术RP系统环境6821097.14%内存指纹识别332594.29%异常处理375688.10%陷阱244585.71%其他427785.71%进程环境4313876.79%列出进程52171.43%沙箱针对反调试技术的准备概率，按类别分组“成功”列表示成功应对的规避尝试总数，“失败”列表示未成功应对的规避尝试总数，而“技术”列表示该类别中评估的技术总数。RP列显示由此得出的准备概率。6.2.2 反虚拟化。图5(b)显示了每个受测沙箱成功应对的反虚拟化技术百分比。平均而言，沙箱表现出86%的准备程度，表明其在隐藏会暴露虚拟化环境存在的工件方面能力强大。表8呈现了沙箱针对反虚拟化技术的准备概率，按家族分组。虽然整体准备程度相对较高，但我们的实验揭示了其在绕过“反向图灵测试”和隐藏虚拟化CPU信息方面的能力不足。针对“反向图灵测试”的低准备程度揭示了沙箱无法模拟人类活动，例如鼠标滚动、鼠标点击或键盘输入。如表1所示，仅通过等待鼠标或键盘输入即可检测到沙箱。此外，一些沙箱在隐藏低级虚拟化工件方面表现不佳。例如，SMSW技术（检查是否存在真实CPU）成功规避了所有受测沙箱。基于CPUID的技术也被证明有效：当使用EAX = 0x1（例如，核心数）查询时，三个沙箱暴露了虚拟化细节，当使用EAX = 0x40000000（例如，hypervisor信息）查询时，另有三个沙箱暴露了信息。弱点超出了CPU指纹识别，延伸至更广泛的硬件环境。基于WMI的技术（查询系统属性如序列号和设备ID）通常返回指示虚拟化硬件的值——这凸显了几个沙箱在隐藏基于硬件的虚拟化工件方面的低准备程度。虽然“系统环境”家族的技术通常获得较高的准备程度，但所有基于区域设置的检查都成功绕过了检测。这表明许多沙箱配置了不常见的系统区域设置，这可以作为分析环境的可靠指标。表4呈现了沙箱针对加壳程序引入的反虚拟化技术的准备率。总体而言，结果表明准备程度较高，因为最常用的技术平均被五个沙箱成功处理。表8.类别成功失败技术RP表描述2103100.00%列出服务262492.86%仿真软件262492.86%其他375688.10%陷阱61185.71%文件系统173385.00%WMI186523478.15%驱动信息52171.43%系统环境139713066.19%CPU指纹识别2015560.00%人类交互1930738.78%调试器针对反虚拟化技术的准备概率，按类别分组“成功”列表示成功应对的规避尝试总数，“失败”列表示未成功应对的规避尝试总数，而“技术”列表示该类别中评估的技术总数。RP列显示由此得出的准备概率。6.2.3 杂项。图5(c)显示了每个受测沙箱处理的杂项技术百分比。平均而言，每个沙箱处理了这些技术的42%，表明沙箱更容易受到识别通用执行环境的技术的影响，而不是特定的反虚拟化或反调试工件。表9呈现了沙箱针对各类杂项规避技术的准备概率。结果显示，针对“计时”和“停滞”技术的准备程度特别低，这些技术始终成功规避。这凸显了沙箱在隐藏虚拟化开销或分析钩子所引入的延迟方面存在关键弱点，使其容易通过基于计时的启发式方法被识别。“注册表”家族也显示出准备程度有限的领域。该类别中的许多技术成功检索到与分析工件相关的注册表键，表明受测沙箱未采取适当步骤隐藏或清理注册表信息。类似地，表5证实了沙箱对加壳程序实施的杂项技术的低准备程度。最常用的技术属于“计时”类别，所有技术都能够在所有受测环境中规避检测，强调了基于计时的方针对现代沙箱防御构成持续挑战。表9.类别成功规避技术RP进程环境701100.00%系统环境701100.00%列出进程131292.86%其他427785.71%注册表199467.86%文件系统2515662.50%停滞32591335.16%计时41851832.54%调试器针对杂项技术的准备概率，按类别分组“成功”列表示成功应对的规避尝试总数，“失败”列表示未成功应对的规避尝试总数，而“技术”列表示该类别中评估的技术总数。RP列显示由此得出的准备概率。6.2.4 加壳程序规避技术的组合。表10报告了针对受测沙箱测试来自被分析加壳程序的技术组合的结果。沙箱S2和S4被排除在本次评估之外，因为该评估是在我们无法再访问这些特定环境的时期进行的。表10. PC1PC2PC3PC4PC5PC6PC7PC8PC9PC10PC11PC12PC13PC14PC15PC16PC17PC18PC19PC20PC21PC22PC23PC24PC25S1S3S5S6S7沙箱针对商业加壳程序所用技术组合的准备程度概览每列代表特定加壳程序所采用的技术组合，而行对应于一个沙箱。表示该加壳程序的技术组合成功规避了分析，而表示它们未能规避。结果显示，沙箱尚未准备好处理商业加壳程序所采用的技术组合。最具抵抗力的沙箱能抵挡不到一半的受测加壳程序（44%），而抵抗力最弱的沙箱仅能抵挡4%的加壳程序技术。对RQ3和RQ4的解答：沙箱在反调试方面表现出强大的抵抗力，平均有72%的技术被成功应对，有效地中和了绝大多数技术。尽管在处理进程枚举和内部环境查询方面仍存在一些弱点，但这些技术很少被加壳程序采用，从而加强了沙箱在此类别中的防御稳健性。类似地，它们在应对反虚拟化技术方面通常有效，平均准备程度为85%。然而，它们仍然容易受到“反向图灵测试”、CPU指纹识别和基于区域设置的检查的影响，凸显了在模拟用户行为和隐藏低级虚拟化工件方面的持续局限性。相比之下，当规避技术像商业加壳程序那样组合实施时，沙箱准备程度大幅下降。我们的结果显示，没有一个沙箱能对超过44%的受测加壳程序保持抵抗力，而抵抗力最弱的仅能抵挡其中4%。这凸显了单独技术处理与真实世界规避场景之间的显著差距，表明当前的沙箱防御对于实践中采用的复合规避策略仍然不足。最后，沙箱对杂项规避技术表现出低准备程度，平均处理42%的技术，尤其是那些基于计时和停滞的技术。由于沙箱环境的固有开销，这些类别仍然是持续挑战，并且经常被加壳程序利用以规避检测。6.3 调试器处理规避技术的评估与沙箱一样，对调试器进行的实验分析使我们能够回答：RQ3：公开可用的分析环境（即沙箱和调试器）在处理规避技术方面的覆盖率如何？RQ4：加壳程序添加的技术对受测分析环境的有效性如何？我们测试了Windows平台上可用的四个最著名的调试器，即WinDbg、x64dbg、OllyDbg、Immunity Debugger。其中两个，调试器3和4，支持64位可执行文件，而另外两个，调试器1和2，仅支持32位可执行文件，并且不提供支持64位可执行文件的版本。这种架构区别导致了结果的固有差异，因为一些技术依赖于仅在特定架构上可用的系统API。例如，Wudf API家族是在64位Windows内核中引入的，因此只能从64位可执行文件中调用。除了这些情况外，本工作中考虑的大多数规避技术都依赖于操作系统级接口和分析环境工件，这些在很大程度上与架构无关，因为它们主要使用标准Windows API和进程环境属性。因此，我们期望定性结论能够跨位宽推广，同时承认某些技术固有地限制在特定执行模式下。在报告表1中的结果时，我们将不可用的技术归类为成功的规避尝试，因为相应的规避检查无法执行，并且根据我们合成数据集的构建，恶意软件没有表现出任何恶意行为。所有测试都在一个全新安装的Windows 10操作系统上进行，并禁用了基于虚拟化的安全性，以防止在执行旨在检测VM存在的技术时出现误报。6.3.1 反调试。图6(a)显示了受测调试器针对反调试技术的准备程度，揭示了每个调试器平均准备应对25%的技术，显示出在透明执行被调试程序而不隐藏任何调试工件方面的高倾向。图6.受测调试器针对我们分类法中规避技术的准备程度。每条柱形表示调试器成功应对的技术百分比，相对于适用的技术总数。表11呈现了调试器针对反调试技术的准备概率，按类别分组。结果显示，“异常处理”和“陷阱”家族的准备程度特别低，分别为9.09%和11.11%。这表明大多数调试器在其默认配置下倾向于拦截异常和特权指令，而不是允许它们透明通过——这使它们容易被检测。表11.类别成功失败技术RP系统环境18161052.94%其他820728.57%进程环境824825.00%内存指纹识别416520.00%陷阱216511.11%异常处理22069.09%列出进程0410.00%调试器针对反调试技术的准备概率，按类别分组“成功”列表示成功应对的规避尝试总数，“失败”列表示未成功应对的规避尝试总数，而“技术”列表示该类别中评估的技术总数。RP列显示由此得出的准备概率。类似地，“内存指纹识别”类别的准备概率仅为20.00%，表明大多数调试器不能有效隐藏诸如PEB或KUSER_SHARED_DATA结构中的调试工件。来自“进程环境”家族的技术（通常涉及查询操作系统以获取特定于进程的调试指标）也经常成功，调试器的准备程度仅为25.00%。相比之下，“系统环境”类别在所有类别中显示出最高的准备程度，为52.94%，表明在隐藏系统范围分析指标方面做出了适度努力。然而，总体而言，数据强调调试器仍然容易受到广泛反调试策略的攻击。表3显示了我们所测试加壳程序实施的反调试技术的规避率。与沙箱相比，这些技术对调试器表现出很高的有效性。大多数被评估的反调试方法成功针对所有受测调试器，只有少数例外。这强调了这些技术有效性的显著差异：虽然它们无法持续绕过沙箱环境，但它们在检测和挫败调试器方面非常成功。6.3.2 反虚拟化。图5(b)显示了受测调试器成功处理的反虚拟化技术百分比。结果表明，调试器能够有效处理其中80%的技术。表12呈现了调试器针对反虚拟化技术的准备概率，按类别分组。总体而言，结果表明调试器通常准备好应对大多数类别的规避技术。然而，在文件系统、系统环境和陷阱类别的就绪度较低。表12。

| 类别 | 成功 | 失败 | 技术数量 | 就绪概率（RP） |
|------|------|------|----------|----------------|
| 驱动信息 | 40 | 1 | 100.00% | |
| 仿真软件 | 16 | 0 | 4100.00% | |
| 人工交互 | 28 | 0 | 7100.00% | |
| 表描述 | 12 | 0 | 3100.00% | |
| 服务列表 | 16 | 0 | 4100.00% | |
| WMI | 126 | 10 | 3492.65% | |
| CPU指纹识别 | 18 | 2 | 590.00% | |
| 其他 | 20 | 4 | 683.33% | |
| 系统环境 | 92 | 28 | 3076.67% | |
| 文件系统 | 0 | 12 | 30.00% | |
| 陷阱 | 0 | 4 | 10.00% | |

调试器对抗反虚拟化技术的就绪概率，按类别分组。成功列表示成功规避的尝试总数，失败列表示未能成功规避的尝试总数，而技术数量表示在该类别中评估的技术总数。RP列显示最终的就绪概率。

文件系统类别中的若干技术，通过检查可执行路径成功规避——因为路径中包含“sandbox”子字符串——或通过查询最近的文件列表，其中包含与调试器自身相关的条目。类似地，在系统环境类别中，基于区域设置的检查能够持续绕过检测，因为实验环境被配置为意大利系统区域设置，这在现实世界目标中并不常见。

至于陷阱类别，就绪度降低源于使用VPCEXT指令，该指令旨在检测虚拟机。在这种情况下，调试器的行为——即拦截该指令——无意中触发了规避逻辑，导致误报。

最后，这表明调试器已准备好应对由加壳器引入的技术，如表4所述。少数仍然对调试器有效的技术主要基于区域设置检查以及针对沙箱相关字符串识别的路径分析。

6.3.3 杂项。

图6(c)显示了每个受测调试器处理的杂项技术百分比，表明这些技术中有84.6%被中和。换句话说，只有15.4%的评估策略能够规避检测。

表13展示了调试器针对各类杂项规避技术的就绪概率。注册表类别显示最低就绪度（75.00%），主要原因是有一项技术成功查询了与分析环境相关的注册表键。相比之下，计时和停滞技术表现出高就绪度，成功率分别为88.89%和98.08%。这与沙箱的行为形成对比，沙箱通常会引入更多执行开销，因此更容易通过基于计时的检查被检测。调试器在这些类别中的高就绪度反映了它们对程序执行计时的极小影响，从而降低了通过性能启发式方法进行检测的可能性。

表13。

| 类别 | 成功 | 失败 | 技术数量 | 就绪概率（RP） |
|------|------|------|----------|----------------|
| 进程列表 | 80 | 2 | 100.00% | |
| 进程环境 | 40 | 1 | 100.00% | |
| 停滞 | 511 | 1 | 1398.08% | |
| 计时 | 601 | 21 | 21888.89% | |
| 文件系统 | 20 | 4 | 683.33% | |
| 系统环境 | 31 | 1 | 75.00% | |
| 注册表 | 12 | 4 | 475.00% | |
| 其他 | 18 | 10 | 764.29% | |

调试器对抗杂项技术的就绪概率，按类别分组。成功列表示成功规避的尝试总数，失败列表示未能成功规避的尝试总数，技术数量表示在该类别中评估的技术总数。RP列显示最终的就绪概率。

表5进一步支持这一观察，表明调试器通常准备充分以应对加壳器实施的杂项规避技术。尽管NtQuerySystemTime在所有受测调试器中都规避了检测，但它在加壳器中的使用很少见。总体而言，结果表明大多数加壳器不依赖计时或停滞技术来规避调试器——很可能是因为调试器引入的运行时伪影极少，使得此类检查效果较差。

6.3.4 加壳器规避技术的组合。

表14报告了来自分析的加壳器的技术组合对受测调试器的测试结果。调试器表现出较高的规避率，每个调试器都被96%的受测加壳器规避。这表明，无论使用哪种特定工具，基于调试器的分析对加壳样本的抵御能力有限。这一结果与表3中报告的发现一致。加壳器高度依赖反调试技术，使其能够在实际恶意载荷执行前轻松识别调试环境。

表14。

| PC1 | PC2 | PC3 | PC4 | PC5 | PC6 | PC7 | PC8 | PC9 | PC10 | PC11 | PC12 | PC13 | PC14 | PC15 | PC16 | PC17 | PC18 | PC19 | PC20 | PC21 | PC22 | PC23 | PC24 | PC25 |
|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|------|------|------|------|------|------|------|------|------|------|------|------|------|------|------|
| D1 | | | | | | | | | | | | | | | | | | | | | | | | |
| D2 | | | | | | | | | | | | | | | | | | | | | | | | |
| D3 | | | | | | | | | | | | | | | | | | | | | | | | |
| D4 | | | | | | | | | | | | | | | | | | | | | | | | |

沙箱对抗商业加壳器所采用技术组合的就绪度概述。每列代表特定加壳器采用的技术组合，而行对应调试器。表示特定加壳器采用的技术组合成功规避了分析，而表示它们未成功。

对RQ3和RQ4的答案：调试器未能做好准备以应对反调试规避技术，平均仅有29%的技术被成功应对。此外，这些技术非常有效且被加壳器广泛使用，突显了调试器对加壳恶意软件的显著脆弱性。当考虑商业加壳器实施的规避技术组合时，调试器的韧性进一步恶化。我们的结果表明，每个受测调试器都被96%的加壳器规避，表明基于调试器的分析对真实世界加壳样本提供的保护非常有限，无论使用哪种特定工具。单独来看，调试器在应对反虚拟化技术方面通常有效，大多数类别显示高就绪度。被成功应对技术的平均百分比为80%。然而，基于区域设置检查、文件系统检查和虚拟机陷阱指令的规避方法仍然有效且被加壳器用于绕过分析。最后，调试器对应对杂项规避技术准备充分，特别是涉及计时和停滞的技术。被成功应对技术的百分比为84.6%。少数仍然有效的技术，如特定的注册表和系统环境检查，很少被加壳器使用，进一步增强了调试器在该类别中的稳健性。

7 相关工作

理解规避型恶意软件行为长期以来一直是安全研究界的核心目标。早期努力主要集中在系统化这些行为或通过静态分析检测它们。Afianian等人[2]以及Bulazel和Yener[9]提供了规避技术的综合分类，强调恶意软件如何通过虚拟机指纹识别、计时差异或调试器存在来检测分析环境。然而，他们的研究是定性的，未评估这些技术在现实世界中的普遍性或有效性。

作为这些努力的补充，Barbosa和Branco[6]以及Chen等人[12]采用大规模静态分析来识别恶意软件样本中的反调试和反虚拟化技术。然而，这些静态方法固有局限性，因为它们无法保证识别的代码路径会被执行，且容易受到混淆和加壳技术的影响。

Galloro等人[24]通过对2010年至2019年间45,375个恶意软件和949个良品样本的Windows恶意软件进行全面的纵向研究，解决了这些局限性。他们的动态分析揭示了恶意软件家族与其首选规避策略之间的强相关性，提供了关于规避型恶意软件的首个大规模行为视角。

在类似方向上，D'Elia等人[20]对反分析行为进行了系统分析，并表明手动分析人员经常面临此前被认为仅影响自动化系统的规避技术。他们的评估表明，即使样本被手动解剖，许多规避方法仍然有效。Polino等人[52]测量了7,006个恶意软件样本中抗检测技术的普遍性，显示超过15%的样本主动尝试检测运行时分析。他们的结果突显了规避逻辑即使在商业加壳器和混淆样本中也广泛采用。

Miramirkhani等人[45]引入了一类新颖的基于磨损痕迹分析的沙箱规避技术，这些痕迹捕获长期用户和系统活动的间接证据（例如，估计Windows安装的年龄和使用历史）。通过提取此类痕迹的多样集合并训练决策树分类器，他们表明恶意软件能够以92.86%的准确率区分真实用户系统与分析环境。

Nappa等人[48]引入了一种基于执行工作量证明（PoW）算法的新型沙箱规避技术。通过利用PoW计算的稳定且硬件依赖的执行时间，恶意软件可以检测虚拟化分析环境并抑制其恶意行为。他们的评估表明，嵌入PoW显著降低了真实恶意软件的检测率，同时难以被标记为恶意，因为识别PoW计算会对合法使用此类算法的良性应用程序引入大量误报。

在Android上，Ruggia等人[60]进行了类似的系统化研究，并引入了DroidDungeon，一种旨在绕过规避策略的沙箱。他们的工作表明，14%的Android恶意软件在分析伪影存在时终止执行，且规避型恶意软件倾向于更频繁地与高风险API（如调用CLI命令的API）交互。

除了系统化研究，近期研究还探索了针对规避型恶意软件的检测策略。Yin等人[77]提出了一种基于API调用轨迹导出的层次行为模型的分类方法，通过序列感知向量化展示了对规避的增强鲁棒性。Xu等人[75]引入了Antitoxin，一种污点引导的多路径探索框架，能够比传统线性分析更有效地发现逻辑炸弹和未知规避行为。

与这些努力相比，我们的工作提供了双重贡献：首先，我们评估了商业和公开可用的加壳器如何将规避技术引入受保护的二进制文件；其次，我们测试了真实世界沙箱和调试器应对这些技术的就绪度。通过将加壳器注入的规避策略与分析工具的能力相关联，我们提供了首个弥合规避混淆与分析工具有效性之间差距的实证研究。表15提供了相关工作摘要。

表15。

| 工作 | 年份 | 分类学 | # 规避技术 | 调试器 | 沙箱 | 加壳器 | 动态分析 | 良品比较 | 真实世界评估 |
|------|------|--------|-----------|--------|------|--------|----------|----------|--------------|
| Barbosa和Branco [6] | 2014 | ? | 16 | ? | ? | ? | ? | ? | ? |
| Chen等人 [12] | 2016 | ? | 6 | ? | ? | ? | ? | ? | ? |
| Polino等人 [52] | 2017 | ? | - | ? | ? | ? | ? | ? | ? |
| Bulazel和Yener [9] | 2017 | ? | 41 | ? | ? | ? | ? | ? | ? |
| Miramirkhani等人 [45] | 2017 | ? | 44 | ? | ? | ? | ? | ? | ? |
| Afianian等人 [2] | 2019 | ? | 41 | ? | ? | ? | ? | ? | ? |
| D'Elia等人 [20] | 2020 | ? | - | ? | ? | ? | ? | ? | ? |
| Nappa等人 [48] | 2021 | ? | - | ? | ? | ? | ? | ? | ? |
| Galloro等人 [24] | 2022 | ? | 92 | ? | ? | ? | ? | ? | ? |
| Yin等人 [77] | 2023 | ? | - | ? | ? | ? | ? | ? | ? |
| Xu等人 [75] | 2023 | ? | - | ? | ? | ? | ? | ? | ? |
| Ruggia等人 [60] | 2024 | ? | 97 | ? | ? | ? | ? | ? | ? |
| 本工作 | 2025 | ? | 191 | ? | ? | ? | ? | ? | ? |

大规模规避型恶意软件研究比较。分类学列指示研究是否提出了规避方法的分类。规避技术数量列报告了分析的独特规避技术数量。调试器和沙箱列分别指示研究是否评估了调试器和沙箱的韧性。加壳器列显示研究是否分析了由加壳器引入的规避行为。动态分析、良品和真实世界评估列指示研究是否进行了动态测试、包含良品比较或测试了真实工具。符号：? = 提供，? = 未提供；= 详细处理，= 部分处理。

8 结论

在这项工作中，我们对分析环境（具体是沙箱和调试器）对抗规避技术的就绪度进行了实验评估。首先，我们基于Galloro等人[24]提出的分类提出了更新的规避技术分类，包含55种新发现且先前未记录的技术。随后，为评估环境对这些技术的就绪度，我们研究了25种公开可用加壳器所采用的规避技术，并测试了7种公开可用沙箱和4种调试器的就绪度。我们对25种加壳器的分析显示，规避技术在二进制混淆过程中被广泛使用。反调试方法最为普遍，其次是反虚拟化和杂项技术。在反调试方法中，异常处理和进程环境查询最常用。反虚拟化技术集中于CPU指纹识别、系统环境和文件系统检查。在杂项类别中，基于计时的技术占主导，表明许多加壳器试图检测仿真或插桩引入的分析开销。然而，一些高级规避技术——如人工交互或基于区域设置的检查——仅由少数加壳器实施。我们对七种公开可用沙箱的评估显示，对抗反调试（72%）和反虚拟化（85%）技术的高就绪度。特别是加壳器常用的技术——如IsDebuggerPresent和NtQueryInformationProcess——被大多数沙箱有效中和。这表明沙箱对应对现成加壳器所采用的规避策略准备充分。然而，就绪度在杂项类别（42%）中显著下降，尤其是基于计时和停滞的技术。与沙箱相比，四个受测调试器对反调试技术的抵御能力有限，仅29%的技术被应对。这与加壳器结果紧密一致：许多加壳器采用直接反调试方法，所有这些方法对调试器都非常有效。然而，调试器对反虚拟化（80%）和杂项（84.6%）技术表现出强大的韧性，包括加壳器最常用的技术。这可能是由于其原生执行模型，最小化了行为和计时伪影。总体而言，虽然加壳器通过标准反调试策略成功击败调试器，但它们在虚拟化和基于计时的规避方面对调试器的有效性有限。我们的评估虽然广泛，但存在几个局限性。许多商业加壳器仅有试用版本，可能缺乏高级功能如延迟执行或虚拟化感知检查。另一个局限性源于我们决定单独测试每种规避技术。虽然这有助于清晰归因观察到的效果，但并未反映恶意软件通常结合多种规避策略的真实场景。最后，我们的分析基于一个最小的“Hello World”二进制文件，尽管其可复现性，但无法完全捕捉真实恶意软件行为的复杂性和丰富性。

我们的实证发现表明，虽然分析环境对常见伪影有效，但它们缺乏一种全面的方法来隐藏架构特征。根据观察到的漏洞，我们提出以下设计变更：——语义一致性优于伪影移除：沙箱往往无法模拟真实的用户活动，这使得它们因缺乏典型的系统伪影而被检测到。因此，防御性设计应超越最小化或新安装的操作系统，并纳入真实的用户交互，如鼠标移动和键盘输入，以更好地模拟真实用户环境。——透明的信号处理：调试器对基于异常的规避（9.09%）和陷阱（11.11%）的响应能力较低，表明这些工具常常干扰程序的预期控制流。因此，防御性设计应确保异常和特权指令被透明地转发给被分析的程序，从而防止通过信号拦截进行检测。——时序抖动和侧信道归一化：基于时序的技术是最常见的杂项规避手段（63.3%），壳程序利用它们来检测虚拟化引入的开销。分析环境应对虚拟机监控器敏感指令（如CPUID）实施时序归一化，以减少由VM退出转换引起的延迟差异。——进程外内省：许多规避性检查针对用户空间结构，如进程环境块（PEB）或KUSER_SHARED_DATA，以检测调试伪影。为缓解这一问题，防御工具可依赖内核模式内省或动态重编译技术，这些技术在独立的内存区域执行重写后的代码，从而减少暴露于内存指纹识别和完整性检查的风险。这项工作为未来研究开辟了多条途径。一个关键方向是分析同一二进制文件中组合多种规避技术的效果，以更好地反映现代恶意软件的复杂性。将我们的分析范围扩展至仅限64位的规避以及非Windows平台（如Linux和Android），也将为分析环境的准备程度提供更全面的评估。此外，对商业壳程序演变的纵向研究可能揭示规避技术的新兴趋势。另一个有前景的领域是设计改进的反规避机制，重点在于混淆时序伪影、模拟用户活动以及隐藏分析相关的系统特征。最后，开发标准化的规避技术基准测试框架将促进研究和工业背景下分析工具的持续评估与比较。