我们有一台 Windows Server，上面驻留着一个应用程序，该应用程序使用域凭据登录应用程序。在最近的一次渗透测试中，测试人员能够使用该应用程序根据应用程序的响应枚举有效的域用户名（对于无效用户名和无效密码，它给出了不同的响应）。
该应用程序正在修复中，因此不会泄露这些信息，但我觉得我们应该已经检测到这次攻击，因为在短时间内有超过 2000,000 次无效用户名尝试。即使我们的管理员密切关注 Active Directory，我们也没有发现它。显然，这些故障只出现在安装该应用程序的服务器的本地事件日志中。
我的问题：1）有没有办法让 Active Directory 将这些失败的用户名请求记录在一个中心位置，以便我们可以注意到它们的激增？
2）如果不是，那么将来监控和主动检测此类攻击的最佳方法是什么（希望不必购买太多新设备）。
感谢您的帮助。
答案1
好问题。
首先，我认为大多数“渗透测试人员”都是脚本小子。我的偏见可能不公平或不准确，但我要声明这一点，这样如果你发现我的语气中有任何愤世嫉俗的情绪，你就知道它来自哪里。我并不是说不熟练的渗透测试人员，但这是我的普遍概括。
（蓝队终身！）
我的问题：1）有没有办法让 Active Directory 将这些失败的用户名请求记录在一个中心位置，以便我们可以注意到它们的激增？
你没有提供足够的信息让任何人能够彻底而自信地回答这个问题。你说你的申请被发现包含一个漏洞，允许攻击者枚举用户帐户。我试图了解你认为 AD 需要以何种方式执行日志记录你的应用。
显然，故障只会出现在安装该应用程序的服务器的本地事件日志中。
显然故障是否出现在服务器的事件日志中？或者故障做过显示在服务器上的事件日志中？如果是，事件具体说了什么？谁记录了它们？您的应用程序？还是 Windows？去查一下，我可能会在我的答案中添加更多说明。
我将根据您假设这些事件应该以某种方式由 Active Directory 记录下来而在此冒险一试……如果您的渗透测试人员实际上根本没有利用您应用程序中的漏洞，而是使用 Kerberos 本身中一个非常著名的漏洞来枚举用户名，会怎么样？Kerberos 本身包含我认为的设计缺陷，攻击者可以尝试成千上万次“预身份验证”尝试（即暴力攻击），并且 KDC 将根据用户帐户是否存在做出不同的响应。这不是 Active Directory 特有的行为，但同样适用于 MIT Kerberos、Heimdal 等。KDC_ERR_PREAUTH_REQUIRED如果提供了有效的用户名而没有预身份验证数据，即使没有尝试实际身份验证，KDC 也会做出响应。通过这种方式，您可以从 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 协议的，我甚至不能真正将其视为理所当然，因为您在帖子中提供的细节太少了。不过，我希望这至少能有所帮助。
答案2
这是一个有趣的问题，我很想听到一个正确的答案。我偶然发现了一些 Doug 可能觉得有用的信息，但我觉得它可能有点不足。其他人可能会提供更详细的答案：
登录到您想要存储审计信息的服务器， 运行->RSOP.MSC->计算机配置->Windows 设置->安全设置->本地策略->审核策略->“审核帐户登录事件”和“审核登录事件”
“帐户登录事件”的解释如下：
审计账户登录事件
此安全设置确定每次计算机验证帐户的凭据时操作系统是否进行审核。
每当计算机验证其具有权威性的帐户的凭据时，就会生成帐户登录事件。域成员和非域加入计算机对其本地帐户具有权威性；域控制器对域中的帐户都具有权威性。凭据验证可能支持本地登录，或者，对于域控制器上的 Active Directory 域帐户，可能支持登录到另一台计算机。凭据验证是无状态的，因此帐户登录事件没有相应的注销事件。
如果定义了此策略设置，管理员可以指定是否仅审核成功、仅审核失败、同时审核成功和失败，或者根本不审核这些事件（即既不审核成功也不审核失败）。
“登录事件”的解释如下：
审核登录事件
此安全设置确定操作系统是否审核用户尝试登录或注销此计算机的每个实例。
每当登录用户帐户的登录会话终止时，都会生成注销事件。如果定义了此策略设置，管理员可以指定是否仅审核成功、仅审核失败、成功和失败，或者根本不审核这些事件（即既不审核成功也不审核失败）。
如果您只想监控失败的尝试，您基本上需要启用这些策略，定义策略设置并选择“失败”。如果您愿意，您也可以监控成功，但如果您只担心寻找这种攻击，这可能会使解析变得有点困难。
如果您担心您的系统可能容易受到类似配置的影响，我建议您查看 STIG 设置（关联)，当与 SCAP 扫描仪结合使用时，它可以真正帮助突出显示您的组织可能面临的一些风险。STIG 查看器往往会引发一些误报，但如果您仔细阅读每个问题的具体内容，您可能会发现它根本行不通。