漏洞名稱：Netlogon特權提升漏洞
漏洞編號：CVE-2020-1472
漏洞描述：Netlogon協議認證的加密模塊存在缺陷，當使用Netlogon遠程協議建立與域控制器連接的易受攻擊的Netlogon安全通道時，存在特權提升漏洞，導致攻擊者可以在沒有憑證的情況下通過認證。通過調用Netlogon中RPC函數NetrServerPasswordSet2來重置域控的密碼，以域控的身份進行Dcsync（域滲透常用技術，可利用Dcsync導出域內所有用戶hash，在域內維持權限等），獲取域管權限。
Netlogon組件是Windows上一項重要的功能組件，用於用戶和機器在域內網絡上的認證，以及復制數據庫以進行域控備份，還用於維護域成員與域之間、域與域控之間、域DC與跨域DC之間的關系。
Netlogon遠程協議是一個可用的在Windows域控制器上的RPC（remote procedure call protocol，遠程過程調用協議，允許像調用本地服務一樣調用遠程服務）接口，用於對域中的用戶和其他服務進行身份驗證，最常見的是方便用戶使用NTLM（NTLAN Manager，問詢/應答身份驗證協議，telnet的一種驗證身份方式）登錄服務器協議，讓計算機更新其域內的密碼。其他機器與域控的Netlogon通訊使用RPC協議MS-NRPC（指定了Netlogon遠程協議，基於域的網絡上的用戶和計算機進行身份驗證）。
Netlogon協議不會使用與其他RPC服務相同的身份驗證方案，而是使用自定義的加密協議，讓客戶端（加入域的計算機）和服務器（域管理員）互相證明它們都知道共享的機密（客戶端計算機的哈希值密碼）。
1）客戶端調用NetrServerReqChallenge，向服務端發送一個client challenge；
2）服務端向客戶端返回一個Server Challenge；
3）雙方利用client的hash、clientchallenge、server challenge計算一個session_key；
4）客戶端利用session_key和client challenge計算一個client credential，並發送給服務端進行校驗；
5）服務端也利用session_key和client challenge計算一個client credential，如果其值和客戶端發送過來的一致，就讓客戶端通過認證。
這里的client challenge使用ComputeNetlogonCredential函數計算，有兩種算法，分別是DES_ECB和AES_CFB，雙方可以通過協商flag來選擇使用哪種加密方式。
攻擊者可控的因素是client challenge，攻擊者將其設置為0，serverchallenge在每一輪認證過程中都會變化，secret則對應用戶密碼的hash，加密過程采用的是AES-CFB8（一種高級加密標准），運算過程詳見https://www.anquanke.com/post/id/217475
這里存在問題的就是AES-CFB8，在AES-CFB8算法中，IV是’\x00’*16，明文密碼是clientchallenge，key是session_key，計算后的密文是client credential。如果IV為零，只要我們能控制明文內容為XYXYXYXY這種格式（X和Y可以一樣，即每個字節的值都是一樣的），那么一定存在一個key，使得clientcredential為00000000000000。我們就可以向服務端發送一個client challenge為00000000000000（滿足XYXYXYXY格式即可），然后循環向服務端發送client credential為00000000000000，直到出現一個session_key，使得服務端生成的client challenge也為00000000000000。
簡單來說，Netlogon協議身份認證采用挑戰-響應機制，其加密算法是AES-CFB8，並且IV默認全零，導致漏洞產生。而且沒有對認證次數進行限制，簽名功能客戶端默認可選，使得漏洞被成功利用。
工具:
檢驗是否存在該漏洞：CVE-2020-1472-master.zip
https://github.com/SecuraBV/CVE-2020-1472
導出域內的hash，橫向移動等：impacket-master.zip
https://www.freebuf.com/sectool/175208.html
https://github.com/SecureAuthCorp/impacket
將域控密碼置空，並后面進行還原：zerologon-master.zip
https://github.com/risksense/zerologon
靶機:
192.168.1.145
testdc
定位域控：掃描389端口
389端口的服務：LDAP（LightweightDirectory Access Protocol，輕型目錄訪問協議）和ILS（NetMeeting Internet Locator Server，Internet定位服務器），LDAP是基於X.500標准的輕量級目錄訪問協議，通過IP協議提供訪問控制和維護分布式信息的目錄信息。由美國密西根大學發明，目前已有多家公司采用，如Netscape將其包含在最新的Communicator套裝產品中，也被微軟加入Active Directory中。
如果該機器同時開放135（主要用於使用RPC（remote procedure call，遠程過程調用）協議並提供DCOM（分布式組件對象模型）服務）、445（共享文件夾或共享打印機）、53（DNS，域名服務器）端口，很大可能就是域控：
Impacket：一個Python類庫，用於對SMB1-3或IPv4/IPv6上的TCP、UDP、ICMP、ARP、NTLM、LDAP等協議進行低級編程訪問。GitHub地址：https://github.com/SecureAuthCorp/impacket
安裝impacket路徑下的setup.py即可：
python3 setup.py install
漏洞驗證：https://github.com/SecuraBV/CVE-2020-1472
DC名稱為其NetBIOS計算機名稱，如果此名稱不正確，腳本可能會失敗並顯示 STATUS_INVALID_COMPUTER_NAME錯誤。
漏洞復現：https://github.com/risksense/zerologon
1）查看域控所在機器賬戶（testdc$）的hash
注：利用CVE-2020-1472重置的是域控所在機器用戶的密碼。機器用戶跟域用戶一樣，都是域內的成員，機器用戶在域內的用戶名是機器用戶+$，如testdc$。
無法獲取域內用戶憑據信息。
2）使用zerologon工具將域控所在機器賬戶的hash置換成空密碼的hash
置空后，再次獲取域內憑證信息：
通過在線加解密網站 https://www.cmd5.com 查詢：
發現testdc$的hash已經被改成空密碼。
使用administrator的hash橫向連接：
3）還原域控機器賬戶的hash
在上面的攻擊過程中，我們將機器的密碼置為空，會導致域控脫域，原因是機器用戶在AD中的密碼（存儲在ntds.dic）與本地注冊表里面的不一致。還原域控機器賬戶的hash，只要將AD中的密碼與注冊表里面的密碼保持一致即可。
獲取計算機賬戶原始hash：
reg save HKLM\SYSTEM system.save
reg save HKLM\SAM sam.save
reg save HKLM\SECURITY security.save
get system.save
get sam.save
get security.save
del /f system.save
del /f sam.save
del /f security.save
使用reg save命令將注冊表里的信息拿回本地，再通過secretdump提取出里面的hash：
python3 secretsdump.py -sam sam.save -system system.save -security security.save LOCAL
使用zerologon工具將原始計算機賬戶哈希還原：
查看testdc$賬戶的hash，已成功還原：
注：password即客戶機密碼
漏洞修復
下載並安裝漏洞官方補丁：https://portal.msrc.microsoft.com/zh-CN/security-guidance/advisory/CVE-2020-1472
及時進行Microsoft Windows版本更新並且保持Windows自動更新開啟。