无法确定域的标识_域渗透(一)：Kerberos简介

“    世间最好的默契，并非有人懂你的言外之意，而是有人懂你的欲言又止。    by 瑞卡斯 ”0 1 活动目录简介

在90年代，微软引入了Windows专业版：Windows NT(New Technology)。Windows主机(服务器和工作站)按照“domains”进行分组。域是主机的逻辑组。他们由特定的Windows主机：域控制器(主域控制器和备域控制器)管理。使用域可以中心化管理用户和主机。

在Windows 2000(2000年发布)微软发布了Active Directory。活动目录在引入时，是Windows域的目录服务：类似于电话簿，包含域中包含的所有记录的元数据：用户，组，主机...

在Windows NT，域是独立的：如果组织在生产环境和开发环境都需要域，则需要创建2个域(使用对应的不同的域控制器)，在2个域之前很难建立关系，除非共享凭证。在引入活动目录后，可以创建一个层级的域：在域树(domain tree)里面，域之间可以建立信任关系。通过建立森林，可以将不同的域树连接在一起。需要注意的是，域不认为是安全边界，但森林是。

活动目录一个重要的功能是组策略：由多种配置(计算机和用户的配置设置)组成，组策略可通过域中心化地管理和应用。

活动目录的一个关键功能是安全：识别(Identification)，认证(authentication)，和授权(authorization)用户(和计算机)。攻击者经常攻击活动目录的这个功能。

Identification：用户在活动目录使用用户名标识自己。因为用户名不是机密的，所以需要进行认证。

Authentication：在提供用户名后，用户将提供一个私密的密码，向系统证明自己确实就是发起请求的个体。

Authorization：在用户成功认证后，活动目录将授权用户执行特定的活动(如登录工作站，访问文件或者目录)。

在活动目录，主要的认证机制是Kerberos。当由于某些原因，Kerberos认证不可用时，Windows将使用NTLMv2。

下面分别对kerberos协议和NTLMv2协议的认证过程进行简单介绍。

02 Kerberos认证介绍

Kerberos是一个基于票据(tickets)的的网络认证协议。这个协议允许2个部分(例如一个客户端和一个服务端)在不安全的网络通信中互相认证，通过2个部分都信任第三方：KDC实现。

kerberos认证过程主要涉及下面3个部分

• KDC(key distribution Center)：密钥分发中心，一般为域控。

• 客户端(client)：请求访问某个资源的客户端

• service：客户端想要访问的某个服务，如FTP服务，数据库服务等。

kerberos使用共享密钥来进行认证，在Windows域环境，只有一个共享密钥，即NTLM hash。在微软的kerberos协议中，密码hash用来加密所有东西。

在下面的例子中，Windows客户端使用Kerberos访问文件服务器，总体流程如下图：

下面对每一个步骤进行详细介绍。

步骤1：客户端发送认证请求

客户端发送一个包含日期和时间的认证请求到kerberos的KDC(key distribution Center)。部分消息是明文的，部分消息使用客户端的密码hash(灰色钥匙)加密。注意这里并没有在消息中包含密码信息。

步骤2：KDC检查客户端的凭证

因为KDC在它自己的数据库中安全地保存了所有用户的密码，包括客户端用户的密码hash，所以使用保存的客户端的密码hash尝试解密客户端发送的消息，如果解密成功，则认为用户认证通过，因为仅有用户自己知道他们的密码。

在认证成功后，KDC为客户端创建一个Ticket Granting Ticket(TGT)并发送给客户端。客户端后续可用这个TGT发起对具体资源的访问请求。

KDC使用只有服务器知道的密钥(紫色key)加密TGT，因为第三方无需知道这个密码，当客户端后续使用这个TGT向KDC发起访问请求时，KDC使用这个密钥(紫色key)解密消息进行认证。TGT将会保存在客户端RAM中的kerberos tray。TGT默认的有效时间为10小时。

步骤3：客户端使用TGT请求访问资源

在上面的例子中，当客户端需要访问文件服务器上的资源，它检查kerberos tray，因为没有对应的访问资源的票据(service ticket)，所以需要请求一个。

客户端使用之前从KDC收到的TGT的副本请求访问文件服务器。当KDC接收到新的请求，它知道用户已经认证过，所以不需要再次认证。

KDC仅仅检查是否可以用它之前记住的密钥(紫色密钥)解密TGT。

如果可以解密，则可以确定这个TGT是KDC之前发送的。

现在，KDC将创建一个service ticket(服务票据)，客户端可用这个ticket访问文件服务器。

因为KDC知道文件服务器的密码，它使用这个凭证(服务器密码hash,黄色key)加密ticket，然后将用于访问文件服务器的新的ticket将返回给客户端，客户端将接收到的service ticket存储到 kerberos tray。

注意客户端至始至终都看不到这些ticket的内容。它仅仅是存储和使用。

在文件服务器的ticket过期之前，当客户端想要访问文件时，可直接发送这个服务票据。

步骤5：客户端使用服务ticket验证

现在，当客户端想要访问文件服务器上的文件，它发送一个服务票据(service ticket)的副本。因为这个ticket是KDC使用文件服务器的密钥加密的，所以文件服务器可以使用自己的密码hash解密票据，验证用户，并授予对应的访问权限。

03 NTLMv2 Challenge Response

由于某些原因，kerberos不可用，此时，将会恢复到NTLMv2 Challenge / Response认证。

即使在同一个域中的成员主机之间，也可能会出现kerberos不可用的情况。例如，Kerberos依赖服务名称(service name)工作。如果我们没有服务名称，kerberos将不可用。如当我们使用IP地址访问文件服务器的共享，而不是使用服务器名称，将会使用NTLMv2进行认证。

NTLM认证分为3步：

1.协商(Negotiate)

2.挑战(Challenge)

3.响应(Response)

详细步骤如下：

1、客户端(Client)发送用户名到服务器(fileserver)(明文形式)

2、服务器(fileserver)创建一个16字节的随机数，称为challenge或nonce，然后发送给客户端(client)。

3、客户端(client)使用用户密码的hash加密这个随机数(challenge),然后返回给服务器(fileserver)。称为响应(response)。

4、服务器(fileserver)转发下面3个部分到域控服务器(DC)：

• 用户名

• 发送给客户端(client)的Challenge

• 从客户端(client)接收到的Response

5、域控(DC)使用用户名从Security Account Manager数据库提取用户密码hash。使用这个密码hash加密从fileserver接收到的challenge。域控使用自己计算的加密的challenge和客户端计算的response(步骤3)进行比较。如果2个匹配，则认证成功。

6、文件服务器(fileserver)授权客户端(client)访问对应的资源。

上面就是分别使用kerberos协议和NTLMv2协议认证的过程。

参考资料

https://docs.microsoft.com/zh-cn/windows/win32/secauthn/microsoft-ntlm?redirectedfrom=MSDN

https://cyberx.tech/kerberos-authentication/

https://www.redsiege.com/wp-content/uploads/2020/09/SIEGECAST-KERBEROS-AND-ATTACKS-101.pdf