之前两篇文章整理了NTLM协议的分析与利用
1、内网渗透——WINDOWS认证机制之NTLM
2、利用netsh抓取连接文件服务器的NET NTLM Hash
本篇文章来学习域内认证的Kerberos协议

文章目录

域认证Kerberos
- 系统角色
- Kerbreros认证流程
- - 具体过程
  - 1、用户登陆
  - 2、身份认证服务（AS）认证流程
  - - 2.1 客户端向AS发送认证请求
    - 2.2 AS确认Client端登录者用户身份
  - 3、票据授予服务（TGS）认证流程
  - - 3.1 客户端向TGS发送请求服务授权请求
    - 3.2 TGS为Client响应服务授权票据
  - 4.发送服务请求
  - - 4.1 Client向Service Server发送服务请求
    - 4.2 Service Server响应Client
  - 认证流程中需要关注的点，票据伪造的原理

参考：kerberos协议分析
参考：ares-x 域渗透学习（二） KERBEROS协议
参考：robert.broeckelmann kerberos-and-windows-security-kerberos-v5-protocol

域认证Kerberos

域内认证不再是两台机器之间互相请求认证，而是通过第三方可信机构KDC（Key Distribute Center）来实现整个认证体系

系统角色

参与域认证的三个角色：

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

从物理层面看，KDC的角色实际为域控制器(Domain Controller)，其中包含AD数据库与AS服务，TGS服务。

Kerberos相关的几个概念：

KDC(Key Distribution Center):密钥分发中心
AS(Authentication Server):身份认证服务
TGT(Ticket Granting Ticket)：由AS身份认证服务提供的票据也称为黄金票据，用于身份认证，存储在内存，默认有效期为10小时。
TGS(Ticket Granting Server)：由TGS服务提供的票据也称为白银票据，用于发出所请求服务的票证。

AD，全称叫Account Database，被称作活动目录数据库，存放在域控NTDS.DIT文件中，存储域中所有用户的用户名和对应的NTLM Hash，KDC可以从AD中提取域中所有用户的NTLM Hash，这是Kerberos协议能够成功实现的基础。

AS，全称叫Authenication Service，是KDC的组件之一，处理初始请求并负责发出TGT给Client，用来完成对Client的身份验证。

TGS，全称叫Ticket Granting Service，也是KDC的组件之一，从AS那里拿到TGT之后，TGS再发出对某个特定服务或服务器访问的Ticket，这个Ticket允许对某个服务访问。

Kerbreros认证流程

下图显示了Client、Server、KDC三者的协议交互过程。

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.对应下面过程1 用户登录
上图的2.3.4.对应下面过程2 客户端与AS认证
上图的5.6.7.对应下面过程3 客户端与TGS认证
上图的8.9.10.对应下面过程4 客户端与SS认证访问

1、用户登陆

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

2、身份认证服务（AS）认证流程

2.1 客户端向AS发送认证请求

客户端向AS发送带有明文 用户名 的认证请求

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

1、AS从AD数据库中查找该用户是否存在。
2、如果该 用户名 存在，则AS使用用户密码生成密钥，然后对响应消息Msg A进行加密。如果找不到，则将错误消息返回给客户端。
3、AS使用TGS密钥对Msg B进行加密。
4、AS将Msg A和Msg B返回给客户端。
5、客户端使用用户的密钥解密 Msg A。请注意，客户端无法解密 Msg B。

TGT（Msg B）中包含如下信息：
– [Client/TGS SessionKey]
– Client ID
– Ticket有效时间
– Client 地址

6、从解密的 Msg A中提取的Client/TGS SessionKey（Client/TGS 会话密钥）。

客户端无法解密Msg B，即无法解密TGT，解密需要TGS密钥，但是密钥存在于KDC上
需要了解：TGS密钥 == KDC Hash == krbtgt用户的NTLM Hash

AS响应的消息中有一条是属于Client的，但另外一条却属于TGS。
认证过程中的加密除哈希外均采用的是对称加密算法。

3、票据授予服务（TGS）认证流程

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

1、客户端发送消息 Msg C，以及 Msg D

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

2、TGS获取两个请求 Msg C 和 Msg D，先从 Msg C中获取TGT以及服务ID。
3、TGS接下来使用TGS密钥（即krbtgt用户的NTLM Hash）解密TGT，从TGT中提取到 Client/TGS SessionKey ，TGS 现在有了Client/TGS SessionKey。
4、TGS此时使用 Client/TGS SessionKey 解密Msg D，获得Authenticator 1 {Client ID, Timestamp}。
5、TGS比较 Msg C以及 Msg D获取到的Client ID。
6、如果相同TGS生成 Msg E以及Msg F，不同则报错误。

TGT在其生命周期内被缓存，并用于请求客户端需要的每个新服务票证。
CLIENT/TGS SESSIONKEY也由客户端缓存。

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

1、客户端接收到TGS发送的 Msg E 以及Msg F

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

2、客户端使用 CLIENT/TGS SESSIONKEY解密Msg F获得 CLIENT/SERVER SESSIONKEY

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

4.发送服务请求

4.1 Client向Service Server发送服务请求

1、客户端生成 Msg E 和 Msg G（Authenticator 2）。

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

2、客户端将 Msg E 和 Msg G 发送到服务器（SS）。
3、服务器使用其自己的密钥对 Msg E（ticket）进行解密，得到 Client/Server SessionKey
4、服务器使用上一步得到的 Client/Server SessionKey 解密 Msg G
5、比较消息 Msg E 和 Msg G中的Client ID。
6、如果匹配，则将Msg H发送给客户端，以确认服务器身份和服务客户端请求的意愿（此部分是可选的）。

4.2 Service Server响应Client

1、客户端收到Msg H。

Msg H是 Client/Server SessionKey 加密的时间戳

2、客户端使用 Client/Server SessionKey 解密Msg H。
3、客户端检查 Msg H的时间戳。
4、客户端现在信任服务器，可以与服务器进行交互。

来自SS的响应（Msg H）是可选的。仅在客户端希望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向SSService 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正常解密完成比对，也就是成功伪造了白银票据

1、黄金票据与白银票据需要拿到krbtgt或者server用户的hash，所以只能做为后门使用
2、白银票据利用之后无日志，所以比黄金票据更好
3、关于Service Hash，Service Hash其实是目标中一个用户名与hostname相同的用户的Hash
如hostname为PC-WIN7的服务器，对应的Hash就是Username : PC-WIN7$的哈希

内网渗透——WINDOWS认证机制之KERBEROS相关推荐

内网渗透-Windows内网渗透
内网渗透-Windows内网渗透文章目录内网渗透-Windows内网渗透前言一.信息收集 1.1.SPN 1.2.端口连接 1.3.配置文件 1.4.用户信息 1.6.会话收集 1.7.凭据收 ...
Windows认证机制之Kerberos协议
Windows认证机制首先,我们简短介绍下Windows的认证机制.主要有以下三种, 本地认证网络认证域内认证如图所示: Kerberos协议 Kerberos 是一种由 MIT(麻省理工大学 ...
【渗透测试笔记】之【内网渗透——Windows系统散列值获取与防范】
拓扑图 Windows系统散列值获取 1.通过CS模块获取用户凭证信息在获取到目标主机权限后,我们可以抓取hash和dump明文密码,这两项功能都需要管理员权限,如果权限不足,先要进行提权操作. 抓 ...
内网渗透----Windows下信息收集
一.基础信息收集使用systeminfo命令查看操作系统版本.架构.补丁情况 Windows-Exploit-Suggester-master -u 参数升级并将数据库下载至本地: -i 参数指定系 ...
内网渗透-windows远程用户管理
文章目录 0x01 获取window权限(管理员) 0x02 添加用户,并且到管理员组 0x03 开启远程桌面 0x04 添加到远程桌面组 0x05 进行远程 0x06 免责声明 0x01 获取win ...
内网渗透(二十四)之Windows协议认证和密码抓取-Mimikatz读取sam和lsass获取密码
系列文章第一章节之基础知识篇内网渗透(一)之基础知识-内网渗透介绍和概述内网渗透(二)之基础知识-工作组介绍内网渗透(三)之基础知识-域环境的介绍和优点内网渗透(四)之基础知识-搭建域环境内 ...
windows内网渗透PTH/PTK攻击
前言 windows内网渗透中,有三种最常用的pass系列攻击: pass the hash(hash传递攻击,简称pth) pass the ticket(票据传递攻击,简称ptt) pass th ...
内网渗透测试：Windows权限提升思路
我的Freebuf:https://www.freebuf.com/author/MrAnonymous 我的博客:https://whoamianony.top/ 文章目录 Windows系统内核溢 ...
内网渗透学习-Windows信息收集
内网渗透学习-Windows信息收集本章内容主要介绍在获取网站服务器webshell后,怎样对Windows主机进行信息收集,对其网络环境进行分析和利用,主要是一个思路整理,在后续的章节中会整理更详 ...

内网渗透——WINDOWS认证机制之KERBEROS