Staying Hidden on the Endpoint: Evading Detection with Shellcode

Written by: Evan Pena, Casey Erikson

True red team assessments require a secondary objective of avoiding detection. Part of the glory of a successful red team assessment is not getting detected by anything or anyone on the system. As modern Endpoint Detection and Response (EDR) products have matured over the years, the red teams must follow suit. This blog post will provide some insights into how the FireEye Mandiant Red Team crafts payloads to bypass modern EDR products and get full command and control (C2) on their victims’ systems.

Shellcode injection or its execution is our favorite method for launching our C2 payload on a victim system; but what is shellcode? Michael Sikorski defines shellcode as a “…term commonly used to describe any piece of self-contained executable code” (Practical Malware Analysis). Most commercial Penetration Testing Frameworks such as Empire, Cobalt Strike, or Metasploit have a shellcode generator built into the tool. The shellcode generator is generally in either a binary format or hex format depending on whether you generate it as raw output or as an application source.

Why do we use shellcode for all our payloads?

The use of shellcode in our red team assessment payloads allows us to be incredibly flexible in the type of payload we use. Shellcode runners can be in written in a wide range of programming languages that can be incorporated into many types of payloads. This flexibility allows us to customize our payloads to support the specific needs of our clients and of any given situation that may arise during a red team assessment. Since shellcode can be launched from inside a payload or injected into an already running process, we can use several techniques to increase the ability of our payloads to evade detection from EDR products depending on the scenario and technology in place in the target environment. Several techniques exist for obfuscating shellcode, such as encryption and custom encoding, that make it difficult for EDR products to detect shellcode from commercial C2 tools on its own. The flexibility and evasive properties of shellcode are the primary reason that we rely heavily on shellcode based payloads during red team assessments.

Shellcode Injection Vs. Execution

One of the most crucial parts of any red team assessment is developing a payload that will successfully, reliably, and stealthily run on the target system. Payloads can either execute shellcode from within its own process or inject shellcode into the address space of another process that will ultimately execute the shellcode. For the purposes of this blog post we’ll refer to shellcode injection as shellcode executed inside a remote process and shellcode execution as shellcode executed inside the payload process.

Shellcode injection is one technique that red teams and malicious attackers use to avoid detection from EDR products and network defenders. Additionally, many EDR products implement detections based on expected behavior of windows processes. For example, an attacker that executes Mimikatz from the context of an arbitrary process, let’s say DefinitelyNotEvil.exe, may get detected or blocked outright because the EDR tool does not expect that process to access lsass.exe. However, by injecting into a windows process, such as svchost.exe, that regularly touches lsass.exe, it may be possible to bypass these detections because the EDR product sees this as an expected behavior.

In this blog post, we’ll cover three different techniques for running shellcode.

• CreateThread
• CreateRemoteThread
• QueueUserAPC

Each of these techniques corresponds to a Windows API function that is responsible for the allocation of a thread to the shellcode, ultimately resulting in the shellcode being run. CreateThread is a technique used for shellcode execution while CreateRemoteThread and QueueUserAPC are forms of shellcode injection.

The following is a high-level outline of the process for running shellcode with each of the three different techniques.

CreateThread

1. Allocate memory in the current process
2. Copy shellcode into the allocated memory
3. Modify the protections of the newly allocated memory to allow execution of code from within that memory space
4. Create a thread with the base address of the allocated memory segment
5. Wait on the thread handle to return

CreateRemoteThread

1. Get the process ID of the process to inject into
2. Open the target process
3. Allocate executable memory within the target process
4. Write shellcode into the allocated memory
5. Create a thread in the remote process with the start address of the allocated memory segment