只读域控制器RODC是难打还是不能打？

只读域控制器（RODC）是一种微软 Windows Server操作系统的角色，它提供了一种安全的方式来将Active Directory服务扩展到安全较低的网络边缘。RODC只允许只读访问，不允许对 Active Directory的数据进行修改，这使得它们成为支持远程办公、分布式办公和边缘部署等场景的理想选择。

然而，与任何安全策略一样，RODC也存在一些潜在的安全风险。在使用RODC 时，需要认真考虑安全因素，并采取适当的措施来缓解这些风险。在本文中，我们将探讨 RODC 的安全风险，并提供一些防范措施，以确保其安全性。

(资料图)

RODC中的管理员

RODC ManagedBy属性值可以用于指定RODC的管理员，这样可以确保只有授权的用户或组才能管理RODC。指定ManagedBy属性值时，可以选择指定一个用户或组。当指定一个组时，该组中的成员都将被授予对RODC的管理权限。这样可以简化管理，避免逐个指定每个管理员。

当获取了RODC ManagedBy属性中列出的账户权限，就可以在RODC上拥有本地管理员权限。如果获取了具有委派权限来修改RODC的ManagedBy属性的账户权限，同样也可以成为管理员。

因此，对于ManagedBy属性值，必须进行适当的管理和保护，以确保只有授权的用户或组才能进行RODC的管理操作。同时，也需要定期审查ManagedBy属性值，以确保其仍然是最新的和正确的。

RODC中的身份验证

在Windows Server 2008中引入RODC时，Microsoft强制规定RODC不得使用 Kerberos TGT加密。这是因为TGT是Active Directory中用于加密用户身份验证凭据的关键密钥之一。如果TGT的密钥被泄露，攻击者就可以使用该密钥解密用户身份验证凭据，从而获取用户的用户名和密码。

为了加强安全性，RODC引入了一种新的加密机制：不可逆转的密码加密。该机制使用一个密码复制策略来控制RODC缓存的用户密码。密码复制策略由域管理员在Active Directory中配置，并指定哪些用户的密码可以被RODC缓存，以及在RODC上缓存的密码是否可被解密。只有在密码复制策略明确允许的情况下，RODC才会缓存用户密码。这可以避免密码被泄露，提高RODC的安全性。

为此，RODC还引入了两个重要的属性：msDS-RevealOnDemandGroup和msDS-NeverRevealGroup。

msDS-RevealOnDemandGroup属性指定了一组可以在RODC上缓存其成员身份的安全组。如果用户是该组的成员，RODC将在需要时向上级域控制器请求其身份信息，并将其缓存在本地。这可以提高身份验证速度和效率。

msDS-NeverRevealGroup属性指定了一组不允许在RODC上缓存其成员身份的安全组。如果用户是该组的成员，则其身份信息将始终从上级域控制器请求，并不会缓存在RODC上。这可以保护敏感信息，避免在RODC上泄露。

其中后者的优先级最高，当某用户或组同时存在于两个属性当中，RODC无法检索其凭据。

进行身份验证时，RODC需要访问用户和计算机的凭据来在本地对它们进行身份验证。每个RODC都有一个特定的主体列表，它被指定为要认证的主体，并因此允许检索其凭据。这个列表存储在RODC的机器账户的msDS-RevealOnDemandGroup属性中。

在认证用户或计算机之后需要生成TGT，而RODC并不能使用域中kertgt密钥来对TGT进行加密和签名，因此当某服务器提升为RODC的时候，AD域会创建一个新的krbtgt账户，此用户被分配一个五位数的密钥版本号，同时此账号的名称为krbtgt_xxxxx，此账号的名称可以在RODC机器账户的msDS-KrbTgtLink属性中找到，而五位数的密钥版本号和机器账户的名称可以在新的KRBTGT帐户的msDS-SecondaryKrbTgtNumber和msDS-KrbTgtLinkBl属性中找到。

PS > Get-ADComputer RODC -Properties msDS-KrbTgtLink

PS > Get-ADUser krbtgt_23165 -Properties msDS-SecondaryKrbTgtNumber,msDS-KrbTGTLinkBl

RODC黄金票据

当获得RODC管理员权限时，可以dump缓存在RODC中的凭据，例如krbtgt凭据，因此可以伪造一个RODC的黄金票据。

使用Rubeus来创建一个黄金票据，rodcNumber代表RODC中krbtgt的密钥版本号，aes256代表RODC krbtgt用户的密钥，id为要制作票据用户的rid，最后还需要域名和域内sid的值。

golden /rodcNumber:23165 /aes256:eacd894dd0d93...7a0ebbfa64c7545 /user:administrator

/id:500 /domain: 

/sid:S-1-5-21-1281121768-1524864103-2976670869

密钥列表攻击

之后将这个黄金票据用于向域控发送kebtgt服务的TGS-REQ，TGS-REQ包含“Key List Request”(KERB-KEY-LIST-REQ)，KERB-KEY-LIST-REQ 结构用于请求KDC 可以提供给客户端的密钥类型列表。

如果目标账户在RODC的msDS-RevealOnDemandGroup属性中且不在msDS-NeverRevealGroup属性中，TGS-REP将返回一个包含目标用户凭证的KERB-KEY-LIST-REP结构，解密后，可以获得其hash从而进行hash传递攻击。

下面由rubeus工具和上面制作的票据来完成key list攻击：

asktgs /enctype:aes256 /keyList /service:krbtgt/ /dc: /ticket:doIFgzCCBX+gAwIBBaEDA.....

域内权限提升

经过上面的描述可以看出，当获取到RODC的本地管理员权限时，可以获取到在msDS-RevealOnDemandGroup属性中而不在msDS-NeverRevealGroup属性中的用户，因此，如果我们可以操作这两个属性，就可以加入administrator账户，实现提权。

具体过程：

1.首先将域管理员账户添加到msDS-RevealOnDemandGroup 属性中。

PS > Set-DomainObject -Identity RODC$ -Set @{'msDS-RevealOnDemandGroup'=@('CN=Allowed RODC Password Replication Group,CN=Users,DC=relay,DC=com', ' CN=Administrator,CN=Users,DC=relay,DC=com')}

2.然后将msDS-NeverRevealGroup 属性直接清空。

PS > Set-DomainObject -Identity RODC$ -Clear 'msDS-NeverRevealGroup'

3.通过修改ManagedBy属性，获得RODC的特权访问以获取缓存凭据的访问权限。

4.之后跟前面提到的一样，伪造目标账户的RODC TGT，并请求key list attack攻击，获取到域管理员凭据。

5.最后进行清理痕迹，还原RODC的msDS-RevealOnDemandGroup和msDS-NeverRevealGroup的属性值。

这种方法与key list attack的区别就是此权限提升方式需要具备更改写入RODC msDS-RevealOnDemandGroup等属性的权限，即GenericWrite，GenericAll，WriteDacl，Owns，WriteOwner，WriteProperty等访问权限。

总结

总结来说，RODC虽然具有许多优点，但与可写DC可能存在相同的安全风险等级，因此RODC和可写DC一样需要采取适当的安全措施来保护RODC，以确保它的安全使用。这包括在RODC上实施最小权限原则、定期进行安全审计、强制实施复杂的密码策略等。

另外针对本文讲解的相关攻击手法，可以采用如下措施帮助缓解：

1.审核所有RODC的msDS-RevealOnDemandGroup属性，确保它不包含任何域管理员组账户。

2.将所有管理员组账户添加到Denied RODC密码复制组，并将该组添加到所有RODC的msDS-NeverRevealGroup属性中。

关键词：