走向DA -构建-突破-防御-修复

  • A+

简述

原文:https://blog.zsec.uk/path2da-pt2/
标题:Roasting your way to DA - Build-Break-Defend-Fix
(直译:走向DA -建设-突破-防御-修复)

作者:ANDY GILL

发布日期:2020年5月8日


image.png
现在你已经欣赏完了冬季苏格兰的美景。
欢迎来到我的DA系列的第二部分,在这篇文章中,我将介绍Kerberoasting和ASREP Roasting,深入了解它们是如何工作的,如何将它们引入环境中,以及如何修复它们或在可能的情况下监控和防御它们。

如果您错过了该系列的第一部分,可以在这里找到,这两者都是相互独立的,但它们是在网络上升级权限的不同方式,而且每一种都可以被防御或修复。

另外,如果你喜欢跟着视频,我在本月早些时候上传了这个
https://www.youtube.com/embed/lYa7niiWJi4?feature=oembed

  1. KDC将验证凭证,并发回一个加密的TGT和会话密钥,供客户访问特定服务。
  2. 使用票证授予服务(TGS)密钥对TGT进行加密
  3. TGT由客户端存储,当它过期时,本地会话管理器将请求另一个TGT(这发生在后台,用户/客户端看不到)。
    当客户端需要与另一个节点上的服务 (Kerberos 的术语是 "Principal") 通信时, 客户端会将 TGT 发送给 TGS, 而 TGS 通常与 KDC 共享同一个主机。服务必须在 TGS 注册一个服务主名 (SPN)。
    SPN是一种功能,用户可以向域控制器请求访问域上的某项服务,域控制器会回复一个与用户加密的该服务哈希值的凭证。
  4. 客户端向TGS发送当前的TGT,并附上客户端要访问的资源的服务主名称(SPN)。
  5. KDC验证用户的TGT,并验证用户是否可以使用服务。
  6. TGS向客户端发送服务的有效会话密钥。
  7. 客户端将会话密钥转发给服务,以证明用户有访问权限,服务授予访问权限。

Kerberoasting(T1558.003)

image.png
Kerberoasting 的工作前提是目标用户有一个非空的 SPN 属性。我们可以使用类似 john the ripper 或 hashcat 的东西来获取他们的 kerberos 哈希值并离线破解他们的密码。

构建

虽然有合法的功能来实现SPNs,但在可能的情况下(我将在后面的文章中深入探讨这个问题),建议使用长密码来设置任何服务账户,并且默认使用AES256而不是RC4。然而,在这个实验室的例子中,我们不打算选择AES256,而是要使用RC4。

首先,我们需要在AD中创建账户,这将是我们的服务账户。这可以通过域内任何一台机器上的域管理员来完成,但最简单的是在域控制器上。要做到这一点,有很多方法,但最简单的命令是:
net user zephr_adm password /add /domain
完成后,我们可以为用户添加一个SPN,具体如下:
setspn -s smb/purplehaze.offense:445 zephr_adm

这将为zephr_adm用户在445端口上设置SMB服务的服务主体名称。如图所示:

image.png

突破限制

为了使用kerberoast,有两种选择,在域上和域外/域外。 从域内的攻击路径开始(这是内部或网络钓鱼攻击中最有可能发生的情况)。
有三种工具可用于执行域内kerberoast:Rubeus、Sharproast和Invoke-kerberoast。是的,当然还有其他工具,但我将在这篇文章中介绍如何使用这三个工具执行攻击,以及如何破解在Hashcat中产生的散列:-)

Rubeus

Rubeus是一个用于与kerberos交互和滥用功能的C#工具集,它是GhostPack的一部分,可以从GitHub上拉到这里。它可以使用visual studio社区版进行编译,可以在这里下载。 只需在VS中打开.sln文件,然后选择Build->Build Solution

image.png
这将建立并将exe文件放到bin文件夹中,准备好用命令行或执行-assembly来使用。在这篇博客中,我将演示在域内机器上使用命令行接口,而不是通过命令和控制服务器(C2)。但是,无论如何,执行方法是相同的(有多种方法可以将其编译成库和其他东西)。

image.png
一旦我们建立了Rubeus,就需要对域控制器进行轮询,以寻找域上潜在的kerberoastable账户,我们可以通过从域连接的机器或在域用户的上下文中启动Rubeus来实现。
在这个阶段,值得注意的是,每次运行这个命令时,机器都会检索该域的所有kerberos ticket,因此需要考虑这个问题,因为它们也会被缓存。
Rubeus.exe kerberoast /format:hashcat

image.png
另外如果防守团队很聪明的话,他们可能会用域名账号蜜罐来实现蜜罐(后面会详细介绍如何从防守的角度来实现和跟踪)。

为了演示的目的,我们将追寻我们创建的zephr_adm账户,因此我们将使用该用户的RC4哈希值。这个命令只请求zephr_adm用户的RC4版本的哈希值,并将其输出为hashcat格式,以便于破解。
Rubeus.exe kerberoast /user:zephr\_adm /format:hashcat /tgtdeleg

image.png
我们用hashcat来破解哈希:

image.png
从哈希值我们可以看到是$23,说明我们检索到的哈希值是RC4。 这一点hashcat应该可以轻而易举的做到
.\\hashcat64.exe -m 13100 ep.txt wordlist.txt
对于那些从未使用过hashcat的人来说,上面的命令本质上是:
* hashcat64.exe:在Windows上运行hashcat64二进制文件
* -m 13100: 这是在告诉 hashcat 哈希特类型是什么, 这叫做掩码。在本例中, 我们指示它使用 Kerberos 5, etype 23, TGS-REP。
* ep.txt:这是哈希文件所在的地方, 可以叫任何名字, 但我把这个文件命名为ep.txt, 如上面的屏幕截图所示.
* wordlist.txt:这是一个字表,我们要根据这个字表进行哈希运算 来提取明文密码。

image.png
RC4_HMAC,所以比较容易破解,但是如果我们无法检索到RC4哈希值,另一个指标是$18,这是一个AES哈希值。Hashcat仍然可以尝试破解这个指标,但是由于使用的加密算法,需要的时间会更长。

除了rubeus之外,还有一些其他的方法可以在域连接的机器上提取哈希值,sharproast和invoke-kerberoast,它们的工作方式都很相似,如图所示。

SharpRoast

Rubeus的弟弟,也是该工具的基础,SharpRoast(名字中就有)是一个基于C#的工具集。它现在已经停产,转而使用Rubeus,不过可能还是有一些环境没有检测到它与Rubeus。

为了使用它,它还需要以与Rubeus相同的方式进行编译。一旦完成,该工具可以按照以下方式运行。
SharpRoast.exe all all
这个命令将请求该域的所有SPN,并返回哈希值,可以再次发送到hashcat或john the ripper。不过在这个演示中,为了方便访问,我们将指定
.\SharpRoast.exe zephradm

image.png
同样这个哈希值可以用hashcat,另一种方式技术来进行同样的操作,并进行破解。

Invoke-Kerberoast

最后可能是这段时间用的最多的就是这个攻击的powershell实现,虽然攻击者越来越远离powershell,但还是有一些环境可以有效的使用。

Invoke-Kerberoast是一个老模块,它被写进了powersploit和empire,但此后被许多框架和工具链采用。它本质上是一个与Rubeus和sharproast相同的powerhell脚本。

它可以简单地从powershell中运行:
Invoke-Kerberoast
这将以我们从Rubeus和SharpRoast那里得到的相同格式,丢出域名上所有的哈希值。

image.png
再次把哈希值放到hashcat中,有一个快速输出的方法:
Invoke-Kerberoast -OutputFormat HashCat|Select-Object -ExpandProperty hash | out-file -Encoding ASCII kerberosHashes.txt
这将把哈希值降到一个输出文件中,为破解做好准备。

Operational Security Considerations

虽然了解攻击是有用的,但在使用工具和技术时,了解操作安全影响(也称为运维安全)也同样重要。 具体来说,如果目标已经实施了蜜糖烘焙,那么有一些单行道可以让你在雷达下操作,比如:
Rubeus.exe kerberoast /pwdsetbefore:01-01-2017 /resultlimit:10
这将责成Rubeus要求所有SPN在2017年1月1日之前设置密码,这是在蜜糖烘焙的概念被引入之前,因此不太可能触发这方面的警报!

防御

现在我们已经看了如何构建和破解这个问题,重要的是要了解如何有效地监控网络上的使用情况,并识别类似的攻击。有几种检测使用情况的方法,特别是kerberoasting可以使用基于kerberos请求的检测或通过实现蜜糖烘焙来检测。与其重新发明轮子,不如看看我的同事Tim写的这篇关于honeyroasting的文章。
https://www.pentestpartners.com/security-blog/honeyroasting-how-to-detect-kerberoast-breaches-with-honeypots/
创建一个自定义的事件视图,以识别我们的蜜罐用户账户何时被请求使用 Kerberos 服务票据。这可以通过使用以下包含我们新创建的帐户的 XPath 查询来实现。如果我们不做这一步,在一个大型的活动目录环境中,将会有成千上万的4769事件日志,这将很难识别恶意活动。
<QueryList> <Query Id="0" Path="Security"> <Select Path="Security">\*\[System\[(Level=4 or Level=0) and (EventID=4769)\]\] and \* \[EventData\[Data\[@Name='ServiceName'\]='tkerb'\]\]</Select> </Query> </QueryList>
如图所示,可以快速简单的单线创建一个honeyroast账户,这需要微软的RSAT工具。
https://www.microsoft.com/en-gb/download/details.aspx?id=45520

``$UserPassword = ConvertTo-SecureString 'set a really long password in here for a user you want to have as a honeyroast account' -AsPlainText -Force`

New-ADUser -Name "tgttest" -AccountPassword $UserPassword -ChangePasswordAtLogon $false -City "London" -Company "CompanyName" -Country "UK" -Enabled $true -Description "Account used for testing access to senstive content" -Department "Privileged Accounts" -DisplayName "tgttest"  -SamAccountName "tgttest" -Path "OU=PrivilegedAccounts,dc=STREAM-DC,dc=purplehaze,dc=offense" -PasswordNeverExpires $true -AllowReversiblePasswordEncryption $true
```
本质上,这创建了一个对攻击者来说看起来非常多汁的账户,然而当kerberoasting被启动并且这个账户被触发时,它是识别网络上邪恶活动的一个可靠方法。

MITRE的其他建议包括:

启用审计Kerberos服务票操作来记录Kerberos TGS服务票请求。特别是调查不规则的活动模式(例如:账户在很小的时间范围内发出许多请求,事件ID 4769,特别是如果他们还请求RC4加密[类型0x17])。

修复

在实际修复问题方面,有几个关键的建议,如果可以帮助,尽可能不要使用RC4。使用长密码,或者使用服务账户的密码库。改变你的密码策略,要求100个以上的字符密码,这些密码是随机生成的,因此不太可能被破解。

实现对异常服务票据请求的检测,需要跟踪一个域中所有tgt票据请求的状态,这不是一项琐碎的任务。实现使用蜜罐账户来提醒恶意活动。
启用AES支持(取决于基础域支持2008+)。

image.png

ASREP-Roasting

image.png
ASEPRoasting与Kerberoasting类似,攻击方式也是查询账户的TGT,抓取哈希值,然后用我们最喜欢的密码破解工具hashcat进行破解。

在这个例子中,我将从一台域内机器上进行攻击,有很多帖子从各个角度深入研究,但很少有帖子能展示从头到尾的全过程。

构建

ASEPRoasting 最大的区别和注意事项是需要禁用 Kerberos 预认证。这是一个罕见的设置,与kerberoasting不同的是,它不是一个默认设置。

image.png
当您通过 Kerberos AS-REQ 消息请求 TGT 时, 您还需要提供一个与您的用户名和密码一起加密的时间戳。

密钥分发中心 (KDC) 会对时间戳进行解密, 验证该请求来自该用户, 然后继续进行身份验证过程。这就是 Kerberos 的预认证过程,这对攻击者来说显然是个问题,因为我们不是 KDC,无法解密该消息。当然,这是为了防止攻击而设计的,但是如果预认证被关闭,我们可以向任何用户发送 AS-REQ,并返回他们的哈希密码。

由于预认证是默认启用的,所以必须手动关闭,所以这种情况很少见,不过还是值得一提,因为这里有一个可行的攻击方式,可以为用户检索哈希值。

突破

Rubeus ASREP

同样和kerberoasting一样,ASREP也可以使用Rubeus进行攻击。要做到这一点,可以使用以下命令:
Rubeus.exe asreproast
这将查询到所有不需要预先认证的账户:

image.png
我们可以把这个哈希值在hashcat里用不同的掩码来破解:
.\hashcat64.exe -m 18200 epqa.txt wordlist.txt
幸运的是,asrep只有一个哈希类型,这让破解变得更容易,要使用账户有很多方法来重放凭证,如winrm、smb、rdp和LDAP。我将在后面的博文中提到这些技术,让你利用所学的技术。

Invoke-ASREP Roast

和kerberoasting一样,Rubeus也有一个对应的powershell,它可以让你提取asrep弱势用户的哈希值。
Invoke-ASREPRoast -Domain purplehaze.offense

image.png
同样这个哈希值也可以用hashcat轻松的取值和破解。powershell实现的缺点是,它更容易被AMSI和其他EDR监控等东西捕捉到,而Rubeus是以自己编译的方式提供的,以逃避简单的基于签名的检测,并能够更好地定制。

防御和修复

这个问题的主要修复方法是取消选中的方框,值得注意的是,由于第三方插件的依赖性,这可能并不总是可能的,因此,相反,可以应用相同的修复方法,如长密码和监控ASREP账户的潜在警报。

使用AS-REP,你会看到事件ID为4768和4625。这是因为用户不需要预先认证,因此攻击者不需要知道密码。

image.png
从防守的角度看,kerberoasting和asrep的主要区别是:
* 在Windows安全日志中,Kerberoast的事件ID为4768和4769,而AS-REP的事件ID为4768和4625。对我来说,AS-REP和Kerberoast最大的区别是登录失败,而且没有请求服务单。
* Kerberoast 有 AS-REQ/AS-REP 和 TGS-REQ/TGS-REP, 但 AS-REP Roasting 只使用 AS-REQ/AS-REP。这里的关键是因为 Kerberoast 请求的是服务帐号授权票据, 而 AS-REP 只请求 Kerberos 认证凭证。

总结

image.png
基本上,这两种攻击都可以在域内的机器上进行,并且可以让你升级权限,正如我们所看到的,这很容易在环境中实现,并且有很多工具可以进行攻击。困难总是落在防御和修复措施上,因为没有一个真正适用于所有情况的解决方案,当然在Kerberoasting的情况下,因此拥有一个积极主动的蓝色团队是最好的解决方案,而设置额外的陷阱(以蜜糖烘焙的形式)是一个很好的方法。

对Kerberoasting的检测是很难的,因为合法目的的服务请求确实发生了很多,但是如果你寻找以RC4格式化的服务请求,那么这应该标志着更多的恶意或异常活动。

下一篇文章将深入研究一些使用kerberos和其他有趣的方法的横向移动技术。

由于这是一个5部分系列的一部分,如果你错过了第一部分,可以在这里找到:
https://blog.zsec.uk/path2da-pt1/