关于在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进行身份验证。当用户或核算机期望经过 *** B在主机somehost.corp.com上运用Kerberos进行身份验证时，Windows将向域操控器发送一个服务收据恳求。这个恳求将包含服务主体称号(SPN)，它由协议和服务地点的主机组成。在本文所举的比如中，这将是cifs/somehost.corp.com。域操控器在分配了这个ServicePrincipalName的帐户(假如有的话)的目录中履行查找，然后运用与该帐户相关的Kerberos密钥加密服务收据。[1][2][3]黑客接单网