[Feature Idea] Idea to add powershell scripts

[PoSHMagiC0de]

hey @mame82 Benn thinking about your Powershell thing. Since you are using a .NET DLL, have you though about adding a Powershell script or command job handler to it using System.Management.Automation?

You could even run them async with the option of a timeout in case they are running a script that shouldn't take too long and with a cancelation token you can make it so you track it with the Pi and kill the script if you want. I was scrounging through your backdoor dll project to find where to add something like that and talk back through your channels but taking some time with work and stuff. Look into it if you have not already. You could make the function take the script as base64 encoding. Hell, compress and encode it from the pi to make it smaller if you like to send less and have to not worry about special keys or anything and have the function on the agent undo it and run it. I was going to create a custom Posh command that will just use the CreateProc functions to do a Powershell process, unicode base 64 the script or command to place on the command line but issues could ensue if someone gets nutty and their script is huge, with the cmdline 8K character limit.

[mame82]

As you stated running powershell code is possible with CreateProc or shell powershell.

But indeed i was thinking about inline PowerShell runspaces using System.Management.Automation. There's a simple reason for that: the upload function.

The backdoor allows uploading files to disc. With some small changes it would allow uploading to MemoryStreams which is similar to the technique shown with the frontdoor payload. But without support of PowerShell it would be hard to make use of the data uploaded into memory to run code.

So rough idea is:

• keep at least one powershell runspace ready in the remote agent
• if files are uploaded to memory, propagate them as variable of type byte[] to the session state of this runspace
• allow remote command invokation for this runspace

The idea is still very rough and won't be implemented to soon.

There are several design decisions involved, I haven't even thought about. Especially when it comes to the need for an elevated PS session (invoking Mimikatz for example). This is because I'm not able to carry over HID communication to a newly spawned process (like meterpreters migrate would do).

So to make something practical out of it in terms of PS support, much more effort has to be put into the HID backdoor.

A benefit of using System.Automation over running something like CreateProc powershell would be, that no new PowerShell child process is spawned (at least till jobs come into play). So afain some brain work is needed on how to handle asynchronous PowerShell tasks. From my opinion avoiding jobs, in favor of dedicated PowerShell runspaces (with dedicated pipelines) is the way to go when it comes to concurrent running PS tasks. But on the other hand I know how weird and confusing the code could get, because the first remote agent for backdoor payload was built on pure PowerShell using multiple Runspaces. This ended up in a mess (thread safe data exchange between runspaces is difficult, memory leakages occurred making GC useless, CPU consumption was high).

So I'm still trying to find the most simple, but flexible approach to introduce PowerShell support in a way allowing usage of in-memory-uploads (my only use case, so far)

[mame82]

Btw. If the aim of you proposal (you mentioned base64 data transfer) to push PS scripts to the target in order to run them, we are barely talking about the same. But my idea would do it like this:

• upload PS1 file to memory (no base64 encoding, thus faster)
• propagate the upload to a variable in the PowerShell runspace as $var1
• run iex $var1 | out-string $varResult
• dowload $varResult

Thus P4wnP1 backdoor shell needs 3 new methods:

• uploadToPS
• downloadFromPS
• invokePSCommand

Additionally a function wrapping up the single steps into one command runFromPS, like the shell command wraps up CreateProc and interact.

So @PoSHMagiC0de, seems the initial brainstorming on this is finished ;-)

I've done the same, but the other way around, for frontdoor when providing a bash to Windows. A single bash process is ran to proceas incoming commands and could be restarted remotely when it stalls. But this was much easier (bash is cgaracter stream based, powershell needs to exchange objects with NET agent)

[PoSHMagiC0de]

Sorry for delay, been a busy week. The first idea of the compression was if you were to get around the Powershell way just launching powershell processes from the command line so the scripts could fit and also did not know if it was beneficial to compress the script before sending serially to the agent. I was thinking you could create the Powershell run space when the command is issued but did not know if you needed another serial channel for that or if you had a central job handling mechanism that handled all that.