Right now, offensive use of Powershell is one the hottest topics in infosec. Powershell scripts are most often pitched as being appropriate for the "post-exploitation" phase of a penetration. This question follows somewhat along those lines, except it involves taking a step toward using Powershell a bit earlier than usual: when the only foothold you've gotten so far has been from getting an application to run shellcode of your choosing. (Call it " very early post-exploitation" if you like.) So:

Let's say you are in a situation where you have gained the ability to execute assembly shellcode (with no size limit or character restrictions) inside a certain process on a Windows machine. You want to leverage that ability not to directly run lots of low level code, but to do something quite different: to create a execution environment inside that process where you can run Powershell code.

The reasoning behind that choice is pretty simple: setting up a Powershell execution environment allows you to take advantage of all of the ever-increasing Tools, Tactics, and Procedures that use Powershell that the security community now has produced/is producing. And setting up that environment within a process that's already running allows you to avoid starting a new process to run the Powershell code (and especially avoid starting powershell.exe, cmd.exe, or wscript.exe) like most lower-skill pen testers and bad guys will often do, something that can be very, very suspicious to a defender that is monitoring event logs or is using well-configured HIDS/HIPS software. The overall goal is to replicate some of the capabilities and stealth of some higher-end attackers without having to much custom programming work in low level programming languages, instead taking advantage of the universe of Powershell scripts/tools that already exist.

I know that the general concept of what I'm interested in doing here works, because I've been able to prove it out, using (for example) Metasploit--specifically with adllinject payload that starts from shellcode generated by msfvenom-- along with a reflective dll (from Empire, for eg.) to successfully get a Powershell agent up and running without creating a new process in a number of test situations. But, to be frank, I'm a little skittish about the idea of using anything that relies on Metasploit payloads or communications for something that might eventually (hopefully) be used during an actual engagement against a defender with HIDS, HIPS, NIDS, etc.

Are there alternative tools/methods that might be quieter while accomplishing the same result--getting Powershell code running on a target where you already have some code execution and without creating a new process that might be easily detected? I'm open to considering pretty much anything that doesn't require writing a lot of custom code in assembly. (Though, of course, more straightforward to implement is always preferable.)

  • WMI with Create Process.
    – Overmind
    Commented Jan 7, 2017 at 14:00
  • @Overmind The problem is that creating a new process is what I'm trying to avoid. Commented Jan 7, 2017 at 17:49

1 Answer 1


If I understood correctly what you want, you could try mapping a writable page, writing code to it, switching it to executable, and then you just execute it (and it can be your PS or anything). Use VirtualAlloc instead of Malloc to obtain memory-write permissions with PAGE_EXECUTE_READWRITE. Do not forget to set the execution flag using VirtualProtect after writing to the memory but before finally executing it. Such a tactic should work for your objective and no new process is involved.

  • This is solution. The PS interpreter needs to be in memory and have some way to receive your PS scripts, unless it's a one-shot deal. This could mean re-using the socket/fd, some sort of connect-back, etc. Obviously this will require some custom assembly. If you're that worried about payload detection, you could just write your own msfvenom encoder, and custom communication channel via the PS script.
    – movsx
    Commented Jan 13, 2017 at 16:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .