Attacking Execution Policy

So last night I was hanging out in the chat room during the live taping of the Powerscripting Podcast.  Their guest was self-proclaimed “Security Ninja” David Kennedy.  The interview was a lot of fun and really compelling.  During the conversation he discussed a presentation he gave at Blackhat and Defcon that showed how to use PowerShell as a payload system (not an exploit).  You can check out the code from the presentation here (at the bottom of the page).

The SAM dump script is interesting – David definitely needs to learn how to use pinvoke code with add-type, but we’ll let him slide on that  What is more interesting to me is the technique he used to get around a restricted execution policy.  To summarize he reads a script as Base64 encoding and then passes it into the powershell.exe with the -encodedCommand parameter.

I couldn’t resist one-lining this.  If you put this in a batch file like execute.bat you can call a PowerShell script by typing

execute.bat script.ps1

PowerShell -noprofile -Command "PowerShell -noprofile -encodedCommand ([Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes((Get-Content %1 |%%{$_}|out-string))))"

If you just want to paste it into a cmd prompt you need to omit the %1 and %% like this:

PowerShell -noprofile -Command "PowerShell -noprofile -encodedCommand ([Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes((Get-Content .\t.ps1 |%{$_}|out-string))))"

David says that Microsoft doesn’t consider this an exploit because execution policy was never intended to be a security feature.  In a way this makes sense.  It’s real intention is to prevent a user from accidentally double-clicking on an untrusted PowerShell script.  However, it’s still a way to get a PowerShell script run on a system that is locked down when you don’t have the rights to change the execution policy yourself.

Well, the ninja is cool in my book.  I highly recommend checking out the show when it’s released next week as episode 129.

About these ads