carnal0wnage [Shared Reader]

Tuesday, May 15, 2012

PowerShell, Shellcode, metasploit, x64

This is a quick blog post based on my slides from the May 2012 NovaHackers Meeting

Two posts got me started looking at PowerShell and its ability to execute shellcode


The first post talks about executing shellcode and gives the calc.exe example. These examples work on x64 and x86. yay!

The second post talks about doing something more than calc.exe...getting shell whooo hooooo

You can review the code but it only shows a x86/32bit shellcode. This will fail miserably on x64.

I was initially thought it would be an easy fix, just grab an x64 payload from MSF. Problem is there are no x64 http/https payloads...

CG was a sad panda.

This left me with two options:

Suck it up and use an existing x64 payload (like rev_tcp) or just pop calc.exe to prove how awesome i am during pentests


Invoke 32 bit PowerShell and run 32 bit shellcode (now we get http/https payloads)

So googling turned up a way to tell PowerShell to use the x86 version even on x64. The solution i used was here:

You will need to set the execution policy for  v1.0 powershell, or possibly try a bypass technique.

I ended up adding this to Nicolas' code before it started doing its thing (line 24). It detects if its not x86 and just runs the shellcode with the x86 PowerShell.  You'll have to set the execution policy for it first.

[Byte[]]$sc = $sc32
if ($env:Processor_Architecture -ne "x86")
  write-warning "WTF!  This is 64x, switching to 32x and continuing script."
   &"$env:windir\syswow64\windowspowershell\v1.0\powershell.exe" -noprofile -file $myinvocation.Mycommand.path -executionpolicy bypass

now it works

Remember that you have to migrate out of the PowerShell process.
Much like the office macro and shellcode exec, if user closes office, or you close exit powershell process shell goes bye-bye.



Matt said...

For the scripts on exploit-monday, any 32/64-bit Windows shellcode should work as long as you specify 'thread' as the exit method since the technique I use calls CreateThread. The same goes for shellcode generated for PowerSyringe.

Glad you're enjoying the evil applications of PowerShell! ;D


CG said...

yes but the point i was making is that there is no x64 HTTP/HTTPS shellcode for msf.

you are still going to need x64 shellcode to run on x64 unless you specifically call the x86 powershell and pass it the x86 shellcode correct?

Matt said...

No. You're right about the lack of 64-bit HTTP payloads.

I was just making the point that the script you referenced will execute more than just calc.

As a note, you can also test if you're in 32 vs 64-bit PowerShell via `[IntPtr]::Size`.

Matt said...

Hey Chris,

So my question to you is...

Would you rather see pure 64-bit reverse HTTP shellcode or would you be interested in a PowerShell reverse-HTTP stage 1 that just pulled down and executed stage 2? I could implement either one or both given enough demand.

Facebook Application Developer said...

I also use calls CreateThread. The same goes for shellcode generated for PowerSyringe but i I could implement either one or both given enough demand.

PsYcH said...

Hi CG,

I'm sorta in a situation where everything in a Citrix environment is blocked by Group Policy/Applocker, but I can run macros under Office. Problem though is there is a proxy for outbound http/https and there's no x64 metasploit reverse http/https payloads ! I've tested the other x64 payloads and they seem to work but I cant get to run cmd.exe etc to user powershell as Group/Policy applocker blocks it. Any way outta this ??


CG said...

the post goes though showing you how to invoke the 32 bit powershell so you can do http/https