gMSA是什么

魁首哥

作者

gMSA是什么

这篇文章给大家分享的是有关gMSA是什么的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。

概述

gMSA，英文全称为“Group Managed Service Accounts”，即活动目录AD中的组托管服务账户。gMSA账户会将它们的密码存储在一个名叫“msDS-ManagedPassword”的LDAP属性中，DC每隔三十天就会自动对这个值进行重置，授权管理员以及安装它们的服务器都可以检索到这些密码。msDS-ManagedPassword是一个加密的数据块，名为“MSDS-MANAGEDPASSWORD_BLOB”，并且只有当连接是安全的时候（LDAPS或认证类型为‘Sealing&Secure’）才可以被检索到。

其实在此之前，我个人对gMSA了解的并不多，但是在观看了由Wald0和CptJesus主办的《Bloodhound 3.0》网络研讨会之后，我对gMSA有了新的认识，而这个研讨会主要讨论了gMSA为什么应该在渗透测试中成为焦点。

分析之后我们了解到，一般来说除了授权管理员，目标设备上还可能会有更多的用户账号被授予了读取gMSA密码的权限，而gMSA帐户通常会被授予管理员权限，有的时候甚至会被授予域管理权限。

那我们应该怎么去利用这种安全问题呢？我们如何才能收集到那些特权账号的密码呢？

因为目前社区有很多技术可以帮助我们生成传入的NTLM身份验证连接，而这种类型的身份验证密码都存储在一个LDAP属性之中。我认为最佳的解决方案，就是从ntlmrelayx中的LDAP属性msDS-ManagedPassword中检索密码。

与LDAP的中继链接

要通过NTLM中继实现一条与LDAP的连接，我们必须确保中继的身份验证连接使用的是HTTP协议。由于连接所需的签名数据位，我们无法中继SMB认证连接，不过漏洞CVE-2019-1040能够帮助我们绕过NTLM签名保护机制，这样我们就可以实现中继SMB->LDAP了。

NTLM中继过程如下：

1、目标向攻击者发送一个NTLM_NEGOTIATE数据包；
2、接下来，攻击者将NTLM_NEGOTIATE数据包中继至所选的目标服务器；
3、目标服务器向攻击者发送应答信息，其中包含一个NTLM_CHALLENGE数据包；
4、攻击者将NTLM_CHALLENGE数据包中继至目标；
5、目标向攻击者发送应答信息，其中包含一个NTLM_AUTHENTICATE数据包；
6、攻击者将NTLM_AUTHENTICATE数据包中继至目标服务器；
7、攻击者现在将成功与目标服务器建立已认证的会话连接；

但遗憾的是，我没有在ntlmrelayx中成功实现“Sealing & Secure”身份验证。现在，我们必须中继到LDAPS，而LDAPS只是通过SSL实现的LDAP，默认情况下活动目录AD安装是没有这种配置的，因为不存在默认的可用证书。

配置gMSA

#CreateaKDSRootKeyonDCAdd-KdsRootKey-EffectiveTime(Get-Date).AddHours(-10)#CreateanewgMSAonDCNew-ADServiceAccount-Namesvc_msa-DNSHostNamedc.htb.local-ManagedPasswordIntervalInDays30-PrincipalsAllowedToRetrieveManagedPasswordmsa_read,dc$#InstallgMSAonthetargetserverInstall-WindowsFeatureAD-DOMAIN-SERVICESInstall-AdServiceAccountsvc_msa

漏洞利用

首先，我们必须生成用于中继的NTLM认证请求，我们可以通过以下几种方式来实现，比如说：

1、ADIDNS通配符记录
2、Responder
3、WPAD + Mitm6
4、利用一个存在漏洞的服务器来创建HTTP认证请求

接下来，使用下列命令将我的代码库克隆至你的本地主机中，安装impacket，开启ntlmrelayx，然后选择你喜欢的方式来生成NTLM认证流量（关于如何生成NTLM认证流量的问题，本文不做过多描述）：

gitclonehttps://github.com/cube0x0/impacketcdimpacketpythonsetup.pyinstallpython./examples/ntlmrelayx.py--dump-gmsa--no-dump--no-da--no-acl--no-validate-privs-debug-tldaps://10.0.0.5