2019年在Windows 10的18305版本中，微软加上了一个最为实用的沙盒（Windows Sandbox）功能。Windows Sandbox虽然内置在Windows 18305中，要使用却需要用户自己手动添加，具体步骤：控制面板→程序和功能→启用或关闭Windows功能→勾选Windows Sandbox，确认后安装需要重启系统。

此外，在硬件上，还需要CPU支持（ Intel 虚拟化技术 (Intel VT) 或 AMD 虚拟化 技术(AMD-V))。

这个沙盒有的出现可以说在一定程度上对沙盒的技术规范起到了一定的作用，比如：

1.Windows 10（Pro / Enterprise）的集成部分。

2.在Hyper-V虚拟化之上运行。

3.原始的和一次性的：每次运行时都会进行自我清理，并且没有持久状态。

4.可通过具有专用格式（WSB格式）的配置文件进行配置，你可以配置网络，vGPU，映射的文件夹，在用户登录时运行的自动脚本以及许多其他选项。

5. 该部署基于 Windows Containers 技术。

从这篇技术博客文章来看，我们可以说微软实现了一个重大的技术里程碑。由此产生的沙盒体现了两方面的优点：一方面，沙盒基于Hyper-V技术，这意味着它继承了Hyper-V严格的虚拟化安全性。另一方面，沙盒包含一些允许与主机共享资源以减少CPU和内存消耗的特性。

其中一个有趣的功能特别重要，我们将在本文中详细说明。

动态生成的映像

用户磁盘和文件系统是动态创建的，并使用主机文件系统中的文件来实现。

动态生成的映像

我们出于以下几个原因决定更深入地研究这项技术。

1.缺乏有关官方和社区内部关于该技术的详细技术说明文档，虽然它结合了两种广泛记录的技术（Windows容器和Hyper-V），但我们仍然缺少有关它们如何协同工作的信息。例如，上述博客提到了Windows容器技术，但是在官方文档中，Windows容器的创建和管理是使用Windows的Docker实用程序完成的，而Windows沙盒中并未使用该实用程序。

2.不幸的是，除了调整WSB文件之外，Microsoft不允许对沙盒进行任何自定义。这意味着我们无法安装任何需要重启的程序，也无法为沙盒创建我们自己的基础映像。

在本文中，我们将分解几个组件、执行流程、驱动程序支持以及动态映像功能的实现设计。我们展示了其中涉及的几种内部技术，例如NTFS自定义重新标签、VHDx分层、用于正确隔离的容器配置、虚拟存储驱动程序、基于VMBus的vSMB等。另外，我们还创建了一个自定义的FLARE VM沙盒用于恶意软件分析，其启动时间仅为10秒。

通用组件

Hyper-V及其模块的复杂生态系统已经得到了广泛的研究，目前安全研究人员已经发现了几个漏洞，例如下一个VmSwitch RCE，它可能导致从用户到主机的完全退出。几年前，微软推出了Windows容器（主要用于服务器），该功能允许在Windows上本地运行Docker来简化软件部署。

这两种技术还以两个组件的形式引入Windows 10终端平台：WDAG（Windows Defender Application Guard）和最近的Windows Sandbox。最近，WDAG和另一个令人兴奋的Office隔离功能被组合成MDAG - Microsoft Defender Application Guard。

在POC2018大会上，一位技术人员做了一个演讲，他深入探讨了WDAG架构和内部结构。如我们所展示的，Windows Sandbox为其基础实现共享了相同的技术。

沙盒可以分为三个组件：两个服务“CmService.dll”和“vmcompute.exe”，以及创建的工作进程“vmwp.exe”。

Windows Sandbox常规组件

准备沙盒

每个基于Hyper-V的VM后面都有一个VHDx文件，这是计算机使用的虚拟磁盘。为了了解如何创建磁盘，我们查看了一个正在运行的沙盒的工作文件夹：%PROGRAMDATA%\Microsoft\Windows\Containers。令人惊讶的是，我们发现了8个以上的VHDx文件。

工作文件夹结构

我们可以在下一个路径——Sandboxes\29af2772-55f9-4540-970f-9a7a9a6387e4\sandbox.vhdx中按其动态大小跟踪主VHDx文件，其中，每次运行沙盒时都会随机生成GUID。

当我们手动挂载VHDx文件时，我们看到它的大多数文件系统都丢失了（在前面提到的WDAG研究中也可以看到这种现象）。

已安装的沙盒VHDx

我们可以立即观察到文件夹图标上的“X”符号。如果打开文件资源管理器中的“属性”列，我们将看到两个不寻常的NTFS属性。解释如下：

O – Offline

L – Reparse Point

NTFS重解析点（Reparse Points）是NTFS的扩展，它允许它创建到另一个路径的“链接”。 随Windows 2000发布的NTFS版本5里最有趣的一个属性是引入了一些特殊的文件系统功能，并应用于特定的文件或目录上。这些特殊功能使NTFS文件系统更加强大和有扩展性。这个特性的实现基础叫做重解析点（reparse points）。

重解析点的使用源于一些应用程序想把一些特殊数据存储到特殊的地方——重解析点，然后由应用程序做上特殊的标签，只允许它使用。为此文件系统引入了一个应用程序相关的特殊过滤器（application-specific filter），并与重解析点的标签关联起来。多个应用程序可以把不同的数据存储到同一个重解析点文件里，只要使用不同的标签。微软保留了几个标签为自己使用。

它还在其他功能（例如批量安装）中起作用，在我们的案例中，使用此功能是有道理的，因为大多数文件不是“物理上”存在于VHDx文件中。

为了了解重解析点指向的位置以及其中的内容，我们将更深入地研究NTFS结构。

解析MFT记录

主文件表（MFT）存储从NTFS分区检索文件所需的信息，一个文件可以具有一个或多个MFT记录，并且可以包含一个或多个属性。我们可以使用mftparser选项运行流行的取证工具Volatility，以解析基础文件系统中的所有MFT记录。可以使用以下命令行完成此操作：

volatility.exe -f sandbox.vhdx mftparser --output=body -D output --output-file=sandbox.body

当我们在输出中搜索kernel32.dll（示例系统文件）记录时，会遇到以下文本：

我们可以看到与之前相同的reparse（“S”）和离线（“o”）属性，但是Volatility并没有提供任何其他信息，我们可以使用MFT记录的偏移量0x3538c00来启动我们自己的手动解析。

我们在解析过程中使用了下一个NTFS文档，不过我们并没有提供MFT格式的完整规范，但简单地说，MFT记录包含可变数量的属性，并且每个属性都有自己的标头和有效载荷。我们正在寻找$ REPARSE_POINT属性，该属性由序号0xC0标识。

MFT属性标头结构

$ REPARSE_POINT属性有效载荷结构

我们对上面列出的结构进行的分析工作产生了以下数据：

一些重要的注意事项：

1.我们没有找到任何有关Microsoft重新解析数据结构的公开文档，但是对它进行反向工程并不是很困难。

2.重新解析标签0x90001018在此处定义为IO_REPARSE_TAG_WCI_1，其描述如下：由Windows容器隔离过滤器使用，仅服务器端的解释，对网络没有任何意义。

3.在本研究中对Windows模块进行逆向工程时，我们几次遇到了作为硬编码值的参考GUID 77 F6 64 82 B0 40 A5 4C BF 9A 94 4A C2 DA 80 87。该值表示对主机基础层的引用，稍后我们将对其进行讨论。

4. 重新解析数据中的路径显示了我们的示例文件的相对路径:Windows\System32\kernel32.dll。

根据上述信息，我们可以得出结论，文件是由基础文件系统“链接”的（可能已链接到指定的FS过滤器），但是仍然有许多问题尚未得到解答：VHDx是如何构造的，其他VHDx的目的是什么，以及负责链接到主机文件的组件。

VHDx分层

如果我们在沙盒创建过程中跟踪Procmon日志，就会注意到一系列的VHDx访问尝试：

VHDx分层导线

虽然第一个是我们之前解析过的“真正的”VHDx，但它之后是其他3个VHDx访问。我们怀疑微软为虚拟磁盘模板使用了某种分层。

通过使用二进制编辑器检查VHDx文件，可以轻松验证我们的理论：

010编辑器中的parent_linkage标签

可以使用多种方法来指定VHDx格式的父定位符：绝对路径、相对路径和卷路径，该文档可以在这里找到。

有了这些知识，我们就可以继续构建下一层了：

Sandboxes\

Sandboxes\

BaseImages \ 0949cec7-8165-4167-8c7d-67cf14eeede0 \ Snapshot \ SnapshotSandbox.vhdx：可能与基础层截屏有关。

PortableBaseLayer \ SystemTemplateBase.vhdx：基本模板。

当我们浏览这些虚拟磁盘时，会注意到文件仍然缺失。比如一些系统文件夹是空的，还有用户/程序文件和各种其他文件的文件夹。

使用Procmon可以让我们了解到另一个重要的层——操作系统基础层缺失了。

操作系统基础层

操作系统基础层主文件存在于沙盒工作文件夹中的下一个路径中：BaseImages\0949cec7-8165-4167-8c7d-67cf14eeede0\ basellayer .vhdx。通过查看Procmon的安装过程，我们可以看到下一个.wim（Windows映像格式）文件C：\ Windows \ Containers \ serviced \ WindowsDefenderApplicationGuard.wim被提取到同名的PortableBaseLayer文件夹中，并且复制并重命名为上面的基础层文件。这显示了WDAG与Windows沙盒之间的另一个相似之处。

浏览BaseLayer.vhdx磁盘时，可以看到创建的沙盒的完整结构，但系统文件仍然“物理上”缺失。像以前一样解析kernel32.dll的MFT记录会导致相同的$REPARSE_POINT属性，但具有不同的标签：0xA0001027: IO_REPARSE_TAG_WCI_LINK_1。记住该标签，下面会用到。

基础层用户文件夹

另外，当我们运行mountvol命令时，我们看到基础层VHDx被装载到它所在的同一目录中：

已安装的操作系统基础层

到目前为止，负责安装该卷的服务以及我们之前提到的所有以前的功能，都是容器管理器服务CmService.dll。

该服务运行一个名为cmimageworker.exe的可执行文件，该文件具有下一个命令行参数expandpbl / deploy / clean来执行这些操作。

创建CmService基础层

我们可以在cmimageworker.exe中观察到对computestorage！HcsSetupBaseOSLayer的调用，以及在calculatestorage.dll中实际创建基础层的一部分。

cmimageworker!Container::Manager::Hcs::ProcessImage启动基础层创建

在computestorage！OsImageUtilities :: ProcessOsLayer中创建基础层的一部分

微软发布了有关沙盒的以下声明：

Windows的一部分——Windows 10 Pro和Enterprise附带了此功能所需的一切，无需下载VHD！

到目前为止，我们已经了解了有关该功能的关键实施细节，让我们继续看看容器是如何执行的。

本文翻译自：https://research.checkpoint.com/2021/playing-in-the-windows-sandbox/如若转载，请注明原文地址：