【技术分享】从Mimikatz 解读windows 下的协议

一、了解Mimikatz

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

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

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

二、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:

KRB-TGS-REQ:client可以利用密码解密密文1，得到as-sessionkey，但是不能解密TGT（密文2），所以使用as-sessionkey加密时间戳与TGT一起发送到TGS服务，请求与server交流的server-sessionkey。

1. KRB-TGS-REP:TGS解密TGT得到as-sessionkey，在使用as-sessionkey解密时间戳部分，如果时间戳符合要求，就生成server-sessionkey，然后继续使用as-sessionkey加密server-sessionkey为密文1，利用server的密码加密server-sessionkey+PAC 为密文2（图中的service ticket），一同发给client。

2.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，就完成了一个权限提升的过程。

三、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。

四、总结

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

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