During the past two months, FortiGuard Labs has been monitoring an onslaught of updates from GandCrab as a result of their agile development method. Some of these updates included major changes, while some only had minimal. In the midst of this, a series of tit-for-tat exchanges were witnessed by many researchers between the ransomware authors and the South Korean-based security company Ahnlab over the vaccine tools that the latter released in mid-July. At some point, the threat actors even released a POC of a Denial-of-Service attack against Ahnlab’s antivirus application.
This report is a rundown of GandCrab’s developments since its release of version 4.0 in July, 2018. Read our last research blog on the same topic.
The image below illustrates the various versions and events that transpired during GandCrab’s development over the last two months. In general, it visualizes how rapid GandCrab’s development is, including one point when the authors released several updated versions of the malware over just a few days. Fortunately, this malware has been transparent with their build versions by explicitly including that information in the malware binary. This makes it a lot easier to map the changes with every release.
Just a few months before the release of v4.0 at the beginning of July, GandCrab’s rapid development pace began to quiet down. That new version was a total transformation compared to its previous version. The most notable change was the switching of its file encryption algorithm from RSA to the much faster Salsa20 algorithm, as well as its capability to encrypt network shares. To be able to encrypt devices that are not connected to the internet, it had done also away with its Command-and-Control (C2) server connection. An interesting behaviour was also added wherein it checks for a file named <8hex-chars>.lock in the user’s COMMONAPPDATA directory. This played a major role in the succeeding iterations of this malware. We previously discussed the details of these developments in this article.
In v4.1, a network communication was added that sends the encrypted data collected from the victim to a long list of URLs, although without a clear purpose. This was also the time when speculations of a new SMB spreader capability also began to circulate. Our detailed report on these developments can be found here.
Only minor changes were observed in v4.1.1, which were mostly for code optimization.
Just two days after the discovery of v4.1.1, Ahnlab released a vaccine tool to stop the execution of this malware before it encrypted any files. The tool achieves this by manually creating the .lock file that is checked by the malware before encryption. Security researchers had mixed reactions about this, mainly due to the fact that public release of the knowledge of this weakness would tip off the threat actors, who could then simply make a few modifications to address that fix.
And true enough, GandCrab v4.1.2 was released only after four days later with modifications designed to bypass the tool. This version changed the process for generating the .lock filename by incorporating the Salsa20 algorithm into the process, thereby rendering Ahnlabs’ vaccine tool ineffective. And as part of their trademark of shouting out security researchers and companies, both Fortinet and Ahnlab had been their targets during the development of this version. As a rebuttal, Ahnlab released a second version to address the change.
No changes were observed in v4.1.3.
Their versioning got a bit messed up when an updated variant of v4.1.2 was discovered, and as expected, it was a retaliation to Ahnlabs’ new vaccine tool update. This time, instead of checking for the existence of the .lock file, they switched to checking for the existence of the malware’s mutex, thereby bypassing the tool once again.
The process of generating the mutex name is identical to the one used by the older v4.1.2 version - just based on a new mock string directed to Ahnlab. The string includes a link to an image with a Russian text, which roughly translates to “I added you to my gay list. I used a pencil for the time being,” implying that inclusion to the list was temporary.
As of this writing, we have not seen any updated responses in the vaccine tool, and to be honest, we are not expecting them. To support this new change, aside from manually creating the mutex in the user’s system, the vaccine would also need to be system persistent, meaning it would have to be kept running in the background at all times and must also be registered to execute upon system boot. In our opinion, going to such lengths for a temporary remedy is both extreme and impractical, especially considering how closely the threat actors monitor the development of the tool and how quickly they can release a new version to bypass remedies.
As an example of how rapidly the malware developer’s agile development process operates, the same day that the 4.1.2 bypass was identified, v4.2 was discovered that included some basic sandbox evasion techniques. However, this sandbox detection function was short-lived, as it was no longer observed in v4.2.1.
Interestingly enough, even though there was no update to the vaccine tool, the developers continued their attacks by releasing a link to a Proof-of-Concept (POC) source code that could cause a Denial of Service (DOS) attack on Ahnlab V3 Lite’s TSFltDrv.sys service driver. When triggered, this attack causes a Blue Screen of Death (BSOD) in the system. The actual POC was also integrated as a new function in the malware. We were able to confirm this on Ahnlab V3 Lite 188.8.131.52 with TSFltDrv.sys file version 184.108.40.206.
The underlying bug that this malware exploits is due to a lack of user-mode input parameter sanitization, which can be sent by non-privileged users to the vulnerable module. In a nutshell, the POC works by sending a non-existing memory address to the service driver. This results in an error when the driver tries to access it. Furthermore, we found that this kernel mode module also currently does not have proper security attributes set on its device object interface. This opens up the potential for another attack surface, which can be possibly be exploited for privilege escalation, confirming claims made by the GandCrab authors.
Fortunately, Ahnlab announced that this bug has been fixed in V3 Lite 220.127.116.11, the latest version at the time of writing. This is just another example of why it is always critical that you make sure you are always running the latest version of an application.
The GandCrab authors continued their string of updates with the release of v4.3, which included an added anti-disassembly trick to complicate analysis. While this is not an advanced or a new technique, it does add another step to analysing the malware. An option to beating this technique is to modify the malware binary and ignore (NOP-ing) the added unnecessary code to reveal the “real” code. This technique is a bit rough, but in this case it’s a good quick solution.
GandCrab’s latest version v4.4, was an unexpected move by the threat actors. It was not an upgraded version of the malware, but instead, a vaccine for itself. Version 4.4 is basically a variant of v4.3 that has been roughly patched to execute a function that creates the mutex that the malware checks before encryption, and which then sleeps indefinitely to stay running in the background. Aside from VirusTotal, we were not able to find the variant being distributed through other sources, which probably makes sense. It seems like its sole purpose is to continue its mocking of the previous vaccine tool releases. Of course, actually using the tool as a vaccine is out of the question – don't. We have already seen how quickly and easily this development team can release modifications to mitigate these kinds of countermeasures.
FortiGuard customers are protected by the following:
As we strongly suggested in a previous report about the “kill-switch” fix, vaccine tools should not be treated as a permanent solution, especially for actively developed malware like GandCrab. Instead, the best response is to keep systems up to date with vulnerability patches, and implementing isolated backups should be on everyone’s priority list as a last line of defense against any ransomware attacks.
FortiGuard Labs will continue monitoring this malware’s development.
-= FortiGuard Lion Team =-
6c1ed5eb1267d95d8a0dc8e1975923ebefd809c2027427b4ead867fb72703f82 (4.0) - W32/GandCrypt.CHU!tr
37e660ada1ea7c65de2499f5093416b3db59dfb360fc99c74820c355bf19ec52 (4.1) - W32/Gandcrab.IV!t
8bd9ca75496baa5fcc5a39995e7c8f8c84a73dc56122d67fbf2bc9ea1c53c2e1 (4.1.1) - W32/GandCrab.D!tr.ransom
ce093ffa19f020a2b73719f653b5e0423df28ef1d59035d55e99154a85c5c668 (4.1.2) - W32/GandCrab.D!tr.ransom
768d3ffd942d8aea0f5def0c113d1a4e86bf9f78732b49c42222fa94bae3cf71 (4.1.3) - W32/GandCrab.D!tr.ransom
a1a60f808ef6804231cad1d78f87b90561f31e897c068db9dfae349beef13a61 (new 4.1.2) - W32/GenKryptik.CFUK!tr
3b0096d6798b1887cffa1288583e93f70e656270119087ceb2f832b69b89260a (4.2) - W32/GandCrab.D!tr.ransom
4b6db1a59ce31c78b9958342e6315a2d40e9b078747def487b9606e312cad630 (4.3) - W32/Filecoder_GandCrab.D!tr
be32aec1e61303c28ec294939260d4daa2e20f003c3f5c190c9b29153b0bf712 (4.4) - W32/Filecoder_GandCrab.D!tr