如何检测传票攻击

在本系列的第一篇文章中，我们研究了检测哈希传递攻击的方法，该攻击利用 Active Directory 域内的 NTLM 身份验证。传递票证是一种相关的攻击，它利用 Kerberos 身份验证来执行横向移动。

在这篇文章中，我们将深入探讨传票攻击的工作原理以及如何检测它。

传票如何运作

在传递票证攻击中，攻击者从系统上的 LSASS 内存中提取 Kerberos 票证授予票证 (TGT)，然后在另一个系统上使用此有效票证来请求 Kerberos 服务票证 (TGS) 以获得对网络资源的访问权限。

传递哈希值和传递票证之间的一个主要区别是 Kerberos TGT 票证会过期（默认情况下为 10 小时），而 NTLM 哈希值仅在用户更改密码时才会更改。 因此，TGT 票据必须在其有效期内使用，或者可以续订更长的时间（7 天）。

Mimikatz 可用于执行传递票据，但在本文中，我们想展示如何使用另一种工具 Rubeus 执行攻击，该工具可让您执行基于 Kerberos 的攻击。 Rubeus 是由 Harmj0y 编写的 C# 工具集，基于 Mimikatz 的作者 Benjamin Delpy 的 Kekeo 项目。

步骤 1. 提取 TGT。

要使用 Rubeus 进行传票攻击，第一步是获取 TGT。 根据安全设置，用户注销后，TGT 和 NTLM 哈希可能会也可能不会存储在系统上。 Rubeus 有趣/可怕的功能之一是监视器，它将查找 4624 登录事件并转储系统上任何新登录会话的 TGT 数据。

如果我们使用以下命令，Rubeus 将每 30 秒开始监控登录会话：

Rubeus.exe 监控/间隔:30

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

运行 /user:[域用户名] cmd.exe

30 秒内，Rubeus 将检测此登录并获取此用户的 TGT，并将其输出为 Base64 编码字符串：

我们可以将此字符串复制到文本编辑器中并删除换行符和空格。

步骤2. 传递门票。

既然我们已经偷了票，我们就在它过期之前使用它吧。 为此，我们将坚持使用 Rubeus，但这次使用 ptt 命令：

Rubeus.exe ptt /ticket:[此处为 Base64 字符串]

您可以看到我们已将受感染用户的 TGT 加载到会话中，现在我们可以使用它来请求 TGS 服务票证以作为该用户访问网络资源。

检测

您可以在端点或域控制器上检测传递票证。

检测端点的传递票据

在研究传票检测过程中，我们发现了 Javelin Networks 的研究员 Eyal Neemany 发布的一种非常有趣的方法。 它建议，当您想要调查传递票证活动时，可以对环境中的任何端点执行以下步骤：

1. 查看该系统上当前的登录会话。
2. 使用 klist 命令检查与会话关联的 Kerberos 票证。
3. 查找与会话关联的用户不匹配的 Kerberos 票证，这意味着它们被注入到内存中，并且传递票证攻击正在进行中。

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

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

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

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

第 3 步。我们检查了用户 Michael 的会话，但我们看到了用户 Gene 的 Kerberos TGT。 检测到传票！

这在测试实验室中工作可靠，没有误报，但如果您知道除传票之外的活动可以触发此操作的任何方式，请发表评论。

检测域控制器上的传递票证

还有一种方法可以在域控制器上查找传递票证行为。它可能不太可靠，但从 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。 您还可以看到续费的用户以及续费的来源：

查找表明传票攻击的事件

那么，当存在传递票证活动时，事件日志中有什么不同呢？应该寻找什么？ 攻击者很可能会获取 TGT，然后在不同的系统上使用它们，因此您可以使用特定帐户/客户端对查找 TGS 请求或 TGT 续订，而该帐户/客户端对没有关联的 TGT 请求。 您必须查看 TGS 请求或 TGT 续订，然后回溯过去 10 小时以查看是否存在与该用户和计算机匹配的 TGT 请求。 这是因为在传递票证中，攻击者永远不会请求 TGT；他们总是会从 LSASS 那里窃取它。 他们可以续订它，并且肯定可以使用它来请求 TGS 服务票证。

现在，这种检测超出了事件日志过滤的范围，大规模地进行检测可能需要 SIEM 或第三方产品。如果您正在寻找检测此问题的方法，请查看 StealthDEFEND，看看它如何帮助应对此攻击和其他 Active Directory 攻击，例如 Golden Ticket、Pass the Hash 和 Kerberoasting。

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

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

第 3 步。我们检查了用户 Michael 的会话，但我们看到了用户 Gene 的 Kerberos TGT。 检测到传票！

这在测试实验室中工作可靠，没有误报，但如果您知道除传票之外的活动可以触发此操作的任何方式，请发表评论。

检测域控制器上的传递票证

还有一种方法可以在域控制器上查找传递票证行为。它可能不太可靠，但从 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。 您还可以看到续费的用户以及续费的来源：

查找表明传票攻击的事件

那么，当存在传递票证活动时，事件日志中有什么不同呢？应该寻找什么？ 攻击者很可能会获取 TGT，然后在不同的系统上使用它们，因此您可以使用特定帐户/客户端对查找 TGS 请求或 TGT 续订，而该帐户/客户端对没有关联的 TGT 请求。 您必须查看 TGS 请求或 TGT 续订，然后回溯过去 10 小时以查看是否存在与该用户和计算机匹配的 TGT 请求。 这是因为在传递票证中，攻击者永远不会请求 TGT；他们总是会从 LSASS 那里窃取它。 他们可以续订它，并且肯定可以使用它来请求 TGS 服务票证。

现在，这种检测超出了事件日志过滤的范围，大规模地进行检测可能需要 SIEM 或第三方产品。如果您正在寻找检测此问题的方法，请查看 StealthDEFEND，看看它如何帮助应对此攻击和其他 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。 检测到传票！

这在测试实验室中工作可靠，没有误报，但如果您知道除传票之外的活动可以触发此操作的任何方式，请发表评论。

检测域控制器上的传递票证

还有一种方法可以在域控制器上查找传递票证行为。它可能不太可靠，但从 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。 您还可以看到续费的用户以及续费的来源：

查找表明传票攻击的事件

那么，当存在传票活动时，事件日志中有什么不同呢？应该寻找什么？ 攻击者很可能会获取 TGT，然后在不同的系统上使用它们，因此您可以使用特定帐户/客户端对查找 TGS 请求或 TGT 续订，而该帐户/客户端对没有关联的 TGT 请求。 您必须查看 TGS 请求或 TGT 续订，然后回溯过去 10 小时以查看是否存在与该用户和计算机匹配的 TGT 请求。 这是因为在传递票证中，攻击者永远不会请求 TGT；他们总是会从 LSASS 那里窃取它。 他们可以续订它，并且肯定可以使用它来请求 TGS 服务票证。

现在，这种检测超出了事件日志过滤的范围，大规模地进行检测可能需要 SIEM 或第三方产品。如果您正在寻找检测此问题的方法，请查看 StealthDEFEND，看看它如何帮助应对此攻击和其他 Active Directory 攻击，例如 Golden Ticket、Pass the Hash 和 Kerberoasting。