如何检测 Pass-the-Ticket 攻击

在本系列的第一篇文章中，我们探讨了如何检测 pass-the-hash 攻击，它利用 Active Directory 域中的 NTLM 身份验证。Pass-the-ticket 是一种相关攻击，它利用 Kerberos 身份验证来执行横向移动。

在这篇文章中，我们将深入探讨 pass-the-ticket 攻击的工作原理，以及你可以采取哪些措施来检测它。

Pass-the-Ticket（票据传递）如何工作

在 Pass-the-Ticket（票据传递）攻击中，攻击者会从某台系统的 LSASS 内存中提取 Kerberos 票据授予票据（Ticket Granting Ticket，TGT），然后在另一台系统上使用该有效票据请求 Kerberos 服务票据（Ticket Granting Service，TGS），以获取对网络资源的访问权限。

两者最主要的区别在于 pass-the-hash 与 pass-the-ticket：Kerberos 的 TGT 票据会过期（默认 10 小时），而 NTLM 哈希只有在用户更改密码时才会变化。因此，TGT 票据必须在有效期内使用；或者可以在更长时间内进行续期（7 天）。

Mimikatz 可用于执行 pass-the-ticket 攻击，但在这篇文章中，我们希望展示如何使用另一个工具 Rubeus 来执行该攻击。该工具可让你开展基于 Kerberos 的攻击。Rubeus 是由 Kekeo 编写的 C# 工具集，并基于 Benjamin Delpy（Mimikatz 项目。

步骤 1。提取 TGT。

使用 Rubeus 执行 pass-the-ticket 攻击的第一步是获取 TGT。根据安全设置，用户注销后系统中可能会也可能不会存储 TGT 和 NTLM 哈希。Rubeus 的一个既有趣又令人紧张的功能是 Monitor：它会查找 4624 登录事件，并把系统上任何新的登录会话的 TGT 数据导出（dump）。

如果使用下面的命令，Rubeus 将开始每 30 秒监视一次登录会话：

Rubeus.exe monitor /interval:30

现在，如果有人登录到该系统，我们就将获取他们的 TGT。为模拟这一点，我们将以用户身份运行一条命令：

Runas /user:[domainusername] cmd.exe

在 30 秒内，Rubeus 将检测到此 logon，并获取该用户的 TGT，然后将其输出为一个以 base64 编码的字符串：

我们可以将这个字符串复制到文本编辑器中，然后删除换行符和空格。

步骤 2：传递票据（Pass the ticket）。

既然我们已经窃取了票据，就让我们在它过期之前使用它。为此，我们仍然使用 Rubeus，但这次使用 ptt 命令：

Rubeus.exe ptt /ticket:[此处填写 base64 字符串]

你可以看到，已将遭入侵用户的 TGT 加载到会话中。现在我们可以利用它来请求 TGS 服务票据，从而以该用户的身份访问网络资源。

检测

你可以在终端（endpoint）或域控制器（domain controllers）上检测 pass-the-ticket。

在终端（Endpoint）上检测 Pass-the-Ticket

在研究如何检测 pass-the-ticket 时，我们发现了一种非常有意思的方法，由来自 Javelin Networks 的研究员 Eyal Neemany 发布。该方法建议：当你想要调查 pass-the-ticket 活动时，可以对环境中的任意终端（endpoint）执行以下步骤：

1. 查看该系统上的当前登录会话。
2. 使用 klist 命令检查与会话关联的 Kerberos 票据。
3. 查找与会话关联的用户不匹配的 Kerberos 票据。这表明票据可能已被注入到内存中，并且正在发生 pass-the-ticket（传票）攻击。

我们来更深入地了解这些步骤。

步骤 1。要输出所有登录会话，我们可以使用这个脚本，它改编自 GitHub 上的 Get-LoggedOnUsers 函数：

              $regexa = '.+Domain="(.+)",Name="(.+)"
      

第 2 步。 现在我们可以使用 klist –li 命令，并传入会话 ID，以查看与该会话相关联的票据。

第 3 步。 我们检查了用户 Michael 的一个会话，但发现了用户 Gene 的 Kerberos TGT。检测到 Pass-the-ticket！

在测试实验室中，这种方法运行稳定且没有误报，但如果你知道可能在 pass-the-ticket 之外的活动下触发这种情况的方法，请留言告知。

在域控制器上检测 Pass-the-Ticket

你也可以在域控制器上寻找 pass-the-ticket 行为。它的可靠性可能没有那么高，但拥有一种可以从 DC 日志中获取的检测方式始终是好事。

合法 Kerberos 身份验证的事件日志

为了理解需要关注什么，让我们回顾一下在网络中进行正常 Kerberos 身份验证时会看到的事件日志。

4768 – 已请求 Kerberos 身份验证票据（TGT）

你应该看到的第一个事件是一个 4768 事件。该事件表示 TGT 请求，也是用户利用 Kerberos 访问网络资源时必须发生的第一件事。每个用户在其从中访问你的域的每个终端上都会获得其中一条。如果同一用户账户从两台独立的工作站登录，则会分别向每台工作站请求 TGT。

此事件中最相关的信息是请求 TGT 的用户，以及发出请求的计算机：

4769 – 已请求 Kerberos 服务票据

Kerberos 身份验证的下一步是：用户使用该 TGT，并请求获取 TGS 服务票据，以访问计算机上的某项服务，例如通过 CIFS 访问文件共享。 这也会在事件 4769 的日志中出现，并显示请求该票据的用户以及源计算机：

4770 – 已更新 Kerberos 服务票据

更新 TGT 会生成事件 4770。默认情况下，TGT 最多可续期 7 天。若要测试这一点，Rubeus 提供了用于续期已提取 TGT 的命令“renew”。你也可以查看是谁续期了 TGT 以及续期的来源：

查找指示 Pass-the-Ticket 攻击的事件

那么，当发生 Pass-the-Ticket 活动时，事件日志里有什么不同之处？需要关注什么？通常攻击者会先窃取 TGT，然后在另一台系统上使用它。因此，你可以查看：使用特定 Account/Client 组合发起的 TGS 请求或 TGT 更新，但该 Account/Client 组合并没有关联到来自同一组合的 TGT 请求。你需要先查看某个 TGS 请求或 TGT 更新，然后回溯前 10 小时，看看是否存在与该用户和计算机匹配的 TGT 请求。这是因为在 Pass-the-Ticket 中，攻击者从不会请求 TGT；他们总是从 LSASS 中窃取。攻击者可能会对其进行续期，也很可能会用它来请求 TGS 服务票据。

不过，这种检测已经超出了事件日志筛选的范围；要在规模化环境中实现，可能需要 SIEM 或第三方产品。如果你正在寻找检测这种情况的方法，请查看 Netwrix Threat Manager，了解它如何帮助应对这一类威胁以及其他 Active Directory 攻击，例如 Golden Ticket、Pass the Hash 以及 Kerberoasting。

              $regexd = '.+LogonId="(d+)"
      

步骤 2。 现在我们可以使用 klist –li 命令，并传入会话 ID 来查看与该会话关联的票据。

步骤 3。 我们检查了用户 Michael 的会话，但看到了用户 Gene 的 Kerberos TGT。已检测到 Pass-the-ticket！

该方法在测试实验室中经过验证能够稳定运行，且不会产生误报。不过，如果您知道在 pass-the-ticket 之外的活动也可能触发该行为的任何方式，请留言告知我们。

在域控制器上检测 Pass-the-Ticket

您还可以在域控制器上查找 pass-the-ticket 行为。这种方法的可靠性可能没那么高，但能够从 DC 日志中获得检测结果始终是件好事。

用于合法 Kerberos 身份验证的事件日志

为了理解需要关注什么，让我们回顾一下网络中正常进行 Kerberos 身份验证时会看到的事件日志。

4768 – 已请求 Kerberos 身份验证票据（TGT）

你应该看到的第一个事件是 4768 事件。这是 TGT 请求，也是用户利用 Kerberos 访问网络资源时必须发生的第一件事。对从你域访问的每个终端，每个用户都会出现其中一条记录。如果某个用户账户从两台不同的工作站登录，他们将分别从每台工作站请求一个 TGT。

此事件中最相关的信息是请求 TGT 的用户以及他们从哪台计算机发起请求：

4769 – 已请求 Kerberos 服务票据

Kerberos 身份验证的下一步是：用户使用该 TGT 并请求 TGS 服务票据，以便访问计算机上的服务，例如使用 CIFS 访问文件共享。 这也会显示在事件 4769 的日志中，并会显示请求票据的用户以及源计算机：

4770 – Kerberos 服务票据已更新

更新 TGT 会生成事件 4770。默认情况下，TGT 最多可更新 7 天。 如果你想测试这一点，Rubeus 有一个命令 “renew”，用于更新已提取的 TGT。 你还可以查看是谁更新的以及更新的来源：

查找指示 Pass-the-Ticket 攻击的事件

那么在发生 pass-the-ticket 活动时，事件日志有什么不同之处？应该关注什么？ 很可能攻击者会窃取 TGT，然后在另一台系统上使用它，因此你可以寻找：使用某个特定的 Account/Client 组合发起的 TGS 请求或 TGT 更新，但该 Account/Client 组合并没有对应的 TGT 请求。 你需要查看某次 TGS 请求或 TGT 更新，然后回溯此前 10 小时，看看是否存在与该用户和计算机匹配的 TGT 请求。 这是因为在 pass-the-ticket 中，攻击者永远不会请求 TGT；他们总是从 LSASS 中窃取它。 他们可能会对 TGT 进行更新，而且肯定会使用它来请求 TGS 服务票据。

不过，这种检测超出了对事件日志的筛选；要在规模化环境中完成，可能需要 SIEM 或第三方产品。 如果你正在寻找检测这种情况的方法，请查看 Netwrix Threat Manager，了解它如何帮助应对这一类问题，以及其他 Active Directory 攻击，例如 Golden Ticket、 Pass the Hash 和 Kerberoasting。

              $logon_users = @(Get-WmiObject win32_loggedonuser -ComputerName 'localhost')

        $session_user = @{}
        $logon_users |% {
            $_.antecedent -match $regexa > $nul
            $username = $matches[1] + "" + $matches[2]
            $_.dependent -match $regexd > $nul
            $session = $matches[1]
            $sessionHex = ('0x{0:X}' -f [int]$session)
            $session_user[$sessionHex] += $username
               
        }
        $session_user
      

第 2 步。 现在我们可以使用 klist –li 命令，并传入会话 ID，以查看与该会话关联的票据。

第 3 步。 我们检查了用户 Michael 的一个会话，但看到的是用户 Gene 的 Kerberos TGT。检测到 Pass-the-ticket！

该方法在测试环境中可靠运行且未出现误报，但如果你知道是否可能由 pass-the-ticket 之外的活动触发，请留言告知。

在域控制器上检测 Pass-the-Ticket

在域控制器上也有办法查找 pass-the-ticket 行为。它可能没有那么可靠，但拥有一套可以从 DC 日志中获得的检测手段始终是有益的。

用于合法 Kerberos 身份验证的事件日志

为了理解需要关注什么，我们先来查看网络中正常进行 Kerberos 身份验证时会看到的事件日志。

4768 – 请求了一个 Kerberos 身份验证票据（TGT）

你应该首先看到的事件是一个 4768 事件。这是 TGT 请求，也是用户利用 Kerberos 访问网络资源时必须发生的第一件事。每个用户在从其访问你域的每个终端（endpoint）发起访问时，都会生成其中一个事件。如果某个用户账户从两台不同的工作站登录，他们将分别向每台工作站请求一个 TGT。

该事件中最相关的信息是：请求了 TGT 的用户，以及他们从哪台计算机发起请求：

4769 – 已请求 Kerberos 服务票据

Kerberos 身份验证的下一步是，用户使用该 TGT，并请求 TGS 服务票据以访问计算机上的某个服务，例如使用 CIFS 来访问文件共享。 这也会出现在事件 4769 的日志中，并显示请求该票据的用户以及源计算机：

4770 – 已更新 Kerberos 服务票据

更新 TGT 会生成事件 4770。默认情况下，TGT 可续期 7 天。要测试这一点，Rubeus 提供了命令“renew”，用于续期已提取的 TGT。你还可以查看续期的用户以及续期的来源：

查找指示 Pass-the-Ticket 攻击的事件

那么在出现 pass-the-ticket（传票）活动时，事件日志中有什么不同？应该留意什么？ 很可能攻击者会先窃取 TGT，然后在另一台系统上使用它。因此，你可以查看：使用某个特定的 Account/Client 组合发起的 TGS 请求或 TGT 更新，但该 Account/Client 组合并没有关联的 TGT 请求。 你需要先查看某次 TGS 请求或 TGT 更新，然后回溯之前的 10 小时，确认是否存在与该用户和计算机匹配的 TGT 请求。 这是因为在 pass-the-ticket 场景中，攻击者从不会请求 TGT；他们总是从 LSASS 中窃取它。 他们可能会对其进行续订，而且当然也可能会用它来请求 TGS 服务票据（service tickets）。

这种检测不仅仅是对事件日志进行筛选那么简单；要在规模化环境中实现，可能需要 SIEM 或第三方产品。 如果你正在寻找一种方法来检测它，可以查看 Netwrix Threat Manager ，了解它如何帮助应对这一点以及其他 Active Directory 攻击，例如 Golden Ticket、Pass the Hash 和 Kerberoasting 。