关于Kerberos认证的一些攻击手法学习总结

Kerberos认证流程

前言

本文主要分享最近学习的关于域内Kerberos认证的一些攻击手法,以自我的理解为主,从原理理解切入到基本工具利用来阐述,个人的理解分析较为啰嗦,嫌太兀长的可以跳着看就好,还请各位谅解。如有错误,请师傅们提出更正
对于Kerberos认证流程只是简单的描述带过,下面有很多细节没有说明,比如PAC,S4U2SELF(委派),S4U2PROXY(委派)等。详细的解读推荐翻阅daiker师傅写的相关文章
本文主要环境利用的是红日靶场VulnStack

  • 域控 owa win2008R2 192.168.52.138
  • 域主机 sut1 win7 192.168.52.130
  • 域外主机 k0uaz win7(可访问到域控) 192.168.52.162主要涉及主体和角色
  • Domain Controller 域控制器,简称DC,一台计算机,实现用户、计算机的统一管理
  • Key Distribution Center 秘钥分发中心,简称KDC,默认安装在域控里,包括AS和TGS
  • Authentication Service 身份验证服务,简称AS,用于KDC对Client认证
  • Ticket Grantng Service 票据授予服务,简称TGS,用于KDC向Client和Server分发Session Key(临时秘钥)
  • Active Directory 活动目录,简称AD,用于存储用户、用户组、域相关的信息。
  • Client 客户端,指用户。
  • Server 服务端,可能是某台计算机账户,也可能是某个服务。

过程和原理


上图中涉及到了三个请求返回过程:Client与KDC的AS,Client与KDC的TGS,Client与Server,详细的请求响应如下

  1. AS-REQ:Client向KDC(AS)发起一个认证请求,请求的凭据是Client的NTLM Hash加密的时间戳以及身份信息等
  2. AS-REP:AS使用Client NTLM HASH进行解密,若检验正确则返回用KRBTGT HASH加密的TGT票据(再TGS-REQ中发送到TGS并用于换取ST),TGT里面包含PAC
  3. TGS-REQ:Client获得TGT缓存在本地(不能解密),可用来向TGS换取访问相应服务的ST票据
  4. TGS-REP:TGS使用KRBTGT HASH解密TGT,若结果正确,返回用提供服务的服务器的Server Hash(机器用户HASH)加密的ST(server ticket)
  5. AP_REQ:Client拿着获得的ST去服务器请求资源
  6. AP_REP:Server使用自己的Hash解密ST,若解密正确,则拿着获取的PAC去访问KDC判断Client是否有权限访问。KDC解密PAC后获取用户sid以及所在组的信息,并根据访问控制表(ACL)判断权限。若符合,Server返回资源给Client

Kerberos相关安全问题

图片来自dariker师傅的文章

Pass The Key(Hash)

Pass the Hash

Pass the Hash适用于NTLM认证也适用于Kerberos认证,不仅在域外,域内也可以使用。Kerberos认证中AS-REQ通过Client Hash加密相关信息发送给AS,因此如果我们获取到了Client的NTLM Hash,我们可以通过Pass The Hash横向获取其他主机的权限。

利用

这里我们假设获得了在某台域机器上登录的域管NTLM HASH

以下适用于PTH的工具

  1. 使用Mimikatz,由于需要注入凭据到lsass中,因此需要本地管理员权限(bypassuac)去开启Sedebug,注入后可以使用该用户凭据访问域内主机
  2. 使用wmicexec(py或者exe都有)去pth,不需要管理员权限,适用于直接远程执行命令
  3. 使用cme去批量验证pth
  4. 等等

这里以Mimikatz举例,hack用户(stu1的本地管理员组内成员,域用户)

没有权限访问域控共享目录

mimikatz注入凭据后
mimikatz "privilege::debug" "sekurlsa::pth /user:a /domain:god.org/rc4:b4ab235f987be3621a4ebd862189fd34"

Pass the Key

mimikatz资料提示

ntlm hash is mandatory on XP/2003/Vista/2008 and before 7/2008r2/8/2012 kb2871997 (AES not available or replaceable) ; AES keys can be replaced only on 8.1/2012r2 or 7/2008r2/8/2012 with kb2871997, in this case you can avoid ntlm hash.

Pass the Key只能在域中使用,支持Aes加密方式的版本有win8.1/2012r2或者是安装了kb2871997补丁的win7/2008r2/8/2012

利用

获取aes key

然后同样使用sekurlsa::pth模块
mimikatz "privilege::debug" "sekurlsa::pth /user:administrator /domain:god.org /aes256:bf723755bc5f72a377bda41ca58fd925df7ee45df9a026ac5cd320102a3a2e33"

由于Win7主机没有打补丁,自然Pass The Key失败。在实战环境中,当不支持rc4加密方式的PTH的时候,可能是在Protected Users组中,这时可以尝试Aes128,Aes256加密方式来PTK

Pass The Hash With Remote Desktop(Restricted Admin mode)

2014年,Microsoft发布了KB2871997补丁,它主要囊括了Windows 8.1和Windows Server 2012 R2中增强的安全保护机制。所以,以往的例如:Windows 7,Windows 8,Windows Server 2008R2和Windows Server 2012也可以更新该补丁后获得上述安全保护机制。
————————————————————————————————————————————————
Restricted Admin RDP模式的远程桌面客户端支持:
在此更新之前,RDP登录是一种交互式登录,只有在用户提供用户名和密码之后才可以访问。以这种方式登录到RDP主机时,会将用户凭据放置在RDP主机的内存中,如果主机受到威胁,它们可能会被窃取。此更新使RDP支持网络登录,其中可以传递用户现有登录令牌以进行RDP访问的身份验证。使用此登录类型可确保RDP服务器上不存储用户的凭据。从而保护凭据

通过上述解释可以理解该模式是为了保护使用RDP登录的用户凭据,通过网络验证的登录方式,RDP服务端不会保存用户的凭据

利用

win8.1以及win2012R2以上支持Restricted Admin mode模式,win8.1以及win2012R2默认开启Restricted Admin mode
条件:Client支持Restricted Admin mode模式,Server启用Restricted Admin mode模式
由于手头缺少win2012R2,因此这里使用两台Windows10来进行Pass The Hash With Remote Desktop
首先获取NTLM HASH

利用mimikatz注入NTLM HASH(需先privilege::debug开启debug权限,这里截图截少了)
sekurlsa::pth /user:administrator /domain:192.168.226.137 /ntlm:9c3767903480e04c089090d27123eaf9 "/run:mstsc.exe /restrictedadmin"
/domain指定计算机名或者ip
这里不要选择始终要求凭据

凭据正确但是没有开启Restricted Admin mode

通过注册表开启(0为开启,1为关闭,需要完整管理员权限),然后再次进行RDP连接
REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f

远程主机开启Restricted Admin mode后,RDP连接成功

可以看到注入到内存中的Hash

然后这里我又使用了管理员账户K0uaz,因此该Pass The Hash With Remote Desktop只需要目标的本地管理员权限即可,不一定是sid为500的本地administrator账户

但是如果只是加入Remote Desktop Users,不在Administratros组内,是无法成功的,因为该机制就是针对受限的管理员的

AS-REP Roasting

原理

在AS_REP中,KDC会返回一个有用户NTLM Hash加密的Session Key(该Sesions Key用于确保客户端和TGS之间的通信安全)

在RC4_HMAC加密方式下,我们可以通过穷举明文口令,利用相同加密流程加密明文口令,然后将加密结果对比密文是否相同来判断爆破结果
上图中返回的用户NTLM Hash加密的Session Key密文虽然是通过AES256加密的,但是这里我们同样可以使用加密降级方式(下文中Kerberoast突破用户支持AES加密转而返回RC4_HMAC类型的加密数据使用的方法)指定客户端最高支持加密方式仅为RC4_HMAC,使AS_REP中返回的密文的加密方式为RC4_HMAC,这样我们就可以破解该明文口令了
但是这里需要解决一个问题就是预认证的问题,在AS_REQ中会生成一个有Client Hash加密的Timestamp发送到KDC,KDC通过解密该密文获得时间戳,如果解密成功并且时间戳在5分钟之内,则预认证成功,KDC通过该方式来检验客户端身份,以此有效防止暴力破解


至于为什么默认情况下会发送两次AS_REQ,从harmj0y的文章中得到的解释是由于客户端提前并不知道支持的加密方式(这里我认为是具体到客户端不知道预认证中Timestamp的加密方式),因此请求获取KDC支持的加密方式


因此关闭预认证,我们就可以进行穷举爆破破解出明文口令

关闭预认证后不再有二次的AS_REQ,唯一一次的AS_REQ也不会带有NTLM Hash加密Timestamp的密文

利用

可以通过LDAP查询具有Do not require Kerberos preauthentication属性的域用户
具体的查询条件为userAccountControl:1.2.840.113556.1.4.803:=4194304
这里以Rubeus举例
Rubeus.exe asreproast /nowrap /format:hashcat

hashcat解密
hashcat -m 18200 hash.txt passwords.dict --force

Rubeus asreproast原理分析

通过Wireshark分析流量可以看出该模块原理就是通过LADP查询该属性特征的域用户,然后批量发送AS_REQ请求包,提取返回包中的NTLM Hash加密部分进行格式化输出适合于Hashcat爆破的形式
ldap查询:

指定支持加密类型仅为RC4_HMAC

返回的密文使用RC4_HMAC加密(因此可进行穷举爆破)

黄金票据

特点

  1. 需要与DC通信(不需要与AS进行交互,需要与TGS)
  2. 需要krbtgt用户的hash

原理

在 Windows 的kerberos认证过程中,Client将自己的信息发送给 KDC,然后 KDC 使用 Krbtgt 用户的 NTLM-Hash 作为密钥进行加密,生成 TGT。那么如果获取到了 Krbtgt 的 NTLM-Hash 值,不就可以伪造任意的TGT了吗。因为Krbtgt只有域控制器上面才有,所以使用黄金凭据意味着你之前拿到过域控制器的权限,黄金凭据可以理解为一个后门。

条件

1、域名称
2、域的SID值
3、域的KRBTGT账户密码HASH
4、伪造用户名,可以是任意的(TGT使用期限20分钟之内,域控制器KDC服务不会验证TGT中的用户账户)

当我们获取到krbtgt的Hash的时候,我们就可以用来制作黄金票据
假设我们已经通过dcsync的攻击手法(下文中有解释和实践)获取到了krbtgt的hash

条件1:spn扫描获取域名称god.org

条件2:whoami /all获取域用户sid,域的SID去掉最后的一串

条件3:krbtgt账户Hash
58e91a5ac358d86513ab224312314061
条件4:伪造用户名
administrator

制作黄金票据

利用mimikatz kerberos::golden伪造tgt

黄金票默认组:
域用户SID:S-1-5-21 <DOMAINID> -513
域管理员SID:S-1-5-21 <DOMAINID> -512
架构管理员SID:S-1-5-21 <DOMAINID> -518
企业管理员SID:S-1-5-21 <DOMAINID> -519(只有在森林根域中创建伪造票证时才有效,但为AD森林管理员权限添加使用/sids参数)
组策略创建者所有者SID:S-1-5-21 <DOMAINID> -520

mimikatz.exe "kerberos::golden /domain:god.org /sid:S-1-5-21-2952760202-1353902439-2381784089 /user:administrator /krbtgt:58e91a5ac358d86513ab224312314061 /ticket:k0u.kiribi" exit
tip:可添加/endin:xx /renewmax:xx修改票据的有效期以及续订票据最长有效期,mimikatz默认都是10年

生成的票据可以到其他域机器上导入,也可以直接使用/ptt将tgt注入内存
首先先清空票据缓存klist purge

然后通过mimikatzkerberos::ptt k0u.kiribi注入到缓存票据中

klist查看票据缓存可以看到伪造的tgt了

这时就获取到了非常高的权限了

klist purge清空票据缓存后

Tips:
普通黄金票据存在局限性,适用于单域内,不适于域森林中

Pass The Ticket

Kerberos除了第一步需要Client端的用户NTLM Hash加密验证,后续的操作都是通过票据(Ticket)来验证,因此我们如果拿到了票据或者伪造了票据,我们就可以通过该票据来横向移动,黄金票据和白银票据以及MS14068的利用都可以算做是Pass The Ticket的一种攻击方式

利用

Mimikatz

通过Mimikatz导出内存中的票据

(管理员权限开SeDebug)Mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

这时,我们抓到了域管的TGT,我们就可以注入域管的TGT到缓存并且使用该TGT来向TGS换取相应的服务凭证ST
(不需要管理员权限)此时以god.org\hack域用户(Stu1本地管理员权限)访问域控的Cifs共享服务是提示没有权限被拒绝的,这里注入域管的TGT到缓存后可成功访问

Rubeus

Rubeus,利用C#实现Kekeo中的部分函数攻击手法等,该工具主要是针对Kerberos的一些攻击方式集成化的利用工具
导出内存中的票据
(管理员权限)Rubeus.exe dump >test.txt

箭头指向的就是base64编码后的.kirbi
可以直接通过Rubeus导出base64编码形式的凭据或者转化为文件形式,文件形式可以和MimikatzKerberos::ptt xxx.kirbi导入票据互相通用
Rubeus.exe ptt /ticket:base64(需要处理下导出的base64编码格式,删除多个空格,删除换行,可以通过添加/nowrap参数不换行)


导入后可以通过Rubeus.exe klist查看缓存的票据

以域管的高权限票据可访问域控共享服务

也可以使用/ticket:file.kirbi的形式
可以通过Powershell调用.net类库的system.io命名空间中的file类中WriteAllBytes方法将base64编码解码后写入文件中
[IO.File]::WriteAllBytes("Adcontrol.kirbi", [Convert]::FromBase64String("处理后的凭据Base64编码"))

导入Rubeus ptt /ticket:file.kirbi

Tips:
票据文件注入内存的默认有效时间为10小时
Klist Purge清除缓存后注入的TGT也随着被清除

Kerberoasting

原理

在kerberos认证流程中的TGS_REP中返回的是Server Hash(Ticket)以及Session Key(Server Session Key),其中最为重要的是通过服务的NTLM Hash为密钥加密生成的ST票据。当认证加密算法为RC4_HMAC(弱加密类型)时,我们可以通过穷举口令,利用相同的加密过程获得密文,将获得的密文与ST票据中的密文比较,若相同,则说明口令正确,成功爆破获得服务凭据的明文
Tip:服务票据会使用服务账户的哈希进行加密,在Windows中使用服务主体名称(SPN)来确定使用哪个服务帐户的哈希来加密服务票证

(服务主体名称)SPN

服务主体名称(SPN:ServicePrincipal Names)是服务实例,Kerberos 身份验证使用 SPN 将服务实例与服务登录帐户相关联
SPN的格式为:serviceclass/host:port/servicename

SPN是域内一个服务的唯一标示名称,SPN类型分为两种:

  1. 一种注册在AD上机器帐户(Computers)下,当一个服务的权限为Local System或Network Service,则SPN注册在机器帐户(Computers)下,比如SMB或者远程注册表服务
  2. 另一种注册在域用户帐户(Users)下,当一个服务的权限为一个域用户,则SPN注册在域用户帐户(Users)下,此时访问某个服务,返回的ST票据中加密的服务票据就是服务账户的票据即SPN与服务所对应相关联的账户的凭据

    Tips:
    Setspn -Q */*查询所有的SPN
    可以通过LADP将域用户属性servicePrincipalName设置为目标SPN
    可以通过LDAP来快速检索哪些域用户拥有servicePrincipalName属性来找到寻找爆破目标(低权限即可)

    实现要点

    寻找有价值的SPN : 寻找基于域账户的(最好是高权限)SPN,基于主机的SPN密码复杂随机且30天自动更换一次,因此难以破解
    获得RC4_HMAC加密形式的ST票据 : 支持RC4_HMAC或启用AES认证加密但是未禁用RC4_HMAC

    利用

    首先为域用户liukaifeng01关联一个SPN

    老方法

    用到的工具为kerberoast
    首先通过遍历SPN(筛选有价值的SPN),然后对获得的所有SPN发起TGS请求获取ST票据缓存到本地(Mimikatz中的kerberos::ask可实现发起单个TGS请求),再通过Mimikatz等工具导出ST凭据,然后通过爆破脚本tgsrepcrack.py尝试爆破出明文口令

    新方法

    用到的工具为Invoke-kerberoast
    较新的方式是一步到位,(首先通过LDAP查询带有ServicePrincipalName属性的域用户)不需要发送TGS请求后通过Mimikatz导出ST凭据了,通过微软提供的类KerberosRequestorSecurityToken直接发起TGS请求,然后再返回的内容中提取加密的ST票据进行格式化,方便使用John和Hashcat来破解
    这里举例使用的工具是Rubeus,该工具同样实现了Invoke-kerberoast的功能
    Rubeus kerberoast(普通域用户权限即可)

    如果复制粘贴不方便,可以使用/outfile:path指定Hash参数的写入路径

    Rubeus返回的Hash参数对应的值就是hashcat官方指定的RC4_HMAC加密方式破解的格式

    kali中使用hashcat爆破
    hashcat -m 13100 hash.txt passwords.dict --force

    加密降级突破AES加密类型

    首先设置用户启用AES加密,通过AD用户和计算机管理设置liukaifeng01用户启用AES加密
    LDAP查看msDS-SupportedEncryptionTypes属性

    这时候再进行Kerberoast时,返回的票据加密类型为AES256

    抓包查看TGS_REQ,可以看到客户端向服务端提供了支持的加密算法,包括RC4AES加密

    通过查看TGS_REP可以发现返回的ST票据中使用的算法是最高支持的加密类型=>AES256

    那这里就可以提出一个猜想,如果我们在TGS_REQ中提供最高的支持的加密算法是RC4,呢么TGS_REP中返回的加密方式是否也会是RC4
    在Rubeus中已经实现了该方法,并且确实有效
    Rubeus kerberoast /tgtdeleg

    TGS_REQ请求包中支持的加密算法仅为RC4

    虽然域用户liukaifeng01支持的加密方式是AES,但是得到的是一个RC4加密的票据,这样获得的票据仍然是可以破解的
    解决加密降级的办法只有在组策略中的安全策略Kerberos验证中彻底禁用RC4

    白银票据

    特点
  3. 不需要与域控(KDC)交互
  4. 需要目标服务的NTLM Hash(获取Server Hash伪造TGT)

原理

来自倾旋师傅的图
在第三步认证中的Ticket的组成:
Ticket=Server Hash(Server Session Key+Client info+End Time)
如果我们有了Server Hash的话,我们就可以伪造ST,服务器在没有收到ST之前是不知道Server Sessoin Key的,所以这一切的认证最重要的就是Server Hash,有了Server Hash我们就可以伪造ST来访问指定的服务。这里的Server Hash指的就是机器用户的Hash,机器用户其实就是System用户

条件

1、域名称
2、域的SID值(SID值,注意是去掉最后一个-后面的值)
3、域中的Server服务器账户的NTLM-Hash
4、伪造的用户名,可以是任意用户名.
5、目标服务器上面的kerberos服务

制作白银票据

这里还是以域控owa举例,通过mimikatz获取机器账户的Hash

获取hash后,通过mimikatz制作白银票据(部分条件上述黄金票据实践中已经获得),目的服务是cifs
正常情况是普通域用户hack没有权限访问:

通过mimikatz制作白银票据并直接导入

查看当前票据

成功访问共享目录

但是这里与正常的加密类型是不同的,Mimikatz的伪造是RC4的加密类型,而正常的SPN关联在机器账户下的一般都是AES加密,因此对于伪造访问服务CIFS的ST票据而言,白银票据的流量也比较容易识别

常见的伪造服务类型如下

Tips:
开启PAC验证可防御白银票据(Server发送PAC的数字签名给KDC校验)

用户名枚举和口令暴力破解

三种情况

存在用户

存在用户描述:error_code:eRR-PREAUTH-REQUIRED
密码错误描述:error_code:eRR-PREAUTH-FAILED

不存在的用户

描述:error_code:eRR-C-PRINCIPALL-UNKNOWN

kerbrute

使用场景

不在域内的情况下且无法通过LDAP或者SAMR协议去获取域内用户(如果掌握域内用户名以及密码,域外也可通过LDAP与域控交互获取信息)
若攻击主机在域外,需要主机能与域控直接交互
不会有像LDAP暴力破解产生的日志(4625 - An account failed to log on)

主要原理

发送构造的AE-REQ请求包后,通过返回的包的区别来判断用户是否存在以及密码是否正确

用户名枚举

域内
kerbrute_windows_amd64.exe userenum -d god.org username.txt

域外
kerbrute_windows_amd64.exe userenum --dc 192.168.52.138 -d god.org username.txt
需指定Dc的ip地址

密码喷洒

指定密码,遍历用户名
kerbrute_windows_amd64.exe passwordspray -d god.org username.txt Abc123!
第一个包发送用户名
DC返回用户名正确后发送第二个AS-REQ,其中包含了密码的NTLM HASH

pyKerbrute

3gstudent师傅实现的Python版本的kerbrute,添加了两个功能
◼增加对TCP协议的支持
◼增加对NTLM hash的验证

用户名枚举

EnumADUser.py主要实现的就是发一个As-REQ结构的包修改CnameString即可(固定sname指向krbtgt)

EnumADUser.py : EnumADUser.py 192.168.52.138 god.org user.txt tcp

与kerbrute发送的数据包稍有区别

密码喷洒

首先pyKerbrute分成了两种模式,clearpassword和ntlmhash
classpassword:实现了将明文加密成NTLM Hash然后通过RC4-HMAC加密算法加密时间戳,然后也可以通过ntlmhash模块来密码喷洒
ntlmhash:直接通过RC4-HMAC-MD5加密算法加密时间戳

ADPwdSpray.py : ADPwdSpray.py 192.168.52.138 god.org username.txt clearpassword Abc123! udp

与kerbrute发送的数据包在支持的加密算法上有较大区别,不如kerbrute隐秘

pyKerbrute这里就发送了一个包,没有发送判断用户名是否存在,直接请求认证,且加密算法指定了RC4-HMAC-MD5,kerbrute支持多种加密方法
稍微看了下Kerbrute的代码,发现实现的方法NewWithPassword来自gokrb5这个库,该库便利了用于客户端与服务端的Kerberos相关认证,而且库中实现了众多的加密算法

Kerberos pre-auth bruteforcing的检测

Kerbrute使用Kerberos pre-auth协议,不会产生日志(4625 - An account failed to log on)
但是会产生以下日志:
◼口令验证成功时产生日志(4768 - A Kerberos authentication ticket (TGT) was requested)
◼口令验证失败时产生日志(4771 - Kerberos pre-authentication failed)

我自己本地域控查看日志发现,存在4768,但是用户正确,密码错误并不会爆出4771,没有任何提示

成功

失败

解决

通过查阅资料,找到了修改登录策略的地方,具体可查看Audit Kerberos Authentication Service

修改审核策略后可捕获到4771类型:


Dcsync攻击

DCSync攻击原理

利用目录复制服务远程协议(DRSR)协议从域控制器获取敏感信息
将当前主机伪装成域控制器(DC),并通过发出请求说服真实的DC将其数据库与该主机伪装的恶意DC同步

利用条件

需要具备如下扩展权限对应的DACL

根据3gstudent师傅的文章总结如下的组内用户具有上述权限
◼Administrators组内的用户
◼Domain Admins组内的用户
◼Enterprise Admins组内的用户
◼域控制器的计算机帐户

实践

这里指的Administrator组内的用户不是指域机器上的本地Administrators,而是域控制器上的本地Administrators组。这里以红日靶场一举Administrators组内用户的例子
比如likaifeng01这个用户,通过域控查看工具,或者终端DOS命令查看liukaifeng01所在的组

该用户是域控本地管理员组成员,但不是域管成员
通过Powerview的Get-DomainObjectAcl来获取该成员的ACL控制列表查看上述三项权限

  1. DS-Replication-Get-Changes-In-Filtered-Set
  2. DS-Replication-Get-Changes
  3. DS-Replication-Get-Changes-All

满足上述三项权限,通过mimikatz的dcsync功能来导出Hash

也可以通过PowerView来直接为普通域用户一次性加上上述的三条特权,就可以具有执行Dcsync攻击的权限了,可以作为一种权限维持的方法
首先添加一个普通域用户hack,利用hack直接Dcsync会失败

以管理员权限通过PowerView给域用户hack加上三个扩展特权
Add-DomainObjectAcl -TargetIdentity "DC=god,DC=org" -PrincipalIdentity hack -Rights DCSync -Verbose
然后通过ADfind.exe或者Get-DomainObjectAcl查看用户拥有的特权
AdFind.exe -sc getacls -sddlfilter ;;;;;god\hack -recmute

Get-ObjectAcl -Identity "dc=god,dc=org" -ResolveGUIDs | ? {$_.SecurityIdentifier -match "S-1-5-21-2952760202-1353902439-2381784089-1111"}

图截不全,上面已经证明hack用户有这三个权限后,再次通过mimikatz来调用dcsync模块,可获取全部的Hash

然后删除该用户的三个扩展特权可以用如下命令
Remove-DomainObjectAcl -TargetIdentity "DC=god,DC=org" -PrincipalIdentity hack -Rights DCSync -Verbose
删除后再次使用Dcsync模块,已不能获取

Tips
Dcsync攻击可以作为权限维持的方式=>拿到高权限后可以通过Powerview中的Add-DomainObjectAcl给普通用户添加上述三个特权,使普通用户仍然可以通过Dcsync获取所有Hash

工具地址

kerbrute
pyKerbrute
Rubeus
kerberoast
Invoke-Kerberoast

学习参考链接

上文学习总结自3gstudent文章,倾旋博客,unknowsec博客,car7n博客,Muxueo博客,harmj0y博客,安全客等等
当时看的有点太杂了,整理完笔记后发现很多粗看的文章都没记下来文章链接
渗透技巧——通过Kerberos pre-auth进行用户枚举和口令爆破
Kerberos的黄金票据详解
Kerberos的白银票据详解
彻底理解Windows认证 – 议题解读
手把手教你入门内网渗透之二
Kerberos
Pass the Hash with Remote Desktop(Restricted Admin mode)
【技术分享】Kerberoasting:一种Kerberos活动目录攻击方法
域渗透——Kerberoasting
高级域渗透技术之再谈Kerberoast攻击
Roasting AS-REPs

关于PAC

对于PAC有疑惑的可以看下面的下四篇文章
Windows内网协议学习Kerberos篇之PAC
了解 Microsoft Kerberos PAC 验证
PAC在Kerberos认证协议中的作用
什么是 Kerberos PAC

posted @ 2023-05-09 10:05  渗透测试中心  阅读(629)  评论(0编辑  收藏  举报