一、背景介绍

这是去年11月份的应急事件，反复到客户现场多次才找到原因，最后得到的结论也极为简单。解决问题过程中，由于客户给的压力较大，甚至几次都找错方向，但最终还是将问题解决，在这里我分享一下此次应急，希望能帮助到工作中的您。

1.1问题初步了解

接到客户反馈，某一域用户无法登录，客户通过查看域控服务器系统安全日志，发现域控服务器存在大量用户登录失败日志，初步判断域控服务器可能受到攻击。

1.2问题猜想与信息收集

问题猜想

当接到客户提供的信息和相关截图时，就对客户提供的信息进行分析，针对客户现场的问题作出相关猜想，将可能的原因都列举一下。

1、发现大量用户登录失败日志首先联想到是否存在RDP爆破？

2、是否存在内网横向攻击情况；

3、……

信息收集

针对客户提供的信息和判断结果，我便了解一下信息：

1、域控服务器是否对互联网提供应用；

2、该问题是什么时候出现的，出现后有哪些特征；

3、除域账号无法登录外，是否存在其他现象；

4、……

1.3客户反馈信息

通初步交流重客户处得到信息：

1、该域控不对互联网提供应用，域控服务器处于内网，与互联网无数据交互；

2、除域账号无法登录外，无其他异常情况。

二、问题分析

将自己的猜想同客户反馈到的信息做对比，完全对应不上，两个信息完全是处于两个相对的极端上，心凉凉的。由于到客户现场需要一段时间，因此在这段时间中，我查找了相关域控的信息，对域控有一个初步了解。在应急中最忌讳的就是慌张，没有头绪了解域控后，我放空了思路，让自己安静下来。

“知止而后有定，定而后能静，静而后能安，安而后能虑，虑而后能的。”我很喜欢《大学》中这句话，在每次的应急中我都能从容应对。

三、现场分析

3.1日志分析

在现场分析中，首先考虑了是否存在暴力破解情况，因此对安全日志进行分析，但在发现的过程中发现安全日志记录241198条数其中ID为4771事件有92982条，4776事件有72732次。系统中设置日志保存大小为128M，由于每天日志量很大，只保留了当天的日志，当日前的日志已被覆盖，无法得知之前是否存在RDP爆破，在未被覆盖的日志中未发现大量用户登录失败信息（RDP爆破），但存在4625事件（登录类型是3，是访问网络共享文件夹或打印机）。

ID：4771事件：

ID：4776事件：

4625事件（登录类型是3——是访问网络共享文件夹或打印机，登录类型不是10——该类型为远程交付）：

通过对日志进行筛选，发现kerberos预身份验证日志ID：4771占总日志的38.6%，NTLM验证方式验证密码凭据事件ID：4776占总日志的：30%，两者相加占总日志两的68.6%，这一点让我很惊讶，为什么会有这么大的占比？

这里解释一下4771事件、4776事件和Kerberos 策略，详细如下：

4771事件: Kerberos 预身份验证失败：每次密钥分发中心无法发出Kerberos票证授予票证(TGT)时,都会生成此事件。当域控制器没有为智能卡身份验证安装的证书 (例如, 使用 "域控制器" 或 "域控制器身份验证" 模板) 时,用户的密码已过期或错误的密码将会发生这种情况。此事件仅在域控制器上生成。如果为帐户设置了 "不要求 Kerberos 预身份验证" 选项, 则不会生成此事件。

事件4776是使用NTLM验证方式验证密码凭据时产生的，并且只会具有权威性的机器上产生，比如域帐户登录时是需要和域控进行验证的，域控就是具有权威性的机器，而造成登录失败的可能性也很多，比如用户名密码不正确，密码过期，帐号被锁定等等。请检查您环境中是否对该用户做过类似的更改。

Kerberos策略：通过减少Kerberos票证的生命周期,你可以降低合法用户的凭据被盗用并成功被攻击者使用的风险。但是,这还会增加授权开销。

通过对4771事件和4776事件深入分析后，发信当用户的密码已过期和错误进行时会出现上述情况，由于系统设置了Kerberos策略，因此存在上述问题，Kerberos策略设置如下（该策略参数是按照微软给出的最佳参数设置）：

因此每隔一定时间后会出现以下问题：

0x0指代无错误

0xC000006A：帐户登录时出现拼写错误或密码错误：

3.2系统进程分析

通过对异常的域控服务器系统进程和服务进行分析，未发现异常。

3.3安全设备日志分析

对客户安全设备和感知平台一周前的日志进行分析，也未发现攻击痕迹。

3.3第一次分析总结

该问题为kerberos策略引起，因此不是安全事件（看着这个结论，觉得不对，可有找不到异常原因，觉得很难受，第一次分析到此）。

3.4最终分析及结论

我对这个结果不满意，客户拿到这个结果不满意，这个没有找到原因。我有去了客户现场2次，这两次和之前一样也没有找到原因，结论还是和之前一样。感觉自己像个迷路的小孩，对这个问题无能为力。

第四次又厚着脸去了客户现场，到现场处理了一段时间还是一无所获，在黔驴技穷时，客户反馈到，他哪里还有一个问题：“发现一个重复SPN的组”，说到这里时，我起初也没有注意，当对该问题进行深入分析时发现：是由于错误的 SPN 组导致，如果有两个条目尝试使用相同的 kerberos 票证进行身份验证，它们将发生冲突，并导致错误和服务失败。

看到这里有可能对SPN组这个名词有点懵，这里我解释一下SPN组：服务主体名创（SPN）是 kerberos 客户端用于唯一标识给特定 kerberos 目标计算机的服务实例名称。Kerberos 身份验证使用 SPN 将服务实例与服务登录账户向关联，因此如果有两个条目尝试使用相同的 kerberos 票证进行身份验证，它们将发生冲突，并导致错误和服务失败。最终出现上述问题，也解释了为什么存在有的域账号不能登录。至此问题解决，成功脱坑。

3.5相关连接

Kerberos 策略

ID：4771事件

ID：4776事件

ID：4625事件

Kerberos 和 NTLM–SQL Server 连接的那点事（可以重点查看一下）

四、总结

作为应急人，这里没有什么想要总结的，只想说一句话：“要做好应急就要先学会收集信息”。

*本文作者：bbbbbbig，转载请注明来自FreeBuf.COM