HTB: Jeeves

8 min readAug 30, 2026

Privilege Escalation & Methodology Write-up

Focus: Initial Foothold → Local Enumeration → Privilege Escalation

Introduction

This write-up focuses primarily on the privilege escalation phase of the HTB Jeeves machine rather than providing a complete step-by-step solution to every question or flag.

The objective is to document my enumeration methodology, reasoning, and decision-making process after obtaining an initial foothold.

Instead of simply listing commands and exploits, I will explain:

What I discovered during enumeration
Why a particular finding was interesting
What a technique or exploit actually does
Why I decided to investigate it
What I expected to happen
What actually happened
What I learned from the result

The overall approach was:

Reconnaissance
      ↓
Service Enumeration
      ↓
Jenkins Discovery
      ↓
Initial Foothold
      ↓
User Enumeration
      ↓
Local Enumeration
      ↓
Privilege Escalation Enumeration
      ↓
Evaluate Possible LPE Techniques
      ↓
SYSTEM

Note: This is intentionally not written as a simple "follow these commands to solve Jeeves" guide. The focus is on understanding the attack path and the reasoning behind each step.

Reconnaissance

I started with basic network enumeration using Nmap to identify the services exposed by the target.

Nmap

nmap -Pn -T4 [Target IP]

The scan revealed several interesting services, including:

After some try to access port 80 and 50000

I could not get anymore helpful information so I moved to the next step

Directory Enumeration

I continued enumeration using Gobuster to discover directories and endpoints that weren’t immediately visible from the main page.

gobuster dir -u http://[TARGET_IP]:[PORT] -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

at this path, the Jenkins installation was accessible.

I then navigated through the Jenkins interface and discovered the Script Console.

The Jenkins service immediately stood out because Jenkins can expose functionality that allows users to execute code on the underlying server, depending on the level of access available.

Why Jenkins caught my attention

Jenkins is primarily a CI/CD automation platform, but it can execute scripts and commands as part of jobs or administrative functionality.

Therefore, once I identified Jenkins, I wanted to determine:

Can I access any functionality that allows arbitrary code execution?

Initial Foothold — Jenkins Script Console

The Jenkins Script Console was the key finding that led to my initial foothold.

The console allows Groovy scripts to be executed directly on the Jenkins server.

The important observation here was:

If I can execute arbitrary Groovy code on the Jenkins server, I may be able to execute commands on the underlying Windows operating system.

I therefore used the Script Console to execute a command that established a reverse shell back to my attacking machine.

I found this one was useful https://gist.github.com/frohoff/fed1ffaab9b9beeb1c76

On my attacking machine, I configured the corresponding listener:

nc -lvnp 8044

The connection succeeded and gave me a session.

Identifying the Initial User

Once I obtained the session, I immediately checked which account the session was running under.

getuid

The result was:

Server username: JEEVES\[redacted]

This is an important point in the attack chain.

I had achieved remote code execution, but I had not yet achieved the highest privilege level.

Therefore, the next phase was:

Local enumeration and privilege escalation.

At this point, I wanted to answer several questions:

Who am I?
What privileges do I have?
What operating system/version is running?
What processes/services are running?
Are there interesting files or credentials?
Are there known local vulnerabilities?

I investigated the Windows environment.

Current privileges

I checked the Windows privileges from a shell:

whoami /priv

This information is particularly important for Windows privilege escalation because certain privileges can provide powerful escalation primitives.

Credential / File Enumeration

During the post-exploitation enumeration, I inspected the user’s directories for potentially interesting files.

One particularly interesting file was:

C:\Users\[redacted]\Documents\CEH.kdbx

The .kdbx extension indicates a KeePass database.

This immediately became interesting because a KeePass database can contain stored credentials.

My reasoning was:

Accessible user directory
        ↓
Interesting .kdbx file
        ↓
Potential credential store
        ↓
Possible additional credentials
        ↓
Potential privilege escalation path

I transferred the database to my Linux machine:

download "C:\\Users\\[redacted]\\Documents\\CEH.kdbx"

KeePass Credential Path

I identified a KeePass database (CEH.kdbx) that could potentially contain useful credentials. The database was password protected, so one possible path was to extract its hash and crack the master password with Hashcat.

However, I chose not to pursue the KeePass cracking path. Instead, I focused on privilege-escalation enumeration and looked for a direct escalation technique that matched the target’s environment.

Upgrading the Initial Shell

After obtaining the initial reverse shell through the Jenkins Script Console, I wanted a more capable session for post-exploitation and enumeration.

I used Metasploit’s Web Delivery module to deliver a PowerShell-based Meterpreter payload to the target. I configured it for the Windows environment and executed the generated command from my existing shell.

Get Hadeer Amr’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The connection was successfully received by Metasploit, resulting in a Meterpreter session.

The important point is that I was not using Web Delivery as the initial foothold. Jenkins had already provided code execution and the initial reverse shell. Web Delivery was used afterward to obtain a more functional post-exploitation session.

The attack chain was:

Jenkins Script Console
        ↓
Groovy Code Execution
        ↓
Initial Reverse Shell
        ↓
Web Delivery
        ↓
Meterpreter Session

Privilege Escalation Enumeration

Rather than immediately choosing an exploit, I wanted to identify which escalation mechanisms were relevant to the current system.

One useful Metasploit module for this purpose is:

post/multi/recon/local_exploit_suggester

I ran:

run post/multi/recon/local_exploit_suggester

Metasploit reported several potential candidates.

Among the results were:

exploit/windows/local/bits_ntlm_token_impersonation
exploit/windows/local/ms16_075_reflection
exploit/windows/local/ms16_075_reflection_juicy

Understanding local_exploit_suggester

An important lesson here is that the output of local_exploit_suggester should not be interpreted as: “These exploits definitely work, so run all of them.”

Instead, it should be treated as a list of potential candidates based on the information Metasploit collected from the target.

My reasoning was therefore:

Exploit suggested
       ↓
Understand what it targets
       ↓
Compare it with my current privilege/context
       ↓
Determine whether it actually makes sense
       ↓
Test if appropriate
       ↓
Verify the result

This avoids blindly executing exploits without understanding why they might work.

Investigating MS16–075 / Juicy

One of the techniques that caught my attention was:

exploit/windows/local/ms16_075_reflection_juicy

The module describes the vulnerability as:

Windows Net-NTLMv2 Reflection DCOM/RPC (Juicy)

Why did I investigate it?

There were several reasons:

The local exploit suggester identified the target as potentially vulnerable.
The target was an older Windows environment.
The technique involves DCOM/RPC and NTLM reflection.
It is a well-known Windows local privilege-escalation technique.
It was directly relevant to the privilege-escalation phase I was investigating.

I therefore loaded the module:

use exploit/windows/local/ms16_075_reflection_juicy

Press enter or click to view image in full size

and the session was elevated

Tip before attempting a local privilege escalation exploit, I should always establish:

Current user
Current integrity level
Current privileges
Current token

In this case, verification showed:

JEEVES\[redacted]
        ↓
[PRIVILEGE ESCALATION STAGE]
        ↓
NT AUTHORITY\SYSTEM

Final Privilege State

Therefore, the privilege escalation objective was achieved.

Initial Foothold
      │
      │ Jenkins Script Console
      ▼
Groovy Code Execution
      │
      ▼
Initial Reverse Shell
      │
      │ Web Delivery
      ▼
Meterpreter Session
      │
      │ Identify User / Privileges
      ▼
JEEVES\
      │
      │ Local Enumeration
      │
      ├── CEH.kdbx
      │      │
      │      └── Potential Credential Path
      │
      ▼
Privilege Escalation Enumeration
      │
      │ Local Exploit Suggester
      │
      ├── MS16-075 / Juicy Candidate
      │
      └── Verify Current Privilege
      ▼
NT AUTHORITY\SYSTEM

What I Learned

This machine reinforced the importance of methodology over blindly running exploits. Enumeration should drive exploitation:

Enumerate → Understand → Hypothesize → Test → Verify

Tools such as local_exploit_suggester should be treated as a source of potential candidates, not proof that an exploit will work.

The most important lesson was to always verify the current privilege level before attempting LPE; the Session is already elevated message led me to check getuid and confirm that I was already NT AUTHORITY\SYSTEM.

The discovery of CEH.kdbx also showed how credential and file enumeration can reveal alternative attack paths.

Finally, understanding the context of each shell—Meterpreter vs. Windows CMD—is essential for choosing the correct commands and avoiding unnecessary troubleshooting.

Mitigation

From a defensive perspective, several controls could reduce or eliminate this attack path.

Jenkins

Restrict access to the Jenkins administrative interface.
Require strong authentication and authorization.
Restrict access to the Script Console.
Run Jenkins using a dedicated low-privilege service account.
Keep Jenkins and plugins updated.

Credential Storage

Sensitive credentials should not be stored in easily accessible locations where a compromised user can retrieve them.

KeePass databases should be protected with:

Strong master passwords
Appropriate filesystem permissions
Secure storage
Proper credential rotation

Windows Privilege Escalation

Windows systems should be kept fully patched and unnecessary privileges should be removed from service accounts.

Particular attention should be given to:

DCOM
NTLM
Token impersonation privileges
Service-account privileges
Local administrator permissions

Final Takeaway

The main lesson from this machine was not simply learning a particular exploit.

The more valuable lesson was understanding how to move from:

"I have a shell."

to:

"What exactly can this shell do?"

and then:

"What evidence do I have for a particular privilege-escalation path?"

The process becomes:

Recon
  ↓
Initial Access
  ↓
Identify User
  ↓
Local Enumeration
  ↓
Credential / File Discovery
  ↓
Privilege Enumeration
  ↓
Research Potential LPEs
  ↓
Validate Before Exploiting
  ↓
Verify Privilege
  ↓
SYSTEM