在运营网络安全团队中工作的人员都知道，在了解 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]
此查询中仍存在一个打开的窗口，该窗口可能允许攻击者仍使用伪造的 TGT 来获取未检测到的 TGS。我会让读者找到破绽！
第二个用例示例是检测 Pass-The-Ticket 场景的新机会。攻击者可以选择窃取现有票证并重新使用它，而不是请求新票证，可能来自其他资产。为了检测这一点，我们可以简单地查看给定票证在其生命周期内使用的不同源 IP。
挑战也是多方面的：
- 再说一次，SNAT呢？
- 人们的笔记本电脑在工单的生命周期内被分配了多个IP（例如，如果他们在建筑物内移动）怎么办？
我再次猜测，回复将取决于您自己的环境。解决方法的一个示例是简单地将此搜索限制为服务帐户，这些帐户仍经常成为攻击者的目标。
与登录 GUID 有什么区别？
其中一些人可能已经使用登录 GUID 字段来执行本文中介绍的一些透视。如 Microsoft 文档所述，登录 GUID 在技术上允许将 4769 与身份验证事件链接。
实际上，众所周知，通常不可能这样做，例如在Windows事件圣经中解释的那样。不过，如果您不相信自己，我鼓励您自己进行测试。
但是，4624 事件本身非常重要，因为它提供了有关会话级别本身的重要信息（是否提升了令牌等），而 4768 事件提供了票证级别的信息。换句话说，如果您能够关联 4624 事件，它总是有用的。