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相关安全问题

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加密，通过AD用户和计算机管理设置liukaifeng01用户启用AES加密
   LDAP查看msDS-SupportedEncryptionTypes属性
   
   这时候再进行Kerberoast时，返回的票据加密类型为AES256
   
   抓包查看TGS_REQ，可以看到客户端向服务端提供了支持的加密算法，包括RC4和AES加密
   
   通过查看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