欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

Kerberos中继攻击:滥用无约束委派(上)

来源:本站整理 作者:佚名 时间:2019-10-06 TAG: 我要投稿

关于在Active Directory中滥用Kerberos的研究,最近十分火爆。所以,这篇文章也讨论了一个相对未知(从攻击者的角度来看)但很危险的特性:无约束的Kerberos委派。另外,在撰写本文的过程中,我还发现了一些有趣的RPC调用,这些调用可以让域控制器对你进行身份验证,甚至允许跨越“森林边界”发起攻击。然后我发现了PrivExchange,它可以使交换验证以类似的方式进行。由于用于无约束委派滥用的工具非常少,所以我编写了一个新的工具包krbrelayx,它可以滥用无约束委派,并从连接到你主机的用户那里获取TicketGrantingTicket(TGT)。在本文中,我将深入研究无约束的委派滥用,以及krbrelayx工具包可能提供的一些更高级的攻击。
结合NTLM中继
在开始之前,让我们先澄清一个事情:你实际上不能以中继NTLM身份验证的方式中继Kerberos身份验证。我编写的这个工具之所以称为krbrelayx,是因为它的工作方式类似于impackets ntlmrelayx(中继工具),并且共享了相当一部分代码。Kerberos票据使用基于用户正在验证的服务的密码的密钥进行部分加密,因此将其发送到不同的服务是没有意义的,因为他们将无法解密票据,因此我们无法进行身份验证。那么这个工具到底是做什么的呢? 当Windows对启用了无约束委派的服务或计算机帐户进行身份验证时,会发生一些有趣的事情(稍后我会解释),这些帐户最终会有一个可用的TGT。如果我们(作为攻击者)是控制这个帐户的人,那么可以使用这个TGT对其他服务进行身份验证。Krbrelayx执行此操作的方式与使用ntlmrelayx进行中继时类似,即使用自动转储密码、获取DA权限或执行基于ACL的攻击,因此它们的命名也很类似。如果你想了解无约束委派是什么,我推荐你看一下Sean Metcalf 的博客。
攻击要求
要执行这种无约束的委派攻击,我们需要满足以下几个要求:
1.使用无约束的委派权限控制帐户;
2.修改该帐户的servicePrincipalName属性的权限(可选);
3添加/修改DNS记录的权限(可选);
4.一种连接受害者用户/计算机的方法。
无约束的委派帐户
首先,我们需要一个具有无约束委派权限的帐户。这意味着设置了TRUSTED_FOR_DELEGATION UserAccountControl标志的帐户,可以是用户帐户,也可以是计算机帐户。AD中的任何用户都可以使用PowerView来查询这些帐户:
$Computers = Get-DomainComputer -Unconstrained
$Users = Get-DomainUser -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"
或使用ActiveDirectory Powershell模块来查询这些帐户也行:
$computers = get-adcomputer -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"
$user = get-aduser -ldapfilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)"
或者可以使用我自己编写的工具ldapdomaindump提取它们,它将使用TRUSTED_FOR_DELEGATION标志报告具有此权限的用户/计算机:
grep TRUSTED_FOR_DELEGATION domain_computers.grep
grep TRUSTED_FOR_DELEGATION domain_users.grep
此时,我们已经获取了帐户密码或Kerberos密钥,就可以解密Kerberos服务票据了,这些票据是用户在对与受攻击帐户关联的服务进行身份验证时使用的。以前滥用无约束委派的方法包括使用Mimikatz或Rubeus等从LSASS转储缓存的票据,但这需要在已受攻击的主机上执行代码。在本文中,我不会这么做,而是通过完全控制的主机通过网络完成整个操作,这样就不必担心端点检测或通过转储进程破坏执行服务器。不过这不适用于Rubeus,因为它使用native API。
对于用户帐户,可以通过Kerberoast攻击(Kerberoast是一种可以作为普通用户从Active Directory中提取服务帐户凭证而不需要向目标系统发送任何数据包的有效方法),破解NTLMv1 / NTLMv2身份验证,简单地猜测弱密码或从受损主机上的内存中转储密码来获取密码。计算机帐户很难获取,因为它们默认情况下具有非常强大的随机生成密码,并且其密码/密钥仅驻留在帐户所属的主机或DC上。当我们在关联主机上拥有管理员权限时,它变得相对容易,因为计算机帐户密码存储在注册表中,因此可以通过网络使用secretsdump.py获取,或者通过使用mimikatz lsadump :: secrets转储密码,这两种方法都支持从离线注册表配置单元转储密码。
要从明文密码计算Kerberos密钥,还需要指定salt值。如果你熟悉Kerberos,就会知道使用了不同的加密算法。现代AD安装支持的最弱密码使用RC4,密钥基于用户的NTLM哈希(不包括任何salt值)。然而,Windows默认选择的AES-128和AES-256密码确实包含一个salt值,我们需要将其包含在密钥计算中。计算这些salt值的步骤如下:
1. 对于用户帐户,它是大写的Kerberos域名+区分大小写的用户名;
2. 对于计算机帐户,它是大写域名+主机名(the word host )+完整的小写主机名;
Kerberos域名是域的完全限定域名(FQDN)(因此不是NETBIOS名称!),完整主机名也是主机的FQDN,而不仅仅是计算机名称,并且不包含$。用作用户帐户salt值的用户名是区分大小写的SAMAccountName,因此,如果用户名为awEsOmEusER1,那么awEsOmEusER1将不会生成正确的密钥。
对于计算机帐户,我已经为secretsdump.py添加了一些功能,如果在主机上运行它,它将自动转储设备Kerberos密钥(至少需要impacket 0.9.18或运行git的最新开发版本)。如果由于某种原因无法计算出正确的salt值,你可以使用——krbpass或——krbhexpass(用于十六进制编码的二进制计算机帐户密码)和——krbsalt值参数将其指定为krbrelayx.py。附带说明一下,由于计算机帐户密码是UTF-16-LE中的随机二进制,但是Kerberos使用UTF-8输入进行密钥推导,所以实现起来比预期的时间要长得多。然而,UTF-16字节不是有效的Unicode,当你试图将其转换为UTF-8时,Python会不太给力。我花了一些时间才发现,在将Kerberos密钥执行转换为UTF-8时,Microsoft实现实际上已经悄悄地替换了所有无效的Unicode字符。
对无约束委派帐户的ServicePrincipalName属性的控制
在获取受攻击帐户的Kerberos密钥之后,就可以解密票据了,但是我们还没有讨论如何让主机使用Kerberos进行身份验证。当用户或计算机希望通过SMB在主机somehost.corp.com上使用Kerberos进行身份验证时,Windows将向域控制器发送一个服务票据请求。这个请求将包括服务主体名称(SPN),它由协议和服务所在的主机组成。在本文所举的例子中,这将是cifs/somehost.corp.com。域控制器在分配了这个ServicePrincipalName的帐户(如果有的话)的目录中执行查找,然后使用与该帐户关联的Kerberos密钥加密服务票据。

[1] [2] [3]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载