搜索公眾號：暗網黑客

可領全套網絡安全課程、配套攻防靶場

一介小白是如何成長為黑客大佬的

一、背景介紹

這是去年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

總結

以上是生活随笔為你收集整理的域控服务器取消验证_记一次域控服务器应急的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。