Active Directory 安全和事件日志面临的四大挑战

---

随着攻击者不断开发新策略来破坏凭证和数据，监控 Active Directory (AD) 等关键系统是否存在恶意活动迹象变得越来越重要。

许多组织向安全信息和事件管理 (SIEM) 产品寻求帮助。尽管这些解决方案非常强大，但它们最终依赖于 Windows 事件日志，这些日志使用起来很复杂，并且不提供监控多个关键 AD 攻击向量所需的信息。

本博客探讨了保护 Active Directory 的四个主要挑战，并解释了使用事件日志来解决这些挑战的局限性。

挑战 1. 监控群组成员资格的变化

Active Directory 安全组是授予用户访问 IT 资源（包括数据、计算机和应用程序）的主要方式。当攻击者在您的环境中横向移动时，他们通常会将已泄露的帐户添加到新的安全组中以获得额外的权限，因此跟踪安全组成员身份的更改至关重要。

跟踪提供特权访问的组的更改尤其重要。这包括内置组，例如域管理员、企业管理员和架构管理员，以及您的组织创建的提供提升访问权限的任何安全组。

事件日志捕获的内容及其局限性

Active Directory 会在事件日志中跟踪安全组的更改。例如，如果将用户添加到 Domain Admins 组，AD 将生成如下所示的事件，其中包括以下关键详细信息：

• 执行更改的用户的 ID
• 已更改对象的 DN 和类
• 更改的类型（在本例中为添加成员）

图 1. 显示安全组已修改的示例事件

然而，事件日志有几个重要的限制：

• · 没有记录更改的来源 - 事件日志不记录组成员身份更改的来源。尽管从跳转服务器或域控制器 (DC) 对域管理员组进行更改可能很正常，但从非管理工作站或其他面向 Internet 的计算机进行的更改可能是攻击的明显迹象。如果没有有关变化来源的详细信息，就不可能对来自异常位置的变化发出警报。
• · 不监控有效组成员身份 - Active Directory 仅记录对组的直接成员身份的更改。但是，组可以包含其他组作为成员。因此，要真正监视组成员身份的更改，您必须监视组本身以及嵌套在其中的每个组。
• · 事件之间不一致 - 记录的事件会有所不同，具体取决于组的更改方式。例如，如果使用 Active Directory 服务接口 (ADSI) 将用户添加到组，则事件日志将显示每个现有组成员的一个删除事件，然后是一个重新添加每个组成员的事件，然后是一个添加该组成员的事件。新用户;因此，将用户添加到具有 50 名成员的组中将生成 101 个事件日志条目。如果使用 LDAP 进行更改，则可能会列出对象的 GUID，而不是其可分辨名称。这些不一致可能会导致 SIEM 产品中的混乱和错误信息，并使针对收集的数据建立有效的规则变得极其困难。

挑战 2. 监控组策略的更改

组策略设置会影响 Active Directory 域中的用户和计算机，例如包括谁具有系统管理访问权限。对组策略对象 (GPO) 的单个更改可能会产生严重的安全影响或导致生产中断，因此监视这些更改至关重要。

事件日志捕获的内容及其局限性

当组策略更改时，将记录如图 2 所示的事件。此事件提供有用的信息，例如谁进行了更改以及 GPO 的标识符。

图 2. 记录组策略更改的事件

然而，这些事件缺乏以下关键信息：

• · 更改的设置及其前后值的详细信息 - GPO 支持数百种开箱即用和自定义设置。更改可能会修改用户的默认浏览器主页，或为所有用户提供对关键计算机的管理控制。但是，事件日志不会捕获更改的设置及其更改内容。
• · 更改来源更改 - 与安全组更改一样，记录组策略更改的事件并不表明更改来自何处。大多数 GPO 更改应来自选定的几个位置，并且能够识别来自异常位置的更改对于快速检测攻击至关重要。

挑战3.监控目录读取

保护 Active Directory 的另一个关键任务是监视用户帐户如何读取和枚举 AD 对象。希望在您的网络中立足的攻击者通常会枚举关键帐户、组和服务器，以便发现导致权限升级并最终导致敏感数据的攻击路径。通过监视可疑的读取事件，您可以检测到此侦察活动并在为时已晚之前阻止攻击。

事件日志捕获的内容及其局限性

为了帮助您了解谁在浏览 Active Directory，事件日志会捕获读取活动。该事件显示有关用户帐户、正在读取的对象以及正在执行的操作类型的详细信息，如图 3 所示：

图 3. 显示已读取 Domain Admins 属性的事件

然而，尝试使用这些事件来监视可疑活动有多个缺点：

• 太多噪音 - 记录读取事件会导致事件日志中出现太多噪音，以至于几乎不可能找到任何有价值的信息。事实上，用户查看某个组的单个实例可能会在日志中生成数十甚至数百个事件，这使得几乎不可能在所有合法事件中找到可疑活动。
• 没有读取来自何处的记录 - 而且，无法知道读取事件源自何处。正如我们对安全组和 GPO 的更改所看到的那样，了解读取事件来自哪台计算机对于确定读取事件是无害读取还是恶意侦察行为至关重要。
• 访问被拒绝事件太多 - 发现试图访问他们无权查看信息的用户也很重要。例如，Active Directory 可以在计算机属性中存储管理帐户的明文密码，因此尝试读取这些属性的用户帐户可能会尝试破坏特权凭据。不幸的是，每次任何帐户出于任何目的查看对象时，该操作都会为他们无权读取的所有属性生成访问失败事件，即使他们不打算读取这些属性。试图在无辜事件的海洋中找到真正可疑的失败访问事件根本不是一个可行的策略。
• 没有简单的方法来监控 LDAP 查询 - LDAP 查询通常用于探索 Active Directory 以发现用户、组和计算机。不幸的是，Microsoft 没有提供简单的方法来监视 LDAP 查询以查看发出的查询及其来源。由于这个问题，即使打开诊断级 LDAP 监控也没有什么价值；事实上，微软并不建议这样做，因为它会在事件日志中产生大量噪音。

挑战 4. 跟踪身份验证事件

随着最近基于凭据的攻击激增，监控身份验证模式对于识别受损帐户、哈希传递和票证传递攻击的迹象、伪造的 Kerberos 票证或用于获取特权和访问敏感信息的其他漏洞至关重要。数据。

事件日志捕获的内容及其局限性

Active Directory 捕获事件以监视域控制器、成员服务器和工作站上的用户登录和身份验证活动，包括下表中列出的事件：

Event IDDescriptionLogged to4768A Kerberos authentication ticket (TGT) was requested.Domain controller4769A Kerberos service ticket was requested.Domain controller4773A Kerberos service ticket request failed.Domain controller4776The domain controller attempted to validate the credentials for an account.Domain controller4771Kerberos pre-authentication failed.Domain controller4624An account successfully logged on.Server or workstation4625An account failed to log on.Server or workstation4634An account logged off.Server or workstation

虽然这些事件捕获了一些有用的信息，但由于以下缺点，它们并没有提供有效的方法来发现基于身份验证的攻击：

• 太多噪音 - 每次用户登录任何计算机时都会创建事件，这通常是大量活动。许多其他事件都是在幕后创建的。例如，当用户登录加入 AD 域的成员服务器时，服务器会启动与 DC 的连接，检索组策略信息，这会导致 DC 的事件日志中出现登录/注销事件。如果不忽略域控制器的关键登录活动，则无法禁用正常用户登录活动的日志记录。
• 没有 DC 上的登录类型记录 - 日志不会跟踪 DC 上登录事件的登录类型，而上下文对于确定帐户是否以适当的方式使用非常宝贵。例如，没有简单的方法来区分通过远程桌面登录的用户和通过映射网络驱动器的网络登录；您需要从每个成员服务器收集日志并尝试将它们与来自 DC 的日志关联起来。
• 缺乏特定于协议的详细信息 - 这些事件还缺少其他有价值的详细信息。例如，Kerberos 身份验证事件不会记录票证寿命和续订寿命时间戳，而这些时间戳是金票利用中使用的伪造票证的重要指标。同样，NTLM 日志不会指定所使用的 NTLM 版本，这些信息对于确定是否可以禁用较旧的 NTLM 版本以支持更安全的协议非常有价值。

Netwrix 如何提供帮助

正如我们所看到的，事件日志不足以及时检测攻击并有效响应。对于端到端保护，请考虑 Netwrix Active Directory 安全解决方案。它将帮助您：

• 通过深入的风险评估主动识别安全漏洞。
• 最大限度地减少代价高昂的停机时间和业务中断。
• 及时发现高级威胁并快速响应。