目录

• Windows认证协议
• • • • NTLM（NT LAN Manager）
      • Kerberos
  • NTLM认证
  • • • Windwos 密码hash
      • NTLM hash
      • NET-NTLM hash
      • 流程
      • 注意
      • 图解
  • Kerberos认证
  • • • 名词解释
      • 流程
      • • • 注意
      • 图解
• 利用方式
• • • • NTLM的利用方式
      • • • 1、Pass the hash
          • 2、Pass the key
      • Kerberos的利用方式
      • • • Pass The Ticket 1（Golden Ticket）
          • Pass The Ticket 2（Silver Ticket）
          • 黄金、白银票据的区别

Windows认证协议

Windows认证协议有两种：

NTLM（NT LAN Manager）

NTLM主要应用于用于Windows NT 和 Windows 2000 Server（或更高版本） 工作组环境

Kerberos

而后者则主要应用于Windows 2000 Server（或更高版本） 域环境

简单来说，在Windows 2000 Server或者更高版本里，想在工作组环境认证，就用NTLM协议；想在域环境里面认证，就得用Kerberos协议。

而在AD域环境中，如果需要认证 Windows NT操作系统，也得用NTLM协议。

NTLM认证

Windwos 密码hash

早期SMB协议在网络上传输明文口令，后来出现"LAN Manager Challenge/Response"验证机制，简称LM，由于容易被破解，微软提出了windows NT挑战/响应机制，称之为NTLM。

所以说NTLM主要是一种基于质询（challenge）/响应（response）消息交互模式的认证过程。

现在已经有了更新的NTLM v2以及Kerberos验证体系。windows加密过的密码口令，我们称之为hash，windows的系统密码hash默认情况下一般有两部分组成：LM-hash，NTLM-hash 。
这是对同一个密码的两种不同的加密方式

NTLM hash

在windows系统中比较常见的是从系统导出来的NTLM hash，通过Hashcat能够破解出明文密码。

NTLM hash通常是指windows系统下Securtiy Account Manager中保存的用户密码hash。

在渗透测试中，通常可从windows系统中的SAM文件和域控的NTDS.dit文件中获得所有用户的hash，通过mimikatz读取lsass.exe进程能获得已登陆用户的NTLM hash

NET-NTLM hash

通常是指网络环境下NTLM认证中的hash

流程

客户端发起认证请求
服务端收到认证请求，向客户端发送随机数（chanlleng/挑战）
客户端使用NTLM Hash打乱该随机数，生成Net-NTLM Hash，发送回服务端

说的有点懵了，简单点就是：

1.客户端向服务器发送一个请求，请求中包含明文的登录用户名。服务器会提前存储登录用户名和对应的hashpass（应该是密码hash，我这里写作hashpass）

2.服务器接收到请求后，首先检查你要登录的用户名存不存在，存在的话不管三七二十，先生成一个16位的随机数(这个随机数被称为Challenge)，使用存储的登录用户的hashpass加密Challenge，生成一个验证码（同样只是个人理解，官方说法或许不叫这个）

3.服务器将这个16位数随机生成的Challenge 明文发送给客户端。

4.客户端接收到Challenge后，使用登录用户的hashpass对Challenge加密，获得的结果叫response

5.客户端将response这个值明文发送给服务器

6.服务器接收客户端明文发送过来的response，比较验证码和response，如果两个值相同，则验证成功

注意

要注意的一点是，在2 、4过程中，都是用hashpass去加密challenge，而不是用challenge加密hashpass。

图解

这样，在认证登录的过程中，客户端不需要直接将密码发给服务器，减少了中间被嗅探劫持的风险。

Kerberos认证

名词解释

KDC(Key Distribution Center)：密钥分发中心里面包含两个服务：AS和TGS
AS(Authentication Server)：身份认证服务
TGS(Ticket Granting Server)：票据授予服务
TGT(Ticket Granting Ticket)：由身份认证服务授予的票据，用于身份认证，存储在内存，默认有效期为10小时
Pass The Ticket：如果我们能够拿到用户的TGT，并将其导入到内存，就可以冒充该用户获得其访问权限

流程

Kerberos提供了一个集中式的认证服务器结构，认证服务器的功能是实现用户与其访问的服务器间的相互鉴别。

Kerberos被称作三头狗，之所以用它来命名，是因为整个认证过程涉及到三方：客户端、服务端和KDC（Key Distribution Center）。在Windows域环境中，KDC的角色由DC（Domain Controller）来担当。

Kerberos是一种基于“票据”的认证方式。票据(Ticket)用来安全的在认证服务器和用户请求的服务之间传递用户的身份，同时也传递附加信息。用来保证使用Ticket的用户必须是Ticket中指定的用户。Ticket一旦生成，在生存时间内可以被Client多次使用来申请同一个Server的服务。

客户端要访问服务器的资源，需要首先购买服务端认可的票据。也就是说，客户端在访问服务器之前需要预先买好票，等待服务验票之后才能入场。在这之前，客户端需要先买票，但是这张票不能直接购买，需要一张认购权证。客户端在买票之前需要预先获得一张认购权证。这张认购权证和进入服务器的入场券均有KDC发售。

简单说，就是有客户端、服务器、KDC三台机器。

1.我想登录某个账号，我就在客户端上输入我要登录的账号密码。客户端呢，会把你的密码hash一下，hash后的值呢，这里叫hashpass。

2.客户端呢，再用hashpass加密我当前客户端的信息、登录的账号、KDC的id、时间戳信息，这里加密后的结果叫A。客户端就会把A和要登录的账号发给KDC

3.KDC收到后，首先是AD出马，AD是数据库，存储域里面所有的账号信息。AD一检查你要要登录的账号是存在的，就把A转发给AS。

4.AS里面事先保存着你的hashpass，它用hashpass解密A，看到里面的信息正常没问题。说明客户端的确是用hashpass加密的(不然你用其他的数据加密，AS用hashpass解密后的结果自然是无意义的。)

5.既然客户端没问题，那AS就随机生成一个秘钥，这里把它称作K。然后AS说，客户端你不是要票（TGT）吗？那我们来进行一下票据授予服务（TGS）啊。

客户端就做了两手准备，首先把TGS服务的名字、id啥的信息、还有K的值，当前时间戳用hashpass加密好。（把这个加密结果叫②）
然后把上面的信息加上客户端的信息和当前时间戳用TGS秘钥加密。这个TGS加密的结果呢，只有TGS才能解密。（把这个加密结果叫①）

6.AS把①、②全发给客户端。客户端接收一看，妈耶，①我解不开，不晓得啥意思。那就看②，②能用hashpass解开，解开后客户端拿到了K的值。

然后客户端就用K加密②解密后的内容、客户端信息和当前时间戳，加密后的结果呢就叫验证器（authenticator）。

7.客户端将①和验证器全都发给TGS。TGS一收到，验证器我解不开，先看①。用TGS秘钥解开了①（前面说了，①只有TGS才能解开），然后拿到了K的值，和其他信息。

然后TGS用K解密验证器。

将①和验证器解密后的结果做个对比，如果没问题，好，通过验证。

8.通过验证后，TGS就随机生成一个值，我们把它叫做K2。然后票据授予服务不是验证通过了吗？TGS小手一挥，给你两张票据。

票据1里面有K1、客户端身份信息、服务器 ID、时间戳等信息，这里用服务端秘钥加密，只有服务器才能解密。
票据2里面同样有K1、服务器ID、时间戳信息，用k加密。

然后TGS将两张票据全发给客户端

9.客户端收到后，同样解不开票据一，用K解密票据二后，知道了服务器ID和K1的值。

然后客户端用K1将票据二解密后的内容、客户端信息、时间戳加密。加密的结果叫验证器2吧。

10.客户端将票据一、验证器2全发给服务器（第9步知道了服务器的id等信息）

11.服务器接收后，先用服务器秘钥解密票据一。知道了K1的值及相关信息。

然后服务器用K1解密了验证器2，得到了验证器2里面的内容

服务器就验证两者之间的内容，如果通过验证，就允许客户端登录。

注意

要注意的地方是8/9/10/11步后面的什么客户端信息、服务器信息。有些参考资料上说应该写成TGS、TGT啥的id等内容，然后这些服务、票据内容里面包括了客户端、服务端、时间戳信息。但是因为作者只是个初学者，所以只按自己的理解来写，如果理解错了希望有大佬能指出来。

然后上面的时间戳都是指当前时间戳，每个步骤里面的时间戳都是不一样的。他们（as，tgs，服务器）会计算拿到手的信息里的时间戳和当前时间戳的时间差，如果隔太久了（比如超过了2分钟，比如超过了5分钟。这个时间差是由管理员设置的，默认是5分钟。）那么他们会认为这是假的是伪造的，不同意下一步的认证。

下图揭示了Kerberos整个认证的过程。

图解

利用方式

两种验证方式看起来都无懈可击，是不是就真的安全了呢？
当然不。

NTLM的利用方式

先说说ntlm的利用方式
他有两种利用方式

1、Pass the hash

首先，如果内网主机的本地管理员账户密码相同，那么可以通过pass the hash远程登录到任意一台主机。

拿下域里面一台主机的管理员权限后，从dump内存获取其他用户的账号和hashpass（hash后的密码），用账号及hashpass登录其他主机（从前面的认证过程中可以看到，ntlm验证只用到hashpass，不知道明文的密码也可以登录）

然后如果恰好某个hashpass对应的账号是某台主机的管理员，你就又拿下了一台主机。在这台主机里获取用户的hashpass，然后又去其他主机登录……

如此重复下去，总有拿下域管理员的的账号及hashpass的一天

当然，微软在2014年发布了更新补丁kb2871997禁止本地管理员账户用于远程连接。也就是说除了一些2014年前的未更新的老古董，这个方法基本上没用了。

不过有大佬验证过默认的 Administrator (SID 500)账号例外，利用这个账号仍可以进行Pass The Hash远程连接。

参考资料：https://www.tiejiang.org/23508.html

2、Pass the key

mimikatz实现了在禁用ntlm的环境下仍然可以远程连接，通过利用用户账户的aes key进行远程连接，即利用pass the key。
注意
1、Windows vista以后，本地管理员administrator默认是禁用状态，而用户添加的本地管理员是受限管理员，pass the hash远程连接后权限为普通用户权限；
2、Pass the key时需要确保系统安装了补丁kb2871997

Kerberos的利用方式

票据攻击（PTT）

Pass The Ticket 1（Golden Ticket）

英文看不懂没关系，中文意思是黄金票据
黄金票据伪造票据授予服务
黄金票据的利用条件是原先已成功取得域用户的HASH。

如果你知道TGS的秘钥，是不是就没AS什么事了？（见第5步）

①、②里面有你要请求的TGS的服务。如果你知道TGS的秘钥，①、②是不是就由你写了。然后你再把①发给TGS，TGS一解密，它开具的票据就是你在①②里面请求的票据授予服务。所以拿到TGS秘钥后，你就能伪造任意

因为TGS的秘钥AS知道（第五步）你可以伪造任意服务票据。

TGS的秘钥是什么呢？域控里有个用户叫krbtgt，专门用来发票据的。就是说TGS的秘钥，其实就是他这个用户的秘钥。所以只要我们知道了这个krbtgt用户的passhash，就可以伪造黄金票据

Pass The Ticket 2（Silver Ticket）

这里说的是白银票据

如果我们知道了服务器秘钥。
那么我们可以伪造票据一，伪造验证器2.然后直接和服务器通信，就没KDC什么事了。

黄金、白银票据的区别

1. 访问权限不同：
   Golden Ticket：伪造TGT，可以获取任何Kerberos服务权限
   Silver Ticket：伪造TGS，只能访问指定的服务
2. 加密方式不同：
   Golden Ticket由Kerberos的Hash加密
   Silver Ticket由服务账号（通常为计算机账户）Hash加密
3. 认证流程不同：
   Golden Ticket的利用过程需要访问域控，而Silver Ticket不需要访问域控