DCSync是AD域滲透中常用的憑據(jù)竊取手段，默認情況下，域內(nèi)不同DC每隔15分鐘會進行一次數(shù)據(jù)同步，當一個DC從另外一個DC同步數(shù)據(jù)時，發(fā)起請求的一方會通過目錄復制協(xié)議（MS- DRSR）來對另外一臺域控中的域用戶密碼進行復制，DCSync就是利用這個原理，“模擬”DC向真實DC發(fā)送數(shù)據(jù)同步請求，獲取用戶憑據(jù)數(shù)據(jù)，由于這種攻擊利用了Windows RPC協(xié)議，并不需要登陸域控或者在域控上落地文件，避免觸發(fā)EDR告警，因此DCSync時一種非常隱蔽的憑據(jù)竊取方式。

1.攻擊場景

• DCSync通常是作為其他攻擊的先兆性攻擊:
  

• 例如攻擊者可能會使用DCSync竊取krbtgt用戶的hash來制作黃金票據(jù)；

• 在hash傳遞攻擊中，攻擊者會利用DCSync去獲取低權(quán)限用戶的hash進行登錄。

• DCSync也可能是其他一些漏洞的后置性攻擊手段:

• 例如CVE-2020-1472漏洞，攻擊者利?Netlogon協(xié)議漏洞將域控機器賬戶密碼置空，然后利用空密碼對域控進行DCSync攻擊獲取域內(nèi)用戶憑據(jù)。
  

• DCSync也可以會作為一種維權(quán)手段
  

• 攻擊者在控制某個域之后可能會對域內(nèi)某些普通用戶或者用戶組賦予DCSync權(quán)限，以便在下一次進入內(nèi)網(wǎng)后直接利用該低權(quán)限用戶憑據(jù)來dump域管憑據(jù)，實現(xiàn)對AD域的隱蔽控制。
  

2.利用條件

在默認情況下，只有域控機器用戶、域管理員（Domain Admins）、企業(yè)管理員（Enterprise Admins）等高權(quán)限賬戶才有DCSync操作的權(quán)限，從更細粒度的ACL層面來說，DCSync需要以下兩個權(quán)限

• 目錄復制同步
  （Replicating Directory Changes）

• 目錄復制同步所有項
  （Replicating Directory Changes All）
  

3.原理分析

在AD域環(huán)境中域控制器（Domain Controller）扮演了最核心的角色，承擔了域內(nèi)用戶的管理、認證、票據(jù)授權(quán)等作用，為了防止一臺域控宕機導致整個域環(huán)境崩潰，企業(yè)內(nèi)通常會部署多臺域控，為了保證這些域控中存儲的用戶數(shù)據(jù)一致性，這些域控之間會利用MS-DRSR 協(xié)議中的drsuapi RPC 接口來進行數(shù)據(jù)同步。

DCSync攻擊就是“模擬了”域控同步的行為去調(diào)用DRSGetNCChanges函數(shù)，這個函數(shù)返回的數(shù)據(jù)中就包含了用戶的密碼。

目前DCSync攻擊的常用攻擊工具一般為mimikatz或impacket工具包中的Secretsdump.py

從mimikatz代碼來分析，整個過程一共調(diào)用了以下4個RPC函數(shù)

DRSBind；

• DRSBind
  

DRSBind函數(shù)的作用是初始化drs句柄，與服務端進行消息版本和加密方式的協(xié)商，這是調(diào)drsuapi中函數(shù)之前的必要操作。

在這個函數(shù)中有兩個參數(shù)，一個是puuidClientDsa，指向調(diào)用方的GUID的指針，另一個是pextClient，pextClient參數(shù)主要包含的是協(xié)商信息，它指向的是一個DRS_EXTENSIONS_INT結(jié)構(gòu)體，在這個結(jié)構(gòu)體中的dwFlags字段標識了調(diào)用方支持的功能列表。

在mimikatz中dwFlags被設置為

DRS_EXT_GETCHGREPLY_V6 | DRS_EXT_STRONG_ENCRYPTION。

在Secretsdump工具dwFlags設置的是

DRS_EXT_GETCHGREQ_V6 | RS_EXT_GETCHGREPLY_V6 | DRS_EXT_GETCHGREQ_V8 | DRS_EXT_STRONG_ENCRYPTION

puuidClientDsa表示調(diào)用方的GUID，在兩個工具中都是一樣的 “e24d201a-4fd6-11d1-a3da-0000f875ae0d” 。

在[MS-DRSR]文檔中這個guid被稱作NTSAPI_CLIENT_GUID，微軟在文檔中表示只有puuidClientDsa是NULL GUID時服務端才會返回錯誤，我在實際測試中修改成其他的GUID也沒有對DCSync造成影響，不知道這兩個工具將puuidClientDsa設置為NTSAPI_CLIENT_GUID是出于什么目的。

• DRSDomainControllerInfo
  

DRSDomainControllerInfo函數(shù)主要是獲取域控的一些信息，在這里目的是獲取目標服務端域控的GUID，這是調(diào)用DRSGetNCChanges函數(shù)必須使用的參數(shù)。

• DRSCrackNames

DRSCrackNames作用是查詢目錄內(nèi)的對象，并將結(jié)果返回給調(diào)用方，我們在dump hash是這里的對象就是傳入的用戶名，DRSCrackNames接受多種形式的用戶名，包括UPN、FQDN、SPN等。

在Secretdump中只有以下兩種格式被支持。

DS_NT4_ACCOUNT_NAME

mimikatz中支持的格式就比較多了

傳入的用戶名類型需要在DRS_MSG_CRACKREQ結(jié)構(gòu)體的formatOffered參數(shù)中指定，在rpNames傳入需要查詢的用戶名，這里是一個數(shù)組，可以一次傳入多個用戶。這一步最核心的目的是獲取用戶的GUID，這是調(diào)用DRSGetNCChanges函數(shù)另一個必要參數(shù)。

• DRSGetNCChanges
  

這是整個DCSync過程最重要的一個函數(shù)

輸入的參數(shù)是一個DRS_MSG_GETCHGREQ結(jié)構(gòu)體，這里以DRS_MSG_GETCHGREQ_V8為例:

uuidDsaObjDest和uuidInvocIdSrc分別表示客戶端DC和服務端DC的GUID，secretsdump中將這兩個參數(shù)都設置成DRSDomainControllerInfo請求中獲取的服務端DC的GUID。

而mimikatz只設置了uuidDsaObjDest，uuidInvocIdSrc默認為NULL

在實際測試中將uuidDsaObjDest設置為NULL或者服務端DC的GUID時，uuidInvocIdSrc設置為任意的GUID時DCSync都可以成功，所以實際上DRSDomainControllerInfo這一步是可以省略的。

pNC表示需要復制的對象，這是一個DSName結(jié)構(gòu)，可以通過GUID、SID、或者是DN來表示域內(nèi)的一個對象，impacket和mimikatz都是通過GUID來標識用戶的。

實際上，在知道用戶的SID或者DN的情況下也是可以成功的

所以在知道目標sid或者dn的情況下DRSCrackNames這一步也是可以省略的。

pPartialAttrSet包含了需要復制的對象屬性，類型是ATTRTYP，這里的ATTRTYP實際上是壓縮形式的oid， 屬性名和對應的oid在mimikatz和secretsdump中都有定義。

其中密碼字段就保存在unicodePwd屬性中，這里只要有這一個屬性就能獲取到對象的密碼。

DRSGetNCChanges返回的是DRS_MSG_GETCHGREPLY結(jié)構(gòu)，兩個工具協(xié)商的返回類型都是DRS_EXT_GETCHGREQ_V6，所以這里以DRS_MSG_GETCHGREPLY_V6為例分析。

對象的信息包含在pObjects屬性中，這是一個鏈表結(jié)構(gòu)，在mimikatz中對這個鏈表進行了遍歷，并根據(jù)不同屬性的類型進行解析。

這里我們最關注的屬性就是unicodePwd，在復制以下屬性時會將這些屬性用sessionKey進行加密，加密方式是RC4。

unicodePwd

kull_m_rpc_drsr_ProcessGetNCChangesReply函數(shù)是mimikatz中對這些屬性進行解密的關鍵函數(shù)，詳情如下。

最后使用rid生成的key對unicodePwd進行解密就的到我們想要的ntlm hash。

• 總結(jié)
  

通過對DCSync原理及利用過程進行分析,發(fā)現(xiàn)在以上4個RPC函數(shù)中DRSBind不可以省略，DRSDomainControllerInfo目的是獲取drsuapi服務端的GUID，這個GUID可以是NULLGUID，可以省略，DRSCrackNames的作用是獲取用戶的GUID，DRSGetNCChanges可以接受SID或者DN形式的用戶名，也可以省略。

因此,可以對現(xiàn)有工具進行代碼簡化，簡化之后可以用直接用DRSBind和DRSGetNCChanges函數(shù)來進行DCSync，利用過程如下圖所示。

4.防御和檢測

由于DCSync攻擊需要Replicating Directory Changes和Replicating Directory Changes All這兩個權(quán)限，可以通過LDAP查詢域內(nèi)對象的ACL，對域內(nèi)有DCSync權(quán)限的用戶進行排查。

在網(wǎng)絡層面，除了一些特殊情況，從非域控ip發(fā)起的IDL_DRSGetNCChanges rpc請求基本上可以判定為攻擊行為。

5.參考

• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/f977faaa-673e-4f66-b9bf-48c640241d47

• https://github.com/gentilkiwi/mimikatz

• https://github.com/SecureAuthCo