Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86377714

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

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 服务端,可能是某台计算机账户,也可能是某个服务。

过程和原理

qjzuucb3jys13813.png
上图中涉及到了三个请求返回过程: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
1hz3cw1z5cu13816.png
以下适用于PTH的工具

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

这里以Mimikatz举例,hack用户(stu1的本地管理员组内成员,域用户)
vom5uw5kd5z13817.png
没有权限访问域控共享目录
korcc1sljlt13818.png
mimikatz注入凭据后
mimikatz "privilege::debug" "sekurlsa::pth /user:a /domain:god.org/rc4:b4ab235f987be3621a4ebd862189fd34"
vyfnmalsy3n13819.png

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
i1x1j332ipy13820.png
然后同样使用sekurlsa::pth模块
mimikatz "privilege::debug" "sekurlsa::pth /user:administrator /domain:god.org /aes256:bf723755bc5f72a377bda41ca58fd925df7ee45df9a026ac5cd320102a3a2e33"
xu5ld0glpuc13821.png
由于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
j0d1i44veti13823.png
利用mimikatz注入NTLM HASH(需先privilege::debug开启debug权限,这里截图截少了)
sekurlsa::pth /user:administrator /domain:192.168.226.137 /ntlm:9c3767903480e04c089090d27123eaf9 "/run:mstsc.exe /restrictedadmin"
/domain指定计算机名或者ip
这里不要选择始终要求凭据
4xf2qx0iy2t13825.png
凭据正确但是没有开启Restricted Admin mode
20omrwbdom213826.png
通过注册表开启(0为开启,1为关闭,需要完整管理员权限),然后再次进行RDP连接
REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f
ixlbkp5gsrs13834.png
远程主机开启Restricted Admin mode后,RDP连接成功
jtayvcyuq3h13835.png
可以看到注入到内存中的Hash
l4ams1svpdq13836.png
然后这里我又使用了管理员账户K0uaz,因此该Pass The Hash With Remote Desktop只需要目标的本地管理员权限即可,不一定是sid为500的本地administrator账户
cn2jrqzoobk13841.png
但是如果只是加入Remote Desktop Users,不在Administratros组内,是无法成功的,因为该机制就是针对受限的管理员的

AS-REP Roasting

原理

在AS_REP中,KDC会返回一个有用户NTLM Hash加密的Session Key(该Sesions Key用于确保客户端和TGS之间的通信安全)
p5fh4jrv3gv13842.png
在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通过该方式来检验客户端身份,以此有效防止暴力破解
x3xaplcvruc13845.png
dpfz1kc0maj13849.png
至于为什么默认情况下会发送两次AS_REQ,从harmj0y的文章中得到的解释是由于客户端提前并不知道支持的加密方式(这里我认为是具体到客户端不知道预认证中Timestamp的加密方式),因此请求获取KDC支持的加密方式
ivaizgnzvcc13855.png
cxq10vfdpyp13859.png
因此关闭预认证,我们就可以进行穷举爆破破解出明文口令
fzcnoh3thtj13862.png
关闭预认证后不再有二次的AS_REQ,唯一一次的AS_REQ也不会带有NTLM Hash加密Timestamp的密文
m5pxa1qwvr513864.png

利用

可以通过LDAP查询具有Do not require Kerberos preauthentication属性的域用户
具体的查询条件为userAccountControl:1.2.840.113556.1.4.803:=4194304
这里以Rubeus举例
Rubeus.exe asreproast /nowrap /format:hashcat
5zlwbwhjhkt13866.png
hashcat解密
hashcat -m 18200 hash.txt passwords.dict --force
gksh4cetjar13869.png

Rubeus asreproast原理分析

通过Wireshark分析流量可以看出该模块原理就是通过LADP查询该属性特征的域用户,然后批量发送AS_REQ请求包,提取返回包中的NTLM Hash加密部分进行格式化输出适合于Hashcat爆破的形式
ldap查询:
crcpm3g0doa13872.png
指定支持加密类型仅为RC4_HMAC
uip4acgxpk113874.png
返回的密文使用RC4_HMAC加密(因此可进行穷举爆破)
ylsjbz0isus13876.png

黄金票据

特点

  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
hfx0hoemioy13877.png
条件1:spn扫描获取域名称god.org
ncdjyffitmx13880.png
条件2:whoami /all获取域用户sid,域的SID去掉最后的一串
zemeunnyyfn13882.png
条件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年
pyn03keb1n413883.png
生成的票据可以到其他域机器上导入,也可以直接使用/ptt将tgt注入内存
首先先清空票据缓存klist purge
4wmv0mp1cfe13884.png
然后通过mimikatzkerberos::ptt k0u.kiribi注入到缓存票据中
zw0fohj4mhx13885.png
klist查看票据缓存可以看到伪造的tgt了
hg1zzuaeear13889.png
这时就获取到了非常高的权限了
n1001eocbwp13891.png
klist purge清空票据缓存后
pupg3ylbpiv13893.png

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

Pass The Ticket

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

利用

Mimikatz

通过Mimikatz导出内存中的票据
w52tmfhasqz13895.png
(管理员权限开SeDebug)Mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit
fi4ajz4nww413898.png
这时,我们抓到了域管的TGT,我们就可以注入域管的TGT到缓存并且使用该TGT来向TGS换取相应的服务凭证ST
(不需要管理员权限)此时以god.org\hack域用户(Stu1本地管理员权限)访问域控的Cifs共享服务是提示没有权限被拒绝的,这里注入域管的TGT到缓存后可成功访问
00nano5hhkm13904.png

Rubeus

Rubeus,利用C#实现Kekeo中的部分函数攻击手法等,该工具主要是针对Kerberos的一些攻击方式集成化的利用工具
导出内存中的票据
(管理员权限)Rubeus.exe dump >test.txt
sir5hwtwlkg13907.png
箭头指向的就是base64编码后的.kirbi
可以直接通过Rubeus导出base64编码形式的凭据或者转化为文件形式,文件形式可以和MimikatzKerberos::ptt xxx.kirbi导入票据互相通用
Rubeus.exe ptt /ticket:base64(需要处理下导出的base64编码格式,删除多个空格,删除换行,可以通过添加/nowrap参数不换行)
yqjdbal51lp13908.png
c2j4rfslbuh13913.png
导入后可以通过Rubeus.exe klist查看缓存的票据
ly5jk4czdic13927.png
以域管的高权限票据可访问域控共享服务
zuvv35bwv1n13932.png
也可以使用/ticket:file.kirbi的形式
可以通过Powershell调用.net类库的system.io命名空间中的file类中WriteAllBytes方法将base64编码解码后写入文件中
[IO.File]::WriteAllBytes("Adcontrol.kirbi", [Convert]::FromBase64String("处理后的凭据Base64编码"))
lylw3zbutaa13940.png
导入Rubeus ptt /ticket:file.kirbi
y2znlvbko5u13946.png

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
4n3jsd4b2cn13951.png
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
    2kkqgosz01n13955.png

    老方法

    用到的工具为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(普通域用户权限即可)
    x12tya5543013960.png
    如果复制粘贴不方便,可以使用/outfile:path指定Hash参数的写入路径
    qkki0d4i1rl13963.png
    Rubeus返回的Hash参数对应的值就是hashcat官方指定的RC4_HMAC加密方式破解的格式
    2whppseax1e13965.png
    kali中使用hashcat爆破
    hashcat -m 13100 hash.txt passwords.dict --force
    xyx4z5g4onl13971.png

    加密降级突破AES加密类型

    首先设置用户启用AES加密,通过AD用户和计算机管理设置liukaifeng01用户启用AES加密e35ptn25mqo13975.png
    LDAP查看msDS-SupportedEncryptionTypes属性
    x5fpjuzi4no13978.png
    这时候再进行Kerberoast时,返回的票据加密类型为AES256
    zc4nmawrcux13981.png
    抓包查看TGS_REQ,可以看到客户端向服务端提供了支持的加密算法,包括RC4AES加密
    5q2qdfwynhz13984.png
    通过查看TGS_REP可以发现返回的ST票据中使用的算法是最高支持的加密类型=>AES256
    2w4dqxw3k1m13986.png
    那这里就可以提出一个猜想,如果我们在TGS_REQ中提供最高的支持的加密算法是RC4,呢么TGS_REP中返回的加密方式是否也会是RC4
    在Rubeus中已经实现了该方法,并且确实有效
    Rubeus kerberoast /tgtdeleg
    dkaj5xejtyo13988.png
    TGS_REQ请求包中支持的加密算法仅为RC4
    xi2rgxseu1y13990.png
    虽然域用户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
xlyobby4kgx13995.png
获取hash后,通过mimikatz制作白银票据(部分条件上述黄金票据实践中已经获得),目的服务是cifs
正常情况是普通域用户hack没有权限访问:
i10utzemcku13998.png
通过mimikatz制作白银票据并直接导入
ifmm5mm01fd13999.png
查看当前票据
zetjtqgettc14002.png
成功访问共享目录
n5yh4khpwox14004.png
但是这里与正常的加密类型是不同的,Mimikatz的伪造是RC4的加密类型,而正常的SPN关联在机器账户下的一般都是AES加密,因此对于伪造访问服务CIFS的ST票据而言,白银票据的流量也比较容易识别
nnndq1jsu2f14006.png
常见的伪造服务类型如下
u34hsr4fqr314009.png

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

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

三种情况

存在用户

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

不存在的用户

描述:error_code:eRR-C-PRINCIPALL-UNKNOWN
oc1z3eqpus514012.png

kerbrute

使用场景

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

主要原理

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

用户名枚举

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

密码喷洒

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

pyKerbrute

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

用户名枚举

EnumADUser.py主要实现的就是发一个As-REQ结构的包修改CnameString即可(固定sname指向krbtgt)
4uyypvrk5hx14022.png
EnumADUser.py : EnumADUser.py 192.168.52.138 god.org user.txt tcp
1s0fmywflh214024.png
与kerbrute发送的数据包稍有区别ino1evl0k5u14027.png

密码喷洒

首先pyKerbrute分成了两种模式,clearpassword和ntlmhash
classpassword:实现了将明文加密成NTLM Hash然后通过RC4-HMAC加密算法加密时间戳,然后也可以通过ntlmhash模块来密码喷洒
ntlmhash:直接通过RC4-HMAC-MD5加密算法加密时间戳
m544v1hvarw14030.png
ADPwdSpray.py : ADPwdSpray.py 192.168.52.138 god.org username.txt clearpassword Abc123! udp
mrnqrct0akb14032.png
与kerbrute发送的数据包在支持的加密算法上有较大区别,不如kerbrute隐秘
shtla0zi3ry14036.png
pyKerbrute这里就发送了一个包,没有发送判断用户名是否存在,直接请求认证,且加密算法指定了RC4-HMAC-MD5,kerbrute支持多种加密方法
稍微看了下Kerbrute的代码,发现实现的方法NewWithPassword来自gokrb5这个库,该库便利了用于客户端与服务端的Kerberos相关认证,而且库中实现了众多的加密算法
njcgv5h1i4k14040.png

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,没有任何提示

成功

kfikwfdth0214045.png

失败

解决

通过查阅资料,找到了修改登录策略的地方,具体可查看Audit Kerberos Authentication Service
p0rwcx45kqi14047.png
修改审核策略后可捕获到4771类型:
1l4oamxw5ry14049.png
cmpjlbwpmic14052.png
aedemhk5je314053.png

Dcsync攻击

DCSync攻击原理

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

利用条件

需要具备如下扩展权限对应的DACL
jxhrpj0djr214056.png
根据3gstudent师傅的文章总结如下的组内用户具有上述权限
Administrators组内的用户
Domain Admins组内的用户
Enterprise Admins组内的用户
域控制器的计算机帐户

实践

这里指的Administrator组内的用户不是指域机器上的本地Administrators,而是域控制器上的本地Administrators组。这里以红日靶场一举Administrators组内用户的例子
比如likaifeng01这个用户,通过域控查看工具,或者终端DOS命令查看liukaifeng01所在的组
1gso3yw0ok114059.png
该用户是域控本地管理员组成员,但不是域管成员
通过Powerview的Get-DomainObjectAcl来获取该成员的ACL控制列表查看上述三项权限
ynrlnftceao14061.png

  1. DS-Replication-Get-Changes-In-Filtered-Set
    vyyomt4uk4b14063.png
  2. DS-Replication-Get-Changes
    3qqfw1z43ur14066.png
  3. DS-Replication-Get-Changes-All
    04dqhf1xgyq14069.png

满足上述三项权限,通过mimikatz的dcsync功能来导出Hash
nnaphgfhdj114071.png
也可以通过PowerView来直接为普通域用户一次性加上上述的三条特权,就可以具有执行Dcsync攻击的权限了,可以作为一种权限维持的方法
首先添加一个普通域用户hack,利用hack直接Dcsync会失败
qfoh0ddvdy314073.png
以管理员权限通过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
oumklmeab2p14074.png
Get-ObjectAcl -Identity "dc=god,dc=org" -ResolveGUIDs | ? {$_.SecurityIdentifier -match "S-1-5-21-2952760202-1353902439-2381784089-1111"}
xwpq0ebgu5t14076.png
图截不全,上面已经证明hack用户有这三个权限后,再次通过mimikatz来调用dcsync模块,可获取全部的Hash
gev5ajgbm1s14077.png
然后删除该用户的三个扩展特权可以用如下命令
Remove-DomainObjectAcl -TargetIdentity "DC=god,DC=org" -PrincipalIdentity hack -Rights DCSync -Verbose
删除后再次使用Dcsync模块,已不能获取
pcpl1fg2r1z14078.png

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

来源: https://forum.butian.net/share/614