最好的方式来跟踪蛮力用户名枚举/失败的用户名尝试AD

伟大的问题。

首先，我认为大多数“渗透testing者”是脚本小子。 我的偏见可能并不公平或不准确，但我正在join这个免责声明，所以如果你发现我的语气中有任何的玩世不恭，你知道它来自哪里。 我不是说没有熟练的testing者，但这是我的普遍性。

（蓝队终身！）

我的问题：1）有没有办法让Active Directory在中央位置login这些失败的用户名请求，所以我们可以注意到他们的一个尖峰？

你没有提供足够的信息给任何人能够充分和自信地回答这个问题。 你说你的应用程序被发现含有一个漏洞，允许攻击者枚举用户帐户。 我正试图了解AD如何为您的应用程序执行日志logging。

显然，这些故障只会在安装应用程序的服务器的本地事件日志中出现。

显然 ，服务器上的事件日志中显示失败。 或者在服务器上的事件日志中显示失败？ 如果是的话，事件到底是什么意思？ 谁login了他们？ 你的申请？ 还是Windows？ 去找出，我可以补充说明我的答案。

根据你的推测，这些事件应该已经被Active Directory以某种方式logging下来了……如果你的testing者实际上没有真正利用你的应用中的缺陷，而是使用Kerberos本身的一个非常着名的缺陷来枚举用户名？ Kerberos本身包含了我认为的一个devise缺陷，攻击者可以尝试成千上万的“预authentication”尝试（即powershell攻击），而KDC将根据用户帐户是否存在做出不同的响应。 这不是特定于Active Directory的行为，但也适用于MIT Kerberos，Heimdal等。如果有效用户名没有预先授权数据，KDC将以KDC_ERR_PREAUTH_REQUIRED响应，即使没有尝试实际的身份validation。 通过这种方式，您可以枚举来自KDC的用户名。 但是因为攻击者（或攻击者正在使用的工具，比如KrbGuess，因为在他人使用其他人的工具时他们处于最佳状态）并不需要继续进行完整的身份validation尝试，因此不会logging任何内容尝试实际的身份validation！

现在，接下来的问题：

2）如果不是，将来要监视和主动检测这种攻击的最好方法是什么（希望不需要购买太多的新设备）。

几件事情。

首先，有付费的企业级产品被devise用来检测这种types的攻击（其他很多）。许多供应商提供这样的产品，并且产品推荐对于Serverfault而言是无关紧要的，但是可以说它们已经出来了那里。 这些产品中的许多产品通过要求您在域控制器和这些“数据收集器”之间configuration端口镜像来工作，以便他们逐字地查看和分析进入或退出域控制器的每个数据包。

（对不起，这个“没有买太多新东西”的条款会落入你的。）

另一件可能帮助你的事情是registry项：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

LogLevel = 1

logging在这里 。

如果启用此registry项，则应该在安全事件日志中的事件中充斥有关于提到需要Kerberos预validation的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协议为基础的，我甚至不能认为这是理所当然的，因为你在这篇文章中提供了很less的细节。 不过，我希望这至less有一点帮助。

这是一个有趣的问题，我很乐意听到正确的答案。 我遇到了一些Doug可能会觉得有帮助的信息，但是，我觉得可能有些不足。 其他人可能可以提供一个扩展的答案：

login到服务器，您想要保存审计信息， 运行 – > RSOP.MSC – >计算机configuration – > Windows设置 – >安全设置 – >本地策略 – >审计策略 – >“审计帐户login事件”＆“审核login事件“

“帐户login事件”的解释是：

审计帐户login事件

此安全设置确定操作系统在每次此计算机validation帐户的凭据时是否进行审计。

只要计算机validation其授权的帐户的凭据，就会生成帐户login事件。 域成员和非域join的机器对于本地帐户是权威的; 域控制器对域中的帐户都是权威的。 凭据validation可能支持本地login，或者对于域控制器上的Active Directory域帐户，可能支持login到另一台计算机。 凭据validation是无状态的，因此帐户login事件没有相应的注销事件。

如果定义了此策略设置，则pipe理员可以指定是仅审核成功，仅审核成功还是失败，或者不审核这些事件（即，既不成功也不成功）。

“login事件”的解释是：

审核login事件

此安全设置确定操作系统是否审计尝试login或注销到此计算机的用户的每个实例。

每当login用户帐户的login会话终止时，都会生成注销事件。 如果定义了此策略设置，则pipe理员可以指定是仅审核成功，仅审核成功还是失败，或者不审核这些事件（即，既不成功也不成功）。

您基本上需要启用这些策略，定义策略设置并select“失败”，如果您只想监视失败的尝试。 如果你愿意的话，你也可以监视成功，但如果你只是担心寻找这种攻击，可能会更难以parsing。

如果您担心您的系统可能易受攻击的类似configuration，我build议您查看STIG设置（ 链接 ），将其与SCAP扫描仪结合使用时，可以帮助突出显示您的组织可能存在的某些风险面对。 STIG浏览器往往会引起一些误报，但是如果你仔细阅读每个问题的具体内容，你可能会发现它是一个不起眼的东西。