Jeeves HTB
Jeeves Target Overview Jeeves is a Windows machine focused on Jenkins exploitation, credential extraction, and Windows post-exploitation techniques. The attack began with web enumeration, which revealed a Jenkins instance running on port 50000. Directory brute-forcing exposed the /askjeeves endpoint, leading to an accessible Jenkins dashboard. From there, access to the Jenkins Script Console allowed arbitrary Groovy code execution and provided an initial shell on the target system as the kohsuke user. During local enumeration, a KeePass database file (CEH.kdbx) was discovered inside the user’s Documents directory. The database was transferred to the attacker machine, the KeePass hash was extracted using keepass2john, and the master password was cracked with John the Ripper. Inside the KeePass database, an NTLM hash belonging to the Administrator account was discovered. This hash was then abused using a Pass-the-Hash attack with PsExec, resulting in full administrative access to the target machine. Finally, the root flag was recovered from a hidden NTFS Alternate Data Stream (ADS), demonstrating how hidden filesystem streams can be used to conceal sensitive data on Windows systems. --- Attack Path Perform Nmap scan and identify exposed services Discover Jenkins running on port 50000 Use ffuf to find the /askjeeves endpoint Access the Jenkins dashboard Abuse the Jenkins Script Console for Groovy-based RCE Gain an initial shell as the kohsuke user Discover the CEH.kdbx KeePass database Transfer the database to the attacker machine Extract the KeePass hash using keepass2john Crack the KeePass password using John the Ripper Recover Administrator NTLM credentials from the database Use Pass-the-Hash with PsExec to gain Administrator access Discover the hidden NTFS Alternate Data Stream Retrieve the root flag from the ADS Enumeration Nmap Scan As usual, the first step was to perform a full TCP service and version scan against the target machine to identify exposed services and gather initial information about the environment. Nmap Scan Analysis Based on the scan results, four interesting ports were identified: | Port | Service | Description | |------|----------|-------------| | 80 | HTTP | IIS web server hosting the Ask Jeeves website | | 135 | MSRPC | Microsoft Remote Procedure Call service | | 445 | SMB | Windows SMB file sharing service | | 50000 | Jetty | Jetty web application server | A few important observations from the scan: The target appears to be a Windows-based machine named JEEVES SMB signing was enabled but not required, which can sometimes lead to relay-related attack opportunities Port 50000 was running a Jetty web server, which is commonly associated with Jenkins applications The default page on port 50000 returned a 404 response, suggesting that additional directories or applications might exist behind the service The presence of a Jetty server on a high port made port 50000 especially interesting, so the next step was to investigate the web applications running on both port 80 and 50000. Exploring the Web Application The first web application running on port 80 was opened in the browser for manual inspection. The site returned a simple webpage named Ask Jeeves: image The page itself appeared minimal and only contained a search functionality. --- Testing the Search Functionality After interacting with the search feature, clicking the search button redirected the browser to an error.html page: image At first glance, this looked like a real application error page. However, upon closer inspection, the response appeared suspicious because the "error message" looked more like a static image rather than dynamically generated content. To verify this, the page source and developer tools were inspected: image This confirmed that the page was simply displaying an image and not returning any meaningful backend error information. Since the web application on port 80 did not expose any immediate attack surface, attention shifted toward the more interesting service running on port 50000, which appeared to be powered by Jetty. Investigating Port 50000 Next, the service running on port 50000 was opened in the browser for further inspection. The page returned a Jenkins instance: image One interesting observation was the Jetty 9.4.z-SNAPSHOT banner identified earlier during the Nmap scan. Clicking on the snapshot link redirected to the official Jetty project page, confirming that the application was indeed running on a Jetty web server. At this point, the service looked much more promising than the website hosted on port 80, so the next step was to perform directory brute-forcing in order to identify hidden paths or applications. --- Directory Bruteforcing with FFUF ffuf was used to enumerate directories on port 50000 using a common directory wordlist: The scan revealed a valid path named: The endpoint returned a 302 redirect, indicating that an application or dashboard existed behind the route. --- Accessing the Jenkins Dashboard After visiting the discovered /askjeeves path in the browser, the Jenkins dashboard became accessible: image The dashboard appeared to allow unauthenticated access, which is highly unusual for Jenkins instances since Jenkins often provides functionality for: script execution plugin management build execution credential storage Because Jenkins is commonly targeted for remote code execution attacks and administrative misconfigurations, the next step was to inspect the available features and look for ways to gain command execution on the target system. Finding a Path to Command Execution While exploring the Jenkins dashboard, the Manage Jenkins section exposed access to the Script Console. The Jenkins Script Console is an extremely powerful administrative feature that allows execution of Groovy scripts directly on the underlying server. By navigating to: the following page became accessible: image This was a critical finding because access to the Script Console typically means direct remote code execution on the host operating system. Since Groovy scripts executed from the console run with the same privileges as the Jenkins service, the next step was to test command execution and determine whether a shell could be obtained on the target machine. Gaining Remote Code Execution via Jenkins Script Console Since the Jenkins Script Console allows execution of arbitrary Groovy code on the server, the next step was to attempt remote command execution by spawning a reverse shell. --- Setting Up the Listener Before executing the payload, a Netcat listener was started on the attacker machine to receive the incoming reverse shell connection: --- Groovy Reverse Shell Payload The following Groovy-based reverse shell payload was entered into the Jenkins Script Console. The payload launches cmd.exe on the target system and redirects the input/output streams back to the attacker machine over a TCP connection. The payload was then executed by clicking the Run button inside the Jenkins Script Console. image --- Receiving the Reverse Shell After executing the script, the Netcat listener received a reverse shell connection from the target machine: Verifying the Current User Context Initially, it appeared that the reverse shell had landed with administrative privileges because the shell opened inside the Administrator profile directory. However, after verifying the current user context, it became clear that the shell was actually running as the kohsuke user: This indicated that the Jenkins service was running under the kohsuke account rather than as NT AUTHORITY\SYSTEM or the local Administrator. Even though full administrator access had not yet been achieved, obtaining an authenticated shell as a valid local user was still a significant foothold. --- User Flag The next step was to inspect the kohsuke user directories for useful files and retrieve the user flag. Navigating to the desktop revealed the user.txt file: The user flag was then retrieved: --- Privilege Escalation Enumeration After obtaining the user flag, the next step was to continue local enumeration and search for files that could help escalate privileges. Inside the Documents directory, an interesting file named CEH.kdbx was discovered: The .kdbx extension indicated that the file was a KeePass password database. KeePass databases often contain stored credentials, notes, or administrative passwords, making this file a valuable target for offline analysis. --- Transferring the KeePass Database To analyze the database locally, the file needed to be transferred from the target machine to the attacker system. An SMB share was created locally using Impacket’s SMB server: Once the SMB share was available, the CEH.kdbx file was copied from the target machine to the attacker machine: At this point, the KeePass database had been successfully transferred and was ready for offline password cracking and credential analysis. Analyzing the KeePass Database The transferred CEH.kdbx file was identified as a KeePass password database. To inspect the database locally, KeePassXC was installed on the attacker machine: Once installed, the database was opened using: image However, the database was protected with a master password, preventing direct access to its contents. Since KeePass databases can often be cracked offline, the next step was to extract the password hash and attempt dictionary-based password cracking. --- Extracting the KeePass Hash keepass2john was used to convert the KeePass database into a crackable hash format compatible with John the Ripper: This generated a hash file named CEH.HASH. --- Cracking the KeePass Password John the Ripper was then used with the rockyou.txt wordlist to perform an offline dictionary attack against the KeePass database: The KeePass master password was successfully cracked: At this point, the KeePass database could now be opened and inspected for stored credentials or sensitive information that might assist with privilege escalation. Inspecting the KeePass Entries With the KeePass master password successfully cracked, the database was opened again using: After entering the password moonshine1, the stored entries inside the database became accessible: image Several credentials were present inside the database. However, attempts to authenticate using the discovered plaintext passwords were unsuccessful. One entry named Backup stuff appeared different from the others because instead of a plaintext password, it contained what looked like an NTLM hash: The format strongly indicated a Windows NTLM hash, making it suitable for Pass-the-Hash authentication attacks. Since the shell already provided network access to the target machine, the next step was to attempt remote administrative authentication using the recovered NTLM hash. --- Gaining Administrator Access via Pass-the-Hash PsExec from the Impacket toolkit was used to authenticate as the Administrator user using the recovered NTLM hash: The Pass-the-Hash attack succeeded, providing a shell with administrative privileges on the target machine. --- Root Flag After gaining administrative access, the next step was to retrieve the root flag from the Administrator desktop. However, unlike most machines, no root.txt file was immediately visible. Listing the contents of the desktop revealed an unusual file named hm.txt: Reading the file returned the following message: The message strongly hinted that the real flag was hidden rather than stored directly inside the file. --- Discovering the Alternate Data Stream (ADS) Windows NTFS supports a feature called Alternate Data Streams (ADS), which allows hidden data to be attached to files without appearing in standard directory listings. To inspect hidden streams attached to hm.txt, PowerShell was used: The output revealed a hidden stream named root.txt. --- Reading the Hidden Root Flag The hidden Alternate Data Stream was accessed using PowerShell: The root flag was successfully recovered from the hidden