Shellter is a dynamic shellcode injection tool, and probably the first dynamic PE infector ever created.

It can be used in order to inject shellcode into native Windows applications (currently 32-bit apps only).

The shellcode can be something yours or something generated through a framework, such as Metasploit.

Shellter takes advantage of the original structure of the PE file and doesn’t apply any modification such as changing memory access permissions in sections (unless the user wants and/or he chooses Basic Mode), adding an extra section with RWE access,and whatever would look dodgy under an AV scan.

Shellter uses a unique dynamic approach which is based on the execution flow of the target application.

How does it work?

Shellter uses a unique dynamic approach which is based on the execution flow of the target application. This means that no static/predefined locations are used for shellcode injection. Shellter will launch and trace the target, while at the same time will log the execution flow of the application.

What does it trace?

Shellter traces the entire execution flow that occurs in userland. That means,code inside the target application  itself (PE image), and code outside of it that might be in a system dll or on a heap, etc. This happens in order to ensure that functions actually belonging to the target executable, but are only used as callback functions for Windows APIs will not be missed.

However, the tracing engine will not log any instructions that are not in the memory range of the PE image of the target application, since these cannot be used as a reference to permanently inject the shellcode.

Why do I need Shellter?
Bypass AVs.

Executables created through Metasploit are most likely detected by most AV vendors. By using Shellter, you automatically have an infinitely polymorphic executable template, since you can use any 32-bit ‘standalone’ native Windows executable to host your shellcode. By ‘standalone’ means an executable that  doesn’t need any proprietary DLLs, apart from the system DLLs to load and run. For example, notepad.exe, and many other applications you can find online, or create by yourself as your own custom templates.

You can also use applications that make use of proprietary DLLs if those are not required to create the process in the first place, and are normally loaded later on if needed to execute code for a specific task. In case you select an application that needs one or more proprietary DLLs to create the process in the first place then you will have to include them in the same directory from where you load the main executable. However, this is not recommended since it is more convenient to have just a single executable to upload to the target.

What types of apps can I use?

You can basically use any 32-bit standalone (see above) native Windows application. Of course, since the main goal is to bypass an AV,you should always avoid packed applications or generally applications that have ‘dodgy’
characteristics such as sections with RWE permissions, more than one sections containing executable code etc..

Another reason why you should avoid packed applications is because advanced packers will also check for modifications of the file, so you will probably just break it. Advanced packers also perform various anti-reversing tricks which will detect Shellter’s debugging engine during tracing. If you are a lover of packers, you can first perform the injection and then pack the application with the packer of your choice.

The best bet is to use completely legitimate looking applications (ideally not packed) that are not flagged by any AV vendor for any reason.

These can be either yours, or something you got online.

Can I use encoded/self-decrypting payloads?

Shellter also supports encoded/self-decrypting payloads by taking advantage of  the Imports Table of the application. It will look for specific imported APIs that can be used on runtime to execute a self-decrypting payload without doing any modifications in the section’s characteristics from inside the PE Header.

At the moment 7 methods are supported for loading encoded payloads:

•     VirtualAlloc
•     VirtualAllocEx
•     VirtualProtect
•     VirtualProtectEx
•     HeapCreate/HeapAlloc
•     LoadLibrary/GetProcAddress
•     CreateFileMapping/MapViewOfFile

If the target PE file doesn’t import by default the necessary API(s) then  a method wil be shown as ‘N/A’.
If a method requires more than one APIs, like for example method 4, it will also be shown as ‘N/A’ if the PE file doesn’t import all of them.

If none of the encoded payload handler methods supported are available for the current PE target, you can choose to either select a non-encoded payload or to change the section’s characteristics from inside the PE Header.

This last option has been added in order to provide more flexibility to the user in case he still wants to use a specific encoded payload along with the same PE file.