2 replies to this topic

[joakim]

File Name: Payload Execution Tools
File Submitter: joakim
File Submitted: 15 Mar 2012
File Updated: 18 Mar 2012
File Category: Security

I have lately been diving into the topic of threads and how code can be executed by using different apis. Here's a few sample programs showing different methods of executing code;

DigSigExec

Payload2CallWindowProc

RemoteWinExec

RemotePayload

Backdoor AutoIt PoC v4

Session0Injectors (2 tools; Session0Cmd and Session0Payload)

They mostly originate from this thread discussing backdoors and anti-virus (AV); http://reboot.pro/16405/

In the rest of the text "payload" refers to machinecode that will do a certain task (possibly but not necessarily generated by the MetaSploit tools, as described in the linked thread. A payload may be further obfuscated and/or encrypted to prevent detection by AV.

Short description of the tools;

DigSigExec
Is a program that will find a payload hidden inside the Authenticode digital signature of an executable. An executable can here for instance be a signed exe, dll or sys. The method of obfuscating and hiding the payload is found here; http://reboot.pro/fi...gnaturetweaker/ DigSigExec uses the Windows api CreateThread for actual execution of the final deobfuscated payload. This is a GUI application and supports compression and/or encryption for the payload.

Payload2CallWindowProc
Is a program that executes a file with a payload that is base64 encoded (ie payload in textual form). The api used for the execution is CallWindowProc. This particular sample is a console app, and is somewhat lame, as the payload does not exit cleanly by itself. You need to press CRL+C at the console to exit it, so it was mainly used to show a different method of executing some arbitrary payload. By definition of the underlying api, this sample is probably the most limited by the ones described here (but still worth looking at).

RemoteWinExec
Is a console application that will be start processes by injecting threads into remote processes. The important api is here CreateRemoteThread, which in contrast to the 2 above mentioned tools that uses the running process, will use an external process for the job. In this particular sample the api WinExec in kernel32.dll is used for the injection of the commands. The included readme describes what minor modifications are needed to implement a payload execution by CreateRemoteThread. Remote threads accross user sessions is possible, but possibly not recommended. Anyways, with administrator privileges we can easily work around this by setting the SeDebugPrivilege flag (meaning the SYSTEM account is all yours, at least on nt5.x). The tool however, is compiled with RequireAdmin flag, and will thus not work for non-admins. But that does not mean that non-admins cannot inject into remote processes. It just means that non-admins cannot inject accross user sessions. If you want, you could easily recompile it for non-admins. Not exactly sure how this is for nt6.x, but is true for nt5.x. The technique of using CreateRemoteThread is similarly used when doing dllinjection.

RemotePayload
Is very similar to RemoteWinExec, but instead injects and executes pure machinecode into the virtual address space of a remote process.

Backdoor AutoIt PoC v4
A very different method of starting a process from within a remote process, by completely rebuilding the PE in memory (trancexx). Actual backdoor is embedded as an encrypted resource of the exe.
All tools are tested working on 32-bit XP and 64-bit Windows 7. All tools also have their own readmes as well as source included.

Session0Injectors
These tools are using NtCreateThreadEx to create remote threads. Since nt6.x things changed slightly, and CreateRemoteThread could no longer create remote threads accross user sessions. The undocumented function NtCreateThreadEx does however allow us to circumvent this limitation. Note that in order to do such, you must be administrator. The reason is that the tool asigns the user SeDebugPrivilege, which only administrators can. Therefore you can with this tool execute code directly within session0 processes (ie running as NT AUTHORITY\SYSTEM). Attached is 2 slightly different tools.

Session0Cmd
Uses WinExec in combination with code injection to run native commands as you would from cmd.exe, but from user accounts running in session0. Takes 2 parameters, PID and CmdLine. Usage like this;

Session0Cmd 1165 "cmd /c dir c:\ > c:\dirlisting.txt"

Note that if you try to run an application that needs interaction with windows, you will be asked to switch user session (UI0Detect). Commands like the above example, will not require any switching, and commands are thus run on the fly directly.

Session0Payload
Slightly different to Session0Cmd in that it executes pure machinecode/payload directly into another process's virtual address space. Takes 2 parameters, PID and payload path. Usage like this;

Session0Payload 2365 "C:\tmp\payload.bin"

Both apps have been tested working on Windows 7 SP1 64-bit. As it uses an undocumented Windows api, it is not fool proof and not stable. The Session0Cmd however, seems stable. But Session0Payload does not exit from the thread cleanly. That means that when the thread exits, the parent process will also exit. So don't inject your code into winlogon.exe or any other critical system process wiht the Session0Payload tool. Here is a video I made showing an injected reverse shell with SYSTEM privileges and Kaspersky running in the background;

http://www.youtube.com/watch?v=X_aGLVBvgN8

In addition to these apis as used above;
CreateThread
CreateRemoteThread
CallWindowProc
NtCreateThreadEx

,also other apis can likely be used;

Refer to the first link provided at the top for how to generate a payload.

Sample screenshot for how it looks like when RemoteWinExec has injected commands into prosesses running under the SYSTEM account on nt5.x;



With RemotePayload you could achieve the same with a reverse shell...

Click here to download this file

[joakim]

I added 2 new tools that implement NtCreateThreadEx. That means remote threads accross user sessions are now possible on Windows 7. 1 tool is executing machinecode directly, while the other one takes commands as parameter. Both tools need a PID (process identifier) to hook up to and inject into. The Session0Cmd is thus sort of a cmd shell that will run commands with privileges of accounts running inside session0, like for instance the local SYSTEM account. That means you can also thus start any program with SYSTEM privileges, but will need to switch into a different user session (UI0Detect) if the program in question needs any window interaction. The other tool, Session0Payload, takes a binary file as second parameter and usually executes directly without any switching. For my tests I was working on spoolsv.exe (print spooler service). The Windows Defender also alowed memory modifications. I created a short video, linked in the first post, showing an injected reverse shell into session0 while a fully updated Kaspersky is running in the background without knowing. Only Kaspersky itself did not allow memory modifications, but failed at identifying such an attempt as possibly malicious.. Funny stuff..

Note: I found this undocumented function hard to get working. Other samples found on the Internet, all mention a certain structure that needs to be present. I only got this working when I completely removed it while also suspended/resumed the thread.

[joakim]

Just like to mention something interesting you can do with the Session0Cmd. I bumped into this thread at msfn regarding TrustedInstaller and how Windows Resource Protection (WRP) can be a pain for some power users; http://www.msfn.org/...ustedinstaller/ Basically one of the security measures introduced in nt6.x, besides session separation, was a new system service (Windows Module Installer) with full ACL and security descipits own SID and ACL (or token if you prefer). In short, even "NT AUTHORITYSYSTEM" get access denied when attempting to modify anything inside the WRP protected areas. Now the interesting part. You can use Session0Cmd and inject/start an application from within the TrustedInstaller. Effectively we then duplicate the token of TI into the new thread -> process. Very nice as we then also control the WRP protected areas. But because of the session separation, it is very hard to get such a session interactive. This is where networking comes into play. If you have a server running with the TI privileges ready to accept commands, then we are good. Actually I made a lame client/server toolkit for this, until I realized a much easier and solid solution. Use good old netcat and inject it into TrustedInstaller with Session0Cmd. That's the server you need. When connecting to it, you get a command prompt with the most privileges possible. No longer annoying access denied. So the commands to use;

Session0Cmd 2003 "nc -l -p 6789 -d -e cmd"

Now netcat is running as a daemon and serving cmd.exe for you on port 6789. To connect to it and obtain the actual power-cmd, open a cmd window and use this command;

nc localhost 6789

Note that any true interactive application still will be blocked by the session separation mechanism.

Good luck with hacking your system