During pentesting, one sees such default webpages a lot. It implies two things:
a) The owner has probably a website somewhere in a different directory.
b)The owner does not work clean! So, what else they forgot to turn off?
Time to Directory busting.
Let’s back to the FTP thingy, where according to our NMAP result, anonymous login is allowed.
Let’s see what we can upload there:
We find a JPG file or make a text file and put it in a folder, from which we have initiated the FTP session, then upload the file:
Now, this leads to the question: what is stopping us from putting malicious code on that FTP and let it run by the server? To that, we can use Msfvenom for ASPX, since the server IIS.
To create a payload for x86:
To set up the listener using Metasploit, open up msfconsole:
Upload the malware into FTP:
Now engage that malware and let the server execute it.
On the webserver, call the malware. Nothing should get printed on the page:
In our Metasploit console, the shell should prompt:
No chance! We should go for a post-exploitation enumeration. We leave the reverse session as it is and go back to MSF:
We give it our session 1, we already got:
Now it searches for the best possible privilege escalations for this system and suggests to us what is possibly good:
Now we should do some trials to find what works:
We start with exploit/windows/local/ms10_015_kitrap0d and set the options:
It does not work because our previous session in the background is not running anymore.
We should put that back to work as follows:
Better to be a bit faster, this time with session 2:
Privilege escalated, It is a system user:
Now check the users' folders and find the txt files for flags:
P.S. Whole this could be done without Metasploit using NetCat (nc -nvlp 4444) for port listener and Msfvenom with a different payload than meterpreter, like windows/shell/reverse_tcp (do msfvenom -l payload to see the options).