【技术分享】窃取服务凭证以实现域完全控制

翻译：t0stmail

稿费：200RMB（不服你也来投稿啊！）

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

前言

绕过Win10系统Credential Guard防护功能，窃取服务凭证进行横向渗透。

摘要

CyberArk实验室团队已经发现了一种从本地安全机构（LSA）Secrets注册表配置单元得到加密的服务凭据的方法，并将它们注入到新的恶意服务中，以实现域的横向移动与完全控制。

此漏洞需要攻击者首先在受感染的计算机上获得本地管理员权限，但一旦获得了本地管理员权限，攻击者就可以利用单个加入域的机器横向渗透，最终获得对域控制器的访问权限。

此漏洞可以在Windows端利用，包括启用了Credential Guard（VSM）功能的Windows 10机器。

本博客将解释现今的服务凭证保护方法，和怎样绕过攻击，以及CyberArk实验室团队如何证明这个漏洞可以进行横向渗透。

背景：如何保护服务凭证

从Windows 7开始，Microsoft将凭证存储在安全注册表配置LSA Secrets注册表（HKEY_LOCAL_MACHINE / Security / Policy）中来开始保护服务凭据，凭据使用数据保护API（DPAPI）且通过系统密钥进行加密，一般情况只有system账户能访问，管理员是没办法的，但是，默认情况下。管理员仍然拥有对此注册表的修改权限，利用修改权限，管理员仍然可以访问LSA Secrets，从注册表中转储凭据，或利用DPAPI进行提取。

在Windows 10中，Microsoft引入了Credential Guard功能，旨在通过安全的位置隔离来主动保护内存中的域用户凭据，借此来缓解使用凭据或哈希进行横向移动的风险。 但是，因为Credential Guard仅在内存中保护凭据，无法保护服务凭据。 因此，这些可能具有域访问权限的服务凭证仍保留在LSA Secrets注册表配置单元中。

新风险

CyberArk实验室团队最近发现，存储在LSA Secrets注册表配置单元中的加密服务凭据可泄漏，并用于实现横向移动，即使启用Windows 10中的Credential Guard。在概念上类似于以前版本的Windows中的传递哈希漏洞，攻击者可以使用加密Secrets横向移动通过域，而不需要知道基本的凭据。

概念证明

我们假设这些用于合法服务的服务凭证可能被捕获并注入到恶意服务中，从而允许攻击者访问所有系统和资源，那么在Windows机器上具有本地管理员访问权限的任何恶意用户都可以重用存储的域级服务凭据以横向移动，并可能访问域控制器。

为了测试这个假设，我们从以下基准环境开始：

1. win10计算机，本地管理员访问权限

2. 启用Credential Guard功能

3. 一个非管理域凭据的服务

为了测试这种情况，我们创建了一个新的空白服务，我们将尝试注入捕获这个服务凭据。 这个空白服务旨在模仿攻击者实际创建和使用的恶意服务。

步骤1：获取LSA Secrets的访问权限

访问LSA Secrets的第一步是授予本地管理员对安全性注册表配置单元的访问权限。 如上所述，默认情况下，此访问权限仅保留给SYSTEM用户。 但是，本地管理员具有更改此默认设置所需的权限。

Figure 1: Security registry hive default Administrator permissions

使用本地管理员权限，攻击者可以编辑权限，以授予管理员对安全性注册表配置单元（HKEY_LOCAL_MACHINE / Security）的访问权限。 一旦攻击者具有对安全性注册表配置单元的读取和写入权限，他就能够访问注册表并开始搜索服务的凭据信息。

步骤2：搜索服务信息

通过访问LSA Secrets注册表，接下来我们在机器搜索具有域级访问权的服务（services with domain-level access）。注意，这些服务没有管理权限; 他们只是对同一域上的其他系统进行非管理访问。

Figure 2: Service enumeration

此查询标识了两个具有域级访问权的服务：AppVClient和tzautoupdate。 这些服务在Windows 10机器上属于基础服务，我们能够在注册表中找到他们：

HKEY_LOCAL_MACHINE/Security/Policy/Secrets/SC AppVClient
HKEY_LOCAL_MACHINE/Security/Policy/Secrets/SC tzautoupdate

我们从LSA Secrets注册表中导出了这俩个服务的凭据信息，且并没有尝试利用DPAPI去解密。从这点上说，凭据仍被配置为仅对这些特定服务启用认证。在我们更改配置以使用我们的新服务执行测试之前，我们还需要访问服务的属性。

我们再次使用本地管理员进行访问注册表并导出与这些服务相关联的属性：

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services.

步骤3： 更改凭据和属性进行重复使用

如上所述，合法服务的凭据和属性都被配置为仅为其特定服务工作，这意味着我们不能重复使用它们。然而我们是否可以修改凭据和属性的配置以使他们被不同的服务使用呢，为了测试这个，我们使用上面提到的空白服务。

我们修改了服务的凭据和属性配置，以便两者都指向我们新的空白服务。

Figure 3: Service modifications

然后，我们将修改的凭据导入到空白服务的凭据中，并将修改后的属性导入到空白服务的属性中，如图4和图5所示。

Figure 4: Import modified service secrets into blank service secrets

Figure 5: Import modified service properties into blank service properties

接下来，我们在机器上启动空白服务进行测试。

我们进行域枚举以快速定位域控制器，并且我们搜索了对所有枚举域控制器具有高权限访问的服务。我们还找连接到原始受害者系统的所有其他系统。 如果受害者机器不包含任何具有域控制器访问的服务，我们还能够横向移动到其他可能包含具有更高特权的服务的机器。

步骤4：横向移动和域完全控制

使用服务上的信息以及网络上连接的系统的信息，我们测试了我们的空白服务，看看我们是否能够成功地实现横向移动。 结果是 “是”。使用这些不完全和重用的服务凭证，我们证明不完全的服务凭据实际上可以用于实现横向移动。 并且，每访问一个新机器，我们有可能找到在域上具有更高和更高权限的服务帐户。在每一台新机器上，我们能够重复获取凭证，修改和重复利用的过程，直到我们能够找到一个访问域控和实现完全控制的服务账户

实际意义

CyberArk实验室中的测试清楚地表明，在单个用户的机器上，具有本地管理员访问权限的攻击者可能会获取服务凭据，并重新用它们以实现横向移动和域的完全控制 。（即使启用了Credential Guard）。

在实际情况下，攻击者可以重复“服务凭证窃取，修改和重用”的过程，并且攻击者可以配置恶意服务以自动化该攻击以迭代步骤。在这种情况下，在一台计算机上具有本地管理员访问权限的攻击者可以在几分钟内获得整个域的完全所有权。

缓解

Microsoft Credential Guard不会以保护域级用户凭据的方式保护域级服务凭据。 因此，我们必须采取额外的步骤来保护和监控服务凭据的使用。

为了降低服务凭据失窃的风险以及攻击者横向移动通过网络的能力，应该采取以下步骤：

1. 从标准用户中删除本地管理员权限

2. 尽量在本地服务中少用域账户，除非必须

3. 在需要时，为服务创建专用的域帐户

4. 删除服务帐户的所有不必要的权限

5. 通过Windows事件日志监视对敏感注册表值的所有权限更改

6. 使用凭证盗窃检测工具来检测和阻止窃取LSA Secrets

披露时间轴

2016年10月25日：风险报告给微软安全响应中心

2016年10月26日：微软回应：不认为是一个有效的漏洞，因为它需要攻击者已经入侵了机器。

2016年11月16日：公开