Brute Ratel C4 v0.2 (Prometheus) is now available for download and provides a major update towards process injections and adversary simulations. Along with this release, we have started providing access to an Active Directory trial lab to test the features of injection and pivoting of BRC4 over the test environment.
I released a blog few days back which explains how we can generate object files and execute them as position independent code (PIC). With the release of version 0.2, BRC4 provides a way to load object files in memory directly using the Brute Commander GUI or by creating custom commands via C4 Profiles. Object files are unlinked files which contain relocatable code and not directly executable. One would usually have to compile them using GCC or Clang to create an executable and execute them. However, BRC4 itself acts as a linker and compiler for the object file loaded using the objexec command. This command executes the object file’s code in badger’s memory and returns the output via a named pipe. This named pipe can be easily customized using the set_objectpipe and get_objectpipe commands. I won’t be going into the detail of building the object file since the previously mentioned blog details it out nicely. In order to simplify the process to dynamically load windows libraries, BRC4 provides a header file which can be included in your C file when building the object file. Below is a sample of Exported badger APIs that can be called via from the header file.
This header file contains the exported APIs of badger. When a user includes this header file in their C project, he/she would be able to call several functions exported in this header file and the user wont have to spend time on writing a loader to fetch the Symbol/Function addresses of WinAPI symbols from DLLs like kernel32, advapi32 and so on. The object file can be compiled with the below command:
x86_64-w64-mingw32-gcc getprivs.c -Wall -m64 -c -o getprivs.o
Runs object file in the memory of the badger
The C4 profiles provide a similar json way like register_pe or register_dll to load an object file as a regular command in BRC4.
{
"register_obj": {
"o_getprivs": {
"file_path": "server_confs/getprivs.o",
"description": "Get privilege of current user",
"artifact": "WINAPI",
"mainArgs": "NA",
"optionalArg": "NA",
"example": "o_getprivs",
"minimumArgCount": 1
}
}
}
And once it’s included in the C4 profile, it should be readily available as any other command in Brute Commander.
Since object files get executed within the same process of badger, it’s really important to check your object file for memory leaks. Using bad code can lead to your payload crashing, so its recommended to heavily test your post exploitation object files before loading them in the memory of badger.
The object file execution feature gave rise to another feature in brute ratel, where if you don’t want to create an object file, but still want to use the PIC capability, you can use the shinject command. This command can load PIC executables in a remote process memory and execute either a shellcode, or it can parse a PIC executable, extract it’s text section and execute it in the remote process memory. This command accepts either a bin file or an executable to run the shellcode.
However shinject unlike objexec doesn’t return an output of the executed code, and the reason behind this is that shinject doesn’t have it’s own loader. It basically uses VirtualAlloc, WriteProcessMemory, CreateRemoteThread to write and execute the shellcode unlike objexec where object file is loaded by a custom loader of badger which captures the output and returns the output via named pipe. shinject is best suited for things like injecting exploit code/payload into a remote process.
This release of brute ratel release 2 new Brute Commander features. These include User Activity and MITRE Team Activity. User Activity maintains a log of all the commands executed by users, admin and autoruns.
MITRE Team Activity on the other hand maintains a log of all commands executed (unlike MITRE Brute Ratel graph which lists all MITRE map for all commands) and returns a graph for each command executed mapped to their respective Tactics, Techniques and Sub-Techniques. I personally wanted to simplify the process of listing all commands executed during Adversary simulation and decided that nothing helps better than a graph.
