监控 Active Directory 安全性的四大挑战

由于攻击者不断开发新的策略以窃取凭据并危害数据，监控诸如 Active Directory（AD）之类的关键系统是否存在恶意活动迹象，变得愈发重要。

许多组织会求助于 安全信息和事件管理（SIEM）产品。但尽管这些解决方案可能非常强大，最终仍然依赖 Windows 事件日志——而这些日志难以处理，并且无法提供监控若干关键 AD 攻击向量所需的信息。

这篇博客探讨确保 Active Directory 安全的四个最主要挑战，并说明仅使用事件日志来应对这些挑战的局限性。

挑战 1：监控组成员变更

Active Directory 安全组 是向用户授予访问 IT 资源（包括数据、计算机和应用程序）的主要方式。随着攻击者在您的环境中进行横向移动，他们往往会将已被攻破的账户添加到新的安全组中，以获得额外权限，因此必须跟踪安全组成员的变更。

跟踪提供特权访问的组的变更尤其重要。这包括内置组，例如 Domain Admins、Enterprise Admins 和 Schema Admins，以及组织创建的、提供更高访问权限的任何安全组。

事件日志会记录什么——以及它的局限性

Active Directory 会在事件日志中跟踪对安全组的更改。例如，如果将某个用户添加到 Domain Admins 组，AD 将生成类似下图所示的事件，其中包含以下关键细节：

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

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

但是，事件日志有几个重要的限制：

• · 没有记录变更来自哪里 — 事件日志不会记录对组成员身份的更改来源。尽管从跳转服务器或域控制器 (DC) 对 Domain Admins 组进行更改可能是正常现象，但从非管理工作站或其他面向互联网的机器进行更改可能是攻击的明显迹象。在缺少变更来源的详细信息的情况下，就无法针对来自异常位置的变更发出警报。
• · 无法监控实际（有效）的组成员身份 — Active Directory 只会记录对组的直接成员身份的更改。不过，组可以将其他组作为成员包含在内。因此，要真正监控组成员身份的变化，必须监控该组本身以及其中嵌套的每个组。
• · 事件之间存在不一致 — 记录的事件会根据组是如何被更改而有所不同。例如，如果使用 Active Directory Service Interfaces (ADSI) 将用户添加到某个组，事件日志会显示：每个现有组成员都有一条移除事件；随后每个组成员会各有一条将其添加回去的事件；最后再有一条添加新用户的事件。因此，将用户添加到拥有 50 个成员的组中，将生成 101 条事件日志条目。如果使用 LDAP 进行更改，则可能会列出对象的 GUID，而不是其专有名称（distinguished name）。这些不一致可能会导致 SIEM 产品中的混淆和错误信息，并使基于收集到的数据构建有效规则变得极其困难。

挑战 2. 监控组策略（Group Policy）的变更

组策略（Group Policy）设置会影响整个 Active Directory 域 的用户和计算机。例如，它包括谁拥有对系统的管理访问权限。对某个 组策略对象（Group Policy object）（GPO）进行一次变更，都可能带来严重的安全影响或导致生产中断，因此监控这些变更至关重要。

事件日志记录了什么——以及它的局限性

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

图 2. 因组策略（Group Policy）变更而记录的事件

但是，这些事件缺少以下关键信息：

• · 具体说明更改了哪个设置，以及更改前后的数值 — GPO 支持数百种开箱即用的设置和自定义设置。一次更改可能会修改用户的默认浏览器主页，或为所有用户提供对关键设备的管理控制权限。然而，事件日志并未记录已更改的设置以及它被改成了什么。
• · 更改的来源 — 与安全组的变更类似，记录组策略（Group Policy）更改的事件并不能指明该更改来自哪里。大多数 GPO 更改都应来自少数几个位置；能够识别来自异常位置的变更对于快速检测攻击至关重要。

挑战 3. 监控目录读取

保护 Active Directory 的另一项关键任务，是监控用户账户如何读取并枚举 AD 对象。试图在你的网络中立足的攻击者，往往会枚举关键账户、组和服务器，以发现能够导致权限升级、并最终指向敏感数据的攻击路径。通过监控可疑的读取事件，你可以识别这种侦察活动，并在为时已晚之前阻止攻击。

事件日志捕获了什么——以及它的局限性

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

图 3：显示读取了 Domain Admins 属性的事件

不过，尝试使用这些事件来监视可疑活动存在多种缺点：

• 噪声太多 — 记录读取事件会导致事件日志中充斥大量噪声，使得几乎不可能找到任何有价值的信息。实际上，用户查看某个组的单次行为就可能在日志中生成几十甚至上百条事件，这使得在所有合法事件之中查找可疑活动几乎变得不可能。
• 没有记录读取来源 — 此外，也无法知道该读取事件的起源位置。正如我们在安全组和 GPO 的变更中所看到的那样，了解某个读取事件来自哪台计算机，是判断这是无害读取还是恶意侦察行为的关键信息。
• 访问被拒绝事件过多 — 同样至关重要的是，发现那些试图访问自己无权查看的信息的用户。例如，Active Directory 可以在计算机属性中存储管理员帐户的明文密码，因此，尝试读取这些属性的用户帐户可能正试图泄露或获取特权凭据。遗憾的是，无论任何帐户出于任何目的查看某个对象，该操作都会为其无权读取的所有属性生成访问失败事件，即使它并不打算读取这些属性。在无数无辜事件的海洋中试图找出真正可疑的失败访问事件，根本不是一个可行的策略。
• 无法轻松监控 LDAP 查询 — LDAP 查询通常用于探索 Active Directory，以发现用户、组和计算机。遗憾的是，Microsoft 并未提供一种简单的方式来监控 LDAP 查询，从而查看发出的查询以及其来源位置。由于这个问题，即使开启诊断级别的 LDAP 监控也几乎没有价值；事实上，Microsoft 不建议这样做，因为它会在事件日志中产生大量噪音。

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

随着近期基于凭据的攻击激增，监控身份验证模式对于识别被入侵的账户以及 pass-the-hash 和 pass-the-ticket attacks、 forged Kerberos tickets 或其他用于获取权限并访问敏感数据的漏洞利用行为至关重要。

事件日志捕获的内容——以及它的局限性

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

尽管这些事件能够捕获一些有用信息，但由于以下不足之处，它们并不能提供一种有效的方法来发现基于身份验证的攻击：

• 噪音过多 — 每当用户登录到任何计算机时都会创建事件，这通常会产生大量活动。还有许多其他事件会在幕后生成。 例如，当用户登录到加入 AD 域的成员服务器时，该服务器会与 DC 建立连接以检索组策略信息，进而导致登录/注销事件出现在 DC 的事件日志中。 如果不忽略对域控制器来说至关重要的登录活动，就无法关闭对正常用户登录活动的日志记录。
• DC 上没有登录类型的记录 — 日志不会追踪 DC 上登录事件的登录类型。该上下文对于判断账号是否以合适的方式被使用具有极其重要的价值。 例如，无法轻松区分用户是通过远程桌面登录，还是通过映射的网络驱动器进行网络登录。你需要从每台成员服务器收集日志，并尝试与 DC 的日志进行关联。
• 缺乏特定协议的详细信息 — 这些事件也缺少其他有价值的细节。例如，Kerberos 认证事件不会记录票据的有效期和续期有效期的时间戳，而这些正是用于 Golden Ticket exploit 的伪造票据的重要指示信息。同样，NTLM 日志也不会注明所使用的 NTLM 版本。此类信息对于判断是否可以停用更旧的 NTLM 版本、改用更安全的协议非常有价值。

Netwrix 能提供的帮助

正如我们所看到的，事件日志不足以及时发现攻击并有效响应。要实现端到端保护，请考虑 Netwrix Active Directory security solution。它将帮助你：

• 通过深入的风险评估主动识别安全漏洞。
• 尽量减少昂贵的停机时间和业务中断。
• 及时发现甚至是高级威胁，并迅速做出响应。