从Mimikatz 解读windows 下的协议

阅读量    16397 |   稿费 300

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

0x01 了解Mimikatz

大家使用这个工具最多的就是提取密码,可能对其中涉及到的windows协议不了解,mimikatz项目的介绍当中:

mimikatz is a tool I’ve made to learn C and make somes experiments with Windows security.

我们就来从其中来了解下windows 的协议。

 

0x02 kerberos 协议

我们先来大致使用下mimikatz 的kerberos 模块。

其中list,tgt和purge

list 列举出当前会话的所有缓存凭证,tgt列出当前会话的tgt信息:

purge 销毁所有的缓存凭证:

ptt: pass the ticket 以及golden/silver,中都涉及到了kerberos 协议(V5)的部分,我们就先来看看kerberos 协议的实现。

图的来源,说明下这张图:

主要包含了3个部分:1.AS 服务 2.TGS 服务 3.C/S 端

1,2两个部分一起称为KEY DISTRIBUTION CENTER简称KDC,Client要向Server 请求数据就需要验证身份,在这个不安全的网络环境下必须要证明自己。这就需要一个信任度第三方来帮助完成验证,KDC就是为了这种需求所设计的服务。我们来解析上图中的流程(wireshark 抓包):

  1. KRB-AS-REQ:Client 通过用自身密码加密一个时间戳timestamp,向as服务验证身份,请求TGT。
  2. KRB-AS-REP:AS服务使用client 的密码副本,解密对比是否符合timestamp要求,成功就是认证了client,生成一个短期的as-sessionkey,用client密码加密成密文1,另外将as-sessionkey+PAC(特权证书,指明了client所具有的权限)使用TGS服务的密码加密为密文2(这就是TGT),组成了KRB-AS-REP发送给client。

PAC:

  1. KRB-TGS-REQ:client可以利用密码解密密文1,得到as-sessionkey,但是不能解密TGT(密文2),所以使用as-sessionkey加密时间戳与TGT一起发送到TGS服务,请求与server交流的server-sessionkey。
  2. KRB-TGS-REP:TGS解密TGT得到as-sessionkey,在使用as-sessionkey解密时间戳部分,如果时间戳符合要求,就生成server-sessionkey,然后继续使用as-sessionkey加密server-sessionkey为密文1,利用server的密码加密server-sessionkey+PAC 为密文2(图中的service ticket),一同发给client。

  1. KRB_AP_REQ:client 利用as-sessionkey 解密得到server-sessionkey,因为不能解密service ticket(4中的密文2),所以就无法伪造,再使用server-sessionkey 加密时间戳,与service ticket 一起发送到server 端,也解决了server可能无法及时接收SessionKey的问题。

  1. KRB_AP_REP:server受到KRB_AP_REQ之后,利用server密码解密ServiceTicket,得到server-sessionkey,然后用server-sessionkey解密Authenticator得到时间戳,成功验证client的身份。

这样整个kerberos 协议的流程就完成了,其中都使用到了时间戳,所以域内都要时间同步才可以,整个协议设计的很是巧妙。

我们来说明下其中golden与ptt的使用:

从上图演示中,可以看出来在一个低权限域用户提升到管理员了,后面想要执行命令可以用psexec,也是不用输入密码的。其中godlen票据导出的时候,sid与krbtgt的ntlm,可以在原来有DC权限的时候,使用lsadump::lsa /patch导出。

golden ticket 就是伪造了TGT,可以看到第二步中需要TGS服务密码加密,然而TGS就是kerberos的密码,修改PAC权限,这样就合法的伪造了TGT,就完成了一个权限提升的过程。

 

0x03 MS-DRSR协议

Mimikatz其中一个重要的模块:lsadump::dcsync ,使用DRSR向DC查询用户信息。我们先看一个使用例子:

for /f "tokens=1" %i in (username.txt) do @mimikatz.exe "lsadump::dcsync /user:%i /domain:localtest.com" exit >> info.txt

导出了第一列用户的hash信息:

SRSR介绍:

The Directory Replication Service (DRS) Remote Protocol is an RPC protocol for replication and management of data in Active Directory.

使用RPC协议,不会产生LOG,但是必须要有:Administrator 和 Domain controller。其中主要的函数:

客户端通过调用IDL_DRSBind获取特定DC的DRS_HANDLE,然后调用该DC上的任何其他drsuapi方法,并将DRS_HANDLE作为第一个参数传递。 直到客户端调用IDL_DRSUnbind,或直到服务器的DRS_HANDLE无效(例如崩溃),客户端的DRS_HANDLE仍然可用于进行方法调用。

与DRS_HANDLE关联的唯一状态是由IDL_DRSBind建立的状态。 只要DRS_HANDLE保持有效,该状态就是不变的。 因此,如果客户端通过对IDL_DRSBind使用相同的参数来为同一个DC创建两个绑定句柄,则drsuapi方法的服务器行为不受客户端传递给该方法的绑定句柄选择的影响。其中大多都是涉及一些函数调用,例如IDL_DRSGetNT4ChangeLog 这个方法用于支持Active Directory复制到Windows NT 4.0备份域的控制器(BDC)的实现。以及其中关于两个函数UUID的设置:

更多详细的过程看这里:https://msdn.microsoft.com/en-us/library/cc228096.aspx

 

0x04 总结

​ windows 应该是还是现在主流的办公系统,所以公司中windows 的域对企业就很重要,方便人员协作以及管理,但是如果不做好严格的权限控制,以及对服务器及时 的更新,就有可能这个企业内网都会被一举攻陷。例如ms14-068 和 ms11-013 都是出在windows 协议方面的漏洞,像MS17-010,也是SMB协议方面的问题。所以我们就要对windows 下的协议更加了解,才能挖到0day嘛。这里有一份windows 下的所有协议介绍:

https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/Windows_Protocols.zip

 

0x05 参考

1.https://github.com/gentilkiwi/mimikatz

2.https://msdn.microsoft.com/library/windows/desktop/aa378170.aspx

3.https://msdn.microsoft.com/en-us/library/cc228086.aspx

4.https://channel9.msdn.com/Events/Open-Specifications-Plugfests/Windows-Identity-and-Exchange-Protocols-Plugfest-2012/MS-DRSR-Windows-AD-Protocol-Test-Suite-Presentation-2012
分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多