Objectives

This week, Z2A provided me with a sample of a BruteRatel C4 implant to analyze.

BruteRatel C4 is a C2 used and developed for Adversary Simulation and Pentesting and is relatively new in the world of Red Teaming tools compared to Cobalt Strike.

BRC4 is known to be undetectable by EDRs thanks to advanced techniques (detection of hooks, syscalls instead of API calls, communications via DoH…).

But a good tool for Red Teaming companies remains a good tool in the hands of an attacker. Many versions of BRC4 have leaked, allowing malicious actors to deploy implants.

I analyzed these implants during the challenge, and the objectives were as follows:

1. Identify the location of the configuration and develop a configuration extractor to extract the information.

2. Develop a YARA rule to detect the first layer based on binary patterns.

3. (Bonus) Improve the configuration extractor to extract and decrypt the next stage.

Configuration Extraction

This file is stage 1 of a BRC4 implant. Its purpose is to decrypt the next stage and provide it with the configuration.

Everything happens on the stack, creating a binary with millions of operations. Despite this, the configuration appears in plain text in the very first stack string:

Looking at another sample from the same “campaign,” we see a similar operation:

We can create a simple script to extract the configuration containing the C2 IP, its port, and the admin panel credentials! The first sample appears to have been stolen from the auditing company Deloitte.

This script positions itself at the offset where the configuration is stored, extracts 512 bytes, and then extracts it again with a regex:

YARA Detection Rule

A YARA detection rule allows recognizing certain malware based on several parameters. It is a powerful tool used for Threat Intelligence.

To create an effective YARA rule, you need to identify patterns in different samples that can be used for identification. This can be strings, functions, or in our case, bytes.

I noticed 2 identical stack strings in the 2 binaries:

These strings cannot be exploited as-is. IDA recognizes stack strings, but they are not detectable by the strings or yara command. I extracted the bytes to create a detection sequence:

Bonus

Given the relative ease of this challenge, there was an optional step to decrypt the second stage of the implant.

BRC4 uses API hashing to conceal its operation. Here is the function to resolve an API.

This function is simple; it applies ROR13 to each letter of the API, then adds the result to the hash as it goes. With this algorithm understood, I created a list of hashes and compared them to those in the binary.

Using IDAPython, I automatically commented the function resolutions to display their respective names:

Once the functions were resolved, it was easier to understand the unpacking mechanism of stage 2.

The program will:

• Allocate a first memory chunk for its code

• Allocate a second chunk to store the configuration

• Create a thread to launch stage 2 (which turns out to be a shellcode)

To extract this shellcode, I used qiling, which is an advanced emulator that allows tracking and modifying program execution as desired, with no real-world consequences.

To retrieve the shellcode, you simply need to read the memory contents after the first call. I also intercepted the lpStartAddress parameter of the CreateThread function to obtain the entry point of the second stage:

All of this is then saved in a .bin file for further analysis.