ntlm & Kerberos _ 转发

原文： https://www.cnblogs.com/nu1l/p/16317186.html

0x01 为什么要理解windows 安全认证机制:

加深对后续各种漏洞利用的理解深度,还是那句话,要知其然,更要知其所以然,不废话,咱们直接开始

0x02 windows认证协议主要有以下两种:

基于ntlm的认证方式,主要用在早期的windows工作组环境中,认证的过程也相对比较简单

另一种是基于Kerberos的认证方式,主要用在域环境中,下面就这两种不同的认证方式做些简要的通信流程说明

0x03 关于ntlm认证流程简要说明,如下:

0x04 从图中我们可以清晰的看到,ntlm在域中的认证过程主要分为以下几步:

第一步,首先在client输入username,password和domain,然后client会把password hash后的值先缓存到本地

第二步,之后,client把username的明文发送给server(DC)

第三步,DC会生成一个16字节的随机数,即challenge(挑战码),再传回给client

第四步,当client收到challenge以后,会先复制一份出来,然后和缓存中的密码hash再一同混合hash一次,混合后的值称为response,之后client再将challenge,response及username一并都传给server

第五步,server端在收到client传过来的这三个值以后会把它们都转发给DC

第六步,当DC接到过来的这三个值的以后,会根据username到域控的账号数据库(ntds.dit)里面找到该username对应的hash,然后把这个hash拿出来和传过来的challenge值再混合hash

第七步,将(6)中混合后的hash值跟传来的response进行比较,相同则认证成功,反之,则失败,当然,如果是本地登录,所有验证肯定也全部都直接在本地进行了

0x05 关于ntlm的一点小结:

它是一种基于挑战（challenge）/响应（response）消息交互模式的认证过程,从整个认证过程来看,安全确实不怎么到位,也就是说入侵者只需要拿到一个系统管理员的hash,直接给dc认证就好了,反正账户名和域名都知道,早期的pass the hash (psexec)确实就是通过这种方式来进行的,如果本地管理员的账号密码相同,其实不用密码一样可以被认证,我们所要做的就是不断通过这种方式来尝试拓展内网的其他机器,直到控制整个域,但后来的kb2871997,似乎改变了一些现状,但也可能只是似乎

0x06 关于kerberos的一些概述:

相对于ntlm而言,kerberos的认证方式就要复杂的多,因为它提供了一个集中式的认证方式,在整个认证过程中总共要涉及到三方:客户端,服务端和KDC [Key Distribution Center 密钥分发中心], 在Windows域环境中,KDC的角色由DC(Domain Controller[域控])来担任,Kerberos是一种基于票据的认证方式,票据(Ticket)是用来安全的在认证服务器和用户请求的服务之间传递用户的身份,同时也会传递一些附加信息,用来保证使用Ticket的用户必须是Ticket中指定的用户,Ticket一旦生成,在生存时间内可以被Client多次使用来申请同一个Server的服务(票据窃取问题)

0x07 kerberos的大致工作流程:

说到这里,我们大概也能明白,域中的客户端要想访问同域中的某个服务器资源时,需要首先购买该服务端认可的票据,也就是说,客户端在访问服务器之前需要预先买好票,等待服务验票之后才能入场,但是这张票不能直接购买,还需要一张认购权证,也就是说客户端在买票之前需要预先获得一张认购权证,这张认购权证和进入服务器的入场券均有KDC发售,下面就以下图来做简要说明:

1)首先,客户端(client)将域用户的密码hash一次并保存,然后,以此hash来作为客户端和KDC之间的长期共享密钥[kc](当然,在DC上也保存着同样的一条hash)

2)之后,客户端(client)开始利用(1)中的域用户密码hash再把时间戳,clientid,TGS id等信息混合hash一次,然后向as(认证服务器 [Authentication Server])服务器进行请求

3)as接到该请求后,利用长期共享密钥(kc)进行解密,解密成功后,会返回给客户端两个票据

  (1)加密的K(c,tgs)(用于客户端后续向KDC发起请求),TGS Name/ID,时间戳等,该票据由Kc加密

  (2)票据授予票据(Ticket Granting Ticket,简称TGT),该票据是给TGS的,票据的内容包括K(c,tgs),Client身份信息,域名,时间戳等,该票据由TGS的秘钥加密,只有TGS能够解密

4)然后,客户端会利用长期共享密钥解密k(c,tgs),并利用该秘钥加密生成一个Authenticator,内容包括:lifetime,时间戳,Client身份信息等,连同从AS获取的TGT一并发送给TGS

5)TGS利用自身的秘钥解密TGT,获取K(c,tgs),并用K(c,tgs)解密客户端发送的Authenticator,对Client进行认证,如果Client通过了认证,TGS随机生成一个Session Key K(c,s),并产生两个票据

  (1)服务票据(Ts):这是给服务器的服务票据,由Server秘钥Ks加密,内容包括：K(c,s),Client身份信息,Service ID,时间戳,lifetime等

  (2)客户端票据(Tc)：该票据由K(c,tgs)加密,内容包括：K(c,s),Server身份信息等

6)客户端收到tgs的回应后,利用K(c,tgs)解密Tc,获取K(c,s),Server身份信息等,并利用K(c,s)加密生成一个Authenticator发送给Server,内容包括:时间戳,Client ID等信息,连同Ts一并发送给Server

7)Server端在收到Client的请求后,利用自身秘钥Ks解密Ts,得到K(c,s),再利用K(c,s)解密Authenticator,对Client进行认证,如果认证通过,则表示KDC已经允许了此次通信,此时Sever无需与KDC通信,因为Ks为KDC和Sever之间的长期共享秘钥,如果在有效时间内,则此次请求有效

0x08 关于kerberos利用方法:

1) 黄金票据(Golden Ticket)
先假设这么一种情况,原先已拿到的域内所有的账户hash,包括krbtgt这个账户,由于有些原因导致域管权限丢失,但好在你还有一个普通域用户权限,碰巧管理员在域内加固时忘记重置krbtgt密码,基于此条件,我们还能利用该票据重新获得域管理员权限,利用krbtgt的HASH值可以伪造生成任意的TGT(mimikatz),能够绕过对任意用户的账号策略,让用户成为任意组的成员,可用于Kerberos认证的任何服务

2) 白银票据(Silver Ticket)
通过观察Kerberos协议的认证过程不难发现,如果我们获取了Server秘钥Ks(服务器口令散列值),就可以跳过KDC的认证，直接伪造票据和目标Server通信

0x09 关于黄金票据和白银票据的一些区别:

1)访问权限不同

Golden Ticket: 伪造TGT,可以获取任何Kerberos服务权限

Silver Ticket: 伪造TGS,只能访问指定的服务

2)加密方式不同

Golden Ticket 由Kerberos的Hash加密

Silver Ticket 由服务账号(通常为计算机账户)Hash加密

3)认证流程不同

Golden Ticket 的利用过程需要访问域控,而Silver Ticket不需要

小结:

这些其实都是域内渗透最基础的知识,所以觉得大家还是非常有必要多花点儿时间,好好深刻体会一下,另外,微软给我们的建议是,尽量们不要直接使用NTLM,而使用negotiate,如果使用的是negotiate,windows则会先判断kerberos是否可用,如果可用就优先使用kerberos,否则才会使用NTLM,kerberos的安全性确实要比NTLM要高很多

https://www.cnblogs.com/SeanGyy/p/16046842.html

什么是SAM

SAM：

　　安全帐户管理器（Security Accounts Manager）, SAM 是Windows操作系统管理用户帐户的安全所使用的一种机制。用来存储 Windows 操作系统密码的数据库文件，为了避免明文密码泄漏SAM文件中保存的是明文密码在经过一系列算法处理过的Hash值被保存的Hash分为LMHash、NTLMHash。当用户进行身份认证时会将输入的Hash值与SAM文件中保存的Hash值进行对比。

　　SAM文件保存于 %SystemRoot%\system32\config\sam 中，在注册表中保存在 HKEY_ LOCAL_MACHINE\SAM\SAM，HKEY_ LOCAL _MACHINE\SECURITY\SAM 。在正常情况下SAM文件处于锁定状态不可直接访问、复制、移动，仅有system用户权限才可以读写该文件。

windows本地认证:

本地用户认证

　　Windows在进行本地登录认证时操作系统会使用用户输入的密码作为凭证去与系统中的密码进行对比验证。通过 winlogon.exe 接收用户输入传递至 lsass.exe 进行认证。

　　winlogon.exe用于在用户注销、重启、锁屏后显示登录界面。 Isass.exe 用于将明文密码变成NTLM Hash的形式与SAM数据库比较认证。

　　Windows本身不保存明文密码，只保留密码的Hash。

LM Hash

　　全称是 LAN Manager Hash，windows 最早用的加密算法，由 IBM 设计。

　　目前大多数的Windows都采用NTLM协议认证，LM协议已经基本淘汰了。LM协议的脆弱之处在于：

　　1.des的key是固定的，有了Key就能够解出原文。

　　2.可以根据 hash 判断密码长度是否大于7位，如果密码强度是小于7位，那么第二个分组加密后的结果肯定是aad3b435b51404ee

　　3.密码不区分大小写并且长度最大为14位

　　4.7+7字符分开加密明显复杂度降低14个字符整体加密 957+957<9514

NTLM Hash与NTLM

　　在Windows中，密码Hash目前称之为NTLM Hash，其中NTLM全称是：“NT LAN Manager”。

　　这个NTLM是一种网络认证协议，与NTLM Hash的关系就是：NTLM 网络认证协议是以 NTLM Hash 作为根本凭证进行认证的协议。也就是说，NTLM与NTLM Hash 相互对应。在本地认证的过程中，其实就是将用户输入的密码转换为 NTLM Hash 与 SAM 中的 NTLM Hash 进行比较。

NTLM Hash的产生

　　1.先将用户的密码转化为十六进制格式。

　　2.将十六进制格式的密码进行 Unicode 编码。

　　3.使用 MD4 摘要算法对 Unicode 编码数据进行 Hash 计算。

　　假设我的密码是admin，那么操作系统会将admin转换为十六进制，经过Unicode转换后，再调用MD4加密算法加密，这个加密结果的十六进制就是NTLM Hash。

1 admin -> hex(16进制编码) = 61646d696e 
2 61646d696e -> Unicode = 610064006d0069006e00
3 610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634

本地认证流程

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

　　首先，用户注销、重启、锁屏后，操作系统会让winlogon显示登录界面，也就是输入框，winlogon接收输入后，将密码交给lsass进程，这个进程中会存一份明文密码，将明文密码加密成NTLM Hash，对SAM数据库比较认证。

网络认证

　　在内网渗透中，经常遇到工作组环境，而工作组环境是一个逻辑上的网络环境(工作区)，隶属于工作组的机器之间无法互相建立一个完美的信任机制，只能点对点，是比较落后的认证方式，没有信托机构。

　　假设A主机与B主机属于同一个工作组环境，A想访问B主机上的资料，需要将一个存在于B主机上的账户凭证发送至B主机，经过认证才能够访问B主机上的资源。

　　这是我们接触比较多的SMB共享文件的案例，SMB的默认端口是445。

　　早期SMB协议在网络上传输明文口令。后来出现 LAN Manager Challenge/Response 验证机制，简称LM，它是如此简单以至很容易就被破解，现在又有了NTLM以及Kerberos。

　　NTLM是一种网络认证协议，它是基于挑战（Chalenge）/响应（Response）认证机制的一种认证模式。

　　这个协议只支持Windows。

Challenge/Response

　　NTLM的认证过程分为三步：type1（协商），type2（质询），type3（身份验证）

　　1、用户登录客户端电脑

　　2、(type 1)客户端向服务器发送type 1(协商)消息，它主要包含客户端支持和服务器请求的功能列表。

　　3、(type 2)服务器用type 2消息(质询)进行响应，这包含服务器支持和同意的功能列表。但是，最重要的是，它包含服务器产生的Challenge。　　

　　4、(type 3)客户端用type 3消息(身份验证)回复质询。用户接收到步骤3中的challenge之后，使用用户的 NTLM hash对challenge进行加密运算得到response，将response,username,challeng发给服务器。消息中的response是最关键的部分，因为它们向服务器证明客户端用户已经知道帐户密码。

　　5、服务器拿到type 3之后，使用用户 hash 加密 challenge 得到response2，与 type 3发来的 response 进行比较。如果用户hash是存储在域控里面的话，那么没有用户hash,也就没办法计算response2。也就没法验证。这个时候用户服务器就会通过netlogon协议联系域控，建立-个安全通道然后将type 1,type 2，type3 全部发给域控(这个过程也叫作Pass Through Authentication认证流程)

　　6、域控使用challenge和用户hash进行加密得到response2，与type 3的response进行比较。

注意：

　　1.Chanllenge是Server产生的一个16字节的随机数，每次认证都不同

　　2.Response的表现形式是Net-NTLM Hash，它是由客户端提供的密码Hash加密Server返回的Chanllenge产生的结果。

NTLM V2协议

　　NTLM v1与NTLM v2最显著的区别就是 Challenge 与加密算法不同，共同点就是加密的原料都是NTLM Hash。

　　下面细说一下有什么不同:

　　　　Challage:NTLM v1的Challenge有8位，NTLM v2的Challenge为16位。

　　　　Net-NTLM Hash:NTLM v1的主要加密算法是DES，NTLM v2的主要加密算法是HMAC-MD5。

NTLM协议分析介绍

一、NTLM简介

NTLM Hash的计算：（1）.先将用户密码转换为十六进制格式。（2）.将十六进制格式的密码进行Unicode编码。（3）.使用MD4摘要算法对Unicode编码数据进行Hash计算

二、NTLM认证

NTLM验证是一种Challenge/Response 验证机制，由三种消息组成:通常称为type 1(协商)，类型type 2(质询)和type 3(身份验证)。

用户登录客户端电脑
(type 1)客户端向服务器发送type 1(协商)消息,它主要包含客户端支持和服务器请求的功能列表。
(type 2)服务器用type 2消息(质询)进行响应，这包含服务器支持和同意的功能列表。但是，最重要的是，它包含服务器产生的Challenge（一个 16 位的随机字符串）。
(type 3)客户端用type 3消息(身份验证)回复质询。用户接收到步骤3中的challenge之后，使用用户hash与challenge进行加密运算得到response，将response,username,challeng发给服务器。消息中的response是最关键的部分，因为它们向服务器证明客户端用户已经知道帐户密码。
服务器拿到type 3之后，使用challenge和用户hash进行加密得到response2与type 3发来的response进行比较。如果用户hash是存储在域控里面的话，那么没有用户hash，也就没办法计算response2。也就没法验证。这个时候用户服务器就会通过netlogon协议联系域控，建立一个安全通道,然后将type 1,type 2，type3 全部发给域控(这个过程也叫作Pass Through Authentication认证流程)
域控使用challenge和用户hash进行加密得到response2，与type 3的response进行比较