Antisyphon KB

Payload Buffet

Nov 04, 202412 min read

Payload Buffet

The Payload Buffet is a quick and easy way to obtain a wide variety of diverse shellcode loaders using the DotCeption payload generation tool. Payload loader varieties produced range anywhere from a .NET assembly DLL used with InstallUtil.exe to a native Windows executable, native Windows DLL, and/or reflective loader DLL.

Payload loaders generated from DotCeption will always have a unique signature due to various cryptographic and code obfuscation randomization processes employed. There are three different programming languages employed, these being:

  • C#
  • Golang
  • C

The intent is to provide you with as many diverse options as possible. As of today, the most sophisticated payloads in the pipeline are the C based source code loaders called SimpleThread and ModuleStomp.

IMPORTANT: Always read the file called MANIFEST after you generate payload loaders. This file contains detailed information about the payload loaders produced.

Buffet Quick Start Instructions

The short quick version of what you need to do is:

  1. Clone the Payload Buffet repo via SSH from https://git.nopsled.me/joff.thyer/PayloadBuffet

  2. Replace the shellcode file you want to use in the “shellcode” directory. This can be either x86, x64 or both architectures. Make sure to keep the filename the same.

  3. Git commit / git push the repo back up to the server using what I call the “yolo” commit.

    git commit -a -m ”.”; git push

  4. Watch the spinning dial until the pipeline is finish and download your payload artifacts for immediate use. The resulting file is a ZIP file that then contains 7Zip files within it.

    NOTE:

    • The default 7ZIP password is always “infected”
    • If you already have the repo cloned, you should perform a git pull before you use the commit/push action since multiple people use the tool.

Oct-2022 → New Features Added: Red Macros and Payload Inflation

As of October 2022, two new features have been added to the Payload Buffet, these being a tool named “Red Macros”, and a payload inflation option. Both of these tools are controlled using a file called BuffetConfig.yml in the payload buffet runner default git branch.

Below is the default BuffetConfig.yml file that exists in the buffet. In this default configuration, both of the InflatePayload and RedMacros features are set to disable. To enable either or both of these you need to change the enable: field in the YML file to read True. Please note that case is important.

InflatePayload:
    enable: False
    target_size: 150M

RedMacros:
    enable: False
    icon_description: Software Updater
    icon_dll: c:\windows\system32\shell32.dll
    icon_indexes:
        - 4
        - 8
    embedding_methods:
        - exe
        - installutil
        - rundll32
        - regsvr32
    target_choices_exe:
        - RuntimeBroker.exe
        - smss.exe
        - timeout.exe
    target_choices_dll:
        - bfe.dll
        - cdp.dll
        - winsrv.dll

Red Macros

The Red Macros tool has a lot of capability beyond what is initially implemented in the buffet. Today, I chose to implement the embed-zip feature which will create shortcut (LNK) files with the embedded payload and an execution method. So yes, this really/truly means you can drop a shortcut file, and when clicked its going to execute the payload/loader that is embedded.

To reflect the different loaders needed for buffet payload output, the embedding_methods in the YML file specifies the four possible execution methods, those being plain executable through various living off the land binaries.

The other fields in the YAML that begin with target_choices_(exe|dll) represent a list of filenames that the payload will be unzipped to when executed. The unzip directory is by default the user’s TEMP environment variable.

The icon_dll: and icon_indexes: field allow you to specify a DLL from which to extract the ICON for the generated payload.

If/when you enable the Red Macros feature in the buffet, you will end up with an archive file that not only contains the payloads, but also a sub-directory named the same as each of the payloads and containing the shortcut LNK files corresponding to that payload in each sub-directory. There will be multiple icons in each sub-directory depending on how many icon indices you specify.

Payload Inflation

When payload inflation is enabled, every payload that is generated gets the target_size number of NULL bytes appended to the end of the payload. This is to assist with endpoint defense evasion, and the default value of 150MB seems to work well. You are of course welcome to change the default.

C language based defense evasions

There are two C language based payload loaders known as “SimpleThread” and “ModuleStomp” which only support x64 (64-bit) architecture. These two loaders have the following evasions enabled by default.

  • dynamic encryption key generation for shellcode encryption
  • EVADE_DEBUGGER: detects and exits process if a debugger is attached.
  • EVADE_LOWERENTROPY: introduces random strings from Windows system DLL’s to lower overall entropy and make resulting binary look more legitimate.
  • EVADE_MAXCORES: exits process if number of CPU cores is < 2.
  • EVADE_PRIMEDELAY: generates several thousand prime numbers before triggering shellcode loading process to delay shellcode execution.
  • EVADE_RICHHEADER: writes NULL bytes into the RICH compiler generated header.
  • EVADE_SYSWHISPERS: uses the SysWhispers3 Python script dynamically at compilation time to make direct kernel system calls evading any user-mode DLL hooking.
  • EVADE_UTCTIMEZONE: detects if the clock is set to UTC and exits process if true. Often sandboxes are set to UTC timezone and have limited CPU cores (see above).

DLL Side Jacking Feature

As of August 17, 2022, the payload buffet now has a feature which enables DLL loader file generation for DLL side jacking purposes. The quick background is that an application vulnerable to DLL side-jacking / hijacking essentially has a DLL load order / search path problem. The new feature enables us to quickly configure and generate DLL side jack / hijack payloads in the buffet assuming we have knowledge of a vulnerable application.

The example used to test this feature in the buffet is Microsoft Teams. Microsoft teams loads many different DLL’s when executed however suffers from a directory path search order issue. As an non-privileged user, if we place a file named “version.dll” in the %USERPROFILE%\AppData\Local\Microsoft\Teams\Current directory, Microsoft Teams will try and load this dynamic link library (DLL) before loading the authentic/original DLL which exists in \Windows\System32.

All we need to do is generate a DLL which executes payload when the DLL is loaded and attached to the process. Having said, there is one problem and that is the original functionality of the DLL will likely be needed by Microsoft Teams. The way we get around this requirement is to clone the export table from the original DLL, and generate forwarding references in our new malicious DLL. In this way, all of the original needed functionality is made available.

The important thing to note is that the forwarded export references must have the correct path name to the original DLL on the target system. Within the Payload Buffet, there now exists a directory called ReferenceDLLs. In this directory there are two sub-directories to support system architecture, namely x64 and x86. In each of these directories, I have supplied the original DLL files from a Windows 10 patched system as of this date. In order to supply the correct reference path, there is a YAML file named path_references.yml and the current contents are shown below.

#
# This file determines what the forwarding path is
# for the proxied DLL we are copying exports from in
# the export cloning process.
#
# In other words, this file path should actually
# be the unmodified original DLL and it must exist
# on the target system.
#
# Author  : Joff Thyer
# Created : August 17, 2022
#
DLLPathReference_x64:
    - c:\windows\system32\iphlpapi.dll
    - c:\windows\system32\version.dll
DLLPathReference_x86:
    - c:\windows\syswow64\iphlpapi.dll
    - c:\windows\syswow64\version.dll

The process of cloning the exports is performing using a tool named NetClone.exe which has been source from the GIT repository GitHub - monoxgas/Koppeling: Adaptive DLL hijacking / dynamic export forwarding

There is a supporting Python script named dllsidejackclone.py which is designed to execute after the payload buffet finishes created/compiling the custom payload artifacts. This Python script works as follows:

  1. Parses the YML configuration file above to create a dictionary of base reference paths for the reference DLLs.

  2. Reads the supplied target payload directory and searches for DLL’s that specifically are not compiled with Golang or identify as .NET assemblies, but otherwise conform to being a native Windows DLL.

  3. Reads the supplied reference DLL directory (currently only x64) to create a list of reference/original DLL’s which will be cloned.

  4. Invokes the NetClone.exe tool on each of the target and reference DLL’s to create a cloned malicious DLL for each/all of the target and reference DLL’s supplied.

  5. The final payload artifact will have a naming convention that includes the reference DLL name as well as the word cloned so that you can identify the artifact of interest. For example, below we can see a payload artifact DLL as well as its usable clones from the developmental executes of the buffet.

     0015_SimpleThread_rc_x64.dll
 0015_SimpleThread_rc_x64_IPHLPAPI_clone.dll
 0015_SimpleThread_rc_x64_version_clone.dll

    Thus the idea with the above file list is to copy the file with IPHLPAPI in it to the destination writable directory where your vulnerable app will then mistakenly load it.

     PS C:> COPY 0015_SimpleThread_rc_x64_version_clone.dll \
         %USERPROFILE%\AppData\Local\Microsoft\Teams\Current

When the vulnerable application is running, it will load the malicious “cloned” DLL as well as loading the original DLL from the reference path. This is because the cloned DLL has forwarding references in it for the original exported functions to supply the normal needed functionality.

Lastly, and most importantly, aside from the payload DLL needing to be a C based 64-bit compiled artifact today, it must also create the shellcode when the DLL is attached to the target process. In source code terms, an example DLLMain function looks like this.

BOOL WINAPI DllMain( HMODULE hModule, DWORD  ul_reason_for_call,
                   LPVOID lpReserved) {
    switch (ul_reason_for_call) {
        case DLL_PROCESS_ATTACH:
            CreateThread(NULL, 0, NewThread, NULL, 0, 0);
        case DLL_THREAD_ATTACH:
        case DLL_THREAD_DETACH:
        case DLL_PROCESS_DETACH:
            break;
    }
    return TRUE;
}

Within the DOTCeption framework and Payload Buffet automation, this means that the switched named DLLThreadOnAttach must be set to True for the payload artifact.

**IMPORTANT: You must please check your MANIFEST file to select the correct artifact which supports this switch. **

This software feature is now generally extensible which means if we encounter other applications which are vulnerable in this way, and I am sure there will be many, we can build up our configurations for payload artifacts to bring in new victims.

Shellcode Grinder CICD Server

As of 02/22/2022, I have made available a full implementation of the DotCeption shellcode generation tool as a server in Rapid City. The address of the server is 10.3.34.102 and is accessible via Remote Desktop Protocol.

Quick start

If you simply want to generate a bunch of pre-canned payloads quickly, you can do the following:

  1. Connect to VPN and RDP to the server at 10.3.34.102 with username BHIS and password in lastpass vault (search for Shellcode Grinder)
  2. Open up PowerShell as an Administrator (start→shift-CTRL), and immediately set your directory to /DotCeption.

cd /DotCeption

  1. Copy the file “payload_buffer.rc” to a unique filename of your own like “myscript.rc”.
  2. Edit the file with “vi” which is installed or notepad.exe.
  3. Change the first line for the global 64-bit shellcode variable. You may introduce a 32-bit payload also but I don’t recommend it these days. Note: including more shellcode in resulting payloads is a potential opsec decreasing action.

setg X64-SHELLCODE /x64payload.bin setg X86-SHELLCODE /x86payload.bin

  1. Upload via RDP or secure copy your payload onto the server.
  2. Execute the following to process a buffet script of payload generation. This gives you a bunch of .NET assembly, Windows native DLL, and Windows EXE results.

py DotCeption.py -r myscript.rc

  1. When DotCeption is finished it will deploy the resulting payloads into an AES encrypted 7ZIP file that is located in the /payloads directory. The default password on the deployment module is “infected” but can be changed in the script if you want using the ZIPPASS option. (see very bottom of resource script)
  2. Copy the payload 7-Zipped file off the server using secure copy or RDP method as soon as you can.

IMPORTANT NOTE: The entire DotCeption directory on this server is created via a CICD pipeline runner. This allows me to introduce new modules, fix bugs and push out updates easily. It is also why I created a separate /payloads directory for use.

What is DotCeption?

DotCeption was originally developed to generated payloads for living off the land / whitelist bypass activities with .NET. Over time it evolved and branched out into multiple languages and techniques beyond just living off the land.

There is a full templating system within DotCeption that will modify C# source code dynamically every single time a payload generation occurs. In addition, any shellcode used in the framework is always encrypted using an XOR function with randomly generated key.

Multiple programming languages are not supported for real time compilation of payloads including:

  • C#
  • Golang
  • C/C++

It is very important to understand that payloads with a .DLL extension generated by the C# modules are in fact managed code, otherwise known as .NET assemblies. On the other hand, DLLs generated by the GoLang and C/C++ modules are in fact native Windows DLLs.

From an OPSEC perspective, the safest modules today are the C/C++ modules as they will directly use the SysWhispers2 tooling to ensure that any Windows API calls are made directly to the kernel. This is a useful EDR evasion technique.

Multiple different shellcode execution techniques are supported by various DotCeption modules. You may choose to manually use the framework for further experiment with options available on individual modules to fine tune payload creation.

Graph View

Backlinks