花式反沙箱

编者注：本文仅供学习研究，严禁从事非法活动，任何后果由使用者本人负责。

前言

目前沙箱正成为判断恶意威胁的一种最快速和最简单的方式，因此反沙箱检测在实战中发挥越来越重要的作用，无论是从反溯源还是延长加载器寿命的角度，反沙箱都是红蓝对抗中不可或缺的一环。

我会着重讲解我觉得有趣的手法，当然有趣不等于实用，如果你分析过APT组织的样本，会发现那些原理简单且有效的方法会被更多的使用（比如主机名/用户名/进程黑名单，环境检测，用户交互检测等），这些方法往往都是复合使用的，因为很难有一种方法可以适用所有场景。出于学习的目的我们应该都了解一下。

我将反沙箱的手法笼统的分为了几类：时间规避类、环境检测类、硬件检测类、信息搜集类、用户交互类、其它类。篇幅原因，在这一篇主要介绍前两类。

许多资料由于时间太久，忘记从哪里学到（白嫖）的了，参考文献如有遗漏请各位师傅提醒，文章中有哪里不对也欢迎大佬指正。

一、时间规避类

本来我想将这类命名为延迟执行类，但是有些手法不属于延时执行但也与时间检测有关，实在不好划分，所以我将其整合为一个类别，都是基于时间的规避技术。

1）最基础的反沙箱——延时执行

出于性能的考虑，沙箱不可能一直等待一个进程执行，所以有一些聪明的攻击者想到如果在执行恶意代码之前先停一段时间，只要停的时间够长，是不是就绕过了沙箱的检测呢？事实证明在沙箱环境开始识别并防御这种攻击之前，这是可行的。攻击者利用已知的一些Windows API（比如我们都知道的sleep）来延迟执行恶意代码。

其它类似的API还有WaitForSingleObject，WaitForSingleObjectEx，NtWaitForSingleObject，SetTimer， SetWaitableTimer，CreateTimerQueueTimer等等。

这里举一个比较有趣的例子，就是利用Windows socket的select函数延时。

select的作用就是确定套接口的状态，对于每一个socket，调用者可以查询它的可读性、可写性及错误状态信息。结构如下：

我们可以看到它一共有五个参数，唯一一个与时间有关的就是最后一个参数，timeout他是一个指向timeval的指针，表示等待的最长时间。

timeval是一个结构体，用于指定时间间隔。

我们只需要建立一个socket连接，然后调用这个api去查询socket状态就可以了，这个调用消耗的时间就是我们上面提到的timeval里设置的时间。主要代码如下（前面建立socket的代码省略了）：

    fd_set Write, Err;
    FD_ZERO(&Write);
    FD_ZERO(&Err);
    FD_SET(sock, &Write);
    FD_SET(sock, &Err);
    timeval tv = { 0 };
    tv.tv_usec = timeout * 1000;

    // check if the socket is ready, this call should take Timeout milliseconds
    select(0, NULL, &Write, &Err, &tv);

可惜这种方式在风靡一段时间后，很快被沙箱加速针对性的和谐掉了。

2）getTickCount

虽然沙箱厂商通过加速代码执行的方式解决了延时执行带来的影响，但是反沙箱的本质不就是区分沙箱和实体机的区别吗？沙箱加速恰恰成为了新的特征。攻击者开始通过多种方法来识别环境中的加速执行机制。有多款恶意软件家族（包括Win32/Kovter）会在代码中使用GetTickCount这个Windows API来判断代码运行时间是否匹配预期时间，我们也在一些恶意软件家族中看到该方法的一些改进版。GetTickCount返回（retrieve）从操作系统启动所经过（elapsed）的毫秒数：

这种方式很聪明的利用了加速执行带来的差异识别出来沙箱环境，但同样很容易被绕过，只需要Hook这些计算时间间隔的api就可以很好的解决这个问题。也有一些文章建议创建超过20分钟的快照，让主机运行更长时间。但我觉得这种解决方案的开销太大了。

所谓智者千虑，必有一失。一个沙箱Hook了GetTickCount，但是还有GetLocalTime，Hook了GetLocalTime，还会有GetSystemTime。或许想绕过所有沙箱可能很有难度，但是针对一个特定的沙箱想找到一个未被Hook的计时方法还是很简单的。

我当初学到这里也有一些疑问：

1.假如找到的方法只针对特定的沙箱，如何才能同时绕过多个沙箱呢？——写一个使用多个API的并行时间检测。

2.如果真的找不到合适的计算时间间隔的API呢？——从外部服务获取时间，比如NTP。

3.如果从外部源获取时间的API也被HOOK了呢？——可以自己搭建一个服务专门仅用于返回时间。

攻防就像千层饼一样，你觉得不行的方法，深入一层没准又可以了。

3）API Flooding

单纯的拖延时间似乎太明显了，沙箱可以很轻松的识别检测出你调用了哪些API用来延时。如果能将延时和正常业务结合在一起，那检测难度无疑会变得更高。API Flooding（API泛洪）就是通过循环调用无用API来延迟恶意代码的执行。使用该方法的恶意软件代码片段如下：

GetSystemTimeAdjustment的作用是确定系统是否对其时钟应用定期时间调整，并获取任何此类调整的值和周期。通过循环调用这个API达到延时的效果。

如果想知道这个方法更有效的实战，可以看下本文参考文献里的al-khaser项目。

4）内联代码

由于沙箱不能有效的处理某些API Flooding的逻辑，所以这种方法很可能会造成Dos效果。而且正如上文所说，沙箱是可以检测程序调用的API的，因此处理这种基于API的延时也不是什么难事。所以攻击者们引入另一种方式：内联汇编。

原理很简单，在循环1里执行一些无效操作，比如上述代码里的mov edx,edx，循环了指定次数后再跳入循环2继续执行。至于要执行多少循环取决于你想让这段代码延时多久。

幸运的是截止我上次测试（大约五个月前），这种方法仍能绕过许多高级沙箱。不幸的是，许多杀软很干脆的把这段延时汇编直接识别为恶意代码。

5）CPUID

上述的几种方法都是基于延时执行或者由其引出的一些特性来进行沙箱检测的。由于虚拟化自身的特性，也会造成某些指令的执行在虚拟环境和真实环境中有时间差异。

得益于Hypervisor的普及，许多作弊软件制作者利用虚拟化技术逃避了反作弊引擎的检测。与此对应，反作弊引擎的厂商也没有坐以待毙，研究出了一系列检测虚拟化的方法。接下来要介绍的就是来自BattlEye的反沙箱方法。

原理：

首先我们要知道CPUID是什么，它为什么能够作为检测沙箱的指标：CPUID 在真实硬件上是一条相对快捷的指令，通常只需要 200 个周期，而在虚拟化环境中，由于内省引擎产生的开销，它可能需要十倍甚至更多的时间。

    unsigned __int64 old_priority = SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL); 
    unsigned __int64 rdtsc_first = __rdtsc();
    Sleep(2000);
    unsigned __int64 rdtsc_time_delta = __rdtsc() - rdtsc_first;
    DWORD64 result_time = 0;
    int cpuid_data[4] = { 0 };
    for (std::size_t count = 0; count < 0x6694; count++)
    {
        auto rdtsc_iter_time = __rdtsc();

        __cpuid((int*)cpuid_data, 0);

        result_time += __rdtsc() - rdtsc_iter_time;
    }
    unsigned __int64 _time = 10000000 * result_time / rdtsc_time_delta / 0x65;
    if (_time > 400 || _time < 10)
        exit(0);

    SetThreadPriority(GetCurrentThread(), old_priority);

上面这段代码就是这种方法的关键部分，通过计时器计算cpuid执行的平均CPU周期，假如与真实环境的CPU周期差距过大则判断为沙箱，退出程序。

正如一开始说的，CPUID在虚拟化环境中，占用的CPU周期会大幅上升。本质原因就在于这类指令会触发vmexit，在调用一些虚拟机无法完成指令的时候，就会触发它退出虚拟化，然后再执行指令。假如可以绕过vmexit也就绕过了这种检测方式。

不得不说逆向出battleye反沙箱代码的国外大佬不仅技术厉害，在产品方面更有独到的见解。虽然没有直接给出改进的代码，但是给出了反反沙箱的方法和更新建议。

检测方法和缺陷：

1.时间伪造：每次执行CPUID时减少TSC。VMCS 中的 TSC 偏移。

TSC即时间戳计数器，每次执行CPUID时减少TSC很好理解，很直接的篡改计数器。

VMCS中 TSC偏移量 表示该VMCS所代表的虚拟CPU TSC相对于物理CPU TSC的偏移, 即虚拟TSC=物理TSC+TSC偏移量. 当客户软件执行RDTSC时, 处理器直接返回虚拟TSC, 不产生VM-Exit. 这样, 对TSC的虚拟化只需在 适时更新VMCS中TSC偏移量即可, 不需要每次TSC访问都产生VM-Exit。（也就是我上文提到的绕过vmexit）

2.CPUID这个指令的执行时间在处理器之间差异很大，70-300个周期都有可能。

3.SetThreadPriority，正如代码里所写，我们使用这个函数增加了线程的优先级，但是这个方法容易受到中断或者其它进程的干扰，并不能保证这个线程可以被直接调用。

有检测方法，那肯定也有反检测方法（反反反沙箱？）。

改进方法：

1）禁用中断，将CR8修改为最高等级IRQL。

CR8是任务优先级寄存器，存储的就是当前IRQL等级。IRQL即中断请求级别，在同一处理器上，线程只能被更高级别IRQL的线程能中断，每个处理器都有自己的中断IRQL。

2）使用其它计时器替代TSC。

比如ACPI计时器、HPET、PIT、GPU计时器等。这里推荐APERF计时器，因为它难以伪造，并且仅在逻辑处理器处于 C0状态时才累计计数。

但有还有一个问题，那就是CPUID的执行时间在处理器之间差异很大，所以引出了下一种方法。

6）基于FYL2XP1的CPUID执行时间检测

说白了，就是以FYL2XP1这条命令的执行时间作为参照物来分析CPUID。

对于FYL2XP1这条命令其实不需要了解太多，我们只需要知道两点：

1.FYL2XP1是一条算术运算指令，平均执行时间正常情况下比CPUID长。

2.这条指令可以可靠的计时。

所以当CPUID指令的执行时间比FYL2XP1指令的平均执行时间长，就可以确定该系统是虚拟化的。

bool take_time()
{

    constexpr auto measure_time = 5;

    long long __cpuid_time   = 0;
    long long __fyl2xp1_time = 0;

    LARGE_INTEGER frequency = {};
    LARGE_INTEGER start     = {};
    LARGE_INTEGER end       = {};

    QueryPerformanceFrequency(&frequency);

    // count the average time it takes to execute a CPUID instruction
    for (std::size_t i = 0; i < measure_time; ++i)
    {
        QueryPerformanceCounter(&start);
        _cpuid_buffer_t cpuid_data;
        __cpuid(reinterpret_cast(&cpuid_data), 1);
        QueryPerformanceCounter(&end);

        auto delta = end.QuadPart - start.QuadPart;

        delta *= 1000000000;
        delta /= frequency.QuadPart;

        __cpuid_time += delta;
    }

    // count the average time it takes to execute a FYL2XP1 instruction
    for (std::size_t i = 0; i < measure_time; ++i)
    {
        QueryPerformanceCounter(&start);
        #ifdef _WIN64
        _asm_fyl2xp1();
        #else
        _asm FYL2XP1
        #endif
        QueryPerformanceCounter(&end);

        auto delta = end.QuadPart - start.QuadPart;

        delta *= 1000000000;
        delta /= frequency.QuadPart;

        __fyl2xp1_time += delta;
    }

    return __fyl2xp1_time <= __cpuid_time;
}

bool take_time_cpuid_against_fyl2xp1()
{
    constexpr auto measure_times = 5;
    auto positives               = 0;
    auto negatives               = 0;

    // run the internal VM check multiple times to get an average result
    for (auto i = measure_times; i != 0; --i)
        take_time() ? ++positives : ++negatives;

    // if there are more positive results than negative results, the
    // process is likely running inside a VM
    const bool decision = (positives >= negatives);

    return decision;
}

这段代码截取自github项目Hypervisor-Detection，经过了多组循环测试。take_time循环计算了fy12xp1和cpuid的周期大小并返回平均CPU周期的对比结果。take_time_cpuid_against_fyl2xp1为了确保准确，进行了多组测试。

当然CPUID不止如此，在反沙箱领域中还有其它妙用，后面的篇章我会陆续讲到。

7）特定时间执行

可以将我们的程序设置为每个小时的55分执行，或者设置为每个周的某一天执行。虽然有一定局限性，但想检测到我只能靠运气！

8）设置有效时间

最基础的也是加一个时间检测，超过指定时间之后就不再执行恶意代码。进阶一点的可以考虑将shellcode存放在oss的存储桶中远程拉取，但是设置链接的有效时间为2小时。

等蓝队拿到样本的时候我们已经销声匿迹了。

小结

关于时间规避沙箱检测的部分已经讲完了，但是还有许多方法我没有涉及到。就像我上面虽然说延时执行现在已经被沙箱加速很轻松的绕过，但是仍有一些大佬以此为基础创造出了更好的利用方法，例如利用计划任务，不仅可以延迟执行，也可以逃避沙箱的跟踪。

二、环境检测类

这一大类并没有很高的技术含量，就是检测环境，换句话说就是比谁脑洞大。这类检测方法往往不能直接断定沙箱，但是可以通过计算权重作为判断依据。

1）屏幕分辨率

检查屏幕分辨率是否是常用的分辨率，下面给出一个示例代码

void GetMonitorRealResolution(HMONITOR monitor, int* pixelsWidth, int* pixelsHeight)
{
    MONITORINFOEX info = { sizeof(MONITORINFOEX) };
    winrt::check_bool(GetMonitorInfo(monitor, &info));
    DEVMODE devmode = {};
    devmode.dmSize = sizeof(DEVMODE);
    winrt::check_bool(EnumDisplaySettings(info.szDevice, ENUM_CURRENT_SETTINGS, &devmode));
    *pixelsWidth = devmode.dmPelsWidth;
    *pixelsHeight = devmode.dmPelsHeight;
}

修改屏幕分辨率就可以很好的针对这种检测，现在应该很少有沙箱会犯这种低级错误。

2）首选语言

func IFlanguage() {
  a, _ := windows.GetUserPreferredUILanguages(windows.MUI_LANGUAGE_NAME) 
  if a[0] != "zh-CN" {
    os.Exit(1)
  }
}

正常情况下，我们接触到的都是国内项目，系统都是中文的，但是许多沙箱都是默认配置搭建起来的，所以使用英文系统。获取当前系统首选语言也是一种有效的检测方法。

3）主机用户/主机名

某些沙箱厂商会使用几个固定的用户名/主机名，在后面的信息搜集类模块会细讲。

4）注册表

不同的沙箱厂商会有一些特定的注册表路径，还有一些特殊的注册表项值。依旧以我们常见的Vmware举例：

5）进程

可以细分为两个方向，一个是检测正常个人电脑不该有进程，比如Vmtoolsd.exe等。另一个是检测正常个人电脑该有的进程，比如微信、QQ、浏览器等。

这个方法可以更进一步的延伸，检测进程地址空间中有没有特定的libraries。比如sbiedll.dll、dbghelp.dll、api_log.dll、vmcheck.dll等。

6）最近文件

Win+R输入Recent就可以看到当前主机的最近文件，下图是一个正常使用的主机，满满的都是使用痕迹：

如果最近文件夹中的数量少于n，那就可以断定这台主机大概率是沙箱。

7）临时文件

与最近文件同理。

8）特定文件

虚拟环境中存在一些真实环境中没有的文件，以Vmware举例。下面是一个真实主机：

然后再看看虚拟机：

很明显可以看到多了一些vm开头的文件。但不一定都能作为依据判断虚拟机，因为电脑只要装了Vmware这个工具，也会出现许多vm开头的文件，假如你选择了一个不恰当的文件作为依据，只能判断出这可能是一台虚拟机也可能是安装了Vmware的真实物理机。

9）特定目录

与特定文件同理。

10）上次开机时间

用过虚拟机的同学，应该都知道有一个很好用的功能就是快照，还原快照后会将当前虚拟机的状态还原到拍摄快照时的状态。而WMI数据库可能包含创建VM快照时的开机时间，如果快照是在一年前创建的，且沙箱仅更新了上次启动的时间，但是系统正常运行时间还是一年，这无疑是不合理的。

这一特性可以检测出从快照恢复的虚拟机，如果命中下面任何一条规则，都很可疑：

1.系统正常运行时间过长。

2.系统正常运行时间太短。（听说有的同学拿到样本现开虚拟机？）

3.多种方式获得的上次开机时间不一致。

11）CPU运行时间

具体原理见上一条，这里只给出一个简单的demo。

#define MIN_UPTIME_MINUTES 12
BOOL uptime_check()
{
    ULONGLONG uptime_minutes = GetTickCount64() / (60 * 1000);
    return uptime_minutes < MIN_UPTIME_MINUTES;
}

这里使用的API是不是很眼熟？所以绕过方式应该不用我多说了。

12）wifi检测

Windows虚拟机有一个特性，就是将所有网络连接识别为有线连接。所以一台没有任何WIFI连接记录的主机是很可疑的

实体机中执行命令 netsh wlan show profiles

再在虚拟机中执行一下。

区别还是很明显的，当然结果只能作为参考。

13）检查窗口数量

如果你经常使用的云沙箱，会发现返回测试截图的时候除了我们提交的文件，没有别的窗口存在。从性能角度考虑这是合理的，但同时提升了可疑性。

小结

环境检测类部分也讲完了，正如我在本段开头所说的，这里面很多方法只能判断这台主机可疑但是不能直接断定为沙箱，所以实战中最好多种方法复合使用。

一方面限于篇幅，另一方面也感觉自己还有许多没覆盖到的知识面，所以并没有一次性将内容写完。如果大佬们有独到的见解，新奇的脑洞，或者发现什么错误，欢迎私信默安逐日实验室公众号后台交流。