域渗透-Windows认证机制

一、Windows基本认证

1、NTLM认证协议

基本介绍

NTHM是NTLAN Manager的缩写，NTLM是指telnet的一种验证身份方式，即询问/应答身份验证协议，是Windows NT早期版本的标准安全协议，Windows 2000支持NTLM是为了保持向后兼容。WIndows 2000内置三种基本安全协议之一

Windows早期的认证方式，目前所采用的是Kerberos认证

认证过程

NTLM使用在Windows NT和Windows 2000 server（or later）工作组环境中（Kerberos用在域模式下）。在AD域环境中，如果需要认证Windows NT系统，也必须采用NTLM

（1）用户通过输入windows账号和密码登录客户端主机。在登录之前，客户端会缓存输入密码的哈希值，原始密码会被丢弃（“原始密码在任何情况下都不能被缓存”，这是一条基本的安全准则）。成功登录客户端Windows的用户如果试图访问服务器资源，需要向对方发送一个请求。该请求中包含一个以明文表示的用户名

（2）服务器接收到请求后，生成一个16位的随机数。这个随机数被称为Challenge或者Nonce。服务器在将该Challenge发送给客户端之前，该Challenge会先被保存起来。Challenge是以明文的形式发送的

（3）客户端在接收到服务器发回的Challenge后，用在步骤一中保存的密码哈希值对其加密，然后再将加密后的Challenge发送给服务器

（4）服务器接收到客户端发送回来的加密后的Challenge后，会向DC（Domain）发送针对客户端的验证请求，该请求主要包含以下三方面的内容：客户端用户名；客户端密码哈希值加密的Challenge和原始的Challenge

（5）DC根据用户名获取该账号的密码哈希值，对原始的Challenge进行加密，如果加密后的Challenge和服务器发送的一致，则意味着用户拥有正确的密码，验证通过，否则验证失败，DC将验证结果发给服务器，并最终反馈给客户端

进行实操来对上述认证进行理解

我们现在在Windows7这儿登录Windows2003

因为这两台主机同处于一个域环境中

在Windows7的搜索栏中输入\\god-111\就可以正常去访问

然后去访问C盘的时候就得输入用户名和密码了

\\god-111\c$

然后我们在Windows7这儿使用net use去连接Windows2003

登录成功就能访问了

 

既然我们成功连接到了Windows2003，我们可以往Windows2003的C盘中写入木马，然后通过一些操作逐步实现横向移动

二、Windows域认证

1、Kerberos认证协议

相关名词

域控制器（Domain Controller，DC）：在域中至少有一台服务器负责每一台联入网络的电脑和用户的验证工作，相当于一个单位的门卫一样

密钥分发中心（Key Distribution Center，KDC）：KDC维护着域中所有安全主体（Security Principal）账户信息数据库，负责管理票据、认证票据、分发票据

账户数据库（Account Database，AD）：一个类似于Windows本机SAM的数据库，存储了域内所有网络对象的凭证，也存储所有Client的白名单，在白名单中的Client才可以申请到TGT

身份验证服务（Authentication Service，AS）：用于生成TGT的服务

票据发放服务（Ticket Granting Service，TGS）：用于生成某个服务的ticket

认证票据（Ticket Granting Ticket，TGT）：可以理解为入场券，通过入场券能够获得票据，是一种临时凭证的存在

票据（Ticket）：网络对象互相访问的凭证

Master Key：长期密钥（被Hash加密的用户密钥），这里指NTLM Hash，简单理解就是Windows加密过的密码口令

Session Key：短期会话密钥

krbtgt账户：每个域控制器都有一个krbtgt的用户账户，是KDC的服务账户，用来创建票据授予服务（TGS）加密的密钥

Kerberos中的角色

Client：客户端

Server：需要访问的服务

KDC（DC）：认证服务器，一般为域控制器（DC）

认证过程

(1)Client向KDC的AS服务发送请求，希望获取访问Server的权限。KDC收到请求后，通过在账户数据库AD中存储黑名单和白名单来区分Client是否可信。确认成功后，AS返回TGT给CLient

(2)Client得到了TGT后，继续向KDC的TGS服务发送请求，希望获取Server的权限，KDC通过客户端请求信息中的TGT判断客户端是否拥有权限，确认成功返回访问Server的权限ticket

(3)Client得到ticket后，Client与Server二者进行相互验证，成功后，Client就可以访问Server的资源

详细认证过程

（1）Client发送AS Request给AS

AS Request大致内容：

Pre-authentication data：一个使用Client的Master key加密过的Timestamp（时间戳），用于证明自己是所发送用户名对应的那个用户

Client name & realm：Domain name\Client标识，用于KDC从AD中查找Client的Master key

Server name：KDC TGS的Server Name

（2）AS接收到CLient的请求信息，需要验证发送是否为本人，而AS只需从AD中获取Client对应的Master Key对Pre authentication data进行解密验证其是否为合法的Timestamp，若验证合格，则说明发送方在AD中且其密钥正确。但是当Timestamp比当前的时间偏差过多或者Timestamp早于上次认证时间点，AS会直接拒绝

验证通过后，AS将AS Response发送给Client，主要包括请求Client的Master Key加密过的Session Key和被KDC用户（krbtgt账户）使用其自己的NTLM Hash加密过的TGT

TGT的大致内容如下：

Session Key：KDC生成的一个随机字符串，用于后续CLient与TGT服务之间的通信

Client name & realm：Domain name\Client

Server name & realm：简单说就是Domain name\Server，Client访问的Server

End time：TGT到期时间

（3）Client使用自己的Master Key可以将AS返回的加密过后的Session key解密，得到session key。而后发送TGS Request给TGS，请求ticket

TGS Request大致内容如下：

Authenticator：使用Session Key加密的Client info（Client标识等信息）和Timestamp（时间戳）。

TGT

Client info：Domain name/Client

Server info：Client要访问的Server的信息

Timestamp：时间戳

（4）TGS收到TGS Request，通过自己的Master Key（NTLM Hash）对TGS Request中的TGT进行解密，得到Session Key，而后使用Session Key解密Authenticator相关验证，验证成功后TGS向Client发送TGS Response。TGS Response主要包括两个部分，使用session key（KDC-Client）加密过的用于Client和Server通信的Session key（Server-Client）与使用Server的Master Key进行加密的Ticket

Ticket大致内容如下：

Session Key：用于Client和Server通信的Session Key

Client name & realm：Domain name\Client

End time：Ticket的到期时间

（5）Client通过Session Key（KDC-Client）进行解密将TGS Response中用于与Server通信的Session Key（Server-Client）获取到。而后CLient向Server请求服务，发送Request其中包含Ticket，Server Session Key加密的Client info与Timestamp，还包含一个Flag用于表示Client是否需要进行双向验证

（6）Server通过使用自己的Master Key解密用户请求中的Ticket得到Session Key（Server-Client），使用Session Key（Server-Client）解密Client加密过后的信息（Client info与Timestamp）进行验证，验证成功后，让Client访问需要访问的资源

若CLient需要进行双向认证，验证成功后，返回给Client使用Session Key（Server-Client）得到新的时间戳并验证其是否正确。验证通过的话则Client可以信任该Server，可以发送服务请求

校验通过后，该票据会一直存于Client的内存中