一、概述

记录关于Windows认证几种协议的学习，包括NTLM本地认证、NTLM网络认证、Kerberos认证的详细认证过程。

二、本地认证流程

2.1 本地认证流程

Windows Logon Process(即 winlogon.exe)，Winlogon 是负责处理安全相关的用户交互界面的组件。Winlogon的工作包括加载其他用户身份安全组件、提供图形化的登录界面(LogonUl.exe)，以及创建用户会话。

LSASS(本地安全认证子系统服务)用于微软Windows系统的安全机制。它负责Windows系统安全策略。它负责用户在本地验证或远程登陆时验证用户身份，管理用户密码变更，并产生访问日志。用户注销、重启、锁屏后，操作系统会让winlogon显示图形化登录界面，也就是输入框，接收域名、用户名密码后交给lsass进程，将明文密码加密成NTLM Hash，对SAM数据库比较认证，相同则认证成功。

winlogon.exe -> 接收用户输入 -> Isass.exe -> (认证)

用户登陆认证过程

本地认证中用来处理用户输入密码的进程即lsass.exe，密码会在这个进程中明文保存，供该进程将密码计算成NTLM Hash与sam进行比对我们使用mimikatz来获取的明文密码，便是在这个进程中读取到的。

Windows Logon Process(即winlogon.exe)，是Windows NT户登陆程序，用于管理用户登入。

LSASS用于微软Windows系统的安全机制，它用于本地安全和登陆策略。

domainname\username 域环境的登陆

computername\username 本地登陆认证

2.2 身份验证提供程序

Windows中两个主要身份验证提供程序: MSV1_0和Kerberos。这些被Microsoft称为安全支持提供程序身份验证程序包 (SSP / AP )

本地验证

MSV1_0身份验证提供程序访问包含本地帐户凭据的SAM数据库

域用户身份验证

1、当无法访问DC，MSV1_0身份验证提供程序将通过从SECURITY注册表配置单元中读取缓存的域用户凭据来尝试使用缓存的域用户凭据来对用户进行身份验证

2、可以联系DC，调用Kerberos身份验证提供程序。该身份验证提供程序负责使用Kerberos协议 (88端口，执行网络身份验证）

kerberos 88 端口 TCP/IP协议

2.3 认证分类

账号密码认证

通过向服务器发送“账号密码” 来证明自己的身份

挑战认证 NTLM

通过向服务器发送“一段计算的结果”来证明自己的身份

kerberos认证

通过像服务端发送一张“票”，来证明自己的身份

2.4 密钥

长期密钥，长期密钥加密数据，不应该在网络上传输，因为长期密钥可能长期保持不变，比如密码

短期密钥: 由于被长期密钥加密的数据包不能在网络上传送，所以需要使用另一种密钥来加密需要进行网络传输的数据。这种密钥只在一段时间内有效，即使加密过的数据包被黑客截获，等他把密钥计算出来的时候，这个密钥早就已经过期了。我们把这种密钥称为短期密钥。

三、NTLM网络认证

Windows操作系统中加密Hash的算法也分为两种，一种是LM HASH加密算法，一种是NTLM HASH加密算法，目前使用最流行的HASH加密算法为NTLM HASH（NT LAN Manager加密算法）

(1）LM HASH

LM Hash(LAN Manager Hash) 是windows最早用的加密算法，由IBM设计。LM Hash 使用硬编码秘钥的DES，且存在缺陷。早期的Windows系统如XP、Server 2003等使用LM Hash，而后的系统默认禁用了LM Hash并使用NTLM Hash。

(2）NTML HASH

NTLM HASH（NT LAN Manager）是Windows 为了安全性和兼容性而设计的散列加者算法。是微软为了解决LM HASH加密算法存在诸多安全问题而在Windows NT3.1中引入的NTLM算法。目前Windows7/Windows Server 2008以后的操作系统版本均默认开启了NTLM HASH算法。

(3) NTLM Hash算法原理

目前在大部分的Windows操作系统中所使用的密码HASH均为NTLM HASH（NT LAN Manager），是经过Hex、Unicode、MD4三层编码加密等到的一个字母和数字组成的32值的Hash，如下是NTLM HASH的具体算法。

1）将用户密码进行hex编码得到十六进制格式。

2）将得到的十六进制结果转换为Unicode编码。

3）使用MD4加密算法对Unicode转换的结果进行加密。

历史版本

NTLMv1: 服务器通过发送一个8字节的随机数(挑战)来验证客户端，客户端返回两个24字节Hash进行计算并返回计算结果。

NTLMv2: 它通过加强协议来抵御许多欺骗攻击，并增加服务器向客户端进行身份验证的能力，从而增强了NTLM的安全性。服务器通过发送一个16字节的HMAC - MD5随机数(挑战）来验证客户端。

MSV1_0安全软件包实现NT LAN Manager身份验证协议 (NetNTLMv1和NetNTLMv2)

challenge：随机数

3.1、NTLM认证流程图解（工作组）

大致分为三步：

1）协商（Negotiate）：主要用于确认双方协议版本。

2）质询（Question）：就是挑战（Challenge）/响应（Response）。

3）验证（Response）：验证主要是在质询完成后，验证结果，是认证的最后一步。

3.2、具体认证流程

（1）协商

1、Client向Server发送TYPE1 Negotiate 协商消息，确定协议版本

2、服务端接收到客户端发送过来的 TYPE1 消息，会读取其中的内容，并从中选择出自己所能接受的服务内容，加密等级，安全服务等。

（2）质询

1、Client向Server发送明文用户名消息作为请求

2、Server收到请求，验证是否存在Client发来的用户名，如果存在，传入 NTLM SSP，得到NTLM_CHALLENGE 消息。

3、将16位的随机数(Challenge)发送给Cilent，并使用SAM中查询用户名对应的NTLM Hash加密Chanllenge，生成Net-NTLM Hash存放在内存中。

4、Client使用发送的用户名对应的NTLM Hash加密Challenge，将结果(Response)发送给Server

其中第三步，Server生成并放到内存中的 Net-NTLM Hash 与第四步中 Client生成的 Response 是一样的话，认证则通过。

（3）验证

1、Server收到Client发送的Response，将接收的Response与Net-NTLM Hash进行比较，如果相同，则认证通过。

注：每次生成的16字节的Challenge都不同，保证的安全性，

3.3、域内 NTLM 验证

在域中，Server没有用户和密码的Hash，所以Server需要将 challenge、Client返回的Response 同时发给 Domain Controller，让域控制器来进行验证，因为域控制器中才有用户名和密码，所以不但【验证】阶段，Server需要将域控制器来做验证，在第二步【质询】阶段，验证是否存在用户，也应该是在域控制器完成的。

【1】协商

1、用户通过输入Windows帐号和密码登录客户端主机，客户端会缓存密码的哈希值NTLM-Hash。成功登录客户端的用户如果试图访问服务器资源，需要向对方发送一个请求，该请求利用 NTLM SSP 生成NTLM_NEGOTIATE 消息 (被称为 TYPE 1 消息，Negotiate 协商消息)，并将 TYPE 1 消息发送给服务端中，该TYPE 1消息中包含一个以明文表示的用户名以及其他的一些协商信息(认证的主体，机器以及需要使用的安全服务等等信息)

【2】质询

2、服务端接收到客户端发送过来的 TYPE 1 消息，会读取其中的内容，并从中选择出自己所能接受的服务内容，加密等级，安全服务等等。然后传入 NTLM SSP，得到 NTLM_CHALLENGE 消息(被称为TYPE 2 消息，Challenge 挑战消息)，并将此TYPE 2消息发回给客户端。此TYPE 2消息中包含了-个由服务端生成的16位随机值，此随机值被称为 Challenge，服务器将该Challenge保存起来。

3、客户端收到服务端返回的 TYPE 2 消息， 读取出服务端所支持的内容，并取出其中的随机值Challenge用缓存的密码的哈希值NTLM-Hash对其进行加密，得到 Net NTLM-Hash(加密后的Challenge)，并且将Net NTLM-Hash封装到 NTLM_AUTH 消息中(被称为 TYPE 3 消息，Authenticate认证消息),发往服务端。

【3】验证

4、服务器接收到客户端发送来的 NTLM_AUTH 的 TYPE 3 消息后，取出其中的Net NTLM-Hash值，并向DC域控 (Domain Control) 发送针对客户端的验证请求。

该请求主要包含以下三方面的内容：

客户端用户名

原始的Challenge

加密后的Challenge(也就是Net NTLM-Hash)。

5、DC根据用户名获取该帐号的密码哈希值NTLM-Hash，用密码哈希值 NTLM-Hash 对原始的Challenge进行加密得到Net NTLM-Hash。如果加密后的Challenge和服务器发送的一致，则意味着用户拥有正确的密码，验证通过，否则验证失败，DC将验证结果发给服务器。

6、服务器根据DC返回结果，对客户端进行回复。

3.4、针对NTLM Hash的攻击方式

1、Pass The Hash

Pass The Hash (PtH) 是攻击者捕获帐号登录凭证后，复用凭证Hash进行攻击的方式。

2、Pass The Key

在禁用NTLM的环境下，可以用mimikatz等工具直接获取密码。

3、NTLM Relay

攻击者可以一定程度控制客户端网络的时候，可以使用中间人攻击的方式来获取权限。对客户端伪装为身份验证服务器，对服务端伪装为需要认证的客户端。

四、Kerberos认证协议

4.1、基本介绍

Kerberos协议是由麻省理工学院提出的一种网络身份验证协议，提供了一种在开放的非安全网络中认证识别用户身份信息的方法。它旨在通过使用密钥加密技术为客户端/服务端应用程序提供强身份验证。

Kerberos实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取。修改和插入数据。

Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术(如:共享密钥)执行认证服务的

注意

在域环境中，默认先使用kerberos进行认证，当使用kerberos认证出现错误时使用NTLM认证。

在指定的主机名与注册的服务主体名称不匹配的情况下，或者如果使用IP地址，则Windows将退回旧协议，例如NetNTLMy2身份验证。

特点：

• 可信任的第三方认证服务，通过传统的密码技术（如：共享密钥）执行认证服务
• 三方：客户端、服务端、AD（域控制器）
• 不依赖主机操作系统认证
• 无需基于主机地址的信任
• 不要求网络上所有主机的物理安全（假定网络上传输的数据包可以被任意的读取、修改和插入数据）

优点：

• 从不通过网络发送明文密码
• 任何私有或者公共的加密密钥都不会直接在网络上交换
• 用户和应用程序可以互相验证（双向验证）
• 通常作为单点登录

TCP/UDP 88 端口：身份验证和票据授予

TCP/UDP 464 端口：经典Kerberos Kpaswd（密码重置）协议

LDAP：389、636

4.2、Kerberos中的一些名词简称

基本

请求TGT

请求ST

其他

简要理解

TGT 相当于身份证

ST 相当于火车票

SPN 需要访问的服务名

KDC 相当于公安局

AS 相当于公安局发放身份证的服务-作用：判断身份是否有效-以此判断是否发放身份证

TGS 相当于公安局-服务中心（Client 请求TGS 时需要包含所需要访问的SPN）作用：验证身份证是否有效-以此判断是否发放火车票（或者其他服务的认证票据）

4.3、简要流程图

① Client 请求KDC的AS服务拿到TGT

② Client 拿着TGT请求KDC的TGS服务拿到ST

③ Client 拿着ST访问Server

4.4、Kerberos详细认证过程

（一）Client申请TGT

1、Client 向 KDC-AS 发送申请消息（REQ）

消息包括：

• 使用Client 用户的NTLM Hash 加密时间戳（防止重放攻击）
• Username，明文传输
• SPN krbtgt
• User nonce

实战攻击：AS-REQ用户枚举

因为DC也需要这个用户名去匹配 Client的NTLM Hash 去解密消息，如果能解密则认证通过，所以用户名是不加密的，属于明文传输，所以这里存在一个域用户名的枚举。

2、KDC-AS 向 Client 返回消息（REP）

1、身份验证服务(KDC-AS)使用用户NTLM解密时间戳，解密成功KDC-AS检查用户的信息(登录限制、组成员身份等)并创建TGT

2、向本地LSA (Local Security Authority)请求生成一个特殊的数据PAC（使用krbtgt密钥进行进行签名）KDC随机生成一个短期会话密钥(Session Key)，此时AS向Client发送两条消息

（1）TGT（使用krbtgt NTLM Hash 加密）10小时，内容包括：User Name、Session Key、PAC（由krbtgt hash签名）、TGT的生命周期

（2）另一消息TC（使用Client 申请TGT时使用的用户名对应的NTLM Hash加密），内容包括：TGT的生命周期、Session Key、User Nonce

注意：

• KDC-AS 根据用户名，查询到用户的NTLM Hash 如果解密成功，说明Client端的密码是正确的，所以在这步申请x8;TGT过程认证成功。
• KDC-AS认证成功才会发送这一步的返回消息
• 第一步的认证消息Authenticator 是Client 的 NTLM Hash，以此进行认证
• 特殊数据的PAC使用krbtgt密钥进行签名，所以不能被修改
• TGT 使用krbtgt NTLM Hash 加密，在网络上不传输krgtgt NTLM Hash，所以TGT是可以被安全的传输的。
• TC 使用的是认证的Client 用户名对应的NTLM Hash 加密

实战攻击：SESSION KEY 离线爆破

容易产生的攻击 SEESION KEY 离线破解

如果能够拦截到TC消息可以进行离线破解，因为这条消息是使用用户的NTLM Hash 消息进行加密的，如果使用彩虹表进行枚举，可以获取用户名和密码。

（二）Client申请ST

1、Client 向 KDC-TGS 发送申请消息（REQ）

Client -> KDC-TGS (TGS_REQ)

Client 使用用户的NTLM Hash解密TC消息，获得 Session Key，然后向KDC-TGS发送消息：

（1）Authenticator(使用Session Key加密)，内容包括：Client Name、Timestamp（+/- five minutes）

（2）TGT（使用krbtgt hash 加密）：Session Key

（3）所需要SPN

（4）A Nonce

注意

• 黄金票据（伪造TGT，前提是获取krbtgt的口令散列值），可以自己生成Session Key
• 第二步的认证消息 Authenticator 是使用 Session Key 加密的用户名和时间戳（防止重放攻击）
• 这里KDC使用的是Session Key进行验证，因为这个Session Key KDC-TGS 是通过krbtgt的NTLM Hash 解密获取的，而用户是通过第一步的验证，通过自己的NTLM Hash 解密得到的，所以这里可以间接的验证了用户的NTLM Hash 是否正确。

2、KDC-TGS 向 Client 返回消息（REP）

KDC收到REQ消息后

（1）KDC使用Krbtgt NTLM Hash对TGT解密，获取Client信息和Session Key

（2）使用Session Key对Client发来对Authenticator信息解密，对比TGT信息，相同则认证通过

KDC-TGS生成Server Session Key，并给Client回复消息，消息包括这几部分内容：

（1）TGS生成Client需要访问服务的ST发送给Client，Ticket使用目标服务帐户的NTLM Hash加密，包括：

• Client Name
• Server Session Key
• PAC（krbtgt hash 签名）
• TGS生命周期（时间戳）

（2）使用Session Key加密的Server Session Key，内容包括：

• A Nonce
• TGS生命周期
• Server Session Key

（3）用户名

注意：

• ST 使用目标服务账号的NTLM Hash加密
• Server Session Key 使用 Session Key 加密（因为Client在第二步时也获取到Session Key，他是通过自己的NTLM Hash解密从AS获取的；而这里加密Server Session Key 的 Session Key 是通过 krbtgt NTLM Hash解密后获取的，这里可以验证一致性，保证安全）

实战攻击：KERBEROAST

如果能够抓到这个消息，因为ST是使用 Server服务的账号密码的Hash加密的，所以如果我们能够通过彩虹表爆破，就可以得到Server服务的口令账号

（三）Client依据ST访问Server

Client收到消息后，使用Session Key解密获得Server Session Key

1、Client 拿着 ST 向 Server 请求服务（AP-REQ）

（1）Client发送由Server Session Key加密的Authenticator信息和ST访问Server，内容包括：

• Timestamp
• Client Name

（2）ST（Server NTLM Hash加密）

• Server Session Key
• Client Name

注意：

• 第三步的验证消息 Authenticator是使用 Server Session Key 来加密验证
• 上一步验证通过后，返回了两个消息给Client 一个是ST消息（使用server 自己的NTLM Hash 加密，包含Server Session Key），一条消息是使用Session Key加密的消息，也包含Server Session Key 。
• 在这一步，Client 是使用 Session Key 解密后获取的 Server Session Key 来加密Authenticator和ST 发送给Server

实战攻击：白银票据

• 伪造TGS，直接发送给Service
• 不产生AS-REQ、AS-REP、TGS-REQ、TGS-REP
• 利用机器账户生成

2、Server 向 Client 返回消息（AP-REP）

Server

（1）Server使用NTLM Hash解密ST，获得Server Session Key，使用Server Session Key解密Authenticator信息，对比Authenticator信息中的Client信息和Ticket中的Client信息对比，将Authenticator信息的时间戳和Ticket的时间戳是否相同（误差2min）

（2）Server使用Server Session Key加密Authenticator信息，内容包含：

• ID（ID 相当于 cookie ）
• 时间戳

Client

（1）Client使用缓存中的用Server Session Key解密Authenticator信息，得到访问该访问需要携带的ID和时间戳

（2）认证完成，只需要使用申请的Service Ticket就可以正常访问服务

总体理解：

• Session Key 作为一个临时密钥，在网络上传输 作为后两步的验证条件
• 验证过程：包括使用 Client NTLM Hash 、krbtgt NTLM Hash、Session Key、Server Session Key加密解密的方式来验证，还会对比用户名和时间戳，以此进一步防止重放攻击和确认一致性，保证安全。

参考：

https://cloud.tencent.com/developer/article/2381711