搜索公众号：暗网黑客
可领全套网络安全课程、配套攻防靶场
一介小白是如何成长为黑客大佬的
一、背景介绍
这是去年11月份的应急事件，反复到客户现场多次才找到原因，最后得到的结论也极为简单。
解决问题过程中，由于客户给的压力较大，甚至几次都找错方向
但最终还是将问题解决，在这里我分享一下此次应急，希望能帮助到工作中的您。
1.1问题初步了解
接到客户反馈，某一域用户无法登录，客户通过查看域控服务器系统安全日志，发现域控服务器存在大量用户登录失败日志，初步判断域控服务器可能受到攻击。
1.2问题猜想与信息收集
问题猜想
当接到客户提供的信息和相关截图时，就对客户提供的信息进行分析，针对客户现场的问题作出相关猜想，将可能的原因都列举一下。
1、发现大量用户登录失败日志首先联想到是否存在RDP爆破？
2、是否存在内网横向攻击情况；
3、……
信息收集
针对客户提供的信息和判断结果，我便了解一下信息：
1、域控服务器是否对互联网提供应用；
2、该问题是什么时候出现的，出现后有哪些特征；
3、除域账号无法登录外，是否存在其他现象；
4、……
1.3客户反馈信息
通初步交流重客户处得到信息：
1、该域控不对互联网提供应用，域控服务器处于内网，与互联网无数据交互；
2、除域账号无法登录外，无其他异常情况。
二、问题分析
将自己的猜想同客户反馈到的信息做对比，完全对应不上，两个信息完全是处于两个相对的极端上，心凉凉的。
由于到客户现场需要一段时间，因此在这段时间中，我查找了相关域控的信息，对域控有一个初步了解。
在应急中最忌讳的就是慌张，没有头绪了解域控后，我放空了思路，让自己安静下来。
“知止而后有定，定而后能静，静而后能安，安而后能虑，虑而后能的。”
我很喜欢《大学》中这句话，在每次的应急中我都能从容应对。
给往网络安全发展或者准备提升自身技能的伙伴一句话：
实战练习才是硬道理！只有自己动手摸索，不断思考才能有提升
想学习更多黑客渗透技术，却无实战练习挖漏洞渗透权限
现免费提供靶场及工具进行实战演练
靶场+视频教程，新手能锻炼技术，老鸟层层闯关，在实战中进行自我探测！
4个月学成，月薪过万真的不只是说说！(真实案例)
扫描免费领取零基础体系化视频教程，好不好用看了才知道
三、现场分析
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策略设置如下(该策略参数是按照微软给出的最佳参数设置)：
因此每隔一定时间后会出现以下问题：
0×0指代无错误
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 策略：
https://docs.microsoft.com/zh-cn/previous-versions/windows/server/jj852258(v=ws.11)
ID：4771事件：
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4771
ID：4776事件：
https://docs.microsoft.com/zh-cn/windows/security/threat-protection/auditing/event-4776
ID：4625事件：
https://docs.microsoft.com/zh-cn/windows/security/threat-protection/auditing/event-4625
Kerberos 和 NTLM–SQL Server 连接的那点事(可以重点查看一下)：https://blogs.msdn.microsoft.com/apgcdsd/2011/09/26/kerberosntlm-sql-server/
四、总结：
作为应急人，这里没有什么想要总结的，只想说一句话：“要做好应急就要先学会收集信息”。
作者：bbbbbbig
转载自：https://www.freebuf.com/articles/system/231947.html
)
