Kerberoast攻击检测之日志分析
Kerberoast是一种可以作为普通用户从Active Directory中提取服务帐户凭证而不需要向目标系统发送任何数据包的有效方法。这种攻击的效果非常好，因为人们会倾向于创建一些不是很强壮的密码。此攻击之所以能够成功的原因是因为大多数服务帐户的密码长度与域密码的最小长度相同（长度通常为10或12个字符），这意味着即使使用暴力破解所花费的时间也不可能超过密码的有效期。同时，大多数服务帐户没有设置密码的过期时间，因此很可能相同的密码会在很长时间内没有修改过而一直有效。此外，大多数服务帐户的权限都是过度授权的，而且通常情况下这些账户也是域管理员组的成员，在Active Directory中具有完全的管理权限（即使服务帐户的用途只是需要修改特定对象类型上的属性或特定服务器上的管理员权限）。
Tim Medin发布了Python版的Kerberoast TGS 破解器，并在DerbyCon 2014上讨论了这些方法。
本文所涉及的话题在我之前的博文“使用Kerberoast 破解 Kerberos TGS票证”和“AD权限持久控制技巧＃18：在管理员帐户设置SPN作为Kerberoast攻击后门”。还有Will Schroeder（harmj0y）和我一起在DerbyCon 2016上的演讲议题“如何利用Kerberoast提升权限”。
注意：如果是由Windows系统托管的服务，那么此攻击是不会成功的，因为在Active Directory中这些服务会映射关联到一个具有128个字符长度密码的计算机帐户，这种长度的密码不可能很快就被破解出来。
让我们快速介绍Kerberos身份验证的工作原理，然后再介绍Kerberoast攻击是如何工作的以及如何检测Kerberoast攻击活动。
Kerberos概述和通信过程
用户使用用户名和密码进行登录。
1a.将原始的明文密码转换为NTLM哈希，再将这个哈希和时间戳一起加密。最后，将加密的结果作为身份验证者发送到KDC进行身份验证的票据（TGT）请求（AS-REQ）。
1b.域控（KDC）检查用户信息（登录限制，组成员等）并创建票证授权票证（Ticket-Granting Ticket
-TGT）。
2.将TGT加密，签名并返回给用户（AS-REP）。只有域中的Kerberos服务（KRBTGT）才能打开和读取TGT数据。
3.当用户请求票证授权服务（TGS）票证（TGS-REQ）时，会将TGT发送给DC。 DC打开TGT并验证PAC校验和 - 如果DC可以打开票证并且校验和也可以验证通过，那么这个TGT就是有效的。之后，复制TGT中的数据用于创建TGS票证。
4.使用目标服务帐户的NTLM密码哈希对TGS进行加密并将加密结果发送给用户（TGS-REP）。
5.用户连接到服务器托管的服务的相应端口上并发送TGS（AP-REQ）给服务器。被托管的服务会使用服务账户的NTLM密码哈希打开TGS票证。
6.如果客户端需要进行相互之间的身份验证（可以想想MS15-011：在2月份发布的强化UNC的组策略补丁）就会执行这一步。除非需要验证PAC（很少有这样的情况），否则托管的服务会接受TGS票证中的所有数据，而且不会与DC进行通信。
SPN扫描目标
任何通过Active Directory验证的域用户都可以查询具有服务主体名称（SPN）的用户帐户。这使得攻击者能够访问网络上的计算机，并能够确定支持Kerberos身份验证的所有服务帐户及其用途。每个SPN的第一部分是该SPN的类型。例如，如果SPN是“MSSQLSvc / adsmsDB01.adsecurity.org：1433”，则SPN类型为“MSSQLSvc”。可以查看我整理好的 SPN目录列表，并查看Microsoft SQL Server的SPN。第二部分（正斜杠/后面的）是运行Kerberos服务的服务器名称。服务器名称可以是FQDN或短名称（通常是两者都有）。另外，有时会在结尾处有冒号（“：”）提供附加信息，例如端口号或SQL实例。任何人都可以执行“SPN扫描”，以确定在Active Directory林中已经注册的Kerberos服务的SPN。
攻击者最感兴趣自然是那些具有高权限用户组的服务帐户如域管理员组的成员。要快速列出高权限用户组的服务帐户的方法是枚举“AdminCount” 属性等于“1”的所有帐户。我在之前的一篇博文中（“Active Directory 域渗透之无管理员权限下的信息探测”）有提到过AdminCount这个属性，攻击者只需要向AD请求具有SPN且AdminCount = 1的所有用户帐户。
使用Active Directory powershell模块中的 Get-ADUser cmdlet：
get-aduser -filter {AdminCount -eq 1} -prop * |select name,created,passwordlastset,lastlogondate我们还可以使用PowerView中的Get-NetUser cmdlet：
Get-NetUser -AdminCount |Select name,whencreated,pwdlastset,lastlogon一旦我们有了这些数据，我们可以进一步过滤以确定哪些账户是服务帐户。
要找到有趣的服务帐户的另一种方法是基于SPN类型进行过滤。一些SPN往往具有一些比较有趣的权限：
AGPMServer：通常具有所有GPO的完全控制权。
MSSQL / MSSQLSvc：具有管理员权限的SQL服务器通常会有一些有趣的数据。
FIMService：通常对多个AD林具有管理权限。
STS：VMWare SSO服务，可以提供访问VMWare的后门。如果这些SPN的服务账户设置的密码不是很长并且也不复杂，或者如果服务帐户未配置为托管服务帐户，那么攻击者利用Kerberoast攻击技术对这些SPN进行攻击就可能会导致它们获得服务账户的登录凭证。
Kerberoast
此攻击方式主要是利用了请求目标服务帐户（上述步骤3）的服务主体名称（SPN）的Kerberos服务票证（TGS）。此请求需要使用有效的域用户的身份验证票证（TGT）去请求运行在服务器上的一个或多个目标服务的服务票证。域控在Active Directory中查找SPN，并使用与SPN关联的服务帐户加密票证，以便服务能够验证用户是否可以访问。请求的Kerberos服务票证的加密类型是RC4_HMAC_MD5，这意味着服务帐户的NTLM密码哈希用于加密服务票证。
我们可以使用以下PowerShell命令请求加密类型为RC4的Kerberos TGS服务票证：
$SPNName = ‘MSSQLSvc/adsmsDB01.adsecurity.org:1433’
Add-Type -AssemblyNAme System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $SPNName运行klist显示出使用RC4-HMAC加密生成的Kerberos服务票证。
接下来，导出我们刚刚从内存中请求的Kerberos票证，可以使用Mimikatz（无需管理员权限）轻松完成。
利用Kerberoast就可以尝试通过不同的NTLM哈希值来打开Kerberos票证，直到成功打开票证为止，此时，正确的服务帐户密码也就爆破出来了。域控不会跟踪或记录用户是否实际连接到了这些资源（即使用户有访问权限），因此攻击者可以请求数百个服务票证，即使他们从未真正连接到对应的服务。
注意：获取服务票证不需要提升权限，也不会向目标发送任何流量。
注意，使用Mimikatz时，不需要从内存中提取服务票证：可以阅读Will的博文“Kerberoasting without Mimikatz”
Kerberoast攻击活动缓解措施
缓解这种攻击的最有效的措施是确保服务帐户密码的长度超过25个字符（不容易被猜解）。
托管服务帐户和组托管服务帐户是确保服务帐户密码足够长，足够复杂并且定期更改的一个好方法。提供密码保管的第三方产品也是管理服务帐户密码的一种不错的解决方案。虽然任何第三方密码管理工具需要正确评估，因为关联的服务帐户通常需要域管理级别的权限来操作。此类评估还应包括如何在解决方案中管理这些域管理员用户的凭证。
配置日志记录检测Kerberoast攻击活动
在检测Kerberoast攻击活动之前，有一件重要的事情是启用适当的日志记录。
Kerberoast攻击会请求加密类型为RC4的Kerberos TGS服务票证。域控制器可以通过在“帐户登录”下面配置“审查Kerberos服务票证操作”来记录Kerberos TGS服务票证的请求行为，主要是记录成功的Kerberos TGS票证请求行为。
在域控制器上启用此审查类别会记录两个比较有趣的事件ID：
4769：请求了Kerberos服务票证（TGS）
4770：更新了Kerberos服务票证事件ID 4769会在域环境中被记录许多次，因为在初次登录（和请求Kerberos TGT票据）之后，用户在访问网络上的服务（文件共享，SQL，SharePoint等）时就会请求Kerberos TGS服务票证。预计每个用户每天会有大约10到20个Kerberos TGS请求记录。无论在任何环境中，域控制器上的4769事件是最多的事件之一，这就是为什么这个事件通常不会被记录。
检测潜在的Kerberoast攻击活动
我之前已经发表过检测潜在的Kerberoast攻击活动的方法：
1. 检测Kerberoast攻击非常困难，因为在用户需要访问资源时本来就会请求服务票证（Kerberos TGS票证）。
2. 寻找具有RC4加密的TGS-REQ数据包可能是最好的方法，尽管很可能会有“误报”。
3. 可以在Active Directory中监视许多Kerberos服务票证请求，启用Kerberos服务票据请求监视（“审计Kerberos服务票证行为”）并搜索产生过事件ID为4769的用户（Eventid 4769“请求了Kerberos服务票证”）。
以下是确定检测Kerberoast攻击活动的方法：微软从Windows Server 2008和Windows Vista开始，添加了Kerberos AES（128和256）加密，这意味着在任何现代Windows操作系统中大多数的Kerberos请求将使用AES进行加密。任何一个使用Kerberos RC4加密请求的票证都是例外情况。有些系统默认情况下仅支持Kerberos RC4加密（NetApp）。林与林之间的Kerberos票证使用的也是RC4，除非手动配置为AES – 确保你创建的林信任支持AES，然后通过信任启用AES加密。
那么，我们在看日志记录的事件时如何确定这个事件中使用了哪一种加密类型：0x12，0x17 …？
Ned Pyle（@NerdPyle）在TechNet的AskDS博客中发表了一篇关于“如何找到使用Kerberos DES加密的请求”的文章，并提供了下面这个方便的图表：
一旦在所有的域控上配置记录ID为4769的事件，那么在将数据发送到SIEM/Splunk之前，需要对这些事件进行过滤。由于我们只对RC4加密的Kerberos TGS服务票证感兴趣，所以可以通过过滤器过滤此类事件。如上所示，带有AES加密的Kerberos事件的票证加密类型设置为0x12。
使用Kerberos RC4加密过的票证的加密类型字段的值设置为0x17。
这些事件可以使用以下过滤器，这将大大减少流入SIEM/Splunk的事件数量：
票证选项：0x40810000
票证加密：0x17有了这些信息，我们就可以开始调查潜在的Kerberoast攻击活动并减少ID为4769的事件的数量。
注意：
除了要查找Kerberos RC4加密过的票证还要查找Kerberos DES加密，因为这个加密类型也不安全。票证选项可能不同，因此只需过滤ID为4768和4769的事件与票证加密类型：0x1或0x2或0x3。从Windows 7和Windows Server 2008 R2开始，DES加密被禁用，但仍然需要查找系统可能正在尝试（也许已经成功！）获得DES加密类型的 Kerberos票证，这很有必要去做而且也很重要。
我们可以进一步减少流入到SIEM/Splunk中的ID为4769事件的数量：
过滤掉服务帐户的请求（[email protected]）
过滤“审查成功”的请求
使用“$”符过滤掉那些通常用于计算机帐户（信任或托管的服务帐户，Windows会为所有此类帐户自动生成长而复杂的密码）的服务名称的请求。在有限的测试中，我已经看到通过使用这些过滤手段后，ID为4769的事件总数从数百万减少到数千，数百个。
这里有一个可疑的4769事件，很可能是Kerberoast攻击活动：
一些攻击者将使用类似于下图中的一些或所有服务帐户请求多个RC4 加密过的TGS票证。
上图中的PowerShell脚本代码与PowerView的功能类似。 下图显示了上述PowerShell脚本代码运行的结果。
运行klist命令显示在用户内存中缓存的票证信息。 请注意， 初始的krbtgt票证是AES加密的，但其他的是RC4-HMAC（NT）加密。 这有点不同寻常。
所以，还是可以请求RC4加密的票证…如何发现这种攻击活动？
我们可以使用PowerShell来解析DC的事件日志，来查找具有相关可疑的票证加密类型和票证选项信息且ID为4769的事件日志。
上图中的信息看起来很奇怪。为什么任何帐户都可以在一秒或两秒内请求多个不同的服务名称（Citrix PVS，BizTalk，Business Objects，AGPM GPO管理和多个SQL服务帐户）？
这些行为比较明显而且看起来确实很可疑，因此，这很可能就是Kerberoast攻击活动。这提供了关于哪些用户可能已被入侵以及在哪些计算机上的哪些活动应该进行仔细检查等这些很有用的信息。
单个用户请求多个服务的RC4加密过的TGS票据，例如大量的SQL服务主体名称等都比较可疑，而且也值得去调查请求来源的IP（客户端地址）。对于许多服务主体名称，多个RC4加密的TGS请求随时间的变化也都是一样的。当有一个或两个帐户请求多个或RC4 加密的TGS票证时，这种攻击模式就会显现。
如果你正在记录PowerShell活动，你可以使用我的PowerShell攻击特征来检测常见的PowerShell攻击工具。
我在上一篇文章“PowerShell攻击工具检测”和“PowerShell安全：PowerShell攻击工具，缓解措施和攻击检测”中都介绍了检测基于PowerShell的攻击。我还在2016年的BSidesCharm＆BSidesDC会议上介绍了PowerShell的安全性。
特别是下面这几个：
部署PowerShell v5（或更高版本）并启用PS模块日志记录和脚本块日志记录。
将以下PowerShell日志事件标识发送到中央日志记录中心解决方案中：400和800
将以下PowerShell操作日志事件标识发送到中央日志记录中心解决方案中：4100，4103，4104
配置脚本副本记录以便将每个系统的每个用户的所有活动的日志都发送到一个可写不可读的共享中，这个做法对于捕获那些可能错过或未记录到事件日志的可疑或恶意的攻击活动是非常有价值的。更好的做法是将这些PS脚本的副本文本文件放到像Splunk这样的平台中以供进一步分析。注意添加“KerberosRequestorSecurityToken”，这是PowerShell用来请求Kerberos票证的方法。
结论
Kerberoast攻击需要请求使用RC4加密过的Kerberos TGS服务票证，这样的行为不应该是网络上的大多数Kerberos的正常活动。在域控上记录ID为4769的事件，通过票证加密类型（0x17），已知的服务帐户（帐户名称字段）和计算机（服务名称字段）来过滤这些事件可以极大的减少转发到中央日志记录中心和警报系统的事件数量。收集并监测这些数据也可以创造一个良好的“安全”基线，以便于更容易的检测异常活动。