Kerberos中继进击:滥用无约束委派(上) | 申博官网
登录
  • 欢迎进入申博官网!
  • 如果您觉得申博官网对你有帮助,那么赶紧使用Ctrl+D 收藏申博官网并分享出去吧
  • 这里是申博官方网!
  • 申博官网是菲律宾sunbet官网品牌平台!
  • 申博开户专业品牌平台!

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

申博_新闻事件 申博 51次浏览 未收录 0个评论

域渗透——使用Exchange服务器中特定的ACL实现域提权

0x00 最近学到的一个域环境下的提权技巧,在域环境中,安装Exchange后会添加一个名为Microsoft Exchange Security Groups的OU,其中包括两个特殊的组:Exchange Trusted Subsystem和Exchange Windows Permission,如果获得了这两个组内任意用户的控制权限,就能够继承该组的WriteDACL权限,进而修改域对象的ACL,最终实现利用DCSync导出域内所有用户hash。接下

关于在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密钥加密效劳单子。

直击云栖大会|阿里云安全肖力:云原生安全构筑下一代企业安全架构

“数字经济的发展驱动越来越多的企业上云,每个企业都会基于云原生安全能力构筑下一代企业安全架构,完成从扁平到立体式架构的进化,届时云原生安全技术红利也将加速释放!”9月27日,阿里云智能安全事业部总经理肖力在2019杭州云栖大会·云安全峰会上指出。 肖力强调,云原生安全技术会默认植入在下一代企业安全架构的每个模块,从而升级整体安全水位。 阿里云

为了确保受害者运用无束缚委派对帐户举行身份考证,而且出于解密单子的须要,我们须要确保将其通讯流量发送到SPN与我们模仿的帐户相关联的主机名。假如我们具有主机名attacker.corp.com,而SPN没有注册到准确的帐户,则进击将不起作用。最简朴的要领是,假如我们掌握了一个帐户,该帐户具有编辑盘算机属性的权限,或许我们损坏的用户帐户,在这类状况下,我们能够运用krbrelayx中包括的addspn.py实用程序将SPN增加到该帐户。

[email protected]:~/adtools$ python addspn.py -u testsegment\\backupadmin -s host/testme.testsegment.local -t w10-outlook.testsegment.local ldap://s2016dc.testsegment.local
Password: 
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[+] Found modification target
[+] SPN Modified successfully

假如我们没有这些权限,状况会更庞杂一些,而且关于用户帐户,我还没有找到一种要领在不分派这些权限的状况下修正SPN。默许状况下,盘算机帐户能够经由过程“已考证的写入servicePrincipalName”增加它们本身的SPN,然则它们只能编写与它们的完全主机名或SAMAccountName婚配的SPN。这好像进入了一个死胡同,但有一种解决要领!另有一个经由考证的分外写入权限,许可盘算机更新本身的msDS-AdditionalDnsHostName属性,该属性在Server 2012中引入,并包括盘算机对象的其他主机名。依据这份申明,只需我们有Validated-MS-DS-Additional-DNS-Host-Name考证写入权限,这个经由考证的写入就许可增加任何具有我们地点域的FQDN的主机名作为后缀。此权限不是默许分派的:

然则,在运用此属性时,我发明更新msDS-AdditionalDnsHostName属性实际上不须要Validated-MS-DS-Additional-DNS-Host-Name考证的写入权限。默许状况下为盘算机对象启用的“考证写入DNS主机名”也许可我们写入msDS-AdditionalDnsHostName属性,并许可我们将当前域中的任何主机名分派给盘算机对象,然后自动增加SPN。经由过程这个要领,能够在我们的帐户中增加一个SPN,并指向受进击者掌握的主机名:

[email protected]:~/adtools$ python addspn.py -u testsegment\\w10-outlook\$ -p aad3b435b51404eeaad3b435b51404ee:7a99efdea0e03b94db2e54c85911af47 -s testme.testsegment.local s2016dc.testsegment.local
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[+] Found modification target
[+] SPN Modified successfully
[email protected]:~/adtools$ python addspn.py -u testsegment\\w10-outlook\$ -p aad3b435b51404eeaad3b435b51404ee:7a99efdea0e03b94db2e54c85911af47 s2016dc.testsegment.local -q
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[+] Found modification target
DN: CN=W10-OUTLOOK,CN=Computers,DC=testsegment,DC=local - STATUS: Read - READ TIME: 2018-11-18T20:44:33.730958
    dNSHostName: W10-OUTLOOK.testsegment.local
    msDS-AdditionalDnsHostName: TESTME$
                                testme.testsegment.local
    sAMAccountName: W10-OUTLOOK$
    servicePrincipalName: TERMSRV/TESTME
                          TERMSRV/testme.testsegment.local
                          WSMAN/TESTME
                          WSMAN/testme.testsegment.local

假如出于某种原因,我们不能将SPN修正为进击者掌握下的主机名,则能够经由过程修正DNS纪录或运用你最喜欢的诳骗进击或中间人进击挟制当前SPN,只管这将会损坏与主机的衔接,但我不发起在实行环境中如许做。

增加或修正DNS纪录的权限

在增加指向网络上未运用的主机名的新SPN以后,我们固然须要确保我们增加的主机名剖析为我们本身的IP。假如你地点的网络运用Active Directory集成DNS,这应当很简朴。正如Kevin Robertson在他关于ADIDNS的文中形貌的那样,默许状况下,只需没有主机名的纪录,任何经由身份考证的用户都能够建立新的DNS纪录。因而,在我们将attacker.corp.com的SPN增加到我们的无束缚委派帐户以后,我们能够为这个主机名增加一条纪录,该纪录指向我们的IP,比方PowerMad:

我还在krbrelayx repo中增加了一个东西,能够经由过程LDAP在AD中实行DNS修正(dnstool.py):

[email protected]:~/adtools$ python dnsparse.py -u icorp\\testuser icorp-dc.internal.corp -r attacker -a add -d 10.1.1.2 
Password: 
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully

以后,我们能够看到DNS中存在纪录:

[email protected]:~/adtools$ python dnsparse.py -u icorp\\testuser icorp-dc.internal.corp -r attacker -a query
Password: 
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[+] Found record attacker
DC=attacker,DC=internal.corp,CN=MicrosoftDNS,DC=DomainDnsZones,DC=internal,DC=corp
[+] Record entry:
 - Type: 1 (A) (Serial: 36)
 - Address: 10.1.1.2

DNS效劳器经由过程LDAP(默许状况下每180秒革新一次)革新纪录后,剖析纪录:

[email protected]:~/adtools$ nslookup attacker.internal.corp 192.168.111.2
Server:		192.168.111.2
Address:	192.168.111.2#53

Name:	attacker.internal.corp
Address: 10.1.1.2

dnstool.py实用程序另有其他几个选项,包括一个在开辟后再次删除纪录的选项,在本文中我不会细致议论这个选项,然则你能够在GitHub上猎取该东西。假如修正DNS不起作用,或许你地点的网络不运用AD举行DNS,则一直能够实行网络进击来接受DNS效劳器,但这一般要求你与体系位于统一VLAN中。一种一直有用的要领是修正受感染盘算机本身的DNS纪录,但这能够须要一段时候才经由过程DNS缓存举行流传。

猎取通讯流量

如今有许多要领能够猎取从用户到进击者主机的通讯流量。在互联网上议论NTLM身份考证网络手艺的任何手艺都能够让用户对歹意SMB或HTTP效劳器举行身份考证。比方:

1. 带有UNC途径或重定向的垂纶网站;

2. 运用responder, Inveigh或metasploit来复兴LLMNR/NBNS要求;

3. 运用mitm6举行DNS挟制;

4. 将带有链接到UNC途径的图标的文件放在网络中盛行的文件同享上;

……

在撰写本文时,经由过程无束缚委派猎取域管理权限异常有用,就是滥用仅须要通例用户凭证的破绽,以便找到高代价目的。比方以下的连个例子:

1.SpoolService 破绽: MS-RPRN协定中有一个长途历程挪用部份,能够致使长途盘算机经由过程SMB向恣意主机举行身份考证,这是由Lee Christensen别名@tifkin发明的并称之为“打印机破绽”。Harmj0y近来在他的博客中写了一篇关于滥用这个破绽以及对丛林信托举行无束缚委派进击的文章。MS-RPRN协定也由@agsolino在impacket中完成的,固然,我为它编写了一个小实用程序,作为krbrelayx东西包的一部份,名为printerbug.py,它会触发反向衔接。

2.PrivExchange:Exchange Web Services (EWS) SOAP API公开了定阅推送关照的要领,任何具有邮箱的用户都能够挪用此要领,并将Exchange衔接到我们经由过程HTTP指定的任何主机。当要求时,Exchange将(除非它运用最新的CU修补) 运用正在运转的体系的盘算机帐户举行身份考证。默许状况下,此盘算机帐户在域中具有高权限。我在之前的一篇文章和privexchange.py东西中都提到了这一点。除了NTLM将此身份考证中继到LDAP以外,我们还能够运用无束缚委派来猎取Exchange的TGT,并运用它来实行基于ACL的权限晋级。

这篇文章,我只讲了中继进击的基本理论,下一篇文章,我会举两个示例来及详细申明。

本文翻译自:https://dirkjanm.io/krbrelayx-unconstrained-delegation-abuse-toolkit/


申博|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明Kerberos中继进击:滥用无约束委派(上)
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址