BokuLoader - A Proof-Of-Concept Cobalt Strike Reflective Loader Which Aims To Recreate, Integrate, And Enhance Cobalt Strike's Evasion Features!

A proof-of-concept User-Defined Reflective Loader (UDRL) which aims to recreate, integrate, and enhance Cobalt Strike's evasion features!

Contributors:

UDRL Usage Considerations

The built-in Cobalt Strike reflective loader is robust, handling all Malleable PE evasion features Cobalt Strike has to offer. The major disadvantage to using a custom UDRL is Malleable PE evasion features may or may not be supported out-of-the-box.

The objective of the public BokuLoader project is to assist red teams in creating their own in-house Cobalt Strike UDRL. The project aims to support all worthwhile CS Malleable PE evasion features. Some evasion features leverage CS integration, others have been recreated completely, and some are unsupported.

Before using this project, in any form, you should properly test the evasion features are working as intended. Between the C code and the Aggressor script, compilation with different versions of operating systems, compilers, and Java may return different results.

Evasion Features

BokuLoader Specific Evasion Features

• Reflective callstack spoofing via synthetic frames.
• Custom ASM/C reflective loader code
• Indirect NT syscalls via HellsGate & HalosGate techniques
• All memory protection changes for all allocation options are done via indirect syscall to NtProtectVirtualMemory
• obfuscate "true" with custom UDRL Aggressor script implementation.
• NOHEADERCOPY
• Loader will not copy headers raw beacon DLL to virtual beacon DLL. First 0x1000 bytes will be nulls.
• XGetProcAddress for resolving symbols
• Does not use Kernel32.GetProcAddress
• xLoadLibrary for resolving DLL's base address & DLL Loading
• For loaded DLLs, gets DLL base address from TEB->PEB->PEB_LDR_DATA->InMemoryOrderModuleList
• Does not use Kernel32.LoadLibraryA
• Caesar Cipher for string obfuscation
• 100k UDRL Size
• Import DLL names and import entry name strings are stomped in virtual beacon DLL.

Supported Malleable PE Evasion Features

Test

• (2/22/23) All 4 allocator methods tested with threatexpress/malleable-c2/master/jquery-c2.4.7.profile

Project Origins

• Based on Stephen Fewer's incredible Reflective Loader project:
• https://github.com/stephenfewer/ReflectiveDLLInjection
• Initially created while working through Renz0h's Reflective DLL videos from the Sektor7 Malware Developer Intermediate (MDI) Course

Usage

1. Compile the BokuLoader Object file with make
2. Start your Cobalt Strike Team Server
3. Within Cobalt Strike, import the BokuLoader.cna Aggressor script
4. Generate the x64 beacon (Attacks -> Packages -> Windows Executable (S))

5. Use the Script Console to ensure BokuLoader was implemented in the beacon build

6. Does not support x86 option. The x86 bin is the original Reflective Loader object file.

7. Generating RAW beacons works out of the box. When using the Artifact Kit for the beacon loader, the stagesize variable must be larger than the default.
8. See the Cobalt Strike User-Defined Reflective Loader documenation for additional information

Detection Guidance

Hardcoded Strings

• BokuLoader changes some commonly detected strings to new hardcoded values. These strings can be used to signature BokuLoader:

Memory Allocators

DLL Module Stomping

• The Kernel32.LoadLibraryExA is called to map the DLL from disk
• The 3rd argument to Kernel32.LoadLibraryExA is DONT_RESOLVE_DLL_REFERENCES (0x00000001)
• the system does not call DllMain
• Does not resolve addresses in LDR PEB entry as detailed by MDSec here
• Detectable by scanning process memory with pe-sieve tool

Heap Allocation

• Executable RX or RWX memory will exist in the heap if sleepmask kit is not used.

Mapped Allocator

• The Kernel32.CreateFileMappingA & Kernel32.MapViewOfFile is called to allocate memory for the virtual beacon DLL.

Sleepmask Detection

• If sleepmask kit is used, there exists detection methods for this independent memory allocation as detailed by MDSec here

Indirect Syscalls

• BokuLoader calls the following NT systemcalls to setup the loaded executable beacon memory: NtAllocateVirtualMemory, NtProtectVirtualMemory
• These are called indirectly from the BokuLoader executable memory.
• Setting userland hooks in ntdll.dll will not detect these systemcalls.
• It may be possible to register kernelcallbacks using a kernel driver to monitor for the above system calls and detect their usage.
• The BokuLoader itself will contain the mov eax, r11d; mov r11, r10; mov r10, rcx; jmp r11 assembly instructions within its executable memory.

Virtual Beacon DLL Header

• The first 0x1000 bytes of the virtual beacon DLL are zeros.

Source Code Available

• The BokuLoader source code is provided within the repository and can be used to create memory signatures.
• If you have additional detection guidance, please feel free to contribute by submitting a pull request.

Credits / References

Reflective Call Stack Spoofing

• LoudSunRun: Call stack synthetic frame spoofer with indirect syscalls
• SilentMoonwalk: PoC Implementation of a fully dynamic call stack spoofer
• Vulcan Raven: PoC implementation for spoofing arbitrary call stacks when making syscalls
• CallStackMasker: A PoC implementation for dynamically masking call stacks with timers
• ThreadStackSpoofer: Thread Stack Spoofing PoC
• Behind the Mask: Spoofing Call Stacks Dynamically with Timers

Reflective Loader

• https://github.com/stephenfewer/ReflectiveDLLInjection
• Checkout these videos if you're interested in Reflective DLL:
• Dancing with Import Address Table (IAT) - Sektor 7 MDI Course
• Walking through Export Address Table - Sektor 7 MDI Course
• Reflective Injection Explained - Sektor 7 MDI Course
• ReflectiveLoader source review - Sektor 7 MDI Course
• TitanLdr
• AceLdr
• KaynLdr

HalosGate SysCaller

• Reenz0h from @SEKTOR7net
• Checkout Reenz0h's awesome courses and blogs!
• Best classes for malware development I have taken.
• Creator of the halos gate technique. His work was initially the motivation for this work.
• Sektor7 HalosGate Blog

HellsGate Syscaller

• @smelly__vx & @am0nsec ( Creators/Publishers of the Hells Gate technique )
• Could not have made my implementation of HellsGate without them :)
• Awesome work on this method, really enjoyed working through it myself. Thank you!
• https://github.com/am0nsec/HellsGate
• Link to the Hell's Gate paper: https://vxug.fakedoma.in/papers/VXUG/Exclusive/HellsGate.pdf

Aggressor Scripting

• sinusoid @the_bit_diddler : returnIntegerFromArray

Cobalt Strike User Defined Reflective Loader

• https://www.cobaltstrike.com/help-user-defined-reflective-loader

Great Resource for learning Intel ASM

• Pentester Academy - SLAE64

ETW and AMSI Bypass

• @anthemtotheego inline-ExecuteAssembly
• @mariuszbit - for awesome idea to implement bypasses in reflective loader!
• @XPN Hiding Your .NET – ETW
• ajpc500/BOFs
• Offensive Security OSEP

Implementing ASM in C Code with GCC

• https://outflank.nl/blog/2020/12/26/direct-syscalls-in-beacon-object-files/
• https://www.cs.uaf.edu/2011/fall/cs301/lecture/10_12_asm_c.html
• http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Extended-Asm.html#Extended-Asm

Cobalt Strike C2 Profiles

• Tylous's epic SourcePoint project
• threatexpress/malleable-c2/jquery-c2.4.7.profile

DllNotificationInjection - A POC Of A New "Threadless" Process Injection Technique That Works By Utilizing The Concept Of DLL Notification Callbacks In Local And Remote Processes

DllNotificationInection is a POC of a new “threadless” process injection technique that works by utilizing the concept of DLL Notification Callbacks in local and remote processes.

An accompanying blog post with more details is available here:

https://shorsec.io/blog/dll-notification-injection/

How It Works?

DllNotificationInection works by creating a new LDR_DLL_NOTIFICATION_ENTRY in the remote process. It inserts it manually into the remote LdrpDllNotificationList by patching of the List.Flink of the list head and the List.Blink of the first entry (now second) of the list.

Our new LDR_DLL_NOTIFICATION_ENTRY will point to a custom trampoline shellcode (built with @C5pider's ShellcodeTemplate project) that will restore our changes and execute a malicious shellcode in a new thread using TpWorkCallback.

After manually registering our new entry in the remote process we just need to wait for the remote process to trigger our DLL Notification Callback by loading or unloading some DLL. This obviously doesn't happen in every process regularly so prior work finding suitable candidates for this injection technique is needed. From my brief searching, it seems that RuntimeBroker.exe and explorer.exe are suitable candidates for this, although I encourage you to find others as well.

OPSEC Notes

This is a POC. In order for this to be OPSEC safe and evade AV/EDR products, some modifications are needed. For example, I used RWX when allocating memory for the shellcodes - don't be lazy (like me) and change those. One also might want to replace OpenProcess, ReadProcessMemory and WriteProcessMemory with some lower level APIs and use Indirect Syscalls or (shameless plug) HWSyscalls. Maybe encrypt the shellcodes or even go the extra mile and modify the trampoline shellcode to suit your needs, or at least change the default hash values in @C5pider's ShellcodeTemplate project which was utilized to create the trampoline shellcode.

Acknowledgments

• @C5pider for his ShellcodeTemplate project which which was used to create the trampoline shellcode. Also, for Havoc C2 that was used in the POC Demo Video.
• Yxel and @Idov31 for the binary pattern matching code we used from Cronos.
• @modexpblog for the various structures definitions related to DLL Notification Callbacks which were used in this POC.
• @NinjaParanoid for his blog post on TpWorkCallbacks which were used in this POC.
• @onlymalware for his UnregisterAllLdrRegisterDllNotification POC, it gave me some inspiration and helped me understand some of the inner workings of the LdrpDllNotificationList.
• Sektor7 for the calc shellcode used in this POC. They are awesome regardless and I highly recommend their courses!
• @x86matthew and @Kharosx0 for their comments (1, 2) regarding the GetNtdllBase() function.

Windiff - Web-based Tool That Allows Comparing Symbol, Type And Syscall Information Of Microsoft Windows Binaries Across Different Versions Of The OS

WinDiff is an open-source web-based tool that allows browsing and comparing symbol, type and syscall information of Microsoft Windows binaries across different versions of the operating system. The binary database is automatically updated to include information from the latest Windows updates (including Insider Preview).

It was inspired by ntdiff and made possible with the help of Winbindex.

How It Works

WinDiff is made of two parts: a CLI tool written in Rust and a web frontend written in TypeScript using the Next.js framework.

The CLI tool is used to generate compressed JSON databases out of a configuration file and relies on Winbindex to find and download the required PEs (and PDBs). Types are reconstructed using resym. The idea behind the CLI tool is to be able to easily update and regenerate databases as new versions of Windows are released. The CLI tool's code is in the windiff_cli directory.

The frontend is used to visualize the data generated by the CLI tool, in a user-friendly way. The frontend follows the same principle as ntdiff, as it allows browsing information extracted from official Microsoft PEs and PDBs for certain versions of Microsoft Windows and also allows comparing this information between versions. The frontend's code is in the windiff_frontend directory.

A scheduled GitHub action fetches new updates from Winbindex every day and updates the configuration file used to generate the live version of WinDiff. Currently, because of (free plans) storage and compute limitations, only KB and Insider Preview updates less than one year old are kept for the live version. You can of course rebuild a local version of WinDiff yourself, without those limitations if you need to. See the next section for that.

Note: Winbindex doesn't provide unique download links for 100% of the indexed files, so it might happen that some PEs' information are unavailable in WinDiff because of that. However, as soon as these PEs are on VirusTotal, Winbindex will be able to provide unique download links for them and they will then be integrated into WinDiff automatically.

How to Build

Prerequisites

• Rust 1.68 or superior
• Node.js 16.8 or superior

Command-Line

The full build of WinDiff is "self-documented" in ci/build_frontend.sh, which is the build script used to build the live version of WinDiff. Here's what's inside:

# Resolve the project's root folder
PROJECT_ROOT=$(git rev-parse --show-toplevel)

# Generate databases
cd "$PROJECT_ROOT/windiff_cli"
cargo run --release "$PROJECT_ROOT/ci/db_configuration.json" "$PROJECT_ROOT/windiff_frontend/public/"

# Build the frontend
cd "$PROJECT_ROOT/windiff_frontend"
npm ci
npm run build

The configuration file used to generate the data for the live version of WinDiff is located here: ci/db_configuration.json, but you can customize it or use your own. PRs aimed at adding new binaries to track in the live configuration are welcome.

AtomLdr - A DLL Loader With Advanced Evasive Features

A DLL Loader With Advanced Evasive Features

Features:

• CRT library independent.
• The final DLL file, can run the payload by loading the DLL (executing its entry point), or by executing the exported "Atom" function via the command line.
• DLL unhooking from \KnwonDlls\ directory, with no RWX sections.
• The encrypted payload is saved in the resource section and retrieved via custom code.
• AES256-CBC Payload encryption using custom no table/data-dependent branches using ctaes; this is one of the best custom AES implementations I've encountered.
• Aes Key & Iv Encryption.
• Indirect syscalls, utilizing HellHall with ROP gadgets (for the unhooking part).
• Payload injection using APC calls - alertable thread.
• Payload execution using APC - alertable thread.
• Api hashing using two different implementations of the CRC32 string hashing algorithm.
• The total Size is 17kb + payload size (multiple of 16).

How Does The Unhooking Part Work

AtomLdr's unhooking method looks like the following

the program Unhooking from the \KnwonDlls\ directory is not a new method to bypass user-land hooks. However, this loader tries to avoid allocating RWX memory when doing so. This was obligatory to do in KnownDllUnhook for example, where RWX permissions were needed to replace the text section of the hooked modules, and at the same time allow execution of functions within these text sections.

This was changed in this loader, where it suspends the running threads, in an attempt to block any function from being called from within the targetted text sections, thus eliminating the need of having them marked as RWX sections before unhooking, making RW permissions a possible choice.

This approach, however, created another problem; when unhooking, NtProtectVirtualMemory syscall and others were using the syscall instruction inside of ntdll.dll module, as an indirect-syscall approach. Still, as mentioned above, the unhooked modules will be marked as RW sections, making it impossible to perform indirect syscalls, because the syscall instruction that we were jumping to, can't be executed now, so we had to jump to another executable place, this is where win32u.dll was used.

win32u.dll contains some syscalls that are GUI-related functions, making it suitable to jump to instead of ntdll.dll. win32u.dll is loaded (statically), but not included in the unhooking routine, which is done to insure that win32u.dll can still execute the syscall instruction we are jumping to.

The suspended threads after that are resumed.

It is worth mentioning that this approach may not be that efficient, and can be unstable, that is due to the thread suspension trick used. However, it has been tested with multiple processes with positive results, in the meantime, if you encountered any problems, feel free to open an issue.

Usage

• PayloadBuilder is compiled and executed with the specified payload, it will output a PayloadConfig.pc file, that contains the encrypted payload, and its encrypted key and iv.
• The generated PayloadConfig.pc file will then replace this in the AtomLdr project.
• Compile the AtomLdr project as x64 Release.
• To enable debug mode, uncomment this here.

Demo (1)

• Executing AtomLdr.dll using rundll32.exe, running Havoc payload, and capturing a screenshot

• AtomLdr.dll's Import Address Table

Demo - Debug Mode(2)

• Running PayloadBuilder.exe, to encrypt demon[111].bin - a Havoc payload file

• Running AtomLdr.dll using rundll32.exe

• Havoc capturing a screenshot, after payload execution

Based on

• ctaes
• WriteProcessMemoryAPC
• VX-API

APCLdr - Payload Loader With Evasion Features

Features:

• no crt functions imported
• indirect syscalls using HellHall
• api hashing using CRC32 hashing algorithm
• payload encryption using rc4 - payload is saved in .rsrc
• Payload injection using APC calls - alertable thread
• Payload execution using APC - alertable thread
• Execution delation using MsgWaitForMultipleObjects - edit this
• the total size is 8kb + the payload size
• compatible with LLVM (clang-cl) Option

Usage:

• Use Builder to update the PayloadFile.pf file, that'll be the encrypted payload to be saved in the .rsrc section of the loader
• Compile as x64 Release

Debugging:

• Change Linker>SubSystem from /SUBSYSTEM:WINDOWS to /SUBSYSTEM:CONSOLE
• Set the loader in debug mode (uncomment this)
• build as release as well

Thanks For:

• https://www.x86matthew.com/view_post?id=writeprocessmemory_apc
• https://github.com/vxunderground/VX-API

Tested with cobalt strike && Havoc on windows 10