[not an issue] idea: diskless upload and execute .exe

[moo-im-a-cow]

hi I have a method of running a software keylogger:

$ FireStage1
$ upload /home/pi/keylog.exe
$ shell
C:/users/user>keylog.exe
<console output from keylog.exe>

where /home/pi/keylog.exe is any executable that prints characters to the command line

a few problems with this approach:

• file C:/users/user/keylog.exe is written to disk
• takes 4 commands to do this

My idea is to add a command runexe /home/pi/file.exe this command would use the hid backdoor to upload the executable, but wont write it to disk, it will be kept in memory (similar to the backdoor itself), and will act like the shell command piping all output (and input if executable requires)

[mame82]

The base idea of in-memory download&exec is very nice.

The current shell abuses the fact, that powershell (or WMF) are trusted binaries and pre-compiled NET-code is injected at runtime, which neither goes to disk, nor triggers AV. Of course, using the 'upload' command breaks with this approach, as it writes to disc.

Now to upload and execute a PE file (dll or exe) in-memory, another approach has to be taken. An example would be reflective DLL injection into the target process. The underlying techniques are well understood (and detectable). For example meterpreter is using this technique.

Most powershell post exploitation frameworks have pre-built scripts to allow exactly this kind of in-memory code execution, on pure powershell basis. This again could be used with the backdoor, iif direct PowerShell access would be possible (e.g. triggering IEX and piping output back to the shell).

The idea for this is ready and discussed here: https://github.com/mame82/P4wnP1/issues/87

Unfotunately, I'm missing the time to implement this, right now.

Btw. these well-known post exploitation frameworks ship pure PowerShell based keyloggers, which could be ran directly, if PS script execution is supported by the backdoor.

More PowerShell support would allow running sophisticated post exploitation scripts ... the reflective-dll-injection alone would allow migration to other processes and gaining persistence. But in order to communicate through the HID device backchannel, support for a more "socket like" approach has to be added, which is another ToDo. As always, time is the limiting factor.