内网渗透-Windows认证协议


本地认证流程

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

  • winlogon.exe -> 接收用户输入 -> lsass.exe -> (认证)
  • Windows Logon Process(即winlogon.exe),是Windows NT户登陆程序,用于管理用户登录
    和退出。
  • LSASS用于微软Windows系统的安全机制,它用于本地安全和登陆策略。

Windows网络认证

认证

你怎么证明你知道你所声称的用户的密码?(如何证明你是你)

认证分类
  • 账号密码认证

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

  • 挑战认证

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

  • Kerberos 认证

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

密钥

长期密钥:被长期密钥加密的数据不应该在网络上传输,因为有的密钥可能长期内保持不变,比如密码

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

NTLM认证

Client(客户端)、Server(服务端)

历史版本

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

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

    NTLM认证 认证流程图解(工作组)

upload successful

NTLM认证 认证流程(工作组)
[1] 协商

1.Clint向Server发送TYPE 1 Negotiate 协商信息,确定协议版本

2.服务端接收到客户端发送过来的 TYPE 1 消息,会读取其中的内容,并从中选择出自己所能接收的服
务内容,加密等级,安全服务等等。然后

[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

[3] 验证

Server收到Client发送的Response,将接收的Response与Net-NTLM Hash进行比较,如果相同,则认
证通过。
注:每次生成的16字节的Challenge都不同,保证的安全性。

NTLM认证 认证流程图解(域)

upload successful

NTLM认证 认证流程(域)

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

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认证消息),发往服务端。

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

6.服务器根据DC返回的结果,对客户端进行回复。

double-hop (双跃点)
1
2
3
4
5
6
7
8
9
10
impersonate:
主要分为两个级别impersonation和delegation。
impersonation:服务端可以使用客户端的身份访问本地资源。主要因为Double-hop authentication
问题,PSEXESVC使用impersonation,主要因为NTLM SSP不支持委派,NTLM 主要使用用户原始密码
验证身份,所以无法使用网络资源。
Double-hop authentication (双跳认证)
NTLM在转发认证时,只能使用用户原始密码验证身份,所以中间的服务端只能使用匿名身份或者自己
的身份访问Server。
Kerberos因为使用票据进行验证,中间的服务端可以将客户的票据进行转发访问其他服务。delegation服务端可以使用客户端的身份访问本地和网络资源,Kerberos支持该级别的
Impersonation,但是需要在域控制器进行特别的配置。
Kerberos
1
2
3
4
5
6
7
8
9
地狱三头犬
Kerberos实现不依赖于主机操作系统的认证,无需基于主机地址的信任,不要求网络上所有主机的物理
安全,并假定网络上传送的数据包可以被任意地读取.修改和插入数据。
Kerberos 作为一种可信任的第三方认证服务,是通过传统的密码技术(如:共享密钥)执行认证服务
的。
RFC 4120 V5
Tips:
在域环境中,默认先使用Kerberos进行认证,当使用kerberos认证出现错误时使用NTLM认证。
RFC4120 V5版本:https://tools.ietf.org/html/rfc4120
Kerberos会使用的端口
1
2
3
4
5
6
7
8
9
10
11
12
13
14
TCP和UDP的88(Kerberos)端口:身份验证和票证授予
TCP和UDP的464端口:经典Kerberos Kpaswd(密码重设)协议
Kerberos 认证名词
AS:身份认证服务(验证Client身份)
KDC:密钥分发中心(域内最重要的服务器,域控制器)
TGT:票据中心用户信授予的票据(访问 TGS 服务的票)
TGS:票据授权服务
ST:访问服务的票据
Krbtgt:每个域中都有krbtgt账户,此账户是KDC的服务账户用来创建TGT
Principal:认证主体
PAC:特权属性证书(用户的SID,用户所在的组)
SPN:服务主体名称
Session Key(临时会话密钥a,只有Client和TGS知道,在Kerberos认证中至关重要)
Server Session Key(临时会话密钥b,只有Client和Service知道,在Kerberos认证中至关重要)
Kerberos 认证流程

Client(客户端)

Server(服务端)

KDC(也就是参与认证的域控制器)

1.Client请求KDC的AS服务拿到TGT

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

3.Client拿着ST访问Server

upload successful

Kerberos 认证流程图解

upload successful

Client向KDC-AS申请TGT(1)

Client—–>KDC-AS(AS-REQ)

客户端发送由client Authenticator1到AS 通过Client NTLM hash(长期密钥)加密的
时间戳(防止重放攻击)

Client Name

Service Name

AS-REQ域用户枚举

Client向KDC-AS申请TGT(2)

KDC-AS ——-> Client(AS - 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加密),内容包含:
User Name、Domain Name、组成员资格
TGS Name时间戳、IP地址
TGT的生命周期、Session Key
(2)另一条信息T(C)(使用Client申请TGT时使用的用户名对应的NTLM Hash加密),内容包含:TGS
Name、时间戳、TGT的生命周期、Session Key
SESSION KEY 离线爆破

Client拿着TGT 请求 KDC的TGS服务拿到ST(1)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Client->KDC-TGS (TGS_REQ)
Client:
使用NTLM Hash解密 T(C)获得Session Key
1.Client向TGS发送消息
(1)Authenticator(使用Session Key加密),内容包含:
User Name
时间戳
TGT
需要访问的服务名称
(2)TGT (使用krbtgt加密)
Session Key
黄金票据(伪造TGT,前提是获取krbtgt账号的口令散列值)
Forwardable TGT或Unconstrained delegation(非受限委派或无限制委派)
Client->KDC-TGS
KDC:
1.KDC使用Ktbtgt NTLM Hash对TGT解密,获取Client信息和Session Key
2.使用Session Key对Client发来对Authenticator信息解密,对比TGT信息,相同则认证通过
Client拿着TGT 请求 KDC的TGS服务拿到ST(2)
1
2
3
4
5
6
7
8
9
10
11
12
13
KDC-TGS->Client(TGS-REP)
KDC:
TGS生成Server Session Key
1.TGS生成Client需要访问服务的ST发送给Client,Ticket使用目标服务账户的NTLM Hash加密:
(1) Client Name
(2) Server Session Key
2.使用Session Key加密的Server Session Key,内容:
(1)Server Name
(2)时间戳
(3)Server Session Key
Client:
Client收到信息后,使用Session Key解密获得Server Session Key
KERBEROAST
Client拿着ST访问Server(1)
1
2
3
4
5
6
7
8
9
Client -> Server (AP-REQ)
Client:
1.Client发送由Server Session Key加密的Authenticatorticator信息和ST访问Server,内容:
(1)ST
(2)时间戳
2.ST(Server NTLM Hash加密)
(1)Server Session Key
(2) Client Name
白银票据(伪造TGS,前提是获取服务账号的口令散列值)
Client拿着ST访问Server(2)
1
2
3
4
5
6
7
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信息,内容包含:
(1)ID
(2)时间戳

文章作者: thirteensummer
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 thirteensummer !
  目录