使用windows日志监控AD安全性的五大挑战

声明：本文档由12306Bro个人业余时间翻译，个人行为与公司无任何关系！译文来源INSIDER THREAT SECURITY BLOG博客站相关文档。如您对翻译文档内容有异议，请将原文文档做为主要参考，原文版权由博客站及其相关成员持有并保留。翻译文章禁止用于任何商业用途，仅供交流与学习。

前言

随着恶意活动的增加，攻击者用来破坏凭据和数据的方法也各种各样，监控Active Directory（AD）等关键系统变得越来越重要。大多数客户转向使用安全信息和事件管理（SIEM）产品来进行监控。虽然这些解决方案可能非常强大，但它们最终依赖于Active Directory中的Windows事件日志。windows事件日志非常复杂，可能无法提供监视AD中的几个关键攻击向量所需的信息。依靠windows事件日志，我们面临着一些影响我们威胁狩猎的挑战，在本文中，我们将探讨其中的五个挑战。

挑战1——组成员变更

Active Directory安全组是用户被授予跨服务器，工作站和应用程序进行特权操作和信息访问权的主要方式。域管理员、企业管理员和架构管理员等用户组在AD环境中为相关组用户提供了较大的权限。除了这些组之外，典型的组织（或企业）还将拥有大量的其他安全组，这些组可以为跨域环境的访问提供特权。

攻击者可以针对这些群组及其组内用户进行攻击以便获得更高的权限。因此，监控这些组的变化是非常重要的。虽然AD事件日志会跟踪安全组的变更，但是缺少关键信息。

例如，如果您将用户添加到Domain Admins组，AD将会生成一个事件ID，如上图所示。此事件包含的有价值信息，例如：

执行更改的用户ID；
已更改的对象的DN和类（在本例中为指示的Domain Admins组）；
添加/删除用户的更改详细信息；

虽然这看起来是用户权限变更的一整套细节信息，但是缺少一些关键信息。

改变从何而来？

windows事件日志从不记录更改的来源（即进行更改操作的服务器地址）。从跳转服务器或域控制器对Domain Admins组的更改，在组内可能是正常的。来自非管理终端或者面向互联网的服务器（即外网web服务器）的更改行为是异常的，可能是网内遭受到攻击的明显标志。了解更改的来源是至关重要的，有助于帮助分析人员快速排除正常行为（排除误报），快速定位网内威胁源。

有效的组成员变更

Active Directory仅记录组内的直接成员的身份变更。但是，你需要知道：在windows系统中同一个组可以包含用户、计算机和其他嵌套组。组可以包含其他组作为成员，因此想要成功的对任何组的变更进行监控，您必须要监视组本身以及嵌套在组中的每个组。这种关系经常会发生改变，所以无形之中增加了威胁狩猎的复杂性。Active Directory不支持监视组的“有效成员资格”（即嵌套组）的更改，因此很难真正的对组内的成员身份更改进行监视。

事件日志不一致

根据Active Directory中组的更改方式，生成的事件看起来会有所不同。这可能会导致SIEM产品中的混淆和错误信息。例如：使用Active Directory服务接口（ADSI）将用户添加组内和使用LDAP将用户添加组内，两种添加用户的方式导致产生的日志类型的不一致，这种不一致性使得在信息收集及处理时非常困难。

总结

在Active Directory（AD）环境中对具有较大权限的组进行更改是许多黑客的进行权限提升和建立立足点的重要目标。但是，这类攻击会导致安全分析人员无法进行正常有效的分析。

挑战2——组策略的变更

组策略用于控制和管理加入Active Directory的所有计算机的设置。这包括关键安全设置，例如谁具有对系统的管理访问权限以及许多其他设置。对组策略对象的简单更改可能会产生严重的安全影响或导致生产中断。

监控这些变化是至关重要的。但是，Active Directory无法记录对组策略设置所做的更改。更改组策略后，您将看到一个事件，如下图中显示的事件。

此事件提供了一些有意义的信息，例如谁进行了更改以及组策略对象的标识符。但是，这些事件内容缺乏有价值的信息。

设置细节

组策略支持数百种开箱即用和自定义设置。设置的范围可以从设置用户的浏览器主页到提供整个组织计算机的关键管理控制。这些事件不会记录已更改的设置及更改的设置，所产生的事件对GPO的变更调查提供的价值很小。因此，有必要实施其他监控来跟踪GPO更改。

变化的来源

与组成员更改相似，此类事件不显示更改的来源。分析人员可以根据组策略更改的来源信息结合上下文的事件信息进而分析出攻击者更改的意图。大多数的更改来自少数几个位置，能够识别和响应来自关键位置的变化对于快速检测网内的攻击行为是非常重要的。

总结

在Active Directory中无法记录对组策略设置所做的更改，这可能会导致安全分析人员无法对分析攻击过程进行有效的分析，导致分析中断。

挑战3——监控目录读取

检测Active Directory攻击的另一个方面是了解用户如何查看和枚举AD对象。当攻击者在您的组织（即AD环境）中获得立足点时，在最初的阶段，攻击者会进行内部侦察，枚举关键帐户，组和服务器。这些信息是攻击者进行权限提升所必需的信息。通过监控可疑的读取事件，您可以检测到侦察活动，并在攻击完成之前阻断攻击。遗憾的是，Active Directory没有提供监控这些类型事件的简便方法。

干扰数据太多

Microsoft能够记录读取事件，方便分析人员查看谁正在探索Active Directory，但是这样做会在事件日志中产生海量的噪音数据，几乎不可能找到任何有价值的信息。例如，如果用户要查看Domain Admins组，则可以在事件日志中生成200多个事件。这包括如上图所示的事件，表示已读取域管理员的属性。除了列出OU的内容和阅读有关组成员的信息等其他事件之外，无论用户在看什么，都将生成数十个这样的事件。

对于用户查看组的单个实例出现数百个事件，将有意义的信息与无关信息分开变得极具挑战性。

读取来自哪里？

即使可能以某种方式读取理解域对象生成的事件，但也无法识别读取事件日志源自何处。在上图中，您可以清楚地看到哪个用户参与了域管理员的阅读，但您不知道这个阅读来自哪台计算机。如果您希望确定网内是否存在恶意侦察的读取行为，这是你判断网内存在恶意侦察行为的至关重要信息。

监视访问被拒绝的事件

监视目录访问事件的一个常见原因是确定用户尝试读取他们无权查看的信息的位置。有价值的信息可以存储在Active Directory属性中，这些属性可以被攻击者查询并最终被攻击者利用。例如，通过利用本地管理员密码解决方案（LAPS），Active Directory将为用户属性中的管理帐户存储明文密码。如果日志显示用户试图读取这些属性，则可能表示用户试图破坏这些特权凭证。不幸的是，为任何目的查看用户对象的每个用户都将为他们无权读取行为而生成访问失败事件日志，即使他们不打算阅读这些属性。因此，使用事件日志监视失败的访问事件作为攻击的标志不是可行的选择。

监控LDAP查询

LDAP查询通常用于探索Active Directory以发现用户，组和计算机。Microsoft没有提供监视LDAP查询的简单方法，以查看已发布的查询及其来源。即使打开诊断级别的LDAP监控也没什么价值，微软也不建议这样做，因为它会在日志中产生海量的噪音数据。

总结

在Active Directory中的限制是它没有提供监控可疑读取事件的简便方法，这可以帮助您检测侦察活动并在攻击发生之前阻止攻击。

挑战4——跟踪认证事件

随着基于凭证的攻击激增，监控身份验证模式对于识别受感染的帐户，传递哈希传递和传递门票攻击的行为，以及伪造的Kerberos票证行为是至关重要的。Active Directory捕获事件用以监视域控制器，成员服务器和工作站上的用户登录和身份验证活动。下图中出了可能需要收集的一些事件，以监控域中的用户身份验证和登录流量。

虽然记录了一些有用的信息以帮助监控基于身份验证的攻击，但产生的事件数量可能非常大，并且无法进行任何有意义的分析。此外，身份验证日志存在一些缺点，使这一挑战难度更高。

活动ID	描述	登录到
4768	请求了Kerberos身份验证票证（TGT）	域控制器
4769	请求了Kerberos服务票证	域控制器
4773	Kerberos服务票证请求失败	域控制器
4776	域控制器尝试验证帐户的凭据	域控制器
4771	Kerberos预身份验证失败	域控制器
4624	帐户已成功登录	服务器/工作站
4625	帐户无法登录	服务器/工作站
4634	帐户已注销	服务器/工作站

干扰数据太多

许多身份验证和登录事件都是由用户启动的，但也只是干扰数据。一个常见的例子是组策略的应用。当用户登录到加入Active Directory域的成员服务器时，服务器将启动与域控制器的连接以检索组策略信息。这会导致登录/注销事件出现在域控制器的事件日志中。此过程以诸如每90分钟的间隔重复，因此在用户登录到服务器时将继续创建这些事件。这导致每个用户登录到任何计算机都会创建大量登陆事件日志，如果不忽略域控制器的其他有价值的登录活动事件日志，则无法禁用这些日志记录。

丢失的信息

虽然可能存在过多的事件记录以跟踪身份验证和登录活动，但这些日志缺少限制其有用性的某些关键信息。例如，在域控制器上，您无法跟踪登录事件的登录类型。这意味着无法区分通过远程桌面登录的用户，而不是通过映射的网络驱动器进行网络登录。在确定是否以适当的方式使用帐户时，这在结合上下文进行确认分析时是非常有用。收集此信息的唯一方法是从每个成员服务器收集日志，并尝试将这些日志与域控制器中的日志进行关联分析。

身份验证日志中也缺少其他特定协议的信息。例如，Kerberos身份验证事件不包含有关Kerberos票证的有价值信息，如票证生命周期和续订生命周期时间戳。这些是伪造门票的有价值的指标，没有它们，就无法检测利用这些功能的攻击，例如Golden Ticket exploit 。NTLM日志不指定所使用的NTLM版本，这在尝试确定在禁用它们以支持更安全的协议之前使用不同NTLM版本的普遍程度时非常有用。

总结

监控身份验证模式和基于身份验证的攻击将会产生海量的数据阻止安全人员进行任何有意义的分析。

挑战5——权限更改和对象更改

在Active Directory中您需要监视的一些最重要的更改，如权限和对象的安全更改。权限控制谁可以通过更改组策略，攻击者可以利用向管理组添加成员等众多方式来提升权限。

受权限影响很大，有必要知道权限何时发生变化并了解这些更改的产生的影响。虽然Active Directory会记录进行权限更改事件，但这些事件中的信息非常难以理解。在windows中有关权限更改的详细信息使用安全描述符定义语言（SDDL）表示。

此类信息看起来比较神秘难易直观理解，你需要翻译此类信息转化为可用信息，但此信息不会识别许可更改的内容。想要了解系统发生了什么更改，你需要查看事件日志中的两个事件ID。原始权限将在第一个事件中表示，表示删除了原始权限。此事件的上下文第二个事件显示了新的权限。要了解两者之间的差异，您必须比较两者以查看更改内容。

这适用于权限更改，同样也适用于对象保护。对象保护是Active Directory的一项功能，可帮助防止意外删除用户，组和OU等对象。关闭此选项后，删除对象非常容易，因此在大多数关键对象上都启用了此功能。关闭此功能绝对值得监控，但是，此更改由类似于图4的事件表示，您可以在其中看到SDDL中表示的详细信息。

使用这种神秘的语言表示权限更改和对象保护更改使得很难理解Active Directory的安全性如何变化以及更改是否值得警告。

最后

Active Directory重要性不言而喻，这就是为什么它是如此受欢迎攻击目标。通过这个此文章，我们探讨了监视Active Directory可能很困难的各种原因。我们讨论的挑战包括：

组成员身份更改
组策略更改
监视目录读取
跟踪认证事件
权限更改和对象更改

由于攻击者不断发展，关键系统监控必须以更快的速度改进。很明显，事件日志存在一些限制，使客户越来越难以保护其系统免受这些攻击。

附录

原文地址

博客原文：https://www.96007.club/2019/09/19/five-challenges-with-monitoring-active-directory-security-using-event-logs/

参考链接

设备对象的SDDL：https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/sddl-for-device-objects

事件ID 4662说明：https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4662

事件ID 5136说明：https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=5136

Windows 7和Windows Server 2008 R2 安全事件的说明：https://support.microsoft.com/zh-cn/help/977519/description-of-security-events-in-windows-7-and-in-windows-server-2008