关于 kerberos 系列的文章目前将分为三节， kerberos 工作原理、 kerberos 攻击方式、 kerberos 委派攻击。本系列文章是在研究了很多相关文档和有关该主题的一些资料后写下的，意在记录知识/加强记忆，也对外输一些知识内容。
什么是 Kerberos？
kerberos 是 Active Directory 网络中域帐户的首选身份验证协议（它不能在工作组中使用），它由 kerberos SSP 实现。Kerberos 的细节在RFC 4120 中进行了描述，在 Active Directory 中使用的扩展记录在MS-KILE文档中。Kerberos 侧重于使用称为“票据”的令牌，它允许根据主体对用户进行身份验证。
kerberos SSP：
RFC4120：
MS-KILE：
Kerberos 相关
在本节中，将研究 Kerberos 的几个组件。
Kerberos 使用 UDP 或 TCP 作为传输协议，以明文形式发送数据；因此，Kerberos 负责提供加密。
Kerberos 使用的端口是UDP/88和TCP/88，应该在 KDC 中监听它们
几个代理一起在Kerberos中提供身份验证。
如下：
希望访问服务的客户端或用户
AP（Application Server）它提供用户所需的服务
KDC （Key Distribution Center），是Kerberos的主要服务，负责发行票据，安装在DC（域控制器）上；它由颁发 TGT 的 AS（身份验证服务）支持
Kerberos 可以处理一些结构，如票据，许多这些结构都经过加密或签名，以防止被第三方篡改。
这些关键如下：
KDC或krbtgt键，派生自krbtgt帐户NTLM哈希
从用户NTLM哈希派生的用户密钥
服务密钥，派生自服务所有者的 NTLM 哈希值，服务所有者可以是用户或计算机帐户
用户和 KDC 之间协商的会话密钥
在用户和服务之间使用的服务会话密钥
Kerberos 处理的主要结构是票据，这些票据交付给用户，以便用户使用它们在 Kerberos 领域中执行一些操作。
有2种类型：
在TGS （票据授予服务）是用户可以用它来对服务进行身份验证票据，它使用服务密钥加密
该TGT （票据授予票据）是提交给KDC以请求TGSS票，它使用 KDC 密钥加密
该PAC （特权属性证书）是一种包含在几乎所有票据中的结构，该结构包含用户的特权，并且使用KDC密钥进行签名。
服务可以通过与KDC通信来验证PAC（虽然这种情况并不经常发生），PAC验证只检查其签名，而不检查PAC内部的特权是否正确。
此外，客户端可以通过在票据请求的 KERB-PA-PAC-REQUEST 字段中指定 PAC 来避免将 PAC 包含在票据中。
几个用于验证 PAC 和票证数据完整性的签名
服务器签名：使用用于加密票证的相同密钥创建的 PAC 内容签名
KDC 签名：使用 KDC 密钥创建的服务器签名的签名，可用于检查 PAC 是否由 KDC 创建并防止票据击
票据签名：使用 KDC 密钥创建的票据内容的签名，最近引入了此签名以防止青铜位攻击（CVE-2020-17049）
PAC 签名：
CVE-2020-17049: Kerberos Bronze Bit Attack 原理：
Kerberos 使用不同种类的消息，最有趣的是以下几点：
KRB_AS_REQ：用于向 KDC 请求 TGT
KRB_AS_REP：用于通过 KDC 交付 TGT
KRB_TGS_REQ：用于使用 TGT 向 KDC 请求 TGS
KRB_TGS_REP：用于通过 KDC 交付 TGS
KRB_AP_REQ：用于使用 TGS 针对服务对用户进行身份验证
KRB_AP_REP：（可选）服务用于向用户标识自己
KRB_ERROR：用于传达错误情况的消息
此外，即使它不是 Kerberos 的一部分，而是 NRPC的一部分，AP 也可以选择使用 KERB_VERIFY_PAC_REQUEST 消息向 KDC 发送 PAC 的签名，并验证它是否正确。
下面显示了执行身份验证的消息序列摘要：
认证流程
在本节中，将研究执行身份验证的消息序列。
首先，用户必须从 KDC 获得一个 TGT。为此，必须发送 KRB_AS_REQ：
KRB_AS_REQ具有以下字段：
带有客户端密钥的加密时间戳，用于验证用户身份并防止重放攻击
认证用户的用户名
与krbtgt帐户关联的服务SPN
由用户生成的Nonce
注意：加密的时间戳只有在用户需要预认证时才需要，比较常见，除非在用户帐户中设置了 DONT_REQ_PREAUTH 标志。
接收到请求后，KDC通过解密时间戳验证用户身份，如果消息是正确的话，那么它会响应一个KRB_AS_REP：
DONT REQ PREAUTH：
KRB_AS_REP包含以下信息：
用户名
TGT，其中包括：
用户名
会话密钥
TGT 的有效期
具有用户权限的PAC，由 KDC 签名
一些使用用户密钥的加密数据，其中包括：
会话密钥
TGT 的有效期
用户的 nonce，以防止重放攻击
完成后，用户就已经拥有 TGT，可用于请求 TGSs，然后访问服务。
为了请求 TGS，必须向 KDC 发送 KRB_TGS_REQ 消息：
KRB_TGS_REQ包括：
使用会话密钥加密的数据：
用户名
时间戳
TGT
请求服务的SPN
用户生成的Nonce
收到KRB_TGS_REQ消息后，KDC 在KRB_TGS_REP内部返回一个 TGS ：
KRB_TGS_REP包括：
用户名
TGS，其中包含：
服务会话密钥
用户名
TGS的有效期
具有用户权限的 PAC，由 KDC 签名
使用会话密钥加密的数据：
服务会话密钥
TGS的有效期
用户 nonce，防止重放攻击
最后，如果一切顺利，用户已经拥有了一个有效的 TGS 来与服务交互，为了使用它，用户必须向 AP 发送一条KRB_AP_REQ消息：
KRB_AP_REQ包括：
TGS
使用服务会话密钥加密的数据：
用户名
时间戳，避免重放攻击
之后，如果用户权限正确，就可以访问服务。
攻击
基于前面解释的认证过程，本节将解释一下针对 Active Directory 的攻击。
流行的哈希传递 Pass The Hash (PTH) 攻击是使用用户哈希来模拟特定用户，在 Kerberos 的上下文中，这中方式被称为跨越哈希传递密钥（ Overpass The Hash o Pass The Key）。
如果攻击者获得了任何用户的哈希值，那么他就可以冒充 KDC 模拟该瀛湖，然后获得对多个服务的访问权限。
用户的哈希可以从工作站中的 SAM 文件或 DC 的 NTDS.DIT 文件中提取，也可以从 lsass 进程内存（通过使用Mimikatz）中提取，在那里也可以找到明文密码。
票据传递 技术是关于获取用户票据并使用它来模拟该用户。但是除了票据之外，还需要获得会话密钥才能使用票据。
由于 Kerberos 是通过 TCP 或 UDP 发送的，因此有可能获得执行中间人攻击的票据，但是这种技术不允许访问会话密钥。
另一种方法是从 lsass 进程内存中获取票据，其中也驻留了会话密钥，这个操作同样可以用Mimikatz来执行。
最好能获得 TGT，因为 TGS 只能用于一个服务。
另外，还要注意票据的有效期，超过有效期就不能使用了。
Golden Ticket（金票）的目标是建立一个 TGT，所以需要获取 krbtgt 账户的 NTLM hash，一旦获得，就可以构建具有自定义用户和权限的 TGT。
另外，即使用户更改了他的密码，票仍然有效，只有当它过期或 krbtgt 帐户更改其密码的时候，TGT 才会失效。
Silver Ticket 类似，不过这次内置的票是 TGS，在这种情况下，需要从服务所有者的帐户派生的服务密钥。但是如果没有 krbtgt 密钥，就不可能正确的签名 PAC。所以如果该服务验证 PAC，那么这个技术将不起作用。
Kerberoasting 是一种利用 TGS 离线破解用户帐户密码的技术，它从 Active Directory 中提取服务帐户凭据哈希以进行离线破解，攻击者不需要域管理员凭据即可发起此攻击，并且无需向目标发送数据包即可提取服务帐户凭据哈希。
如上所述，TGS使用服务密钥进行加密，服务密钥来自于服务所有者帐户的 NTLM 哈希，服务的所有者通常是执行服务的计算机，但是计算机密码非常复杂，所以尝试破解这些密码几乎是没有用的，krbtgt账户也会发生这种情况，所以TGT也几乎不会被破解。
虽然如此，但是在某些情况下，服务的所有者有时是普通用户帐户，在这种情况下，破解他们的密码更可行，这种帐户通常具有比较高的权限。
另外，因为 Kerberos 不执行授权检查，所以要获得任何服务的 TGS，只需要一个普通的域帐户。
ASREPRoast 与 Kerberoasting 类似，也是账户爆破。
如果在用户帐户中设置了属性DONT_REQ_PREAUTH，则可以在不指定其密码的情况下构建 KRB_AS_REQ 消息。
之后，KDC 将响应一条KRB_AS_REP消息，其中包含一些用用户密钥加密的信息，所以此消息可以用来破解用户密码。
在此篇文章中，我们研究了 Kerberos 的身份验证过程，并介绍了一些攻击方式。之后的文章将展示如何以实际的方式执行这些攻击，以及委托是如何工作的。
如有疏忽错误的地方，还请斧正，谢谢。
文章链接：
kerberos SSP_：https://docs.microsoft.com/en-us/windows/win32/secauthn/microsoft-kerberos_
RFC 4120 ：https://datatracker.ietf.org/doc/html/rfc4120
DONT_REQ_PREAUTH：https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties
跨越哈希传递密钥：https://blog.gentilkiwi.com/securite/mimikatz/overpass-the-hash
mimikatz：https://github.com/gentilkiwi/mimikatz
票据传递：https://blog.gentilkiwi.com/securite/mimikatz/pass-the-ticket-kerberos
Golden Ticket：https://blog.gentilkiwi.com/securite/mimikatz/golden-ticket-kerberos
Kerberoasting：https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/
ASREPRoast：https://www.harmj0y.net/blog/activedirectory/roasting-as-reps/
DONT_REQ_PREAUTH：https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties
kerberos SSP_：https://docs.microsoft.com/en-us/windows/win32/secauthn/microsoft-kerberos_
RFC 4120 ：https://datatracker.ietf.org/doc/html/rfc4120
DONT_REQ_PREAUTH：https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties
跨越哈希传递密钥：https://blog.gentilkiwi.com/securite/mimikatz/overpass-the-hash
mimikatz：https://github.com/gentilkiwi/mimikatz
票据传递：https://blog.gentilkiwi.com/securite/mimikatz/pass-the-ticket-kerberos
Golden Ticket：https://blog.gentilkiwi.com/securite/mimikatz/golden-ticket-kerberos
Kerberoasting：https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/
ASREPRoast：https://www.harmj0y.net/blog/activedirectory/roasting-as-reps/
DONT_REQ_PREAUTH：https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties
