文章目录

Windows认证机制
- Windows认证基础
- 本地认证
- 网络认证
- - hashcat破解net-ntlm hash
- 域认证
- - Kerberos认证协议的基础概念
  - Kerbreros认证流程
  - 1. 用户登录
  - 2. 请求身份认证
  - - 2.1 客户端向AS(身份认证服务)发送认证请求
    - 2.2 AS确认Client端登录者用户身份
  - 3. 请求服务授权
  - - 3.1 客户端向TGS发送请求服务授权请求
    - 3.2 TGS为Client响应服务授权票据
  - 4.发送服务请求
  - - 4.1 Client向Service Server发送服务请求
    - 4.2 SS响应Client
- 票据伪造的原理
- 参考

Windows认证机制

Windows认证基础

Windows的认证包括三个部分：

本地认证：用户直接操作计算机登陆账户
网络认证：远程连接到工作组中的某个设备
域认证：登陆到域环境中的某个设备

本地认证

用户输入密码
系统收到密码后将用户输入的密码计算成NTLM Hash
与sam数据库（%SystemRoot%\system32\config\sam）中该用户的哈希比对
匹配则登陆成功，不匹配则登陆失败

NTLM哈希，是一种单向哈希算法，Windows将用户的密码计算成NTLM哈希之后才存储在电脑中

大致的运算流程为：

用户密码->HEX编码->Unicode编码->MD4

pip3 install passlib>>> from passlib.hash import nthash
>>> print(nthash.hash('admin'))
209c6174da490caeb422f3fa5a7ae634

NTLM Hash的前身是LM Hash，由于存在安全缺陷已经被淘汰

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

网络认证

网络认证即在工作组环境下远程登陆另一台电脑所采用的认证机制

NTLM协议的认证过程分为三步，也叫挑战相应机制：

1.协商

双方确定使用的协议版本，NTLM存在V1和V2两个版本，即Net-NTLM v1 hash、Net-NTLM v2 hash，具体区别就是加密方式不同

在NTLM认证中，NTLM响应分为NTLM v1，NTLMv2，NTLM session v2三种协议，不同协议使用不同格式的Challenge和加密算法

2.质询

挑战（Chalenge）/响应（Response）认证机制的核心

客户端向服务器端发送用户信息(用户名)请求
服务器接受到请求后，判断本地用户列表是否存在客户端发送的用户名，如果没有返回认证失败，如果有，生成一个16位的随机数，被称之为"Challenge"，然后使用登录用户名对应的NTLM Hash加密Challenge(16位随机字符)，生成Challenge1保存在内存中。同时，生成Challenge1后，将Challenge(16位随机字符)明文发送给客户端。
客户端接受到Challenge后，使用自己提供的账户的密码转换成对应的NTLM Hash，然后使用这个NTLM Hash加密Challenge生成Response，然后将Response发送至服务器端。

3.验证

在质询完成后，验证结果，是认证的最后一步。

服务端收到客户端发送的Response后，与之前保存在内存中的Channelge1比较，如果相等认证通过

其中，经过NTLM Hash加密Challenge的结果在网络协议中称之为Net NTLM Hash（不能直接用来进行哈希传递攻击，但可以通过暴力破解来获取明文密码）

其中的关键点在于：第二步中客户端发送的是NTLM哈希值与随机字符串加密的结果，而这个NTLM哈希是由用户输入的密码本地计算得出的，所以在这个步骤中，只要能提供正确的NTLM哈希即使不知道正确的密码也可通过认证

hashcat破解net-ntlm hash

NTLMv2的格式为：

username::domain:challenge:HMAC-MD5:blob

hashcat -m 5600 net-ntlm /tmp/password.list -o found.txt --force-m：hash-type，5600对应NetNTLMv2
详细参数可查表：https://hashcat.net/wiki/doku.php?
-o：输出文件 字典文件为/tmp/password.list
--force：代表强制执行，测试系统不支持Intel OpenCL

域认证

域内认证即采用了Kerberos协议的认证机制，与前两者相比最大的区别是有个一个可信的第三方机构KDC的参与

参与域认证的三个角色：

Client
Server
KDC(Key Distribution Center) = DC(Domain Controller) = AD（Account Database）+ AS（Authenication Service）+ TGS（Ticket Granting Service）

从物理层面看，AD与AS，TGS，KDC均为域控制器(Domain Controller)。

Kerberos认证协议的基础概念

票据(Ticket):

是网络对象互相访问的凭证。

TGT(Ticket Granting Ticket):

看英文名就知道，用来生成Ticket的Ticket

AD(Account Database):

存储域中所有用户的用户名和对应的NTLM Hash，可以理解为域中的SAM数据库，KDC可以从AD中提取域中所有用户的NTLM Hash，这是Kerberos协议能够成功实现的基础。

KDC(Key Distribution Center):

密钥分发中心，负责管理票据、认证票据、分发票据，里面包含两个服务：AS和TGS

AS(Authentication Server):

身份认证服务，为Client生成TGT的服务，也用来完成对Client的身份验证

TGS(Ticket Granting Server):

票据授予服务,为Client生成允许对某个服务访问的ticket，就是Client从AS那里拿到TGT之后，来TGS这里再申请对某个特定服务或服务器访问的Ticket，只有获取到这个Ticket，Client才有权限去访问对应的服务，该服务提供的票据也称为 TGS 或者叫白银票据

TGT(Ticket Granting Ticket):

由身份认证服务授予的票据(黄金票据)，用于身份认证，存储在内存，默认有效期为10小时

注意：

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

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

Server 和 Service可以当作一个东西，就是Client想要访问的服务器或者服务
S
Client/(TGS/Server) Sessionkey 可以看作客户端与TGS服务和尝试登陆的Server之间会话时用来加密的密钥，而(Client/TGS/Service)密钥(上面提到的三个实际为NTLM Hash的密钥)是用来加密会话密钥的密钥，为了保证会话密钥的传输安全，这些加密方式均为对称加密

参与认证的三个角色的NTLM Hash是三个密钥，这三个NTLM Hash的唯一作用是确保会话密钥Sessionkey的安全传输

Kerbreros认证流程

Client向KDC发起服务请求，希望获取访问Server的权限。 KDC得到了这个消息，首先得判断Client是否是可信赖的，也就是从AD数据库中寻找该用户是否可用来登录。这就是AS服务完成的工作，成功后，AS返回TGT给Client。

Client得到了TGT后，继续向KDC请求，希望获取访问Server的权限。KDC又得到了这个消息，这时候通过Client 消息中的TGT，判断出了Client拥有了这个权限，给了Client访问Server的权限Ticket。（TGS服务的任务）

Client得到Ticket后便可以使用这个Ticket成功访问Server。但是这个Ticket只能用来访问这个Server，如果要访问其他Server需要向KDC重新申请。

1. 用户登录

用户输入 [用户名] 和 [密码] 信息
在客户端，用户输入的 [密码] 通过计算生成NTLM哈希作做为 [CLIENT密钥]

2. 请求身份认证

2.1 客户端向AS(身份认证服务)发送认证请求

客户端向AS发送认证请求，请求中带有明文的 [用户名] 信息

此时并未发送[密码]或[密钥]信息

2.2 AS确认Client端登录者用户身份

AS收到用户认证请求之后，根据请求中的用户名信息，从数据库中查找该用户名是否存在。
如果用户名存在，则根据该用户名提取NTLM Hash做为AS生成的CLIENT 密钥，如果第1步中用户提供的密码信息正确，该秘钥与用户登录中的 CLIENT密钥是相等的。
AS为Client响应如下消息：
- Msg A 使用 KDC生成的CLIENT密钥加密的CLIENT/TGS SESSIONKEY
- Msg B 使用 TGS密钥加密的TGT(TICKET-GRANTING-TICKET)，客户端没有KDC NTLM Hash因此Client无法解密TGT。
- TGT中包含如下信息：
  - [Client/TGS SessionKey]
  - Client ID
  - Ticket有效时间
  - CLient 地址
Client收到AS的响应消息以后，利用自身的 CLIENT密钥可以对Msg A进行解密，这样可以获取到 CLIENT/TGS SESSIONKEY 。但由于Msg B是使用 TGS密钥加密的，Client无法对其解密。

AS响应的消息中有一条是属于Client的，但另外一条却属于TGS。

Client/TGS SessionKey出现了两个Copy，一个给Client端，一个给TGS端。

认证过程中的加密除哈希外均采用的是对称加密算法。

3. 请求服务授权

3.1 客户端向TGS发送请求服务授权请求

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

Msg C
- 要请求的服务ID, 即[Service ID]
- 上一步2.2中由AS为Client提供的TGT。
Msg D
- 使用 CLIENT/TGS SESSIONKEY 加密的Authenticator 1 {Client ID, Timestamp}。

KDC接收到TGT与其他内容后，会首先使用KDC 的NTLM Hash解密TGT，只有KDC可以解密TGT，从TGT中提取到 CLIENT/TGS SESSIONKEY ，再使用 CLIENT/TGS SESSIONKEY 解密Authenticator 1，获取到{Client ID, Timestamp} 并与通过解密TGT获取到的{Client ID, 有效时间}进行对比

3.2 TGS为Client响应服务授权票据

TGS为Client响应的消息包括：

Msg E 使用 SERVICE密钥(服务器的NTLMHASH) 加密的 CLIENT-TO-SERVER TICKET , 该Ticket中包含了如下信息:
- [Client/Server SessionKey]
- Client网络地址
- Ticket有效时间
- Client ID
Msg F 使用 CLIENT/TGS SESSIONKEY 加密的 CLIENT/SERVER SESSIONKEY 。

Msg F使用了 CLIENT/TGS SESSIONKEY 加密，因此，该消息对Client可见。Client对其解密以后可获取到 CLIENT/SERVER SESSIONKEY 。

而Msg E使用了 [SERVICE密钥] 加密，该消息可视作是TGS给Service Server的消息，只不过由Client一起携带发送给Service Server

4.发送服务请求

4.1 Client向Service Server发送服务请求

发送的消息中包括：

Msg E 上一步3.2中，TGS为Client响应的消息Msg E。该消息可以理解为由Client携带的消息。
Msg G 由[Client/Server SessionKey]加密的Authenticator 2，包含{Client ID, Timestamp}信息。

CLIENT/SERVER SESSIONKEY 并非直接传输，而是被包含在使用[Service密钥]加密的Msg E中。

既然 [CLIENT/SERVER SESSIONKEY] 并不直接明文传输， Client需要向Service Server证明自己拥有正确的 CLIENT/SERVER SESSIONKEY ，所以，Authenticator 2使用了 CLIENT/SERVER SESSIONKEY 加密。

4.2 SS响应Client

SS收到客户端的服务请求之后，先利用自身的 [SERVICE密钥] 对Msg E进行解密，提取出Client-To-Server Ticket, 在3.2步骤中，提到了该Ticket中包含了 CLIENT/SERVER SESSIONKEY 以及Client ID信息。

SS使用 CLIENT/SERVER SESSIONKEY 解密Msg G，提取Client ID信息，而后将该Client ID与Client-To-Server Ticket中的Client ID进行比对，如果匹配则说明Client拥有正确的 CLIENT/SERVER SESSIONKEY 。

而后，SS向Client响应Msg H(包含使用 CLIENT/SERVER SESSIONKEY 加密的Timestamp信息)。

Client收到SS的响应消息Msg H之后，再使用 CLIENT/SERVER SESSIONKEY 对其解密，提取Timestamp信息，然后确认该信息与Client发送的Authenticator 2中的Timestamp信息一致。

如上信息可以看出来，该交互过程起到了Client与SS之间的“双向认证”作用。

票据伪造的原理

2.2 AS确认Client端登录者用户身份
- KDC返回的Msg B：使用 TGS密钥(KDCHASH/KRBTGT用户NTLMHASH) 加密的TGT(Ticket-Granting-Ticket)，当我们获取到krbtgt用户的NTLM哈希后，便可主动使用krbtgt用户的NTLM哈希做为TGS密钥来生成TGT发送给KDC，这样KDC如果通过解密伪造TGT获取到伪造的 [CLIENT/TGS SESSIONKEY] 可以成功解密 Authenticator 1 并完成与TGT中的数据进行比对，便成功骗过了KDC，也就是成功伪造了黄金票据
4.1 Client向SS(Service Server)发送服务请求
- 客户端向服务器发送的为使用 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正常解密完成比对，也就是成功伪造了白银票据

关于Service Hash，Service Hash其实是目标中一个用户名与hostname相同的用户的Hash
如hostname为PC-WIN7的服务器，对应的Hash就是Username : PC-WIN7$的哈希

参考

Windows下的密码hash——NTLM hash和Net-NTLM hash介绍

彻底理解Windows认证 - 议题解读 « 倾旋的博客

Windows域认证机制相关推荐

深入详解windows安全认证机制ntlmKerberos
0x01 为什么要理解windows 安全认证机制: 加深对后续各种漏洞利用的理解深度,还是那句话,要知其然,更要知其所以然,不废话,咱们直接开始 0x02 windows认证协议主要有以下两种: 基 ...
kerberos认证_初识 Windows域认证体系 Kerberos认证
关键词: Kerberos认证域控制器(Domain Controller,DC) 密钥分发中心(Key Distribution Center,KDC) 帐户数据库(Account Databas ...
C#开发中Windows域认证登录2（扩展吉日嘎拉GPM系统）
为什么80%的码农都做不了架构师?>>> 原文地址:http://www.cuiwenyuan.com/shanghai/post/Windows-AD-Logon-Inter ...
Windows域认证（Kerberos认证）图解
图文经过梳理与绘制已较为详细,希望能帮助大家更清晰.直观地了解Kerberos的认证过程. 相关名词: DC:域控制器 KDC:密钥分发中心 AD:账户数据库 AS:身份验证服务 TGS:票据发放服务 ...
java windows域_JAVA windows 域认证指南
实现方法: import java.util.Hashtable; import javax.naming.Context; import javax.naming.NamingEnumeration ...
浅析Windows域环境身份认证与攻击思路
文章目录前言 Kerberos协议第1步-AS认证获取TGT 第2步-TGS认证获取ST 第3步-服务端服务认证 NTLM 认证本地认证模式网络认证模式内网横向渗透哈希凭证窃取内网远程连 ...
Windows认证机制之Kerberos协议
Windows认证机制首先,我们简短介绍下Windows的认证机制.主要有以下三种, 本地认证网络认证域内认证如图所示: Kerberos协议 Kerberos 是一种由 MIT(麻省理工大学 ...
windows 认证机制
目录 Windows认证协议 NTLM(NT LAN Manager) Kerberos NTLM认证 Windwos 密码hash NTLM hash NET-NTLM hash 流程注意图解 ...
Windows认证机制详解（借物表在文章末尾）
一.本地认证基础知识 Windows系统在本地认证过程中,操作系统会要求用户输入密码作为凭证去做身份验证. 在验证过程中,系统并不保存明文密码,而是将用户输入的密码转变为NTLM hash(也叫NT ...

Windows域认证机制