高级 Active Directory 持久化技术：dMSA 是否可被滥用？

【翻译】Advanced Active Directory Persistence Techniques: Can dMSA Be Abused

委派托管服务账户 (dMSA) 于 Windows Server 2025 引入，通过将身份验证绑定到特定机器身份，为传统服务账户提供了更安全的替代方案。与标准服务账户不同，dMSA 实现了密码管理自动化，支持多服务器，并防止如 Kerberoasting 等凭据收集攻击。用于身份验证的密钥源自机器账户凭据，由域控制器 (DC) 加密，且从不在本地存储，这使其极难被攻破。

在迁移过程中，dMSA 取代现有服务账户的同时保持对所有先前授权资源的访问权限，有效阻止使用旧凭据进行身份验证。此外，Credential Guard (CG) 通过保护存储的密钥免遭窃取来增强安全性，确保只有 Active Directory 中映射的授权设备才能使用 dMSA。这种方法显著降低了攻击面并简化了身份管理，使 dMSA 成为现代 Active Directory 环境中的重要安全增强功能。

服务账户概述：

服务账户是用于在 Windows 环境中运行服务和应用程序的专用账户。传统服务账户通常需要手动密码管理，增加了凭据泄露、滥用和安全配置错误的风险。它们通常使用静态密码，使其成为基于凭据攻击（如 Kerberoasting 和 Pass-the-Hash）的主要目标。

此外还有托管服务账户 (MSA)，在 Windows Server 2008 R2 和 Windows 7 中引入，作为域账户运行，每 30 天自动轮换密码。

为进一步降低所讨论的风险，组托管服务账户 (gMSA) 在 Windows Server 2012 中作为标准服务账户的增强版本引入。gMSA 提供自动密码轮换，消除了手动更新凭据的需求，并支持多服务器分布式工作负载。与传统服务账户不同，gMSA 在 Active Directory 中安全存储密码，只允许授权机器通过 Kerberos 检索密码。

攻击流程：

让我们设想一个场景，我们对"Managed Service Accounts"容器具有"Generic All"权限。

默认情况下，用户可以枚举容器但不能枚举其子对象。

我们可以使用以下命令验证我们是否对容器具有"Generic All"权限：

dsacls "CN=Managed Service Accounts,DC=kingdom,DC=local"

我们也可以使用"Active Directory Users and Computers"检查权限：

更改继承级别

尽管我们对容器具有完全控制权，但除非推送权限继承，否则不能保证对现有子对象的读取访问权限。我们可能只能看到一个没有可读属性的"存根"对象。

AD 中的 ACL 继承基于父子关系工作。Managed Service Accounts (MSA) 容器作为父对象，而每个单独的 MSA（例如 dMSA-POC）是子对象。

要强制将我们的完全控制权继承到子对象，我们可以运行：

dsacls "CN=Managed Service Accounts,DC=kingdom,DC=local" /G "KINGDOMpoc:GA" /T /I:S

(GA = 完全控制权限，/T = 递归，/I:S = 继承到子树。)

我们可以再次使用 dsacl 来确保我们对容器中的子对象具有完全控制权：

在获得对子对象的完全控制权后，我们可以完全看到容器中的对象。

此外，我们可以获得 dMSA 对象的完全所有权（默认情况下"domain admins"组是所有者）：

我们可以通过创建另一个我们完全控制的 dMSA 来实现持久性，同时我们可以通过将我们的用户或机器账户添加到 PrincipalAllowedToRetrieveManagedPassword 中，将自己添加为有资格接收托管密码的实体。

缓解措施：

首先启用仅适用于 Windows 11 24H2 和 Windows Server 2025 或更高版本的以下设置。

在客户端设备上，您必须激活以下组策略设置：

Computer ConfigurationAdministrative TemplatesSystemKerberosEnable Delegated Managed Service Account logons

对于监控，以下事件描述了对具有"Write"权限的对象的访问：