无需登录域控服务器也能抓 HASH 的方法

Delina

原文链接：无需登录域控服务器也能抓 HASH 的方法
​
Active Directory 帮助 IT 团队在整个网络中集中管理系统、用户、策略等。因为它是组织不可分割的一部分，所以这给攻击者提供了机会，利用 Active Directory 的功能来做一些恶意的操作。在这篇文章中，我们可以了解到 DCSync 的原理及检测方法。
关于 Active Directory 复制域控制器 (DC) 是 Active Directory (AD) 环境的核心。企业通常有多个域控制器作为 Active Directory 的备份，或者在每个区域都有不同的域控制器，方便本地身份验证和策略下发。
由于组织中有多个域控制器，所以每一次域内配置的更改，都要同步到其他域控制器。此更改需通过 Microsoft 目录复制服务远程协议 (MS-DRSR)与每个域控制器同步. AD 使用多个计数器和表来确保每个 DC 都具有全部属性和对象的最新信息，并防止任何无休止的循环复制。
AD 使用命名上下文 (NC)（也称为目录分区）来分段复制。每个域林至少有三个 NC：域 NC、配置 NC 和模式 NC。AD 还支持特殊的 NC，通常称为应用程序分区或非域命名上下文 (NDNC)。DNS 使用 NDNC（例如，DomainDnsZones、ForestDnsZones）。每个 NC 或 NDNC 都相互独立地复制。
关于 DCSync 攻击DCSync 是一种用于从域控制器中提取凭据的技术。在此我们模拟域控制器并利用 (MS-DRSR) 协议并使用 GetNCChanges 函数请求复制。作为对此的响应，域控制器将返回包含密码哈希的复制数据。Benjamin Delpy 以及 Vincent Le Toux 于 2015 年 8 月在 Mimikatz 工具中添加了这项技术。
要执行 DCSync 攻击，我们需要对域对象具有以下权限：
1）复制目录更改（DS-Replication-Get-Changes）
2）全部复制目录更改 ( DS-Replication-Get-Changes-All )
3）在过滤集中复制目录更改（DS-Replication-Get-Changes-In-Filtered-Set）（不一定用，但是为了以防万一将其开启）
通常管理员、域管理员或企业管理员以及域控制器计算机账户的成员默认具有上述权限：

​

DCSync 攻击场景我们将在这篇博文中查看 2 个场景（注意：您可以想到执行 DCSync 攻击的更多场景）：
1）假设我们已经有了一个域管理员的账号权限
2）假设我们拥有对域有 WriteDACL 权限的用户凭据
1) 第一个场景
假设我们已经获得了属于 Domain Admins 组成员的用户账户。在我们的实验室中，我们有一个名为 storagesvc 的用户，它是 Domain Admins 组的成员，如下面的屏幕截图所示。

​

所以我们现在可以使用 Invoke-Mimikatz PowerShell 脚本执行 OverPass-The-Hash 攻击，并使用 storagesvc 用户的权限启动一个新的 PowerShell 控制台:
正在上传…重新上传取消
在 New PowerShell 控制台中，我们可以加载 Invoke-Mimikatz PowerShell 脚本并执行 DCSync 攻击:
正在上传…重新上传取消
正如我们在上面的屏幕截图中看到的，我们能够成功执行 DCSync 攻击并检索 KRBTGT 账户哈希。
2) 第二个场景
假设我们已经找到了对域对象具有 WriteDACL 权限的用户的明文凭据。在我们的实验室中，我们有一个名为 sharepointmaster 的用户，他对域对象具有 WriteDACL 权限，如下面的屏幕截图所示。

​

我们将利用 PowerView 脚本将 DCSync 权限授予我们拥有的另一个用户（对手）。
注意：- 我们也可以将 DCSync 权限授予 sharepointmaster 用户。

​

我们将枚举并确认对手用户是否具有 DCSync 权限。

​

正如我们在上面的屏幕截图中看到的那样，我们能够成功地将 DCSync 权限授予对手用户。
现在，我们将加载 Invoke-Mimikatz PowerShell 脚本并执行 DCSync 攻击:
正在上传…重新上传取消
正如我们在上面的屏幕截图中看到的，我们能够成功执行 DCSync 攻击并检索 KRBTGT 账户哈希。注意：还有其他工具也可以执行 DCSync 攻击，例如 Impacket Library & DSInternals 等。
​​
检测为了检测 OverPass-The-Hash 攻击、基于 ACL 的攻击和 DCSync 攻击，我们需要在模拟攻击之前在域控制器上启用少量日志。在我们的实验中，我们已经启用了这些日志。但是您可以按照下面提到的步骤在您的环境中启用日志。
我们还在实验室中部署了 Sysmon 以进行额外的日志记录。您还可以在您的环境中使用 Sysmon 模块化配置部署:

https://github.com/olafhartong/sysmon-modular

要捕获登录事件，我们需要启用“审核登录”日志。按照以下步骤启用日志:

•         登录域控制器
  
•         打开组策略管理控制台
  
•         展开域对象
  
•         展开组策略对象
  
  

•         右键单击默认域策略并单击编辑（应用于所有域计算机的策略。它可能在您的环境中有所不同）
  
  

•         按照以下路径启用审核登录事件: 计算机配置 --> Windows 设置 --> 安全设置 --> 高级审核策略配置 --> 审核策略 --> 登录/注销 --> 审核登录
  
•         选择“配置以下审计事件：”复选框
  
•         选择成功和失败复选框
  
  

要捕获目录服务访问事件，我们需要启用“审核目录服务访问”日志。按照以下步骤启用日志:

•         登录域控制器
  
•         打开组策略管理控制台
  
•         展开域对象
  
•         展开组策略对象
  
  

•         右键单击默认域策略并单击编辑（应用于所有域计算机的策略。它可能在您的环境中有所不同）
  
  

•         按照以下路径启用审核登录事件: 计算机配置 --> Windows 设置 --> 安全设置 --> 高级审计策略配置 --> 审计策略 --> DS 访问 --> 审计目录服务访问
  
•         选择“配置以下审计事件：”、“成功”和“失败”复选框
  
  

要捕获目录服务更改事件，我们需要启用“审核目录服务更改”日志。按照以下步骤启用日志。

•         登录域控制器
  
•         打开组策略管理控制台
  
•         展开域对象
  
•         展开组策略对象
  
  

•         右键单击默认域策略并单击编辑（应用于所有域计算机的策略。它可能在您的环境中有所不同）
  
  

•         按照以下路径启用审核登录事件: 计算机配置 --> Windows 设置 --> 安全设置 --> 高级审核策略配置 --> 审核策略 --> DS 访问 --> 审核目录服务更改
  
•         选择“配置以下审计事件：”、“成功”和“失败”复选框
  
  

在我们的实验室中，我们使用HELK设置来解析和查询日志，并使用winlogbeat将日志从各个系统推送到HELK实例。
检测 OverPass-The-Hash
现在让我们运行以下查询来检测在执行 OverPass-The-Hash 攻击时生成的登录事件。

event_id ：4624
logon_type ：9
logon_process_name ：seclogo

在上述查询中，我们可以搜索包含 logon_type 9 和 logon_process_name seclogo 的事件 ID 4624 日志。

事件 ID 4624 - 创建登录会话时生成此事件。
登录类型 9 - 调用者克隆了其当前令牌并为出站连接指定了新凭据。新的登录会话具有相同的本地身份，但对其他网络连接使用不同的凭据。当我们执行 OverPass-The-Hash 攻击时，登录类型为 9。
登录进程 - 用于登录的可信登录进程的名称。当我们执行 OverPass-The-Hash 攻击时，一个名为“seclogo”的登录进程。

​

​

在执行 OverPass-The-Hash 攻击时，Mimikatz 尝试访问 LSASS 进程。运行以下查询以检测是否以某些特权访问 LSASS 进程，这些特权在机器上运行 Mimikatz 以提取凭据或执行 OverPass-The-Hash 攻击时很常见。

host_name ：“oil-attacker.oil.crude.corp”
event_id ：10
process_granted_access_orig ：（“ 0x1010”或“0x1038” ）

在上述查询中，我们在“oil-attacker”机器上搜索事件 ID 10 日志，该机器已授予对 LSASS 进程的特定访问权限。我们可以在这里查找特定进程的访问权限:

​

这种攻击也可以通过 ATA 检测为“异常协议实现”

​

检测 DCSync
我们可以运行以下查询来确定是否执行了 DCSync 攻击。

event_id : 4662
log_name : "Security"
object_properties : ( "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"或"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"或"89e95b76-444d-4c62-9901a ) -

上述查询中提到的 GUID 是执行 DCSync 攻击所需的 Replication 权限的 GUID。

​

​

​

我们还可以利用网络流量来检测 DCSync 攻击。需要在域控制器上安装一个工具 DCSYNCMonitor 来监控网络流量:

https://github.com/shellster/DCSYNCMonitor

当通过网络执行任何复制时，此工具会触发警报。当真正的域控制器请求复制时，这可能会触发误报警报。因此，建议使用 DCSYNCMonitor 工具和配置文件，我们在其中指定网络中域控制器的 IP 地址，以避免误报警报。
我们可以运行以下查询来识别由 DCSYNCMonitor 工具触发的警报:

event_id ：1
source_name ：“DCSYNCALERT”

​
在上面的屏幕截图中，我们可以看到 IP: 172.16.1.2 地址的误报警报，因为它是真实的域控制器。这是为了在使用 DCSYNCMonitor工具时突出配置文件的重要性。
这种攻击也可以通过 ATA 检测为“目录服务的恶意复制”。
​
检测 ACL 修改
我们可以运行以下查询来识别我们授予对手用户 DCSync 权限的 ACL 修改。

event_id ：5136
log_name ：“Security”
dsobject_class ：“domainDNS”

修改 ACL 时会生成多个事件。
事件日志计数将始终为偶数，因为单个 ACL 修改始终有 2 个事件。同样可以通过使用“相关 ID”过滤来验证。一个事件是“Value Deleted”（ACL 删除/删除），第二个事件是“Value Added”（ACL 添加/修改）。

​

​

​

我们还可以使用 PowerShell 命令:“ConvertFrom-SddlString”转换“nTSecurityDescriptor”值，以获取有关所做更改的更多详细信息。
注意：- 此命令无法检索 DCSync 权限的值，我们将始终将值视为“WriteAttributes”，我们需要从加入域的机器上运行此命令。

​

建议建议定期审核有风险的基于 ACL 的错误配置，因为这可能会导致整个域环境受到损害。
​