在我的上一篇文章“检测Kerberoast攻击活动”中，我解释了Kerberoast攻击是如何工作的，并描述了如何检测潜在的Kerberoast攻击活动。检测的关键是理解什么样的活动是正常的，通过过滤掉“噪音”，提高警报的准确度。

这篇文章描述了如何从数百万个事件中过滤并检测Kerberoast攻击活动。

检测Kerberoast攻击活动

正如我在上一篇文章中所指出的，寻找使用RC4加密的TGS服务票证是一个用来发现Kerberoast攻击活动的一个很好的方法。

微软从Windows Server 2008和Windows Vista开始，添加了Kerberos AES（128和256）加密，这意味着在任何现代Windows操作系统中大多数的Kerberos请求将使用AES进行加密。任何一个使用Kerberos RC4加密请求的票证都是例外情况。有些系统默认情况下仅支持Kerberos RC4加密（NetApp）。林与林之间的Kerberos票证使用的也是RC4，除非手动配置为AES – 确保你创建的林信任支持AES，然后通过信任启用AES加密。

一旦在所有的域控上配置记录ID为4769的事件，那么在将数据发送到SIEM/Splunk之前，需要对这些事件进行过滤。由于我们只对RC4加密的Kerberos TGS服务票证感兴趣，所以可以通过过滤器过滤此类事件。如上所示，带有AES加密的Kerberos事件的票证加密类型设置为0x12。

使用Kerberos RC4加密过的票证的加密类型字段的值设置为0x17。

这些事件可以使用以下过滤器，这将大大减少流入SIEM/Splunk的事件数量：

票证选项：0x40810000
票证加密：0x17

有了这些信息，我们就可以开始调查潜在的Kerberoast攻击活动并减少ID为4769的事件的数量。

我们可以进一步减少流入到SIEM/Splunk中的ID为4769事件的数量：

过滤掉服务帐户的请求（[email protected]）
过滤“审查成功”的请求
使用“$”符过滤掉那些通常用于计算机帐户（信任或托管的服务帐户，Windows会为所有此类帐户自动生成长而复杂的密码）的服务名称的请求。

在有限的测试中，我已经看到通过使用这些过滤手段后，ID为4769的事件总数从数百万减少到数千，数百个。

这里有一个可疑的4769事件，很可能是Kerberoast攻击活动：

遵循这样的检测思路，我们可以查看具有特定票证加密和票证选项的TGS票证请求，以识别潜在的Kerberoast攻击活动。

我们可以使用PowerShell来解析DC的事件日志，来查找具有相关可疑的票证加密类型和票证选项信息且ID为4769的事件日志。

上图中的信息看起来很奇怪。为什么任何帐户都可以在一秒或两秒内请求多个不同的服务名称（Citrix PVS，BizTalk，Business Objects，AGPM GPO管理和多个SQL服务帐户）？

这些行为比较明显而且看起来确实很可疑，因此，这很可能就是Kerberoast攻击活动。这提供了关于哪些用户可能已被入侵以及在哪些计算机上的哪些活动应该进行仔细检查等这些很有用的信息。

单个用户请求多个服务的RC4加密过的TGS票据，例如大量的SQL服务主体名称等都比较可疑，而且也值得去调查请求来源的IP（客户端地址）。对于许多服务主体名称，多个RC4加密的TGS请求随时间的变化也都是一样的。当有一个或两个帐户请求多个或RC4 加密的TGS票证时，这种攻击模式就会显现。

详细的检测方法可以阅读本文开头提到的那篇文章，可以了解到Kerberoast攻击原理等的更多的详细信息。

过滤“噪音”以查找恶意攻击活动

我在本文开头提到的那篇文章中指出过，域控制器上的ID为4769的事件是非常多的，可能会是一些网络上数量最多的事件。

但是，如果我们只关心1个事件呢？

这会将ID为4769的事件的数量减少到只在恶意事件产生时的单个事件吗？

本文将会描述如何进一步将日志记录的事件数量缩小到最佳范围，以便检测网络上的Kerberoast攻击活动：创建服务帐户蜜罐。

注意：我仍然建议在域控制器上过滤ID为4769的事件，并将它们导入到SIEM/Splunk中，因为这将提供有关用户正在访问的资源的一些信息，以及能够作为在单个用户请求多个服务主体名称（这样的行为是可疑的）时的帮助标记。

创建Kerberoast服务帐户蜜罐

为了创建Kerberoast服务帐户蜜罐，我们需要在AD中创建一个用户帐户并给它设置一个假的服务主体名称（SPN）。这个SPN必须是假的，所以我们应该知道，当这个SPN被请求时，很显然这个请求将是无效的，但却是恶意的请求行为。同样重要的是，通过将“AdminCount”属性设置为1，使此服务帐户看起来更有吸引力（对攻击者来说），因为这会将此服务帐户标记为可能用于提升AD权限的域账户。将此帐户添加到一组伪造的用户组中，使其看起来像是能够用来提供额外的提升权限的方式，这些做法将有助于增添一些“迷幻色彩”。

步骤1：创建新的AD用户帐户。

步骤2：将“AdminCount”属性设置为1。

步骤2：向帐户添加服务主体名称（SPN）。 此SPN需要确保是唯一的，因此不应该简单地从另一个系统中直接复制。 SQL服务帐户比较常见，所以这不是一种“坏”的使用（MSSQLSvc / sql01.lab.adsecurity.org）。 只是不要重用已经存在的SPN。

下面的例子有点少…。 ?

步骤3：将蜜罐帐户添加到看起来可能具有管理员权限的假的用户组中可能也很有用。

注意：

为了让事情变得有趣，你可以为此帐户设置一个容易猜到的密码，例如“Password1234”（或常用的键盘组合式密码）。这样我们就可以监控是否有人使用此帐户进行登录。通过Kerberos TGS服务票据请求我们足以知道Kerberoast攻击活动是否正在发生，可以从日志记录的事件信息（“客户端地址”）中得知攻击行为是从哪个计算机上完成的。

检测Kerberoast服务帐户蜜罐的“访问”

一旦创建了蜜罐帐户并为此账户设置了不执行任何操作的服务主体名称，就不应该再请求或使用此SPN。不应该请求这个服务主体名称的原因是它用于搭建蜜罐，并且此SPN也没有链接到任何真正用于处理请求的应用程序。正常情况下，任何一个请求该SPN的Kerberos TGS服务票据都是没有理由的，因为没有运行与此SPN实际关联的服务。因此，如果我们看到有人请求了Kerberos TGS票证，他们很可能会尝试使用Kerberosast攻击爆破此帐户的登录凭证。

攻击者获得对内部网络的访问权限，并搜索具有服务主体名称且“admincount”属性为1的帐户。

上图显示了我们为攻击者准备的新的蜜罐帐户，从图中可以看到，攻击者对此账户很感兴趣并请求了使用RC4加密的Kerberos TGS票证的SPN。

使用Klist命令可以显示攻击者在内存中得到的TGS票证。

通过使用票证加密选项0x12（以及我在Kerberoast检测的文章中提到的其他过滤器）查找域控制器上的4769事件，我们可以看到Joe 这个用户请求了一个不存在的SPN的Kerberos票据，并且此SPN正常情况下是不应该被请求的，因为这是一个蜜罐！

帐户名称显示了请求时所使用的帐户，客户端地址提供了来自攻击者请求Kerberos服务帐户蜜罐的计算机的IP地址。

当我们在域控制器上运行需要处理域控事件日志且用于检测Kerberoast攻击的PowerShell脚本时，我们发现Joe这个用户请求了很多Kerberos服务票证，包括我们的蜜罐服务账户的票证（因为蜜罐的SPN实际上是不存在的，所以它不应该会有请求）。

使用服务帐户蜜罐，将检测从“潜在的”Kerberoast攻击活动变为“明确的”Kerberoast攻击活动。

注意，我们还可以配置一个IDS规则，检测带有服务名称“KerberoastHoneyPot”的TGS-REQ的数据包。

结论

Kerberoast攻击需要请求使用RC4加密过的Kerberos TGS服务票证，这样的行为不应该是网络上的大多数Kerberos的正常活动。在域控上记录ID为4769的事件，通过票证加密类型（0x17），已知的服务帐户（帐户名称字段）和计算机（服务名称字段）来过滤这些事件可以极大的减少转发到中央日志记录中心和警报系统的事件数量。收集并监测这些数据也可以创造一个良好的“安全”基线，以便于更容易的检测异常活动。

通过在域控制器上记录正确的活动行为可以检测到Kerberoast攻击活动。确定此活动行为是否是恶意的不需要深入了解RC4 加密的TGS票据在环境中的使用方式。创建具有不执行任何操作的SPN的服务帐户蜜罐提供了其他的数据点。发送到服务帐户蜜罐的Kerberos票据的任何请求都应该被视为是恶意的请求行为。