Garfield (Hard, Active Directory) Walkthrough

Garfield is one of those rare HackTheBox machines where nothing is exploited with a CVE or a public proof of concept. Every step is a Microsoft documented Active Directory feature being abused exactly the way it was designed. That is what makes it a great box for anyone who wants to understand how real world Active Directory compromises actually look.

The chain runs across seven distinct AD primitives, from a writable SYSVOL share to a forged Kerberos ticket against a Read Only Domain Controller. This post walks through the concepts behind each stage without dumping flags or hand holding every command.

Why Garfield Is Interesting

Most Active Directory boxes stop at Domain Admin. Garfield takes a different route. The writable Domain Controller on this box is a Read Only Domain Controller (RODC), and the RODC sits on a separate subnet that is not directly reachable from the attacker. That means the chain has to tunnel through a foothold, compromise the RODC as a local admin, extract its per RODC krbtgt key, and then use a relatively new technique to turn that RODC compromise into full domain compromise.

The technical interest is concentrated in the second half. The RODC Golden Ticket combined with a Kerb-Key-List Request is a 2022 to 2024 era addition to the AD attacker toolkit. It is barely documented outside a handful of specialist writeups, and it completely changes the traditional assumption that an RODC is a security boundary.

The Kill Chain at a Glance

1. Recon and enumeration. Nmap, SMB, LDAP, and BloodHound to map the domain and identify the RODC.
2. Logon Script Hijack. Writable SYSVOL plus a writable scriptPath attribute on a user object leads to code execution the next time that user logs in.
3. ForceChangePassword pivot. The compromised user has the extended right to reset the password of a higher tier account without knowing the current one.
4. AddSelf to RODC Administrators. A group membership edge grants local administrator rights on the RODC.
5. Resource Based Constrained Delegation. Configure an attacker controlled computer account as a delegate for the RODC, then use Kerberos S4U to impersonate Administrator on the RODC's CIFS service.
6. Ligolo or Chisel pivot. Tunnel through the writable DC onto the isolated RODC subnet.
7. Dump the RODC's krbtgt key. Extract the AES256 key for the per RODC krbtgt account from the RODC's LSA secrets store.
8. RODC Golden Ticket plus Kerb-Key-List. Forge a ticket signed with the RODC key, then request the long term keys of a privileged principal via the Key-List extension.
9. Pass-the-Hash to the writable DC. Authenticate as Domain Administrator and complete the box.

Stage 1: Reconnaissance and the Shape of the Domain

The provided credentials belong to a low privileged domain user. Nmap confirms a Windows Domain Controller with the usual port fingerprint: DNS on 53, Kerberos on 88, LDAP on 389, SMB on 445, Kerberos password change on 464, the Global Catalog on 3268, and WinRM on 5985. The RDP certificate leaks the domain name and the DC hostname.

One detail that trips up solvers is clock skew. Kerberos enforces a five minute tolerance window between the client and the Key Distribution Center. If your clock drifts more than five minutes behind the DC, every Kerberos request fails with a skew error. Always sync before you start anything that touches Kerberos, and remember that on modern Linux you have to disable automatic NTP before you can push the clock manually.

Enumeration with RPC and LDAP reveals three accounts of interest. A standard user, a matching admin account for that same person (the standard tiered admin pattern where every administrator has two accounts), and a per RODC krbtgt account whose numeric suffix matches the RODC's key version number. The presence of that suffix is the single biggest hint that this box is about Read Only Domain Controllers.

Stage 2: Logon Script Hijack

Every Active Directory user object has an attribute called scriptPath. When a user logs on interactively, the Domain Controller tells the client to fetch and execute a script from a share called NETLOGON, which is a virtual mount over a folder inside SYSVOL. If two independent ACL mistakes exist at the same time, an attacker can achieve code execution without ever knowing the victim's password.

The first mistake is a writable SYSVOL scripts folder. By default only Domain Admins can write there. On Garfield, any domain user can drop a file into that folder.

The second mistake is a write permission on the target user's scriptPath attribute. The attacker points the target's script at the file they just dropped, and the next time that user logs on, the Domain Controller pushes the malicious script to the client. Game over for that user.

This technique is not new. Will Schroeder and Sean Metcalf documented it in 2016, and it still pays out in real engagements because writable SYSVOL is easy to miss in a permissions review. The blast radius is code execution as every interactive user.

Stage 3: Chaining ACL Edges Within the Domain

Once a foothold exists as a normal user, BloodHound shows the rest of the graph. On Garfield, the foothold user has the extended right called User-Force-Change-Password over a higher tier account. That right, known by its GUID to defenders, lets a principal reset another user's password without knowing the current one. It is typically granted to helpdesk teams scoped to a specific user OU. When it spans privilege tiers, it is a mistake.

From the higher tier account, the chain continues. That account is a member of a group that has the AddSelf right on the RODC Administrators group. AddSelf is a permission that lets a principal add themselves to a group. On a Read Only Domain Controller, membership in RODC Administrators grants local administrator rights. So an AddSelf edge that looks harmless in isolation becomes a direct path to local admin on a Domain Controller.

Stage 4: Resource Based Constrained Delegation

Resource Based Constrained Delegation, or RBCD, is the modern Kerberos delegation primitive. Every computer account has an attribute called msDS-AllowedToActOnBehalfOfOtherIdentity. That attribute holds a list of principals who are permitted to use the S4U2Proxy Kerberos extension to obtain service tickets on behalf of arbitrary users, but only for services on that specific machine.

If an attacker can write to that attribute on a target machine account, they can add an attacker controlled principal to the list. Because any authenticated user can, by default, create up to ten machine accounts in Active Directory, the attacker has everything they need. The result is a Kerberos service ticket for the target machine, issued in the name of any user the attacker chooses, including Administrator.

On Garfield, the higher tier account has WriteAccountRestrictions on the RODC's computer account. That right includes the ability to modify the RBCD attribute. The result is code execution on the RODC as Administrator, without ever knowing its password.

One subtle detail that catches solvers off guard: Read Only Domain Controllers reject RC4 encrypted tickets with a specific Kerberos error. The attacker has to force AES256 encryption when requesting the ticket, which means computing the AES key for the attacker controlled computer account from its password and salt. This is why some solvers see "STATUS_MORE_PROCESSING_REQUIRED" and cannot figure out why the S4U chain is failing.

Stage 5: Tunneling to the RODC

Read Only Domain Controllers are typically deployed in branch offices, DMZs, or disconnected sites. The whole point is to provide local authentication without exposing the full directory, so the RODC often sits on a different network from the writable DCs. On Garfield, the RODC lives on 192.168.100.0/24 while the writable DC is dual homed on both that subnet and the attacker facing subnet.

The pivot is standard. A tunneling tool such as Chisel or Ligolo-ng creates a SOCKS proxy or a TUN interface on the attacker machine that routes traffic through the writable DC onto the RODC subnet. From the attacker's perspective, the RODC becomes a normal target. All subsequent SMB, WinRM, and Kerberos traffic to the RODC flows through the tunnel.

Stage 6: The Per RODC krbtgt Account

Every writable Domain Controller shares a single secret called the krbtgt key. That key signs every Kerberos Ticket Granting Ticket in the domain. Compromise it and you can forge tickets for any user. The traditional Golden Ticket attack is built on this.

Read Only Domain Controllers cannot use the domain krbtgt key because they cannot hold the full directory. Instead, each RODC has its own krbtgt style account, named krbtgt_<RID>. The numeric suffix is the RODC's key version number and is different for every RODC in the domain. Tickets signed by this key are normally only accepted by the RODC that owns it.

The key is stored in the RODC's LSA secrets store. Once you have local admin or SYSTEM on the RODC, you can dump it. On Garfield, the account is called krbtgt_8245.

Stage 7: The RODC Golden Ticket and Kerb-Key-List

This is the technique that makes Garfield worth writing about. A traditional Golden Ticket is signed with the writable DC's krbtgt key and is accepted by every DC in the forest. An RODC Golden Ticket is signed with the krbtgt_ key and, by default, is only accepted by the RODC that owns the account. That seems useless. What can an attacker do with a ticket for a machine they already control?

The answer is the Kerb-Key-List Request, documented in the MS-KILE specification and added to Active Directory in newer Windows Server versions. When a service ticket request includes a key list extension, the KDC responds with the existing long term keys for the requested principal. The keys returned include the principal's NT hash and its AES256 key.

There is a condition. The KDC only returns those keys if the requesting RODC is configured to be allowed to read that principal's secrets. That configuration lives in two attributes on the RODC's computer account: msDS-RevealOnDemandGroup and msDS-NeverRevealGroup. The first controls who can be revealed. The second is a deny list, and it typically contains the built in Administrators group. Since Administrator is a member of that group, the Key-List request is initially refused.

The attacker controls the RODC. If they also control the account that has WriteAccountRestrictions on the RODC's computer account, they can edit both attributes. They add Administrator to the reveal list, clear the never reveal list, and then forge an RODC Golden Ticket as Administrator signed with the krbtgt_8245 key. That ticket is presented to the writable DC in a Key-List request, and the DC returns Administrator's long term credentials.

At that point the attacker has Administrator's NT hash. Pass-the-Hash to the writable DC and the box is complete.

Why the Traditional RODC Assumption Is Wrong

For years the security industry treated Read Only Domain Controllers as a hardened boundary. The reasoning was simple. An RODC only holds secrets it has been explicitly configured to hold. Even if it is compromised, the assumption was that an attacker would have to perform live replication or extract per account secrets, and both of those require the principal to be in the RODC's allowed replication group. The writable DC would be safe.

The Kerb-Key-List technique short circuits that entire assumption. Once you control the RODC, you can simply ask for a KeyList for any principal allowed to replicate to it. If a defender ever added a privileged user to the RODC's reveal on demand group, or failed to properly scope the never reveal group, that RODC becomes a first class path to domain compromise.

Auditing the password replication policy on every RODC should be a top priority for any AD security program.

Defensive Takeaways

• Audit SYSVOL share and NTFS permissions. Only Domain Admins should be able to write to the scripts folder. Subscribe to Object Access events for writes by non Domain Admins.
• Run BloodHound proactively. Any ACL path from a low tier principal to a high value target is a finding. There should be zero such paths.
• Never grant AddSelf to a wider group on RODC Administrators or other DC admin equivalent groups.
• Disable the default machine account quota, or at least set it to zero, to make RBCD attacks harder to bootstrap. Monitor writes to msDS-AllowedToActOnBehalfOfOtherIdentity with Event ID 5136.
• Review the msDS-RevealOnDemandGroup and msDS-NeverRevealGroup on every RODC. The defaults should be respected. Any modification deserves a ticket and a forensic review.
• Add Administrator to Protected Users. Restrict WinRM to specific admin workstations. Require smartcard logon for Domain Admins.

Final Thoughts

Garfield is a well designed box because it forces the solver to understand seven different AD primitives and to chain them coherently. It is not about finding a bug. It is about understanding how Active Directory actually works and where an organization's configuration choices can open doors that were never intended to be open.

If you want to get better at Active Directory attack paths, this is the box to study. Every step is documented by Microsoft, every primitive is used the way it was designed, and the final technique, the RODC Golden Ticket combined with a Kerb-Key-List request, is one of the most interesting additions to the AD attacker toolkit in recent years.

If this walkthrough helped you, consider buying me a coffee. It keeps the detailed writeups coming.