That’s No Honey Badger. It’s A Brute Ratel. A Look At BRC4.

“Therefore I say: know your enemy as you know yourself. If you succeed in this, even in a hundred battles you will never risk anything.

If you do not know whom you have to fight against, but you only know yourself, your chances of winning will be the same as your chances of losing.

If you do not know yourself and you don’t know your enemy either, you are certain that every battle will mean serious peril for you.”

Sun Tzu – The Art of War

While the Android 13 image is cooking, I thought it would be fun to take a detour from mobile forensics for a bit and look at something that could will affect a substantial part of my day job. Recently, an adversary simulation tool (AST) that is NOT named Cobalt Strike made its way into the hands of attackers, and, since I firmly believe in the above portion of The Art of War (and threat intelligence in general), I thought it would be fun to look at said simulation tool. Doing so helps me, but could also help other folks responsible for defense.

In much the same fashion as another incident where something fell off the back of a truck, I happen to be positioned to acquire a copy of Brute Ratel C4 (BRC4), an AST that started making the rounds in underground forums at the end of September. BRC4 has been around for a while but what makes this recent appearance notable is that just like Cobalt Strike, the licensing function of BRC4 has been bypassed, which allows more malicious actors access to this tool. You know, because one AST being freely passed around isn’t bad enough.

BRC4 is a post-exploitation tool, i.e., a tool used after a host has already been compromised in some fashion by an unauthorized actor. Think exposed RDP with weak credentials, a vulnerability has been exploited, or leaked credentials were used. Regardless, BRC4 is a tool to use to establish persistence, steal credentials, elevate privileges, and move laterally, all of which is done after an attacker gets on a host.

BRC4 setup is very similar to Cobalt Strike. It requires a C2 for comms, there is an attacker user interface (called Commander) that an attacker uses to communicate with the C2 and control the “badgers.” Badgers are analogous to Cobalt Strike beacons, and are the things that exist (in some fashion) on an endpoint.

There have been a few write-ups since July about BRC4, and I highly recommend reading them (MDSec, Unit42, TrendMicro). They cover parts of BRC4 that are outside the scope of my exercise. The goal of my exercise was slightly different to those in that I looked at only the endpoint using some of the tooling I use day-to-day to see if there was any artifact(s) that would indicate BRC4 had been used. To accomplish this I utilized an up-to-date Windows 10 VM (all updates applied as of the end of September) and version 1.2.2 of BRC4 (Scandinavian Defense). I conducted the exercise in four parts, the idea of which came from Ryan Chapman’s SANS FOR528 course. The first involved a version of the VM with default logging (i.e. I did a clean install of Windows and didn’t change any of the logging settings), and the second saw the use of default-configured SysMon on a clean version of the VM. The third part of the exercise involved ProcMon, the reason for which will become evident later. The fourth part invovled Sysmon but with a modified version of the Swift on Security configuration file. For tooling, I used Eric Zimmerman’s tools (including KAPE) and Nirsoft’s BrowserHistoryView.

After the VMs were set up I installed the badgers in two different flavors: as a service executable and as a DLL. Once they were connected back to the C2, I started running commands on the host to figure out where I was, get file listings, move around in the file system, enumerate user accounts, and dump credentials. A BRC4 operator can name a badger anything they wish, so I gave my test badgers names I could easily identify; the file names had “Spotify” in them.

After running commands, I used the KapeTriage target of KAPE to pull data from the VMs and parsed the data with the aforementioned tools.

A few caveats:

This is going to be a longer blog post. There’s a lot to cover.

Let’s get the bad news out of the way first…because there is some bad news. From the point of view of the endpoint BRC4 is quiet, so the default Windows logging was not helpful. If I had not known the name of the DLL and service executable files, I could have easily glossed over their mere existence. Additionally, Windows Defender initially did not detect several of the badgers I either downloaded from the C2 or uploaded to the VM via another badger; the detections did become more frequent the more times I put them on the VM. Figure 1-1 contains an excerpt from the BRC4 logs where I uploaded a service executable, and Figure 1-2 contains an excerpt of the Windows event logs covering showing a detection courtesy of EvtxECmd.

The detection was a result of me trying to upload an additional badger to the target host via a badger that was already present. The odd thing with this detection is that I was able to download the additional badger directly from the C2 using a web browser and Defender did not detect it. So, I am not sure if Defender was asleep at the wheel or what. Again, the more times I downloaded badgers the more frequent the detections got, which is good. One thing to note here (and others have pointed this out) is that the shellcode for badgers is customizable, which will make static file detection extremely difficult with a savvy BRC4 operator. See Figure 2.

The three files shown in Figure 2 are badgers I generated during a single testing session of BRC4, and each had a different hash value. Again, static detection is going to be difficult.

Now that I was on the host, the next thing to do was to determine what type of host I was on and where in the network infrastructure I was located. BRC4 uses the commands sysinfo and userinfo to get system information and user account information from the current host. Unfortunately, when I ran those commands there was no trace of them in the Windows event logs, or anywhere else. As an example, Figure 3 contains an excerpt from the BRC4 logs (system info in the red box and user account info in the blue box) and Figure 4 contains an excerpt of the event logs covering the same time frame.

BRC4 also has the ability to use the net command to illicit some of the same information from the host. So I ran net user, which did have some indication in the event logs. See Figures 5, 6-1, and 6-2. Note the caller process name in Figure 6-2. If an attacker was savvy, they could easily rename the badger to something to blend in.

Keep in mind that I named the badgers something I could easily identify (there was no actual Spotify in the VM). The AppCompatCache (Shimcace) did have an entry for the service executable (spotify.exe) as did the $MFT; however, again, an operator can name the service executable anything they wish and place it anywhere in the file system. The .DLL version of the badger was in the $MFT only. A good operator could easily negate this entry in the logs by naming the badger something seemingly innocuous and could render the AppCompatCache and Shimcache ineffective during analysis.

My liberal use of Mimikatz went undetected. I was able to run Mimikatz multiple times with no Defender detections. As before, Figures 7 and 8 contain sample excerpts from the BRC4 logs and VM event logs, respectively. Figure 9 shows the full event payloads for the two Windows Defender entries seen in Figure 8 (for transparency). Note that I had to set the child process prior to running Mimikatz. The blue box in Figure 7 highlights the setting of the child process while the red box shows the running of Mimikatz and a portion of the output.

BRC4 has a feature called “shadowcloak,” which is designed to dump LSASS. It is described as so:

(only x64) Extracts the memory of lsass.exe without calling MiniDumpWriteDump and downloads it to the Ratel server without touching disk

The output was a .dmp file which is downloaded directly to the downloads folder where BRC4 was stored on my Linux machine. When I ran shadowcloak it, too, went undocumented in the event logs. See Figures 10 and 11.

I checked the UsnJrnl to see if anything had been captured, and bupkis.

BRC4 has a neat feature that allows an operator to change the executable associated with a service. It is called scdivert. It is described as follows:

Changes the service binary path for an existing service over local or remote host using RPC

To test this I created a service named BadgerMimi which pointed to the executable C:\Users\LocalUser\Downloads\BSVCMimi.exe, which I setup on 2022-10-08. I wanted to change the executable associated with the service to C:\Users\Joshua Hickman\Downloads\spotify.exe, which was my badger executable. See Figures 12 and 13.

Note the last line of the output in Figure 12: “Original path restored.” I interpreted that to mean the original executable, BSVCMimi.exe, was re-associated with the service name BadgerMimi after spotify.exe started. So, I opened the SYSTEM registry using Registry Explorer and found the entry seen in Figure 14 (SYSTEM\%CURRENTCONTROLSET%\Services).

My suspicion was confirmed. BRC4 returned the service to its original executable in order to further cover its tracks. Note the last write timestamp for the registry key matches the second timestamp seen in Figure 12. Pretty sneaky.

BRC4 also has a Powershell reflection capability. In order to use it an operator needs to set a child process. The top part of Figure 15 (red box) shows an example of that process. Once the child process is set, an operator can use the psreflect command to run any Powershell commands they wish, including scripts. The bottom part of Figure 15 (blue box) shows my command ($psversiontable) along with the output. Figure 16 shows the pertinent area of the Windows event logs. As can be seen, Windows saw the child process.

I ran three additional commands. The first was dumpclip. This allows an operator to dump the contents of the clipboard and display it on the BRC4 console. The second was screenshot, which does exactly what it sounds like: takes a screenshot and downloads it directly to the BRC4 C2. The third command was samdump. It dumps the NTLM has for each user account on the device. Figure 17 shows the three commands being run with related output. dumpclip is in the red box, screenshot is in the blue box, and samdump is in the purple box. Figure 18 shows the same time period in the Windows event logs, and, again, nothing observed.

Just to be sure, I checked the UsnJrnl file for any indications of the .PNG file, but I did not find anything present.

The rest of the actions I took such as changing directories, getting listings of directories, and downloading files also left no traces of activity. The latter was surprising in that I had suspected I would see something in the SRUM, but there was nothing to be found. I also checked places such as Shellbags, UsnJrnl, $MFT, registry hives, prefetch, and AppCompat/Shimcache with all of them striking out.

Bottom line: if all you have are vanilla Windows event logs, you are going to have a rough time.

In the next exercise I used a clean version of the VM and installed Sysmon (System Monitor) with no additional configuration beyond the default. SysMon caught the process creation when I loaded a DLL badger via the command line. However, if code lands on the host in some other fashion, an examiner/analyst may not necessarily see an entry like the one below.

Unfortunately, default Sysmon was only slightly helpful with BRC4 commands (more on this later – extra configuration is definitely needed). The first commands I ran were sysinfo and screenshot. Figure 20 shows the BRC4 input/output (sysinfo in the red, screenshot in the blue), and Figure 21 shows the relevant time in the Windows event logs.

The next command I ran was dumpclip. Again, Figures 22 & 23 show the BRC4 and Windows event logs, respectively.

The next two commands were shadowcloak (Figure 24 – red box) and userinfo (Figure 24 – blue box). Figure 25 shows the relevant portion of the Windows event logs. Again, there is still nothing.

The next command was samdump. See Figures 26 & 27.

The next command was Mimikatz, and Sysmon finally came through…sorta. See Figures 28 & 29.

Just as before I set the child process (Figure 28 – blue box) prior to executing Mimikatz (red box in Figure 28). The child process was set as C:\Windows\System32\svchost.exe -k -LocalService -p. Figure 29 shows the relevant entry in the Windows event logs. The blue box shows the process that was created, which was the child process seen in Figure 28. The red box in Figure 29 shows the parent command line, C:\Users\LocalUser\Desktop\spotifysvc.exe, which was the badger. Again, keep in mind a more savvy operator could easily blend in to the environment, which is why it is important to understand parent/child processes, the relationships between them and who should be spawning who.

Next, I ran two commands using psreflect. As before, I needed to set the child process (I set it the same as before). Once it was set, I ran two commands, $psversiontable and whoami. Figure 30 shows the sequence.

The Windows event logs for these events looks very similar to what was seen in Figure 29 after I ran Mimikatz. Figure 31 shows the portion of the event logs when I ran $psversiontable. In this instance, I used the .DLL badger (spotify.dll), as can be seen in the red box. The blue box shows the child process I had set.

Figure 32 shows the Windows event logs from when I ran whoami.

As before, the child process I set can be seen in the blue box along with the badger (red box). The actual whoami.exe is at the bottom of the sequence in the green box. Note that the child process that I had set spawned whoami.exe. To confirm what I was seeing in the event logs I turned to the Prefetch files, as seen in Figure 33.

This sequence could look completely different depending on how a BRC4 operator sets child processes and names their badgers. The point here is that examiners should be paying attention to what processes are spawning. Obviously, if Sysmon is not in use, that can be difficult. And, BRC4 may not be spawning things all the time (as was shown earlier), which can negate its effectiveness in this scenario.

But, you should still have Sysmon in your environment. :-).

The rest of the commands I ran looked the same as the Windows event logs of the non-Sysmon VM, which was disappointing. So, with all of this un-logged activity, one should be asking the question: where is this battle actually fought?

As part of an incident response team, I spend part of my time looking at telemetry from EDR tools (no names). Sometimes the telemetry is historical and covers a pertinent event that I am investigating, and other times the telemetry comes in real-time because an attacker left behind a persistence mechanism or they were not fully ejected from an environment during their original incursion. Regardless of the reason, having information about processes, activities against registry hives, file operations, and the like can be valuable.

To simulate this (to a degree), I restored the VM to a clean state and installed ProcMon in the third part of the exercise. This goes slightly beyond my initial plan for this exercise, but I was curious as to what was happening under the hood. Because it can get noisy in ProcMon I filtered the ProcMon output by PID to help cut down on the amount of events I needed to export. In other words, process tracking will not be this neat under normal circumstances. Also, I lowered the jitter settings on the badger during testing so I was not waiting around for it to check in to fetch its commands. So, there could be a gap between things depending on how an operator has set up their badger(s).

The first command I ran was userinfo. Again, as an attacker, I have landed on a host and I need to figure out what user accounts are present. Figure 34 shows the command plus output, but I have highlighted the thread ID (3324) in the red box.

Figure 35. ProcMon with TCP connections and the thread ID.

Here I have a little bit of information. rundll32.exe (PID 312) is involved in some TCP traffic (highlighted in blue), which is likely the comms between the badger and the C2. The host name for the victim machine (where the badger was) was DESKTOP-OK0J4HU, and the attacker machine was josh-ThinkPad-P51. I can also see blank entries for thread ID 3324 (highlighted in red). I do not have any information about what occurred, but, whatever it was, it was “successful.”

The next command I ran was pwd to get the directory I was in. See Figures 36 & 37.

Figure 37 looks almost identical to Figure 35. Some TCP traffic and nondescript information about the thread. The next thing I did was get a listing of files in the directory I was in using the ls command. This is where things got interesting. See Figures 38 & 39.

Finally, something to look at. As before, I highlighted the thread ID in the red box in Figure 38, and used the same color in Figure 39. I have some TCP traffic and the thread being created, but now I had some file operations (Create, Query, Close – highlighted in yellow). Presumably, these operations were performed on the files in the directory I was in at the time in order to get the information needed to report it back to the BRC4 console. After the badger was finished the thread was closed. It is important to note here that this behavior is also exhibited by performing the dir command within the Windows command line interface and is also seen, at times, with Windows Explorer.

What about changing locations in the file system? I changed locations to C:\PerfLogs using the cd command. See Figures 40 & 41.

In Figure 41 the TCP traffic is in blue, the thread creation/exit is in red, and the movement is in yellow. The original location is “closed” (CloseFile) and destination is “created” (operation CreateFile). As with the previous command, this behavior is also seen when changing directories in the Windows command line.

I then ran sysinfo to get system information. See Figures 42 & 43.

Part of sysinfo returns information about the C:\ volume, and the query for that can be seen in the yellow in Figure 43.

Next up is Mimikatz, and this is where it got a bit noisy. Prior to running it, I set the child process as C:\Windows\System32\werfault.exe (highlighted in green). See Figures 44, 45, and 46. Note that this one looks slightly different as this time the badger was named SpotifyBadger.exe. In the green boxes in Figure 44 is the information about the child process and associated thread IDs.

The interesting thing about this particular command is that it seemed to have sent the bytes to the badger in chunks, hence all of the TCP receive entries seen in Figure 45 (maybe that’s normal?). At the top of Figure 46 the thread ID for the original badger task is seen (332 – also seen in the red box in Figure 44). Halfway through Figure 46 SpotifyBadger.exe spawns werfault.exe, which is assigned a process ID of 9696 and is running in thread 5436. At the bottom of Figure 46 we can see werfault.exe really taking off, and the second thread being created (thread ID 2300 – top of last green blob in Figure 46). All threads eventualy exit (not shown).

How about downloading a file? Figure 47 shows the command & output, and Figures 48 and 49 show how it looked in ProcMon.

This operation looks similar to the other two in that the badger received a command, the thread was opened, and then some file operations were run against the file being downloaded, the file was closed and the thread exited.

Taking a screenshot also looked similar. See Figures 50, 51, and 52.

The sequence in Figure 51 starts the same. I have a theory about the yellow-highlighted area. The badger starts interacting with the file GdiPlus.dll, which, I believe is part of the Windows Graphics Device Interface (GDI). However, the file is located in the Windows Side-By-Side (WinSxS) directory, which doesn’t make a lot of sense to me seeing how that directory is typically reserved for Windows components and different versions of said components. Could it be that BRC4 is just leveraging what it knows is there so as to limit the amount of dependencies it needs to bring with it in order to run (LoL-DLL)? Maybe? If someone reading this finds that any part of this is incorrect or can give insight, please let me know and I will update accordingly (giving full credit, of course). The badger also interacts with WindowsCodecs.dll.

Figure 52 shows the badger sending the resulting screenshot back to the C2 and then exits.

Dumping the clipboard with dumpclip is not really that exciting. See Figures 53 & 54.

There isn’t much to see here. It looks just like the userinfo and pwd commands.

The next command is shadowcloak. Again, that is BRC4’s trick that dumps the contents of lsass.exe without touching the disk. Take a look at Figures 55 and 56.

Figure 56 starts out as the rest of the ProcMon screenshots so (TCP traffic and a created thread). Also, you can see the badger calling dbghelp.dll (highlighted in green), which I suspect is it getting symbols (again – if anyone knows otherwise, please let me know). What is interesting is the area highlighted in yellow. The badger creates the file C:\Users\Public\cache.txt. It periodically writes to this file over a period of time. See Figure 57 as an example.

The badger continues to write to cache.txt in spurts in between other operations, until the what is seen in Figure 58.

The spreadsheet went completely yellow. I saw a lot, and I mean a lot of writes to cache.txt with an occasional END OF FILE result. Eventually, it stopped and closed the file, and started sending data. See Figure 59.

The TCP sends continued in spurts until the area seen in Figure 60, at which point it stopped and closed the thread.

I went back and checked the $MFT and UsnJrnl files to see if C:\Users\Public\cache.txt was present, and there was no trace of it.

I wanted to run an additional reflective Powershell action besides Mimikatz, so I ran $psversiontable again. See Figure 61.

The information in Figure 62 looks very similar to Figure 46. The badger receives its commands, which kicks off a thread creation (thread 8824). At the bottom of Figure 62 SpotifyBadger.exe spawned werfault.exe, which was assigned a process ID of 9792 running in thread 7188 (also seen in the green box in Figure 61). The second thread is seen at the top of the bottom green blob in Figure 63.

The last command I wanted to see was the scdivert command, which, if you recall, would replace a service binary with a new binary, start the new binary, and then re-associate the old binary with the service. See Figure 64.

As with previous screenshots, the red box highlights the thread. The yellow box highlights the binary currently associated with the service called NewSpotifyService. The green box highlights the binary that I want to assign to the NewSpotifyService service. See Figure 65.

The top part of Figure 65 should look familar. The badger receives its orders and creates a thread (thread ID 2724). The areas highlighted in yellow represent interaction by services.exe with the registry key SYSTEM\CurrentControlSet\Services\NewSpotifyService\ImagePath. The top two yellow areas (with the blue arrows) are the querying of the original key value (the path for the original binary associated with the service – yellow box in Figure 64). The first red arrow highlights the key being opened with READ/WRITE access, and the bottom red arrow highlights the setting of the new binary (green box in Figure 64).

One the new binary, SpotifyBadger.exe, is associated with the service, it is created. See the yellow highlighted area in Figure 66.

Figure 66 also shows what looks like (I’m not completely sure here) command line data for the new binary on the row where SpotifyBadger.exe starts (first green row). See Figure 67 for the complete cell content.

After the new binary was started, the badger re-associated the original binary, Spotify_2.exe, with the service name. See Figure 68.

Pretty. Sneaky.

I was able to re-create MDSec’s findings regarding a badger loading a substantial amount of DLLs on initilization, but I checked the excutable flavor of the badger (not an injected one). See Figures 69 and 70.

One thing I did not see was the loading of certain DLL files during initialization; specifically, credutil.dll & dgbhelp.dll. I tried both the DLL and service executable versions of the badger, and did not see either get loaded at initilization. It may be that this was changed by the BRC4 author (devs change things all the time), or it could be the non-injected version. Either way, I didn’t see them.

To help with identifying a badger based on what MDSec found and my own observations, I used the pre-configured Sysmon configuration file offered by Swift On Security , but I added the DLLs identified by MDSec to the Event 7 section (loaded DLLs), and a specific file to the Event 11 section (FileCreate). The latter being the file associated with the BRC4 shadowcloak feature (from Figures 56, 57, &58). See Figures 71 & 72.

After Sysmon had the new configuration, I installed a new beacon as a DLL. See Figures 73 and 74.

In Figure 74 the row highlighted in red is the badger being installed. The row in orange shows winhttp.dll being loaded, and the rows in blue highlight the badger calling back to the C2. This view of the event logs is unfiltered, so the badger loading, winhttp.dll loading, and then the immediate call out the C2 is a notable behavior. Again, I did not see the other DLLs being loaded, but that could be due to the type of badge being initialized. With this level of logging an analyst could find legitmate processes with similar behavior, but it is definitely something that should be investigated further.

Next up is shadowcloak. See Figures 75 & 76.

With the new Sysmon configuration I was able to see the C:\Users\Public\cache.txt file FileCreate operation (once), followed by the loading of dbghelp.dll and a lot of network activity. This is a definite tell for this particular BRC4 feature. As always, devs can change things, so this behavior may or may not be in future revisions.

I followed this up with Mimikatz. Note that I had set the child process to C:\Windows\System32\werfault.exe. See Figures 77 and 78.

Figure 78 shows the badger receiving its orders (top two blue rows), which triggered it to spawn the child process (werfault.exe – red highlighted row) along with a remote thread being created by werfault (yellow highlighted row). Note the new process ID of 7812. After that both dbghelp.dll and logoncli.dll are both loaded by werfault.exe, which is followed by network activity by the badger. Again, there are probably scenarios where this might be legitimate activity, but it should definitely be scrutinized further considering what we know about badgers.

Figures 79 and 80 show the scdivert command.

The Sysmon configuration file really helped here. At the top we can see the badger receiving the command, followed by two registry events (Value Set) in the top two green highlighted rows; the new badger executable is being set to the service SpotifyService (Spotify_Badger_3.exe). The red highlighted row represents the new badger executable being started. The two bottom green highlighted rows (two additional registry value sets) represent the old badger executable, SpotifyService_2.exe, being re-associated with the service SpotifyService. The orange highlighted row represents the new badger loading winhttp.dll, followed by blue highlighted rows representing the new badger calling back to the C2.

Next, I ran the psreflect command. See Figures 81 & 82.

The same child process was used as before (werfault.exe). The badger spawns the child process (red highlighted row), which then loads dbghelp.dll (orange highlighted row). The green line represents the child process running a PSScriptPolicyTest; this is Powershell testing for AppLocker’s Constrained Mode. On my VM, this file got created whenever I opened a Powershell terminal, so the file creation, alone, is not indicative of a badger, but, taken within context of everything else, certainly should be scrutinized further. In the grey highlighted area is Powershell execution (Host Application was the child process werfault.exe). Again, the Sysmon configuration file edits made earlier came in handy to give context around the child process. To see if this was consistent, I ran an additional psreflect command. See Figures 83 & 84.

Figure 84 looks very similar to Figure 82. Again, the badger spawns the child process, which loads dbghelp.dll, and then executes Powershell.

The rest of the BRC4 commands I ran went undetected, but a properly tuned Sysmon configuration file could potentially help log some of that activity.

In much the same vein as other ASTs, BRC4 is designed to quietly emulate attacker behavior, and it does this very well. With standard Windows logging defenders may not even know they’re in a battle until it’s too late. Attackers could navigate the file system, download files, steal credentials, or even worse all without being detected, and post-incident forensic analysis could find very little to examine. However, with a appropriately configured SysMon or EDR monitoring (why not both?), defenders may have enough data to identify maliciousness is afoot and take appropriate action, and identify badness in Windows logging.

With BRC4 now available in underground forums it has become a matter of when defenders will encounter attackers using it, whether they know it or not. Knowing where the battle can be fought can go a long way in giving defenders a fighting chance.