在运营网络安全团队中工作的人员都知道，在了解 Active Directory 域内发生（或发生）的情况时，Windows 事件是多么重要。域控制器上的安全通道提供了多个与域身份验证相关的事件，包括我们将在这篇简短的文章中讨论的以下三个事件：

4768：请求了 Kerberos 身份验证票证（TGT）
4769：请求了 Kerberos 服务票证
4770：续订了 Kerberos 服务票证

在过去的几个月里，我们向 Microsoft 表达了有关 Active Directory 事件的几个缺点。其中之一是需要唯一标识 Kerberos 票证，我们将了解为什么它很重要。

需求

想象一下，从可疑的 AD 事件开始的调查，假设是 Kerberoasting 警报。在可疑的 4769 事件中，作为起点，您通常会公开发出 TGS 请求的用户以及该请求的源 IP。

如果还有来自该 IP 的合法用户活动，例如，在到达 DC 之前，已知设备执行 SNAT，该怎么办？您将如何区分合法和恶意的 AD 活动？

但是，如果我们能够唯一地识别为执行任何进一步操作（例如请求 TGS）而呈现的 TGT，我们将能够正确地分离活动。

另一种情况是，两个会话（合法和恶意）确实来自同一资产。下面给出了一个示例，其中我们有一个使用 AD 凭据（VPN 设备、Web 服务等）的公开服务，该服务完全遭到破坏。攻击者可以决定直接从同一台机器打开一个新会话，从 DC 的角度来看，我们也无法将合法行为与恶意行为区分开来。

解决方案

在其最新补丁中，Microsoft 从安全通道发布了 Windows 事件 4768、4769 和 4770 的新字段。活动的“票证信息”部分中的这些字段如下：

存在于 4769 和 4770 中：请求票证哈希
存在于 4768、4769 和 4770 中：响应票证哈希

顾名思义，第一个是提供给 DC 的 Kerberos 票证的唯一标识符，用于执行与事件相关的操作（即获取 4769 的 TGS，或续订 4770 的 TGS）。

第二个是 DC 签发的机票的唯一标识符，它可以是 TGT （4768）或 TGS （4769 & 4770），具体取决于相关事件。

我们如何使用它们？

响应

第一次直接申请是在调查期间。与在进程 ID 之间切换以查找可疑进程的整个进程树的方式相同，您将能够找到 Kerberos 票证树并回答 IR 中可能出现的关键问题，例如：在可疑会话期间执行的其他操作是什么？

在以下示例中，让我们回看 Kerberoasting 警报的示例。能够绘制整个票证树使我们能够显示攻击者在其恶意会话期间执行的所有其他操作，从而显示可能需要进一步调查的其他潜在影响操作。

检波

您还可以构建一些检测用例，这些用例或多或少是可行的，具体取决于您自己的边界。

第一个是关于检测伪造TGT（又名金票）的新机会。这个想法很简单：既然你有你的配送中心签发的所有TGT的指纹，如果你看到一个你不知道的指纹是为了获得TGS票而出示的，那么它一定是伪造的。

挑战是多方面的，这就是为什么它或多或少是可行的：

由于这些是 Microsoft 引入的新字段，它们是否可靠（请参阅下一段和登录 GUID）？
TGT 在我的环境中的生存期是多久？我是否有多个生存期不同的环境？
要获得 TGT 指纹的完整列表，我们不仅应该查看 4768 事件，还应该查看 krbtgt 服务的 4769 事件，以及 krbtgt 的 TGS 门票续订的 4770 事件

该搜索的草稿是这样的，TGT 默认生存期为 10 小时。我正在使用 Splunk 查询语言。

EventCode=4769 最早=-1h
NOT [ 搜索 EventCode=4768 最早=-11h
 |桌子Response_ticket_hash
 |重复数据Response_ticket_hash
 |重命名Response_ticket_hash as Request_ticket_hash ]
NOT [ search EventCode=4769 Service_Name=krbtgt* earliest=-11h
 |桌子Response_ticket_hash
 |重复数据Response_ticket_hash
 |重命名Response_ticket_hash as Request_ticket_hash ]
NOT [ search EventCode=4770 Service_Name=krbtgt* earliest=-11h
 |桌子Response_ticket_hash
 |重复数据Response_ticket_hash
 |重命名Response_ticket_hash Request_ticket_hash]