Brute Ratel v1.3 codename Resurgence is now available for download. This release brings in various changes to evasion techniques, improvements to Badger, user experience (QOL) and several features requested by the BRc4 community. Since this is a major release, I’ve divided the blog into various segments which can be directly accessed with the links below. A quick summary of the changes can be found in the release notes.
This release brings in several changes to Brute Ratel which not only helps with the size optimization of the shellcode, but also helps to avoid further detections. The major improvement to the core starts with the removal of strings and changes to the hashing algorithm which were earlier embedded within the payload. As the release v1.2.2 was leaked by MdSec on Virustotal, it was imminent that several EDR organizations would download and extract telemetry from the payload and build detections from it. This was observed heavily with detections from Microsoft’s Defender/ATP, Crowdstrike and Elastic. Before we understand the changes in the Badger, it’s trivial to understand how the static detections take place. Static detections are built on the following artefacts:
All the said detections here are what I’ve seen during my tenure as a detection engineer with various EDR organizations, building detections when I started my career as a threat hunter, or when I started reversing the EDRs to understand it’s behaviour. Now that we know how the detections are usually handled, lets see where BRc4 lacked till v1.2.9. Till the previous release, Brute Ratel was encrypted using RC4 and was also using the default ror13 algorithm for calculating hashes for various API calls. The loader of the stage contained the decryption routine which also contained encrypted information about the server and it’s metadata as to where it needs to connect to. Thus the strings embedded within the core were not susceptible to detections as they were encrypted, but since they were in base64, it was itself an anomaly. Similarly, when the payload is running in memory, then during sleep, it will encrypt itself and decrypt occasionally to connect to the Ratel Server and fetch commands to execute. However, a threat hunter can simply use a debugger to add breakpoints and extract the decrypted data from the payload and run Yara against it for attribution. Apart from these, Brute Ratel only had malleable profile in the post request, but not in post response from the server. It also did not support response headers. Statistics are laid out using all these telemetry and a malicious score is provided by the EDR’s algorithm which is either allowed to run or be killed depending on the score.
In case of BRc4, the core detection built by several EDRs were on the hashing algorithm, strings when not encrypted, the encryption routine and on the response received from the server as the response was not malleable. This release brings changes to all of these.
With this release, Badger provides extended malleability with custom response types and headers. Ratel Server can be configured to respond differently when a command needs to be sent, and a different response when there is no command in queue. Thus when the Badger checks in and there is no command in queue, the server can just send the configured response without having to send anything else, If there is a command in queue, then that can have a different malleable profile as well. Custom response headers can also be added alongside request headers. The requests/responses and headers are fully compatible with information extracted from Burpsuite. The ‘X-forwarded-for’ headers for authenticated Badgers are now written in the web.log file. Since response headers were added, the original key in the profile ‘extra_headers’ is now renamed to ‘request_headers’. The user interface was also changed along with a built-in help option in the “Add Listener/Add DOH Listener/Add Payload Profile” dialog.
Another malleability update was ‘DNS interval’ for DNS Over HTTPS. DOH requests allows a maximum of 64 bytes per request. This means, if you execute a command where the response is more than 64 bytes, then the response would be split into multiple chunks. When the sleep is complete and Badger decides to check in, it encrypts the chunks available, and then sends the chunks without sleeping till all the chunks are sent. Once all the chunks are sent, it will fetch command from the c2, execute them, store their response in chunks and then go to sleep while hiding itself and also the responses in heap. DNS interval, in this case would be the time interval between various chunks it needs to send for a single request. During this interval Badger does not hide itself. It will just wait for a few seconds before sending the next chunk of data. Once all the chunks are sent, a single request is complete and then it will mask itself and sleep. Badger’s sleep and DNS interval are two different things. Badger can’t hide itself when performing any type of operation because the thread needs to actively read the RX region or read the RW code. However if the badger has zero threads active, then the Badger will encrypt itself, stack, heap and everything related to it. Thus DNS Interval allows to change the frequency at which packets of DNS for a single request is sent to the server.
Badger has always been fully multi-threaded since it’s first release. This meant every new command was run in a seperate thread. This is changed now to avoid multiple thread creations. Badger is still multi-threaded, but it won’t run every command in a thread. Only a few selected commands which might block the main if run as function, is now run as a seperate thread. Everything else is run inline as a function. Several changes were also made to how a local thread was created following some detections from Elastic EDR, as unlike any other EDR, Elastic also monitors local threads. There’s also a major update to the Badger’s shellcode and it was rewritten to avoid detections from the previous releases. Earlier, the shellcode stored the server’s configuration in encrypted base64 which is now fully binary. Since the shellcode was further optimized, it was found that there is no use of the ‘ret’ based shellcodes, so that has been removed. Only RtlExitUserThread and WaitForSingleObject exists now. Default Rc4 key ‘bYXJm/3#M?:XyMBF’ was removed from the shellcode earlier, but it still stayed within the core to decrypt DLL names when DLL loading was required. This is also now removed. All ror13 hashes along with it’s hashing algorithm was removed from stage/stageless and the core payloads including all strings from the Badger’s memory. All command output received from the Badger is now tracked, parsed and formatted directly by the Ratel server. This helped lower down the size from the earlier 240kb to 210kb now, even after adding all the new features.
Another major feature request by several users was reverse port forwarding. Reverse port forwarding can be extremely useful when you want to bring in your own custom C2 or tooling, or for moving laterally. The Badger now comes equipped with the ‘rportfwd’ command which can be used to forward a port on Badger’s host directly to the Ratel server, and the Ratel server will handle the task of forwarding it wherever requested. The below video shows a quick demonstration of reverse port forwarding for metasploit’s meterpreter.
Several other improvements were added to the existing commands as requested by the users. The below list should highlight most if not all.
Several minor improvements were added to the user interface for QOL as requested by the users. The below list should highlight most if not all.
Several other bugs were fixed along with improvements which can be found in the release notes.
When you sell a product which falls under ‘Dual Use’, you will eventually reach a scenario of ethics and how the product needs to be used. I’ve been asked this question several times both in person and on social media on how do I verify the party purchasing the product. Brute Ratel is a product of Dark Vortex, the headquarters of which is located in Mumbai, India. India, like most of the countries have to follow the “Wassenaar Arrangement” which imposes export controls over any product which is to be sold internationally and falls under the category of “Dual Use”. In novice words, since Brute Ratel serves as a command and control, which can be used for assessing the strength of an organization, and also for military use, it comes under “Dual Use”. Thus every party, to whom the product is to be sold will have to be vetted thoroughly, else there is a heavy risk of the criminal implications. Dark Vortex assesses a purchaser in two different ways. The first and foremost is the background verification (BGV). BGV as in, when the company was formed, in which country the company is located in, who is the director of the company, whether the company faced any type of criminal charges and so on and so forth. We also force the party to interact with us only with the official business email ID and also verify the domain from where the email originated from. We do not entertain generic emails such as gmail/outlook/yahoo etc or newly purchased websites. We also check the registration of the company/incorporation and under what type, was the company registered as, whether it’s an infosec/IT company/Banking or anything else to validate we are not selling the product to a newly started company which might also be very suspicious. The BGV is fairly easy when vetting a financial organization or an infosec/IT company as most of the time these companies have usually existed for a good number of years and have a decent reputation. We take heavy precaution when a restaurant or fast food organizations try to buy the product (yes, ironically that happens). The BGV is conducted via a third party company from US and also by me (OSINT much?) to make sure that we are only dealing with legitimate and registered companies. Once this first verification process is complete, then we proceed with the second step of verification which is to make sure the payment is over a wire transfer and the transfer comes from the same company which we verified earlier. The licenses are shared only post the verification of payment and thankfully SWIFT transactions provide a detailed tracking information as to where the payment originated from. At the time of writing this blog, Dark Vortex has around 500+ customers spread mainly across US and Europe. We do not sell the product to sanctioned countries or especially to countries where there is civil unrest.
However, inspite of all the precautions, there are still chances of the product being leaked by an employee of the organization, re-sold or cracked in this instance. There’s nothing more I hate, than the use of Brute Ratel for malicious activities. BRc4 contains heavy trackers and can be traced down if anyone tries to use if for malicious purpose. The tracker is encrypted with a master key which is not shared with anyone. Also the trackers can’t be removed as these trackers are not only a part of the payload/package, but this tracker is also used for encrypting some other parts of the payload. This means if the tracker is removed or modified, the payload will stop working. Lately, I was informed about the leak of Brute Ratel v1.2.2 and v1.2.5 by an anonymous individual along with a video showcasing that Dom Chell from MdSec, and Austin Hudson from Guide Point Security were sharing the samples to selected parties. Upon further investigating the brute ratel’s licensing server logs, it was found that various brute force attempts to crack the licensing algorithm were made. All of this happened before the v1.2.2 was leaked on Virus Total. The time of brute force in the server logs matched the date when the sharing happened in the Austin Hudson’s (@Mumbai in discord) video. The video shows Dom Chell and Austin Hudson responding to having the latest release and at the same day several attempts were made to upgrade an older version of v1.2.2 to v1.2.4 as they mentioned they had the softwares. On the same day, I released a version v1.2.5 which I asked the individual to check if mdsec/austin had the new release. Surprisingly only the anonymous individual, Dom and Austin knew about this release and I saw attempts to upgrade to v1.2.5 sent via burpsuite.
During this time, I decided to change the licensing algo to make it more difficult to crack, following which I noticed that since Dom/Austin could not crack the software, they decided to upload the package to Virustotal, so that someone else might crack it. Unfortunately it did not take long for the infosec community to share this uploaded version among various telegram channels and discord. This was later cracked by a russian group known as ‘The Molecules Crew’ by reversing the algorithm, patching it and sharing it in various underground channels. I was informed that the cracked versions are being utilized by some of the threat actors and I have already provided help to several organizations in need. Thus, I am actively sharing the yara rules to detect stager and the stageless payloads of Brute Ratel. Make note that these won’t affect the v1.3 release as the payload is entirely changed in this release.
Now, there is no sufficient proof apart from the video, server logs and chats from various discord channels that the mentioned individuals shared the product on VT without license keys. However, Dark Vortex has already shared the evidence with various agencies to help them track down the malicious abuse of the product by threat actors. Any agency/company who need help to track down threat actors using BRc4 can contact us at support@bruteratel.com and we will be more than happy to help track down the Brute Ratel servers, reverse the payload and find more attribution information from the attack. Since I’ve already discussed the core parts of detections above, I’ve added the Yara rules to github here for further detecting malicious usage of the product including various other open source detections for BRc4 all at one place.
All in all, this release is going to be the last release for this year, ofcourse if there are any bug-fixes, that will be attended. But the next major release will be in January which will introduce a new type of payload, new lateral movement and staging techniques. Also, the API documentation for v1.3 will be available for use by this weekend. Stay tuned for more interesting releases.