Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Garfield machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs.
Garfield Machine Summary
Garfield is a Windows Active Directory machine that required chaining domain enumeration, SYSVOL abuse, logon script manipulation, Kerberos delegation abuse, RODC password replication abuse, and NTDS dumping to obtain both the user and root flags. The attack started with valid domain credentials for j.arbuckle, which were used to enumerate accessible SMB shares and identify write access to the SYSVOL scripts directory.
Using smbclient, I authenticated to the SYSVOL share and browsed to garfield.htb\scripts, where I found an existing batch file named printerDetect.bat. Since this location was writable, I generated a PowerShell reverse shell payload, encoded it in UTF-16LE Base64, and placed it inside a new printerDetect.bat file. I then uploaded the modified batch file back into the SYSVOL scripts directory. Next, I abused Active Directory logon script configuration by using bloodyAD to set the scriptPath attribute of the Liz Wilson user object to printerDetect.bat. Before triggering the script, I started a Netcat listener on port 4444. Once the logon script executed, I received a reverse shell as garfield\l.wilson, confirming code execution in the context of that user.
From the l.wilson shell, I reset the password of the privileged account l.wilson_adm using PowerShell’s Set-ADAccountPassword. After resetting the password, I verified WinRM access with NetExec and then logged in using Evil-WinRM as garfield\l.wilson_adm. This gave me a stable interactive shell and allowed me to read the user flag from C:\Users\l.wilson_adm\Desktop\user.txt. After obtaining the user flag, I continued enumeration as l.wilson_adm. I discovered that the domain contained both DC01.garfield.htb and RODC01.garfield.htb. DNS resolution showed that RODC01 was located on the internal subnet 192.168.100.0/24, specifically at 192.168.100.2. I also checked privileges and group membership, confirming that l.wilson_adm had useful domain permissions, including membership in the Tier 1 group.
To reach the internal RODC subnet, I downloaded Ligolo-ng, uploaded the Windows agent to the target, and started the Ligolo proxy on my Kali machine. After launching the agent from the Evil-WinRM session, the Ligolo proxy received a connection from GARFIELD\l.wilson_adm@DC01. I fixed the TUN interface permission issue by deleting and recreating the ligolo interface under my current user, then successfully started the tunnel. Once the tunnel was active, I added a route for 192.168.100.0/24 through the Ligolo interface and confirmed connectivity to 192.168.100.2 with ping. I then authenticated to RODC01 over SMB using l.wilson_adm, confirming that the credentials worked across the internal network.
With access established, I created a fake machine account named FAKE$ using impacket-addcomputer. I then used PowerShell from Evil-WinRM to configure Resource-Based Constrained Delegation by setting PrincipalsAllowedToDelegateToAccount on RODC01, allowing the fake computer account to delegate to the RODC. After synchronizing my Kali time with the domain controller using ntpdate, I used impacket-getST to request a service ticket for cifs/RODC01.garfield.htb while impersonating Administrator.
The generated Kerberos ticket was exported into KRB5CCNAME, and I used impacket-psexec with Kerberos authentication to connect to RODC01. This successfully opened a shell as nt authority\system, giving me full control over the Read-Only Domain Controller. From the SYSTEM shell on RODC01, I transferred mimikatz.exe using a Python HTTP server and certutil. After launching Mimikatz, I enabled debug privileges and dumped the RODC-specific krbtgt_8245 account secrets using lsadump::lsa /inject /name:krbtgt_8245. This revealed the AES256 key for the RODC krbtgt account, which was required to forge an RODC golden ticket.
To prepare for the next stage, I transferred PowerView and Rubeus to the target. With PowerView loaded, I modified the RODC password replication policy by setting msDS-RevealOnDemandGroup to include both the Allowed RODC Password Replication Group and the Administrator account, then cleared msDS-NeverRevealGroup. This allowed the Administrator password material to be replicated to the RODC. Using Rubeus, I forged an RODC golden ticket for Administrator with /rodcNumber:8245, the domain SID, and the dumped AES256 key. I then used Rubeus asktgs with the Key List request option to request the Administrator key material from the domain controller. The output revealed the Administrator NTLM hash: eexxxxxxebxxxxxx04xxxxxx75xxxxxx.
After extracting the Base64 ticket output, I saved it into /tmp/ticket.b64, cleaned it, decoded it into /tmp/ticket.kirbi, and converted it into a Linux-compatible .ccache file using impacket-ticketConverter. I exported the cache with KRB5CCNAME and used NetExec with --use-kcache --ntds to authenticate as GARFIELD.HTB\Administrator and dump NTDS hashes from DC01. Finally, with the Administrator NTLM hash recovered, I performed pass-the-hash authentication using Evil-WinRM.
Protected Page
The first step in owning the Garfield machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
Initial Access Information
After starting the Garfield machine, I noted the assigned target IP address as 10.129.61.223. The machine information also provided an initial domain user account, which meant this box was intended to begin from an authenticated Active Directory enumeration path rather than a completely unauthenticated one.
Nmap Enumeration
I started the enumeration by running an aggressive Nmap scan against the target to identify open ports, running services, version information, and possible domain details. The scan immediately showed that the host is a Windows Active Directory machine, with services such as DNS, Kerberos, LDAP, SMB, RPC, RDP, and WinRM exposed.
From the results, I confirmed that the target belongs to the garfield.htb domain and the domain controller hostname is DC01.garfield.htb. The presence of ports 53, 88, 389, 445, 3268, and 5985 strongly indicates an Active Directory environment.
The RDP NTLM information also leaked useful domain metadata, including the NetBIOS domain name GARFIELD, computer name DC01, and DNS domain garfield.htb. SMB signing was enabled and required, which means relay attacks against SMB would not be straightforward.
Another important finding was the clock skew of +8 hours, which is relevant for Kerberos-based attacks because time synchronization issues can cause authentication failures. Based on this scan, I added DC01.garfield.htb and garfield.htb to my hosts file before continuing with domain enumeration.
Nmap Enumeration
After identifying the domain name and domain controller from the Nmap scan, I updated my local /etc/hosts file so the target’s hostname could resolve properly from my machine. This is important because many Active Directory services rely on hostname-based communication instead of only using the IP address.
The command mapped the target IP address to both DC01.garfield.htb and garfield.htb. With this in place, I could interact with Kerberos, LDAP, SMB, WinRM, and other domain services using the proper domain names during the next stage of enumeration.
SMB Enumeration
After confirming the domain information, I tested the provided credentials against SMB and enumerated the available shares on the domain controller. This helped confirm that the credentials for j.arbuckle were valid and that the account could authenticate successfully to the garfield.htb domain.
The output showed that authentication was successful as garfield.htb\j.arbuckle. I also enumerated the default domain shares and found readable access to IPC$, NETLOGON, and SYSVOL, while administrative shares like ADMIN$ and C$ were present but not accessible.
This confirmed that the user had low-privileged domain access, which was enough to continue with Active Directory enumeration and check domain shares for useful files, scripts, or policy information.
SMB User Enumeration
With valid domain credentials confirmed, I continued SMB enumeration by listing domain users from the target. This allowed me to identify other accounts that could become useful later for password spraying, Kerberos attacks, or privilege escalation paths.
The command authenticated successfully as garfield.htb\j.arbuckle and returned seven users in the domain. Besides the default accounts such as Administrator, Guest, and krbtgt, I discovered interesting users like l.wilson and l.wilson_adm.
The presence of a separate admin-style account, l.wilson_adm, stood out as a potential target for further enumeration. This gave me a clearer list of domain users to investigate in the next stage of the attack path.
Active Directory Permission Enumeration
After identifying the domain users, I used bloodyAD to check which Active Directory objects the j.arbuckle account had write access to. This step was important because writable objects can often lead to privilege escalation if the permissions are misconfigured.
The output showed that j.arbuckle had WRITE permission over multiple objects, including Jon Arbuckle, Liz Wilson, and Liz Wilson ADM. The most interesting finding was write access over Liz Wilson ADM, since the _ADM naming convention suggests a higher-privileged account.
This misconfiguration gave me a potential path to abuse Active Directory object permissions and move from a low-privileged user toward a more privileged account.
Active Directory Permission Abuse
After finding that j.arbuckle had write permissions over other domain users, I attempted to abuse that access by resetting the password for l.wilson. The goal was to take control of the account and use it for further domain enumeration or privilege escalation.
However, the password reset failed with an LDAP modification error. The message indicated that the password could not be changed, possibly because the operation required the old password or because the permission was not enough to perform a direct password reset through LDAP.
This showed that although the account had writable permissions, the abuse path was not as simple as resetting the password directly. At this point, I needed to look for another way to abuse the write permission, such as modifying account attributes or using a different password change method.
SYSVOL Enumeration
After confirming that j.arbuckle had read access to SYSVOL, I connected to the share using smbclient to manually inspect the domain scripts directory. SYSVOL is useful during Active Directory enumeration because it often contains logon scripts, policies, or configuration files.
Inside the share, I navigated to the garfield.htb\scripts directory and listed its contents. This revealed a batch script named printerDetect.bat, which looked interesting because logon scripts can sometimes contain hardcoded paths, commands, or credentials.
Finding this script gave me another lead to investigate. The next step was to download or read the file contents to understand what it does and whether it could expose useful information for the attack path.
Payload Preparation
After identifying a possible script-based attack path, I prepared a PowerShell reverse shell payload and encoded it in UTF-16LE Base64 format. This encoding is commonly used when passing commands to PowerShell with the -EncodedCommand option, because PowerShell expects the encoded command in UTF-16LE.
The command generated a long Base64 string containing the encoded PowerShell payload. I used my VPN IP 10.10.14.105 and port 4444, so if the payload was executed on the target, it would connect back to my listener.
This gave me a ready-to-use encoded command that could be inserted into a script or execution point without dealing with quoting issues in the raw PowerShell payload.
Payload Staging
After generating the encoded PowerShell payload, I created a new printerDetect.bat file locally. The idea was to replace or upload a modified version of the existing logon script with a payload that would execute PowerShell and connect back to my listener.
The batch file disables interactive PowerShell prompts, hides the window, bypasses execution policy, and runs the Base64-encoded command. Since the payload points back to 10.10.14.105:4444, I would need a listener running before triggering the script.
This prepared payload could then be uploaded into the writable script location if permissions allowed, turning the logon script into a potential code execution path.
SYSVOL Script Overwrite
After preparing the modified printerDetect.bat file, I reconnected to the SYSVOL share using the j.arbuckle credentials and navigated back to the domain scripts directory. Since the account had write access, I attempted to overwrite the existing script with my payload.
%20Hack%20The%20Box.jpg "Garfield (Hard) | Hack The Box")
The upload completed successfully, and the directory listing showed that printerDetect.bat had been updated with a new timestamp and larger file size. This confirmed that I could modify the SYSVOL script, creating a potential execution path if the script was later triggered by a user or scheduled process.
At this stage, I had successfully weaponized the writable logon script location and prepared it to call back to my listener.
Active Directory ScriptPath Abuse
After uploading the modified batch file into SYSVOL, I used the writable permission on the Liz Wilson user object to modify her scriptPath attribute. This would cause the domain to reference printerDetect.bat as the user’s logon script.
The command completed successfully and confirmed that the scriptPath attribute for Liz Wilson was updated. This meant that if l.wilson logged in, the modified script from SYSVOL could execute in that user’s context.
This was a key privilege escalation step because it abused writable Active Directory attributes instead of requiring a direct password reset.
Reverse Shell as Liz Wilson
Before modifying the scriptPath attribute, I started a Netcat listener on port 4444 to catch the callback from the PowerShell payload. Once the logon script was triggered, the target connected back to my machine and gave me an interactive shell.
The listener received a connection from 10.129.61.223, confirming that the uploaded printerDetect.bat payload executed successfully. I then verified the context of the shell by running whoami.
The output showed garfield\l.wilson, meaning I successfully moved from j.arbuckle to a shell as l.wilson by abusing the writable scriptPath attribute and the SYSVOL logon script.
Privilege Escalation to Admin Account
After gaining a shell as garfield\l.wilson, I used the available Active Directory permissions to reset the password of the higher-privileged account l.wilson_adm. Since the _adm account appeared to be an administrative variant of the same user, it became the next logical target for escalation.
The command uses Set-ADAccountPassword to reset the password for l.wilson_adm to a known value. ConvertTo-SecureString converts the plaintext password into the secure format required by PowerShell before applying the reset.
This step allowed me to take control of the admin-style account and continue the attack path with higher privileges in the domain.
WinRM Access Validation
After resetting the password for l.wilson_adm, I tested the new credentials against WinRM to confirm whether the account had remote management access. This was an important check because WinRM access would allow me to obtain an interactive shell on the domain controller.
The authentication succeeded, and NetExec returned Pwn3d!, confirming that l.wilson_adm had valid WinRM access on DC01. The warning shown was only a Python cryptography deprecation warning and did not affect the result.
This confirmed that the password reset worked and that I could now move from a low-privileged user to a privileged remote shell path through WinRM.
WinRM Shell and Domain Computer Enumeration
After confirming that l.wilson_adm had WinRM access, I used Evil-WinRM to obtain an interactive PowerShell session on the target. Once connected, I verified the current user context to make sure the shell was running as the admin-style account.
The output confirmed that I was operating as garfield\l.wilson_adm. From there, I enumerated domain computers using PowerShell to understand the domain layout and identify other systems that might be relevant.
The domain contained two computer objects: DC01.garfield.htb and RODC01.garfield.htb. The presence of RODC01 stood out because read-only domain controllers can introduce interesting Kerberos and credential replication attack paths.
RODC and Privilege Enumeration
After identifying RODC01 as another domain computer, I resolved its hostname from the WinRM session to find its internal IP address. This confirmed that RODC01.garfield.htb existed on an internal network segment at 192.168.100.2.
Next, I checked the privileges available to the current l.wilson_adm session to understand what actions the account could perform locally or within the domain.
The output showed that SeMachineAccountPrivilege was enabled, meaning the account could add workstations to the domain. This was an important finding because machine account creation can be abused in Active Directory attack paths such as delegation or Kerberos-based privilege escalation.
The other privileges were standard, but the combination of RODC discovery and machine account creation capability gave me a new direction for further enumeration and exploitation.
Group Membership Enumeration
After gaining access as l.wilson_adm, I checked the current user’s group memberships to understand what level of access the account had in the domain. This helped confirm whether the account belonged to any privileged or role-based groups.
![HackTheBox Garfield [Hard] Full Walkthrough](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0K6Z5uUMy83BkXAI43YTkDjHVILmAEqB4ygyJvtm6p3dBRQ1dGhk-jGcIzm1L8hQ6BbVeBB5xlOw_Om3oiz8S0oi9258QPHhfRLJ3Fp82KXErm5y0RgmU5vQeT_wj0eS2BOy7in279OQLn-ZK6ykt3bfMyHF1B-3iubl6ls7-XSi4CWtu8UwnP7Jj1qw6/s1756/HackTheBox%20Garfield%20%5BHard%5D%20Full%20Walkthrough.jpg "HackTheBox Garfield [Hard] Full Walkthrough")
The output showed that the user was a member of Remote Desktop Users and Remote Management Users, which explained why WinRM access was allowed. More importantly, the account was also part of the GARFIELD\Tier 1 group.
The Tier 1 group stood out as a potential privileged administrative group. This suggested that l.wilson_adm may have elevated rights over certain systems or objects, making it worth investigating its permissions further.
User Flag
After gaining a stable WinRM shell as l.wilson_adm, I moved from the Documents directory to the user’s Desktop to check for the user flag. The Desktop contained a user.txt file, which is typically where the user flag is stored in Hack The Box machines.
I then read the contents of the file to capture the flag.
The file contained the user flag, confirming that the initial access and privilege escalation path to l.wilson_adm was successful. At this point, I had completed the user-level objective and could continue enumerating for the root path.
RODC Group Abuse
After discovering the RODC01 host, I focused on gaining control over the read-only domain controller path. Since I was operating as l.wilson_adm, I attempted to add the account to the RODC Administrators group.
This command adds l.wilson_adm as a member of the RODC Administrators group. If successful, this would grant the account administrative control over the RODC-related management scope.
This was an important escalation step because RODC administration can expose additional attack paths, especially around credential caching, Kerberos behavior, and delegated control over the read-only domain controller.
Ligolo Agent Preparation
After identifying RODC01 on an internal network address, I prepared Ligolo-ng so I could pivot through the compromised Windows host and reach the 192.168.100.0/24 network. I first downloaded the Windows AMD64 Ligolo agent from the official release page.
After the archive downloaded successfully, I extracted it to get the Windows agent binary.
Finally, I listed the directory contents and confirmed that agent.exe was available. This binary would later be uploaded to the compromised host and used to establish a tunnel into the internal network.
Ligolo Agent Upload
After extracting the Ligolo Windows agent locally, I uploaded agent.exe to the compromised host through the Evil-WinRM session. I placed it on the l.wilson_adm Desktop so it would be easy to execute during the pivoting setup.
Once the upload completed, I listed the Desktop directory to confirm that the file was present on the target.
The directory listing showed agent.exe alongside user.txt, confirming that the upload was successful. With the agent now on the Windows host, I could use it to establish a Ligolo tunnel and reach the internal RODC01 network.
Ligolo Proxy Setup
After uploading the Ligolo agent to the compromised Windows host, I prepared the Ligolo proxy on my Kali machine. This proxy would receive the agent connection and create a tunnel that allowed me to reach the internal RODC01 network.
I extracted the downloaded archive to get the Ligolo proxy binary.
Then I created a TUN interface named ligolo and brought it up so traffic could be routed through the tunnel once the agent connected.
With the proxy files extracted and the tunnel interface ready, my attacker machine was prepared for pivoting into the internal network behind DC01.
RODC Host Resolution
After resolving RODC01 from the compromised host and identifying its internal IP address, I added the hostname to my local /etc/hosts file. This ensured that my Kali machine could resolve RODC01.garfield.htb correctly once the Ligolo tunnel was active.
The command mapped 192.168.100.2 to both RODC01.garfield.htb and RODC01. This made it easier to run Kerberos, LDAP, SMB, and other domain-related tools against the read-only domain controller using its proper hostname.
With name resolution configured, I was ready to route traffic through Ligolo and continue enumeration against the internal RODC.
Ligolo Proxy Listener
With the Ligolo proxy extracted and the tunnel interface prepared, I started the proxy listener on my Kali machine. I used a self-signed certificate and bound the listener to all interfaces on port 11601 so the Windows agent could connect back to it.
The output showed that Ligolo-ng started successfully and was listening on 0.0.0.0:11601. The certificate warnings were expected because I used the -selfcert option instead of a trusted certificate.
At this point, the proxy was ready and waiting for the uploaded agent.exe on the compromised Windows host to connect back, which would allow me to pivot into the internal 192.168.100.0/24 network.
Ligolo Agent Connection
With the Ligolo proxy already listening on my Kali machine, I executed the uploaded agent.exe from the Evil-WinRM shell. I pointed it back to my VPN IP on port 11601 and used -ignore-cert because the proxy was running with a self-signed certificate.
The agent reported that the connection was established successfully. On the Ligolo proxy side, I received an Agent joined message showing the session as GARFIELD\l.wilson_adm@DC01.
This confirmed that the pivot agent was running on DC01 and connected back to my attacker machine. With the agent active, I could now configure the Ligolo session and route traffic toward the internal RODC01 host.
Ligolo Tunnel Setup
After the agent connected back to the proxy, I selected the active Ligolo session for GARFIELD\l.wilson_adm@DC01 and attempted to start the tunnel. In Ligolo, I ran session, selected the available agent with Enter, and then ran start.
The first attempt failed because Ligolo could not open the existing ligolo TUN interface due to a permission issue. To fix this, I deleted the old interface and recreated it under my current user instead of root.
After recreating the interface, I returned to the Ligolo console and started the tunnel again.
This time, Ligolo successfully started the tunnel to GARFIELD\l.wilson_adm@DC01. With the tunnel active, I could now add routes and reach the internal RODC01 network through the compromised host.
Internal Network Routing
After starting the Ligolo tunnel, I added a route for the internal 192.168.100.0/24 network through the ligolo interface. This allowed my Kali machine to send traffic for the RODC subnet through the compromised DC01 host.
To confirm that the route worked, I tested connectivity to RODC01 at 192.168.100.2 using ping.
The ICMP replies confirmed that the pivot was working and that I could reach the internal RODC through the Ligolo tunnel. With network access established, I could now enumerate services on RODC01 directly from my attacker machine.
RODC SMB Access Check
After confirming that the Ligolo route to the internal subnet was working, I tested SMB authentication against RODC01 using the l.wilson_adm credentials. This verified whether the account could authenticate to the read-only domain controller over the pivot.
The output confirmed that the target was RODC01, running Windows Server 2019 in the garfield.htb domain. Authentication succeeded as garfield.htb\l.wilson_adm, showing that the credentials were valid against the internal RODC.
This confirmed that the pivot was functional for SMB traffic and that I could continue enumerating or abusing RODC-related permissions from my attacker machine.
Machine Account Creation
After confirming that l.wilson_adm had SeMachineAccountPrivilege, I abused that permission to create a new machine account in the domain. This is useful in Active Directory attack paths because controlled computer accounts can be used for delegation or Kerberos-based abuse.
The command successfully added a new machine account named FAKE$ with the password FakePass123!. I pointed the request at DC01 because it is the writable domain controller, unlike the RODC.
This gave me a controlled domain computer object that I could use in the next stage of the attack chain.
Machine Account Verification
After creating the FAKE$ machine account, I verified that it existed in Active Directory by enumerating LDAP users and filtering the output for the new account name. This confirmed whether the machine account creation step actually succeeded in the domain.
The command queries LDAP on DC01 using the l.wilson_adm credentials and searches the returned objects for FAKE. Since machine accounts are stored as AD objects, this was a quick way to confirm that FAKE$ was added successfully.
With the controlled computer account verified, I could continue using it for the next stage of the RODC or Kerberos-based attack path.
Resource-Based Constrained Delegation Setup
After creating the controlled machine account FAKE$, I used my l.wilson_adm WinRM session to configure delegation on the RODC01 computer object. The goal was to allow FAKE$ to delegate to RODC01, which sets up a Resource-Based Constrained Delegation attack path.
I then verified the change by reading the PrincipalsAllowedToDelegateToAccount property from the RODC01 computer object.
The output confirmed that CN=FAKE,CN=Computers,DC=garfield,DC=htb was now allowed to delegate to RODC01. This meant the controlled machine account could be used in the next Kerberos abuse step against the RODC.
Kerberos Time Synchronization
Before continuing with Kerberos-based attacks, I synchronized my Kali machine’s time with the domain controller. Kerberos is very sensitive to clock skew, and the earlier Nmap scan showed an 8 hour time difference between my machine and the target.
I first disabled automatic NTP so my system time would not immediately revert. Then I used ntpdate against DC01 to align my clock with the domain controller.
The output showed that the clock was stepped by about 28801 seconds, confirming the time correction. This reduced the chance of Kerberos errors such as clock skew failures during ticket requests.
S4U Ticket Request
After configuring Resource-Based Constrained Delegation on RODC01, I used the controlled machine account FAKE$ to request a service ticket for the CIFS service on RODC01. I impersonated Administrator so the resulting ticket could be used to access the target service with elevated privileges.
The output showed the full S4U flow: getting a TGT for FAKE$, performing S4U2Self, then requesting S4U2Proxy for cifs/RODC01.garfield.htb. The ticket was saved as an Administrator CIFS ccache file.
This confirmed that the RBCD setup worked and gave me a Kerberos service ticket that could be used to authenticate to RODC01 as Administrator.
Kerberos Ticket Abuse to SYSTEM
After obtaining the Administrator CIFS service ticket for RODC01, I exported it into KRB5CCNAME so Impacket tools could use the cached Kerberos ticket for authentication. I also verified that the environment variable pointed to the correct .ccache file.
With the ticket loaded, I used impacket-psexec with Kerberos authentication and no password to connect to RODC01 through the Ligolo route.
The tool found a writable ADMIN$ share, uploaded a service binary, and started a remote service on RODC01. After the shell opened, I ran whoami and confirmed the session was running as nt authority\system.
This confirmed successful privilege escalation on RODC01 using the RBCD-generated Kerberos ticket.
Tool Transfer to RODC01
After getting a SYSTEM shell on RODC01, I staged mimikatz.exe from my Kali machine so I could transfer it to the target. I copied the binary into /tmp, changed into that directory, and started a Python HTTP server on port 8888.
From the SYSTEM shell on RODC01, I moved into C:\Windows\Temp and used certutil to download the binary from my attacker machine.
The download completed successfully, and the directory listing confirmed that mimikatz.exe was saved in C:\Windows\Temp. The Python server also logged a GET /mimikatz.exe request, confirming that the file was served from my Kali machine to the target.
With the tool transferred, I was ready to dump credentials or inspect cached secrets from the compromised RODC.
Launching Mimikatz
After transferring mimikatz.exe to C:\Windows\Temp, I executed it from the SYSTEM shell on RODC01. This was done to confirm that the binary ran correctly before using it for credential or secret extraction.
The banner confirmed that Mimikatz started successfully and loaded the x64 version of the tool. Since the shell was already running as nt authority\system, I had the required context to interact with sensitive Windows authentication material.
At this point, the tool was ready for the next post-exploitation step, such as checking privileges or dumping cached credentials from the compromised RODC.
RODC krbtgt Hash Dump
Inside Mimikatz, I first enabled debug privileges so the tool could access protected authentication data. Since I was running as SYSTEM on RODC01, the privilege was granted successfully.
Next, I dumped the LSA secrets for the RODC-specific Kerberos account krbtgt_8245.
The output revealed the NTLM hash and Kerberos keys for krbtgt_8245, including AES keys. This account is important because RODCs use their own krbtgt account, separate from the main domain krbtgt.
With the RODC krbtgt_8245 material recovered, I now had the key information needed for RODC-focused Kerberos ticket abuse in the next stage.
PowerView Staging
After dumping the RODC krbtgt_8245 material, I prepared PowerView for further Active Directory enumeration. I first confirmed that PowerView.ps1 existed on my Kali machine inside the PowerSploit Recon directory.
Then I changed into the Recon directory and started a Python HTTP server on port 8888 so the script could be loaded from the target host.
This made PowerView.ps1 available over HTTP from my attacker machine. The next step was to import it into the Windows session and use it to enumerate domain objects, groups, and permissions.
PowerView Transfer
With the Python HTTP server hosting PowerView.ps1, I moved to the Desktop inside the Evil-WinRM session and downloaded the script using certutil. This allowed me to bring PowerView onto the compromised DC01 host for further Active Directory enumeration.
The download completed successfully, confirming that PowerView.ps1 was saved on the target. On my Kali machine, the Python server also logged a successful GET /PowerView.ps1 request from 10.129.61.223.
This confirmed the file transfer worked, and I could now import PowerView into the session to inspect domain groups, ACLs, and delegation-related permissions.
PowerView Import
After transferring PowerView.ps1 to the target, I temporarily bypassed the PowerShell execution policy for the current process. This allowed me to import the script without changing the system-wide policy.
Once PowerView was loaded, I checked for available domain object-related commands to confirm the module imported correctly.
The output showed functions such as Get-DomainObject, Set-DomainObject, and Get-DomainObjectAcl, confirming that PowerView was ready to use. This gave me the tooling needed to enumerate and modify Active Directory object properties during the next stage.
RODC Password Replication Policy Abuse
After importing PowerView, I modified the password replication policy on the RODC01$ computer object. I added both the Allowed RODC Password Replication Group and the Administrator account to msDS-RevealOnDemandGroup, which controls which credentials the RODC is allowed to cache.
I also cleared the msDS-NeverRevealGroup attribute to remove restrictions that could prevent password caching.
Finally, I verified the changes by querying the RODC computer object and checking the replication-related attributes.
The output confirmed that Administrator was now included in the reveal-on-demand list. This meant the RODC could be manipulated into caching the Administrator credential material, setting up the next step of the attack path.
Rubeus Staging
After modifying the RODC password replication policy, I prepared Rubeus for the next Kerberos-focused step. I downloaded the Windows executable to /tmp on my Kali machine so it could be served to the compromised host.
Then I changed into /tmp and started a Python HTTP server on port 8888.
This made Rubeus.exe available over HTTP from my attacker machine. The goal was to transfer it to the Windows host and use it for Kerberos ticket operations related to the RODC attack chain.
Rubeus Transfer
With the Python HTTP server hosting Rubeus.exe, I downloaded the binary from the Evil-WinRM session using certutil. I saved it in the current Documents directory so it would be ready for Kerberos ticket operations.
The download completed successfully, and the directory listing confirmed that Rubeus.exe was present with the expected file size. On my Kali machine, the HTTP server also logged a successful GET /Rubeus.exe request from 10.129.61.223.
This confirmed that Rubeus was transferred to the compromised host and ready to be used for the next Kerberos abuse step.
Rubeus Execution Check
After transferring Rubeus.exe to the compromised host, I executed it without arguments to confirm that the binary worked correctly inside the Evil-WinRM session. This also displayed the available Kerberos-related modules and syntax.
The output confirmed that Rubeus v2.3.3 launched successfully and printed its help menu. The available options included TGT requests, S4U delegation abuse, ticket forging, ticket management, Kerberoasting, and other Kerberos operations.
This confirmed that Rubeus was ready to use for the next stage of the attack path, especially the RODC-related ticket and Kerberos abuse steps.
RODC Golden Ticket Creation
After extracting the AES256 key for the RODC-specific krbtgt_8245 account, I used Rubeus to forge a golden ticket for the Administrator user. Since this was an RODC attack path, I specified the RODC number 8245 along with the domain SID and Administrator RID 500.
Rubeus successfully built the PAC, signed the ticket with the recovered RODC krbtgt AES key, and forged a TGT for Administrator@garfield.htb. The ticket was saved as a .kirbi file, which could later be injected or reused for Kerberos authentication.
This confirmed that the RODC key material was valid and could be abused to forge Administrator Kerberos tickets.
RODC Key List Request
After forging the RODC golden ticket, I used Rubeus to perform a Kerberos Key List Request against DC01. I supplied the forged .kirbi ticket and requested the krbtgt/garfield.htb service using AES256.
The request completed successfully and returned a krbtgt/GARFIELD.HTB ticket for Administrator. Most importantly, the output exposed the AES256 key material and the Password Hash value.
This confirmed that the forged RODC ticket was accepted for the Key List Request and allowed me to recover sensitive Kerberos key information for the Administrator account.
Converting the Base64 Ticket
After Rubeus returned the Base64-encoded Kerberos ticket, I saved the full ticket blob into a file so I could convert it into a usable .kirbi ticket on Kali.
I then switched to root, cleaned the file by removing leading spaces and line breaks, decoded the Base64 content, and wrote the output into /tmp/ticket.kirbi.
The ls output confirmed that the ticket file was created successfully, while xxd showed the expected binary ASN.1/Kerberos structure. This confirmed that the Base64 ticket was properly decoded and ready to be used in the next Kerberos authentication step.
Dumping NTDS with the Kerberos Ticket
After converting the forged .kirbi ticket into a Linux-compatible .ccache format, I exported it using KRB5CCNAME so NetExec could authenticate with Kerberos instead of a password.
With the ticket loaded, I used NetExec against DC01.garfield.htb with --use-kcache and --ntds to dump domain credential material from NTDS.
The output confirmed successful authentication as GARFIELD.HTB\Administrator from the Kerberos cache and returned Pwn3d!. NetExec then dumped NTLM hashes for domain accounts, including Administrator, krbtgt, j.arbuckle, l.wilson, l.wilson_adm, DC01$, RODC01$, and the created FAKE$ machine account.
Root Flag
After dumping the Administrator NTLM hash from NTDS, I used it to authenticate over WinRM with pass-the-hash and opened an Administrator shell on the domain controller.
Once connected, I confirmed the current context and verified that the session was running as the domain Administrator.
The output returned garfield\administrator, confirming full administrative access. From there, I read the final flag from the Administrator desktop.
This successfully revealed the root flag, completing the compromise of the Garfield machine.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee. Found this walkthrough helpful? Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕
Keywords:
Garfield HTB Write Up
Garfield HTB Walkthrough
Garfield Hack The Box Walkthrough
Garfield Hack the Box Write Up
garfield.htb machine season 10 Hack the Box
dc01.garfield.htb garfield.htb machine Hack the Box Season 10 Solution
owned garfield from hack the box
Rooted Garfield from Hack the Box
Pwned Garfield from Hack the Box
HTB Season 10 Garfield Writeup
Garfield Machine HackTheBox htb writeup
Garfield HTB
Complete Walkthrough Garfield HTB Machine
Garfield (Hard) Hack The Box
HTB Garfield Season 10 Walkthrough
Garfield HTB Machine User Flag
Garfield htb-writeups Season 10 Hack the Box
Garfield HTB Complete Writeup
HTB Writeup - Garfield
HTB Season10 Garfield
HackTheBox Garfield [Hard] Full Walkthrough
Garfield HTB All Scripts
I just solved Garfield on Hack the Box!
HackTheBox Writeup - Garfield
Garfield HTB CTF Walkthroughs
Mastering Garfield Beginner's Guide from Hack the Box
RODC01.garfield.htb
SmartHire Writeup - HackTheBox
SmartHire HTB Writeup
Helix Writeup - HackTheBox
Helix Walkthrough - HackTheBox
Helix HTB Walkthrough
helix.htb machine season 10 hack the box
Helix Hack the Box Writeup
Helix Hack the Box Walkthrough
Helix HackTheBox Season 10 Machine Write Up
pingpong.htb machine season 10
PingPong HTB Writeup
PingPong Hack the Box Write Up
cctv.htb hack the box season 10 machine walkthrough
CCTV HTB Write Up
CCTV Hack the Box Write Up
CCTV Hack the Box Walkthrough
cctv.htb writeup
CCTV Machine | HackTheBox
CCTV HackTheBox Writeup - Season 10 Linux Machine Walkthrough
Hack The Box - Season 10 HTB CCTV Writeup
HTB CCTV Write-up
CCTV WriteUp - HackTheBox
HTB CCTV Machine Write-Up
HTB Writeup - CCTV
CCTV HTB Complete Writeup
CCTV HTB Season 10 Hack the Box Complete Writeup
Owned CCTV from Hack The Box
Pwned CCTV from Hack The Box
Rooted CCTV from Hack the Box
I just CCTV from Hack the Box
I just owned Helix from Hack the Box
1 Comments
To current members, the password to access this encrypted page and other pages has been sent to your email address. If you haven't received it yet, reach out to me at isiaqibrahim.tr@gmail.com
ReplyDeleteNote: This write up includes the complete code blocks and commands. The password for each write up is different. I have sent the password to your inbox on Buy Me A Coffee.
Happy Hacking!!!😈