BlueCrab Ransomware’s Continuous Attempts to Bypass Detection

BlueCrab Ransomware (=Sodinokibi Ransomware) is a ransomware that is being vigorously distributed to Korean users. It distributes through a fake forum web page created using various search keywords. The infection process begins at the moment when a user runs the JS file downloaded from the distribution page. The distribution page appears in the front pages of a search engine, allowing it to be easily accessible. Because of this, cases of infection are being continuously reported by users. ASEC analysis team has posted several posts related to the ransomware.

• Distribution of Renewed JS.BlueCrab Ransomware
• BlueCrab Ransomware Distribution Website Revealed (2)

BlueCrab ransomware actively creates variants to bypass AV solutions, and attempts to bypass detection through progressive mutation that occurs at each infection stage. This ransomware would remain unchanged for a long time, but occasionally mutate actively for several months. It went through several mutations from November 2019 to January 2020. It then remained unchanged for a while, and came to be mutated frequently from October 2020 to December 2020. This post will comprehensively explain the infection process of BlueCrab ransomware, and share the methods it used to change the attack process to bypass AV detection.

The attacker attacked vulnerable WordPress environments, stole privileges, and uploaded posts with titles that include ‘Download’ and various keywords. When a user accesses one of these posts, the javascript within the internal source code prints a fake forum web page, and prompts the user to download and run the file. The sentences of this post are incomprehensible; however, the search engine misinterprets the content, placing them in the front pages (SEO-Poisoning technique). It is assumed that these distribution posts are being created by automated tools, and there are countless malicious distribution posts that are being created. For more information, please refer to the links posted above.

Distribution posts that the attacker uploaded may seem no different from typical posts, but when taking a closer look at their source code, they reveal an internal javascript code (see Figure 1). See Figure 2 for details.

The installed javascript deletes all web objects loaded to the current browser, then loads a fake forum page. Because of this, when a user connects to a post, the fake forum page is loaded instead of the actual post content.

It is assumed that the javascript is linked with the attacker’s server. If a user downloads the file from the domain A, the action is not carried out, because the filter is applied to the domain B as well. It is assumed that all distribution posts of the attacker are connected to the attacker’s server which also manages them. The process up to this point shows no difference from that used in the older versions.

Upon clicking the download link in the fake forum page, a compressed JS file (ZIP) is downloaded. The name of the file includes keywords of the distribution post titles, and the filename format changes periodically.

1. Change of JS File

The JS file downloads additional script from C2 and runs it. As the internal code is obfuscated and the size of the script is small, the process of bypassing detection is easy. Even if generic detection is applied, it bypasses detection by taking a slightly different approach such as adding an empty junk code within 1-2 days (on average), or by using a different syntax with the identical feature. Due to the mentioned method, it would be better to use memory detection or behavior detection instead of using file detection when defending against this malware.

• Change of JS File Structure

Previous versions of BlueCrab maintained the identical code structure and randomly changed variable/function names for every single download. However, since December 15, the attacker added a feature that randomizes the order of the lines for each download, and the overall code structure was changed to implement such a feature. The malware performs all features through just 1 function call so that it works even if the lines are randomly arranged. Furthermore, while the previous versions used random strings for variable name and etc., the current variation uses English words. (e.g.: apple) It is believed that this change is implemented to complicate AV solution’s implementation of generic detection on script files.

When briefly scanning through the JS file, it looks almost completely different from previous versions, but deobfuscation of the script—the code that performs actual malicious behavior—reveals that it remains almost unchanged. The only aspect that the attacker constantly changes is the outer shell of the malicious script for detection bypass. Each JS file contains three C2 addresses, and when connection fails, re-attempts connection to the other C2.

• Change of C2 Connection Method

For C2 address, a breached regular domain is used, and for PHP filename, ‘/check.php’ was used until October 26, 2020, until ‘/search.php’ became the new filename. Before then, filenames such as /info.php, and forum.php were used. A random value is added as the argument that is sent to the PHP file. The previous version used HTTP protocol, but starting from March 30, 2020, the new version uses HTTPS protocol. This means that it may not operate in the older version OS where library update is not applied.

When JS file is executed, it downloads additional javascript from C2 and runs it. Javascript extracts the powershell script and runs it. Powershell script loads injector written in .Net language to a memory, runs it, and the injector injects ransomware Loader written in Delphi language to a normal process and runs it. Injected Loader ultimately loads BlueCrab ransomware. As a result, as shown in Figure 6, the BlueCrab has many layers, and it can initiate a change of structure at each stage, allowing it to easily bypass AV solutions. The infection flow of JS -> powershell -> .NET -> Delphi has not changed since the previous version. Instead, execution methods and detailed behaviors for each stage underwent changes.

.Net PE will be referred to as ‘.Net Injector,’ and Delphi PE as ‘Delphi Loader.’

2. Change in Powershell Execution Method

The powershell step underwent most changes during the targeted period. The attacker used the property of powershell which has a comparatively free syntax to conduct variety of changes as shown below.

• Change from file to registry

Previous versions had wscript.exe (JavaScript) drop powershell script as a file and run it. The variant confirmed in October 22, 2020 stopped dropping script as a file, and instead, used the method of inserting .NET Injector binary into certain registry key, reading it, and running powershell command that reads the binary and loads into memory. The command is registered to environment variable and registry autorun key. Figure 7 shows the structure that expresses this, and each command is shown in Table 1. Because the command is registered to the autorun key, ransomware infection begins upon reboot.

• Deletion of behavior of registering registry autorun

On October 26, 2020, the attacker deleted the behavior of registering to registry autorun. This means that the malware does not execute upon reboot. Instead, wscript.exe itself runs the command of environment variable. Also, in the middle of Base64 code, it used “” to attempt obfuscation. Since most AV solutions monitor behavior of registering autorun, it is assumed that the behavior was quickly deleted.

• Addition of cmd.exe to process tree

In previous versions, wscript.exe directly ran powershell.exe, but the method has changed to running powershell via CMD command. This means that the infection process tree has changed.

• Deletion of behavior of registering environment variable, addition of random annotation value

The behavior of registering a command to environment variable and running it has been deleted. This means that wscript.exe directly runs the powershell command that loads .Net Injector registered to the registry. Also, the method has changed to adding a random annotation value to the front of the command, Base64-encoding it, and making it harbor a completely different argument for each infection environment.

3. Variant of .Net Injector that Runs from Powershell

Net Injector injects Delphi Loader and runs it. The obfuscated Delphi Loader binary is included within .Net Injector, and .Net Injector extracts it, injects it into the target process, and runs it.

• Change of Delphi Loader binary (injection data) save method

The previous versions saved Delphi Loader binary as a value that is upside down following Base64 encoding, but the variant confirmed on December 22, 2020 used a simple substitution method to save. It substituted the value ‘1000’ to strings such as ‘!@#.’ The substituted strings also have changed to strings such as ‘$%^.’ (Nov 28, 2020)

• Change of injection method

The format of Delphi Loader binary tht .Net Injector injects has been changed from DLL format to EXE format. This means that the method of injecting the binary has also been changed. The malware previously used Dll Injection technique, and the changed version uses Process Hollowing technique.

The malware previously used the method of allocating virtual memory to the process (powershell.exe) it was loaded into, inserting Delphi Loader, finding the address of DllEntryPoint() function and running directly. The variant confirmed on October 22, 2020 used a new method of creating a suspended separate process, injecting process memory structure of Delphi Loader, and resuming it. The malware changed the method to a typical process hollowing technique.

• Change of injection target process

In the early changed versions, the malware created the process that is the same as itself and injected it. Therefore, powershell.exe was the process targeted for injection. The current version downloads a certain exe file that exists in SysWow64 directory, runs it, and performs injection. The path of the executed process is hard-coded. For injection code, the exception handling by x64 and x86 architecture is configured, but the malware now only targets systems in x64 environment for injection. The process for injection subject is changing constantly like below. It is assumed that this is done to modify the process tree structure. V3 solution is capable of blocking the malware regardless of the process name.

4. Change of Delphi Loader

Delphi Loader loads BlueCrab ransomware. In that stage, the malware changed to disable certain AV solutions and bypassed detection. It obtains admin privilege to enhance infection success rate, and repeatedly prints 100 times until a user presses ‘Yes’ to the UAC message. Afterward, it loads BlueCrab binary and performs VSC deletion and file encryption.

• Addition of code that monitors V3 service

The variant confirmed on November 2, 2020 added a code that monitors ‘V3 Service,’ the service of V3 Lite. If V3 service is running, it goes to sleep mode for 1 second and repeats the action 500 times. Therefore, if a product engine update happens while the loop statement is running, the ransomware operates while the service is temporarily shut down, rendering the system vulnerable. This is assumed to bypass the detection of V3 products which block any attempts to access multiple files even if ransomware is executed. The current version of V3 detects the malware on a level more advanced than that of the monitoring behavior and is capable of blocking the malware regardless of its behavior.

• Encryption of internal strings

To avoid detection, the malware started encrypting the internal strings gradually. In the early stages of changes taking place, ‘V3 Service’ string was used as a whole, but over time, the malware slowly refrained from using strings such as ‘Service’ and ‘ervice,’ and changed to the method of using the strings after decrypting them through self-calculation. Judging by this change, it can be seen that the attacker is precisely aware of the detection points of AV solutions.

• Encryption of .rsrc section data

Among the .rsrc sections, data of the first RCDATA section is XOR-encoded. The key is hard-coded as ‘1234.’ The data is DLL that bypasses AV products of certain other companies, and it is not used if an AV product is not installed. If using a specific AV product of another company, the data is dropped under the name db.bat into %USERPROFILE% directory, is run by rundll32.exe, runs cleanmgr.exe of system32 directory, and injects. Injected cleanmgr.exe finds the directory where decoy file is located and performs deletion.

When BlueCrab ransomware binary is run due to Delphi Loader, the ransomware deletes VSC via powershell command and performs file encryption. Once the encryption process completes, the Windows background changes to the following:

AhnLab’s anti-malware solution V3 detects and blocks BlueCrab ransomware using the aliases below.

[File Detection]
Ransomware/JS.BlueCrab.S1336
Ransomware/JS.BlueCrab.S1366

[Memory Detection]
Ransomware/Win.BlueCrab.XM37
Ransomware/Win.BlueCrab.XM63

[Behavior Detection]
Malware/MDP.Inject.M3044
Malware/MDP.Behavior.M3491
Malware/MDP.Behavior.M3544