Deliver a Strike by Reversing a Badger: Brute Ratel Detection and Analysis

A new adversary simulation tool is steadily growing in the ranks of popularity among red teamers and most recently adversaries. Brute Ratel states on its website that it "is the most advanced Red Team & Adversary Simulation Software in the current C2 Market." Many of these products are marketed to assist blue teams in validating detection, prevention, and gaps of coverage. Brute Ratel goes a level further in receiving consistent updates to evade modern host-based security controls — a cat and mouse game. Adversaries pick up on these products quickly, as noted in a recent blog post by Team Cymru; Brute Ratel C4 (BRC4) servers are limited on the internet compared to other offensive security tools like Cobalt Strike and Metasploit, but its popularity is growing. 

As enterprise defenders who may or may not have access to these products, we have to be able to understand the operation of the tool and  its procedures and behaviors. 

In this blog, the Splunk Threat Research Team (STRT) will highlight how we utilized other public research to capture Brute Ratel Badgers (agents) and create a Yara rule to help identify more on VirusTotal. Additionally, we reversed a sample to better understand its functions. STRT simulated a badger’s functionality using a newly released defender-driven C2 utility. Lastly, STRT describes analytics to help defenders identify behaviors related to Brute Ratel.

Analysis

Hunting for a Badger

Brute Ratel is a commercial C2 framework available only to paying customers; yet, STRT needed a way to acquire a sample for analysis. Fortunately for us, security researchers like Spookysec.net, Unit42 and Mdsec have already found samples and blogged about their analysis. STRT leveraged the sample found on the Analyzing a Brute Ratel Badger blog post and created an experimental generic Yara rule that can be used on VirusTotal to hunt for other potential uploaded samples. 

rule possible_badger
{
  strings:
       //mov eax, 0x00
       // push eax
       //mov eax, 0x00
       // push eax
       //mov eax, 0x00
       // push eax
       //mov eax, 0x00
       // push eax
       //mov eax, 0x00
       // push eax
       //mov eax, 0x00
       // push eax
       $code = { B8 00 00 00 00 50 B8 00 00 00 00 50 B8 00 00 00 00 50 B8 00 00 00 00 50 B8 00 00 00 00 50 B8 00 00 00 00 50}
  condition:
      all of them
}

The Yara rule above hunts for a series of move zero bytes instructions to the EAX register which are then pushed to the stack. These instructions were identified as part of the initial shellcode that sets up the BRC4 agent DLL module on the stack. 

The figure below shows one of the files flagged by the Yara rule, an ISO file named fotos.iso.

The first submission of this file in VT was on July 20, 2022, from Poland. 

The figure below shows the VirusTotal detection list of the ISO fotos.iso at the time of writing.

Using the Yara rule we were able to identify 31 similar samples and graph them using VirusTotal Graphs.

The full VirusTotal graph may be found here.

Malicious ISO File

ISO containers are a common way to deliver malware among threat actors. It enables them to archive malicious files and even bypass security features such as the Mark-of-the-Web. The found sample contains the legitimate Microsoft signed OneDrive binary renamed as onedrive_fotos.exe as well as two hidden DLLs: version.dll and versions.dll files. The latter is also a Microsoft-signed legitimate DLL while the first one is a malicious library that will execute the BRC4 agent.

This initial access vector leverages the DLL Side-Loading technique (T1574.002) to obtain code execution on the victim host. Side-loading takes advantage of the DLL search order used by the loader by positioning both the victim application and malicious payload alongside each other. When the victim mounts the ISO and executes the onedrive_fotos.exe binary, it will load the maliciously crafted version.dll.

The figure below shows the VirusTotal detection list of the version.dll library at the time of writing.

The ISO file we analyzed is similar to the sample analyzed by Palo Alto’s Unit42 in their blog post covering Brute Ratel with a few notable differences:

• This ISO does not contain a shortcut LNK file and relies on the victim double clicking the onedrive_fotos.exe binary to load the malicious DLL.
• The initial shellcode is embedded in the hidden DLL and not present as another file in the ISO archive.

The following image provides a high level overview of the initial access attack vector.

Figure 2.1 and Figure 2.2 show the .ISO component files before and after enabling the “Show Hidden Files” setting.

Initial Shellcode Execution

The malicious version.dll file has an embedded unencrypted shellcode in its .data section that will be copied to an allocated memory address space with the PAGE_EXECUTE_READ protection to then be executed using the callback function of the EnumChildWindows Windows API. This shellcode execution technique was first seen being used by the Lazarus group. 

Figure 3 shows the code snippet of the EnumChildWindows callback function used to execute the shellcode.

The shellcode will set up the Brute Ratel C4 DLL agent in the memory stack using several push mnemonics. Afterward, the shellcode will allocate an executable memory page space where it will move the DLL agent from the stack byte per byte. Lastly, It will execute it using the undocumented API NtCreateThreadEx.

Figure 4 is the code showing the last push command executed by the shellcode to finalize copying the BRC4 DLL agent to the stack.

Once the DLL agent is placed in the executable memory page, we can export it to disk to perform static analysis. We used the Detect It Easy tool to perform high level analysis of the extracted BRC4 DLL and obtain information such as the exported functions (Figure 4.1), the entropy of the file and each section (Figure 4.2), etc.

^{Figure 4.1}

^{Figure 4.2}

Figure 5 shows the code that runs a syscall function to execute the NtCreateThreadEx Windows API with the startAddress argument pointing to the “bruteloader” export function of the BRC4 DLL agent loaded in memory. This thread also has an argument that points to the encoded and encrypted initial configuration that will be used for its C2 communication and beaconing.

^{Figure 5}

The DLL module we extracted from memory was submitted to VT in this link and can be seen in Figure 5.1.

BRC4 DLL Agent Module

Initial Configuration

The configuration data is encoded with base64 and encrypted with RC4 with the passphrase key “bYXJm/3#M?:XyMBF”. Figure 6 is the decrypted version of this configuration data that contains the command and control servers, port (HTTPS), user agent, cookie, and many more details.

^{Figure 6}

The Brute Ratel DLL agent used by this malicious version.dll is composed of techniques to evade detection from endpoint detection and response (EDR), antivirus products, and even obfuscation and encryption to thwart static code analysis.

The following section describes some of the capabilities the STRT found during our analysis of the BRC4 DLL module embedded in version.dll which include: gaining elevated privileges, collecting sensitive information, evading detections, and dumping processes, among others.

BRc4 Agent Capabilities

Windows API Abuse

The BRC4 agent employs several techniques to invoke and abuse native Windows APIs. To attempt to bypass security solutions that rely on hooking common APIs, BRCc4 makes use of direct system calls. The BRC4 agent can also dynamically resolve functions memory addresses using pre-computed hardcoded hashes. Figure 6.1 shows the code snippet of its hashing algorithm it uses in parsing its needed API upon traversing the export table of its needed DLL modules.

^{Figure 6.1}

Common functionality implemented by C2 implants is the ability to verify the connectivity with another host using the ICMP protocol. The BRC4 DLL  agent implements this by using the native Windows API IcmpCreateFile and IcmpSendEcho. 

Figure 7 shows the code with the resolved API hash value on how to implement a PING to a target host using those Windows APIs.

^{Figure 7}

SeDebugPrivilege

By default, users can debug only the processes that they own. In order to debug other processes or processes owned by other users, a process needs to have a SeDebugPrivilege privilege token. This privilege token is abused by adversaries to elevate process access to inject malicious code or dump processes. Figure 8 shows how BRC4 adjusts the token privilege of its process to gain debug privileges.

^{Figure 8}

Parse Clipboard Data

Figure 9 shows the code snippet BRC4 uses to parse or copy the clipboard data on the targeted host using the Windows API functions OpenClipboard and GetClipboardData.

^{Figure 9}

Retrieve DNS CACHE RECORD

Figure 10 shows the code snippet implemented by BRC4 to parse the DNS cache record of the infected host using the undocumented DnsGetcacheDataTable Windows API.

^{Figure 10}

Duplicate Token

Token manipulation is a technique used to create a new process with a token “taken” or “duplicated” from another process. This is a common technique leveraged by adversaries, red teamers, and malware families to elevate the privileges of their processes.

Figure 11 shows the code function that duplicates the token of “winlogon.exe” or “logonui.exe” and uses that token to a new process using CreateProcessWithTokenW API.

^{Figure 11}

Patch ETWEventWrite API

Another interesting feature of the BRC4 DLL agent is that it can evade Event Tracing for Windows (ETW) and AMSI Windows mechanisms by patching known API responsible for generating or tracing system events.

Figure 12 shows the code of this DLL agent that patches “EtwEventWrite” API with “0xC3” opcode which is a “return instruction” to evade the ETW event trace logging.

^{Figure 12}

Parent Process ID Spoofing

BRC4 is also capable of spoofing the parent process (PPID) for its newly created process to evade detections that are based on parent/child process relationships.

The code below in Figure 13 is the function that initializes the process attributes and thread creation for the parent process spoofing technique.

^{Figure 13}

Retrieves IPV4 to Physical Address Mapping Table

Figure 14 shows the code snippet of the function that enumerates Address Resolution Protocol (ARP) entries or physical address map table for IPV4 on the local system using the GetIpNetTable Windows API.

^{Figure 14}

Below is the list of other capabilities we found in the BRC4 DLL module loaded by this malicious version.dll file:

• Check the active and idle session of the user in the target host
• TCP bind connection
• Create, copy, move and delete File
• Create, delete, move directory
• Get and set current working directory
• Get domain information
• Enumerate Drivers with their file information
• Create, start, modify, enumerate and delete services
• Get environment variable list
• Change workstation wallpaper
• Get host by name 
• Enumerate logical drives
• Get process information
• Get process token privileges
• Retrieve global information for all users and groups in security databases like SAM
• List files in a directory
• Workstation lock screen
• Process minidump
• Retrieve NET BIOS information
• Process Injection (QAPC, CreateRemoteThread, and CreateSection Techniques)
• Enumerate Registries
• Get system information
• Terminate a process
• Taking windows desktop screenshot
• Execute shell command (“RUNAS”)
• Retrieves the time of the last input event
• List installed software applications in the targeted host
• Retrieves the active processes on a specified RDP session

Brute Ratel Simulation

Detections written by the Splunk Threat Research Team need to pass the automated detection testing pipeline before they can be released. Building detections for some of the interesting TTPs we identified by analyzing BRC4 was no different; we needed a way to simulate these techniques in a lab environment in order to generate the datasets used for testing and stored in the Attack Data Github repository.

This presented two key challenges:

1. The C2 server of the BRC4 agent we analyzed was inaccessible or already offline during our analysis. Furthermore, even if it was online, we would have not been able to instruct the agent to execute the specific tasks we wanted to run.
2. The Brute Ratel server-side application is a commercial product and the creator was unavailable for us to write detections against the product.

Introducing Atomic-C2

To approach these challenges, we decided to write our own minimal Command & Control framework using C++ for the implant and Python for the server: Atomic-C2. This tool will never be meant to be used as part of offensive engagements but rather to be used by blue teams to learn about how C2s work and be able simulate techniques when commercial or criminal toolsets are not available. 

For this initial and Proof-Of-Concept version of Atomic-C2, we took some of the techniques we learned by reverse engineering the BRC4 agent and re-wrote (simulate) them in C++ with a server side component to trigger them. Two examples are shown below.

Figure 14.1 shows how we simulate the previously shown capability to harvest or parse the clipboard data.

Figure 14.2 shows how we simulate the capability responsible for parent process ID spoofing.

As another example, Figure 15 shows the screenshot of how we simulate the technique of locking the screen of the targeted workstation. The C2 server operator runs the “lock” command to instruct the agent running in the victim host to execute the simulated workstation lock screen code.

Figure 16 shows a screenshot of the simulated QUEUE APC process code injection technique. The simulated code will look for a cmd.exe process and inject shellcode that will execute a calc.exe.

Atomic-C2 helped us simulate Brute Ratel techniques to obtain the datasets we needed to create detections and to pass the automated testing process. At the moment, Atomic-C2 is an internal project, but we hope to  release it in the upcoming months.

Brute Ratel C4 Analytic Story

Armed with the knowledge gained from reversing the Brute Ratel sample and the datasets generated with Atomic-C2, the Splunk Threat Research Team developed a new analytic story to help security operations center (SOC) analysts detect adversaries leveraging the Brute Ratel Command & Control framework. Specifically, the new Analytic Story introduces 17 detection analytics across 10 MITRE ATT&CK techniques.

There can be multiple approaches that rely on different data sources to hunt for Brute Ratel behavior. For this release, we wanted to focus on what we consider to be the most relevant data source: endpoint telemetry. Thus, we focused on the following data sources:

• Process Execution & Command Line Logging
• Windows Security Event Id 4688, Sysmon, or any Common Information Model compliant EDR technology.
• Windows Security Event Log
• Windows System Event Log

The next table describes the data models and the Splunk Technical Add-Ons we used to develop the detection analytics.

IOCs:

Automate with SOAR Playbooks 

All of the previously listed detections create entries in the risk index by default, and can be used seamlessly with risk notables and the Risk Notable Playbook Pack. The community Splunk SOAR playbooks below can be used in conjunction with some of the previously described analytics:

Why Should You Care?

With this article we enabled security analysts, blue teamers and splunk customers to identify the TTP’s used by threat actors abusing BRC4 DLL agents. 

By understanding its behaviors, we were able to generate telemetry and datasets to develop and test splunk detections designed to defend and respond against this type of threats.

Learn More

You can find the latest content about security analytic stories on GitHub and in Splunkbase. Splunk Security Essentials also has all these detections available via push update.

For a full list of security content, check out the release notes on Splunk Docs.

Feedback

Any feedback or requests? Feel free to put in an issue on GitHub and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions if you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank the following for their contributions to this post:

• Teoderick Contreras
• Mauricio Velazco
• Michael Haag
• Rod Soto
• Lou Stella
• Jose Hernandez
• Patrick Barreiss
• Bhavin Patel
• Eric McGinnis