使用 NTP 进行定向 Timeroasting 窃取用户哈希值

【翻译】Targeted Timeroasting Stealing User Hashes With NTP

域管理员可以操纵用户属性来获取计算机账户以外的 MS-SNTP 哈希值。这可以作为一种替代性的特权凭据窃取技术。由于其与定向 Kerberoasting 和 AS-REP Roasting 等攻击的相似性，我将其称为"定向 Timeroasting"。在这些攻击中，通常无法被攻击的账户会被篡改使其变得脆弱，这可能使攻击者通过离线破解获取用户的明文密码。

Timeroasting 是由 Secura 的 Tom Tervoort 发现并记录的一种有趣攻击。该攻击依赖于 MS-SNTP，这是微软对 NTP 和 SNTP 协议的认证扩展，域加入的主机使用它与域控制器同步时间。

未经身份验证的客户端可以使用 RID 列表向域控制器发送 MS-SNTP 请求，以收集使用域计算机哈希值计算的 MD5 摘要。这使得 Timeroasting 成为一种可行的方法，可以比使用字典或像 pre2k 这样的工具更隐蔽地识别和破解预创建的机器账户和其他弱计算机密码。

正如我在关于弱计算机密码的文章中提到的，Timeroasting 有两个弱点：

• 它只能用于获取计算机哈希值
• 它需要一种将 RID 映射到用户名的方法，因此需要 NULL 会话或有效的域凭据

我发现 NTP 可以用来潜在地破坏 Active Directory 账户这一点非常有趣，但这些限制非常严格。这就是为什么我开始思考扩大 Timeroasting 范围的替代方法。

我问自己，域控制器如何检查一个账户是计算机还是用户？我们是否可以欺骗 Windows 认为用户账户实际上是一台计算机，并让它发送其哈希值给我们？答案是肯定的。

用户还是计算机？

AD 用户有一个 sAMAccountType 属性，它告诉我们对象所属的账户子类型，最常见的值是：

• SAM_NORMAL_USER_ACCOUNT (0x30000000) = 用户
• SAM_MACHINE_ACCOUNT (0x30000001) = 计算机

通常这个属性是不能修改的，即使是域管理员也不行。

幸运的是，对象的 sAMAccountType 会自动更新以反映其 userAccountControl 标志中找到的账户类型。这个属性实际上有几个标志来选择账户的特征：

• UF_NORMAL_ACCOUNT = 512（用户）
• UF_WORKSTATION_TRUST_ACCOUNT = 4096（计算机）
• UF_SERVER_TRUST_ACCOUNT = 8192（域控制器）

这些标志是互斥的，因为在任何时候只能设置其中一个值。当用户的 userAccountControl 更改为 4096 时，其 sAMAccountType 会自动更新为 SAM_MACHINE_ACCOUNT，使域控制器将其视为计算机。

根据 MS-SAMR 规范，在正常情况下，即使在目标账户上授予完全写入权限，也不应该可能修改现有账户的 userAccountControl 来将 UF_NORMAL_ACCOUNT 换成 UF_WORKSTATION_TRUST_ACCOUNT 或反之，但域管理员不受此规则限制。

这意味着不幸的是，定向 Timeroasting 不能用作非特权账户接管技术，像定向 Kerberoasting 和 AS-REP Roasting、影子凭据、ESC14 等。

在域控制器决定为用户账户计算 MS-SNTP 哈希值之前，它还会检查其 sAMAccountName 是否以 $ 结尾。对于域管理员来说，修改属性很简单，只要域中没有其他账户的名称是目标名称加上结尾的 $。

一旦用户的 userAccountControl 和 sAMAccountName 被修改，域控制器就会愉快地将其哈希值提供给任何询问的人。

概念验证

需要注意的是，当设置了 UF_WORKSTATION_TRUST_ACCOUNT 时，用户账户不能用于交互式登录。

已打开的会话似乎完全不受影响，如果在收到哈希值后立即恢复原始属性，用户不会注意到任何中断。

我修改了 Jacopo Scannella 的 PowerShell Timeroasting 脚本来制作一个粗略的概念验证，你可以在我的 GitHub 上找到。它需要使用域管理员凭据从安装了 PowerShell ActiveDirectory 模块的已加入域的主机上运行。它的工作方式如下：

1. 获取目标的 objectSid 和 userAccountControl 属性
2. 将目标的 userAccountControl 设置为 UF_WORKSTATION_TRUST_ACCOUNT（4096）
3. 在目标的 sAMAccountName 后添加 $
4. 验证属性是否正确修改（可选）
5. 提取 RID 并在 MS-SNTP 客户端请求中发送给域控制器
6. 从服务器响应中提取哈希值
7. 恢复原始的 userAccountControl 和 sAMAccountName 值
8. 检查恢复是否成功（可选）

如果我们查看数据包交换，我们会看到它实际上就是一个 NTP 事务，请求中提供 RID，回复中包含使用账户的 NT 哈希值生成的摘要。脚本从回复的 NTP 数据包字节中获取附加到哈希值的盐。

再次强调，这只是一个由没有严格 PowerShell 脚本编写经验的人制作的快速且粗糙的概念验证，由于脚本会暂时修改每个目标用户，我不建议对整个域使用它，而是针对少数选定的用户。

Hashcat 的 31300 模式可以帮助我们暴力破解这些哈希值，我们需要从源代码构建程序或下载测试版来使用这个模式：

hashcat -a 0 -m 31300 hashes.txt dictionary.txt

在我的情况下，除非我移除每个哈希值中的 RID，否则该模块无法工作。

结论

这类攻击的最大红色警报是：

• 同一主机发送多个带有不同 RID 的 MS-SNTP 客户端请求
• 这些请求中的 RID 属于用户而不是计算机
• 用户的 userAccountControl 的 UF_NORMAL_ACCOUNT 位 (0x0200) 被取消设置，而 UF_WORKSTATION_TRUST_ACCOUNT 位 (0x1000) 被设置，反之亦然
• 用户账户被修改，在其 sAMAccountName 末尾添加了 $

作为一种技术，当具有域管理员权限的攻击者希望找出特定用户的明文密码但不想冒被发现的风险时，这种方法可能很有用，因此决定避免使用可能触发警报的凭据提取方法。

参考资料

• https://www.secura.com/uploads/whitepapers/Secura-WP-Timeroasting-v3.pdf
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sntp/8106cb73-ab3a-4542-8bc8-784dd32031cc
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/4df07fab-1bbc-452f-8e92-7853a3c7e380
• https://github.com/SecuraBV/Timeroast/blob/main/timeroast.ps1