我们有一个Windows Server，该服务器上有一个应用程序，该应用程序在登录该应用程序时使用域凭据。在最近的笔测试中，测试人员能够使用该应用程序，以便根据应用程序的响应枚举有效的域用户名（对于无效的用户名与无效的密码，它给出了不同的响应）。
该应用程序已修复，因此不会泄露此信息，但我也觉得我们应该已经检测到此攻击，因为在短时间内进行了200000多次无效的用户名尝试。即使管理员正在密切关注Active Directory，我们也没有看到它。显然，故障仅在安装应用程序的服务器的本地事件日志中显示。
我的问题：1）有没有一种方法可以使Active Directory在中央位置记录这些失败的用户名请求，以便我们注意到它们的激增？
2）如果不是，那么将来监视和主动检测此类攻击的最佳方法是什么（希望不必购买过多的新设备）。
谢谢你的帮助。
Answers:
好问题。
首先，我认为大多数“渗透测试人员”都是脚本小子。我的偏见可能不公平或不准确，但我声明了这个免责声明，这样，如果您发现我语气中的任何愤世嫉俗，就会知道它的来历。我并不是说没有熟练的测试者，但这是我的全面概括。
（蓝队一生！）
我的问题：1）有没有一种方法可以使Active Directory在中央位置记录这些失败的用户名请求，以便我们注意到它们的激增？
您没有提供足够的信息来让任何人能够彻底，自信地回答这个问题。您说您的应用程序被发现存在一个漏洞，该漏洞使攻击者可以枚举用户帐户。我想在你的感觉方式，广告必须为执行日志记录，以了解您的应用程序。
显然，故障仅在安装应用程序的服务器的本地事件日志中显示。
显然，故障显示在服务器上的事件日志中吗？还是失败确实显示在服务器上的事件日志中？如果是这样，这些事件到底是怎么说的？谁记录了他们？你的申请？还是Windows？找出答案，我也许可以在答案中添加更多说明。
根据您的推测，这些事件应该已经由Active Directory记录下来，我将在这里走出一条弯路……如果您的渗透测试者实际上根本没有利用应用程序中的缺陷，那该怎么办？ Kerberos本身枚举用户名的一个众所周知的缺陷？Kerberos本身包含我认为的设计缺陷，攻击者可以在其中尝试成千上万的“预身份验证”尝试（即蛮力攻击），而KDC会根据用户帐户是否存在做出不同的响应。这不是特定于Active Directory的行为，但同样适用于MIT Kerberos，Heimdal等。KDC会以KDC_ERR_PREAUTH_REQUIRED如果提供的有效用户名没有预验证数据，即使没有尝试实际验证也是如此。这样，您可以从KDC枚举用户名。但是由于攻击者（或攻击者使用的工具，例如KrbGuess-因为渗透测试者在使用其他人的工具时处于最佳状态）不必继续进行完整的身份验证尝试，因此不会记录任何内容，因为没有尝试进行实际身份验证！
现在，转到下一个问题：
2）如果不是，那么将来监视和主动检测此类攻击的最佳方法是什么（希望不必购买过多的新设备）。
有几件事。
首先，有付费的企业级产品旨在检测这类攻击（以及其他类型的攻击）。许多供应商都提供了此类产品，并且Serverfault的产品推荐是不合时宜的，但足以说明它们已经存在那里。这些产品中的许多产品都需要您在域控制器和这些“数据收集器”之间配置端口镜像，以便它们可以查看和分析从字面上看每个进入或退出域控制器的数据包。
（对不起，这属于您的“无需购买太多新东西”子句。）
可能对您有所帮助的另一件事是注册表项：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
LogLevel = 1
记录在这里。
如果启用此注册表项，则应该在安全事件日志中充斥有关Kerberos错误的事件，这些事件提到需要Kerberos预身份验证。此类事件的示例：
A Kerberos Error Message was received:
on logon session DOMAIN\serviceaccount
Client Time:
Server Time: 12:44:21.0000 10/9/2012 Z
Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
Extended Error:
Client Realm:
Client Name:
Server Realm: DOMAIN
Server Name: krbtgt/DOMAIN
Target Name: krbtgt/DOMAIN@DOMAIN
Error Text:
File: e
Line: 9fe
Error Data is in record data.
但是，如果未指定Kerberos请求的确切海啸来自何处，这可能对您有所帮助，也可能没有帮助。这使我们回到了我前面提到的那些企业入侵检测产品。
并且不要忘记Windows事件转发，它可以使您的服务器将事件转发到集中位置，然后使用您可以使用的任何工具进行分析。
到目前为止，整个答案都是基于Kerberos协议的，我什至不能将其视为理所当然，因为您在帖子中没有提供太多细节。不过，我希望这至少可以有所帮助。
我希望听到一个正确的答案，这是一个有趣的问题。我遇到了一些道格可能会有所帮助的信息，但是，我觉得可能有些不足。其他人可能可以提供扩展的答案：
登录到您要存储审核信息的服务器， 运行-> RSOP.MSC->计算机配置-> Windows设置->安全设置->本地策略->审核策略->“审核帐户登录事件”和“审核登录事件”
“帐户登录事件”的说明如下：
审核帐户登录事件
此安全设置确定每次此计算机验证帐户凭据时操作系统是否进行审核。
每当计算机验证其权威帐户的凭据时，都会生成帐户登录事件。域成员和未加入域的计算机对其本地帐户具有权威性；域控制器对域中的帐户均具有权威性。凭据验证可能支持本地登录，或者在域控制器上的Active Directory域帐户的情况下，可能支持登录另一台计算机。凭据验证是无状态的，因此帐户登录事件没有相应的注销事件。
如果定义了此策略设置，则管理员可以指定是仅审核成功，仅失败，成功和失败，还是根本不审核这些事件（即既不成功也不失败）。
“登录事件”的说明如下：
审核登录事件
此安全设置确定操作系统是否审核尝试登录或注销此计算机的用户的每个实例。
每当登录用户帐户的登录会话终止时，都会生成注销事件。如果定义了此策略设置，则管理员可以指定是仅审核成功，仅失败，成功和失败，还是根本不审核这些事件（即既不成功也不失败）。
如果您只想监视失败的尝试，则基本上需要启用这些策略，定义策略设置并选择“失败”。如果需要，您也可以监视成功，但是如果您只担心寻找这种攻击，则可能会使解析起来有些困难。
如果您担心系统可能会受到类似配置的影响，我建议您将STIG设置（链接）与SCAP扫描仪结合使用时，它确实有助于突出您的组织可能面临的某些风险。面对。STIG查看器往往会带来一些误报，但如果您仔细阅读每个问题的具体内容，可能会发现它是一个不起眼的问题。