轻松看懂的加解密系列(1)番外篇II：Procmon实战和经典案例回顾

Case1，用 Procmon 确认个人密钥或证书丢失问题：

        接上一篇【断点2: 执行到 CryptGenKey 之前】一节最后的内容。当我们尝试强行删除例程所需要的密钥或证书文件后，再次执行例程，得到控制台输出为 CryptAcquireContext failed: -2146893802。查询此错误代码得到如下解释：

    CryptAcquireContext 失败并返回错误码 -2146893802（或 0x80090016）通常表示在尝试获取加密服务提供程序（CSP）上下文时发生了错误。这个错误码通常与加密相关的问题有关。常见的导致 CryptAcquireContext 返回此错误码的原因可能包括以下几种：

1. 提供程序不可用： 指定的加密提供程序（pszProvider 参数）可能不存在或未正确安装。请确保指定的提供程序名称正确，并且已经正确安装。

2. 访问权限问题： 可能缺少执行加密操作所需的访问权限。确保应用程序具有足够的权限来执行加密操作。

3. 密钥容器问题： pszContainer 参数指定了一个密钥容器的名称。如果指定的容器不存在或无法访问，也会导致此错误。确保指定的容器名称有效，并且应用程序有权访问它。

4. 密钥存储问题： 与密钥容器相关的密钥存储可能损坏或不可用。这可能需要修复密钥存储或重新创建密钥容器。

5. 其他加密配置问题： 还有其他可能的加密配置问题，例如证书、证书链、证书存储等方面的问题。

        根据这个错误代码，虽然在网上很容易查询到常见的几种原因，但实际排查起来依然是难以入手。而直接用 Procmon 监视程序的详细事件记录却是非常简单直观的方法。观察实际的 Procmon 日志可以很容易发现程序先是直接访问当前用户目录下的 【663ed5f4fe50a280b70b3badd6c59de5_7914d52b-311e-450f-ad30-0ea710e89468】文件，返回的【Result】是 【NAME NOT FOUND】，意味着没有搜索到目标文件名。接着把精确查找条件降级为模糊查找【663ed5f4fe50a280b70b3badd6c59de5_*】，【Result】依然是【NO SUCH FILE】。最后程序只好关闭了刚打开的注册表项 CSP【Microsoft Enhanced RSA and AES Cryptographic Provider】，直至退出整个程序。

图-1 无论精确还是模糊查找都没有搜索到目标文件

Case2，用 Procmon 发现客户 VDI 环境中密钥和证书丢失问题

        

图-2

        提到 VDI（虚拟桌面基础设施），你一定会很快联想到 VMware、Citrix、Microsoft 等著名的 VDI 厂商。VDI 的部署模式适合各种不同类型的组织，特别像教育、医疗、金融、政府等这类既需要少量个性化配置，同时又要保证一定程度的标准化和数据安全的机构，是 VDI 市场的主要消费群体。

        在一个大型组织内部，部署和维护 VDI 环境需要大量的角色共同负责，主要包括了 VDI管理员、网络管理员、安全管理员、应用管理员和存储管理员等。VDI 的部署模式又主要分为 Persistent VDI（持久性 VDI）、Non-Persistent VDI（非持久性 VDI）和 Semi-Persistent VDI"（半持久性 VDI）。如此，一个大型 VDI 系统因牵涉了多方因素，难免会隐藏很多问题，并且大部分时候只会在终端用户使用具体软件的过程中暴露出来。

        在实际生产环境中，笔者发现主要是【半持久性 VDI】客户在使用软件时经常会遇到一些异常问题。因为【半持久性 VDI】的虚拟机，往往会在终端桌面系统重启后销毁某些个人用户配置。结合 Case1，不难想见，如果某个组织内由于配置问题造成 C:\Users\【UserName】\AppData\Roaming\Microsoft\Crypto\RSA\【SID】下的文件密钥相关文件，在桌面重启后总是被清空或重置，就很容易造成相关软件加解密操作失败。可见 Procmon 在调试这类问题时是一把利器，很容易直接定位问题的直接原因。

图-3

        需要顺便提及一下的是，Windows 提供的另一套 Data Protection API（DPAPI）其实比之前介绍的 Cryptographic API（Crypto APIs）更适合数据的本地加密和解密。因为在一些被黑客攻击的系统上，利用一些系统 API 监视工具（例如 Rohitab’s API Monitor）和 Dump工具（例如 mimikatz、open SSL）还是可以很轻松的将明文和密钥等 Dump 出来并加以逆向分析。该加解密系列文章未来也会有对 Windows Data Protection API (DPAPI) 的实例介绍。

Case3, 用 Procmon 发现杀毒软件造成的软件运行问题

图-4

图-5

         客户报告你发布的软件在他们的系统上运行异常。如上图所示，在你随后获得的 Procmon 日志中，如果发现被执行应用程序在创建时被某个 exe 所“劫持”。然后去搜索这个 exe 的名称后发现是某个杀毒软件或者安全软件套件的一部分，那么十有八九就是因为这个杀软造成的异常。此时最简单的方法就是通知客户的 IT 将你的软件加入到他们的部署白名单里（推荐）。或者你能有办法从客户那里获取杀软的详细日志，然后有针对性的修复软件行为以绕过客户的杀软策略（不推荐）。

        【图-4】TaniumCX.exe 是 Tanium 公司的一个执行文件。Tanium 是一个专门从事终端点安全和系统管理的公司，他们提供了一种综合的系统管理平台，帮助组织管理和保护其计算机网络。Tanium 的产品和解决方案旨在帮助组织提高终端安全性、改进系统管理和加强网络安全。

        【图-5】ccSvcHst.exe 是与 Symantec 的 Norton 杀毒软件（Norton AntiVirus）或 Norton 安全套装（Norton Internet Security）相关的进程。Symantec 公司是一家知名的安全软件和解决方案提供商。ccSvcHst.exe 是 Symantec 安全产品的核心组件之一，它是 Symantec 安全套装的服务宿主进程。

Case4, 用 Procmon 发现软件之间的 Integrity 问题

        如【图-6】所示，我们就拿大家经常使用的腾讯会议为例。一个常见的操作就是通过 Outlook 的腾讯会议插件去 Start Meeting。其原理可以简单认为是 Outlook.exe 进程向另外的 wemeetapp.exe 主进程发送一个带参数的开会命令。

图-6

        正常情况下 wemeetapp.exe 在收到命令后，会按照参数去执行接下来的任务。但笔者在构建一个特殊的前提条件后，执行同样的动作，却得到了Error “Failed to connect Tencent Meeting” 。这显然是因为 Outlook 插件在命令发出后无法得到反馈，导致最后超时报错。而笔者所特意构建的前提条件就是将 Outlook 和 wemeetapp 运行在不同的 Integrity 级别。

图-7

        双击目标进程的任何一条记录，在其【Event Properties】窗口的【Process】分页中，“Integrity" 代表了进程的完整性级别。Windows 强制完整性控制是一种安全特性，用于限制进程的权限和访问，以确保系统的安全性。Windows 安全性模型将进程分为不同的完整性级别，主要包括以下几个级别（从最低到最高）：

1. 低完整性（Low Integrity）： 进程在低完整性级别下运行，通常用于互联网浏览器和一些不需要访问敏感资源的应用程序。这些进程受到最严格的权限限制，以减小对系统的潜在风险。

2. 中等完整性（Medium Integrity）： 大多数应用程序在中等完整性级别下运行，这些应用程序具有一定的权限，可以访问系统和用户资源，但不能访问高完整性级别下的资源。

3. 高完整性（High Integrity）： 进程在高完整性级别下运行，这通常包括管理员级别的进程。高完整性级别具有最高的权限，可以访问系统上的所有资源。

        在 Windows 操作系统中，不同完整性级别的进程通常是隔离的，具有不同的安全上下文和权限。这种隔离是为了提高系统的安全性，防止低完整性级别的进程对高完整性级别的资源进行未经授权的访问。通常情况下，不同完整性级别的进程之间是不能直接互相通信的，因为操作系统会限制它们之间的交互。这就是在本次实验中 Outlook 的命令无法直接发送给 wemeetapp 进程的原因。

        正常情况下 Outlook 和 wemeetapp 进程都属于普通应用程序，所以都应该工作在 Medium Integrity 而能够互相正常通信。但是由于一些潜在的可能性，会造成某些普通应用程序进程工作在非 Medium Integrity。比如，该程序被其工作在 High Integrity 的负责升级的进程所启动，继承了其 Integrity。又比如某虚拟机的开机设置会将所有默认启动软件设置为 High Integrity，而之后用户手动打开的软件都工作在 Medium Integrity，如果两者之间后期有交互行为，可能就会失败。请记住，当下客户的应用环境千差万别，甚者系统本身配置就是有缺陷的，所以不要苛求客户的环境和你的实验室环境完全一样。能够通过某种合适的方法，迅速帮助客户定位问题才是王道。而这些都是需要工程师经历长期的修炼。

        这篇短文只介绍了 Procmon 所擅长的一小部分工作。相信大家在学习了如何使用 Procmon 之后，结合相关工作任务勤加练习和研究，一定会很快地掌握这个系统工具利器。