Ransomware is not at all novel, but it continues to be one of the top cyberthreats in the world today. In fact, according to data from Trend Micro™ Smart Protection Network™, we detected and blocked more than 4.4 million ransomware threats across email, URL, and file layers in the first quarter of 2022 — a 37% increase in overall ransomware threats from the fourth quarter of 2021.

Ransomware’s pervasiveness is rooted in its being evolutionary: It employs ever-changing tactics and schemes to deceive unwitting victims and successfully infiltrate environments. For example, this year, there have been reports of ransomware being distributed as fake Windows 10, Google Chrome, and Microsoft Exchange updates to fool potential victims into downloading malicious files.

Recently, we found a brand-new ransomware family that employs a similar scheme: It disguises itself as a Google Software Update application and uses a Microsoft web hosting service IP address as its command-and-control (C&C) server to circumvent detection. Our investigation also shows that this ransomware uses the QueueUserWorkItem function, a.NET System.Threading namespace method that queues a method for execution, and the modules of KeePass Password Safe, an open-source password manager, during its file encryption routine.

In this blog entry, we provide an in-depth technical analysis of the infection techniques of this new ransomware family, which we have dubbed HavanaCrypt.

Arrival

HavanaCrypt arrives as a fake Google Software Update application.

Figure 1. The file description of the binary file of HavanaCrypt

This malware is a.NET-compiled application and is protected by Obfuscar, an open-source.NET obfuscator used to help secure codes in a.NET assembly.

Figure 2. The properties of the binary file of HavanaCrypt as shown in the Detect It Easy tool, a program used to determine file types

The malware also has multiple anti-virtualisation techniques that help it avoid dynamic analysis when executed in a virtual machine. To analyse the sample and generate the deobfuscated code, we used tools such as de4dot and DeObfuscar.

Figure 3. An obfuscated HavanaCrypt ransomware code sample

Figure 4. A deobfuscated HavanaCrypt ransomware code sample

Upon execution, HavanaCrypt hides its window by using the ShowWindow function with parameter 0 (SW_HIDE).

Figure 5. The ShowWindow function as it is used by HavanaCrypt

HavanaCrypt then checks the AutoRun registry to see whether the “GoogleUpdate” registry is present. If the registry is not present, the malware continues with its malicious routine.

Figure 6. The function containing the parameters used by HavanaCrypt in checking the registry key

It then proceeds with its anti-virtualisation routine, where it terminates itself if the system is found running in a virtual machine environment.

Antivirtualization

HavanaCrypt has four stages of checking whether the infected machine is running in a virtualised environment.

Figure 7. The function used by HavanaCrypt to implement its antivirtualization mechanism.

Figure 8. The entire antivirtualization routine of HavanaCrypt

First, it checks for services used by virtual machines such as VMWare Tools and vmmouse.

Figure 9. The services being checked by HavanaCrypt

Second, it checks for the usual files that are related to virtual machine applications.

Figure 10. The virtual machine files being checked by HavanaCrypt

Third, it checks for file names used by virtual machines for their executables.

Figure 11. The virtual machine executables being checked by HavanaCrypt

Last, it checks the machine’s MAC address and compares it to organisationally unique identifier (OUI) prefixes that are typically used by virtual machines.

Figure 12. The OUI prefixes being checked by HavanaCrypt

Range or prefix	Product
00:05:69	VMware ESX and VMware GSX Server
00:0C:29	Standalone VMware vSphere, VMware Workstation, and VMware Horizon
00:1C:14	VMWare
00:50:56	VMware vSphere, VMware Workstation, and VMware ESX Server
08:00:27	Oracle VirtualBox 5.2

Table 1. Virtual machines’ OUI ranges or prefixes

After verifying that the victim machine is not running in a virtual machine, HavanaCrypt downloads a file named “2.txt” from 20[.]227[.]128[.]33, a Microsoft web hosting service IP address, and saves it as a batch (.bat) file with a file name containing between 20 and 25 random characters.

Figure 13. The details of the Microsoft web hosting service IP address

(Image source: AbuseIPDB)

It then proceeds to execute the batch file using cmd.exe with a “/c start” parameter. The batch file contains commands that are used to configure Windows Defender scan preferences to allow any detected threat in the “%Windows%” and “%User%” directories.

Figure 14. The function that contains the downloading and execution of the batch file

Figure 15. The Base64-encoded 2.txt file as seen on the Microsoft web hosting service IP address

Figure 16. The decoded batch file downloaded from the Microsoft web hosting service IP address

HavanaCrypt also terminates certain processes that are found running in the machine:

agntsvc
axlbridge
ccevtmgr
ccsetmgr
contoso1
culserver
culture
dbeng50
dbeng8
dbsnmp
dbsrv12
defwatch
encsvc
excel
fdlauncher
firefoxconfig
httpd
infopath
isqlplussvc
msaccess
msdtc
msdtsrvr
msftesql
msmdsrv
mspub
mssql
mssqlserver
mydesktopqos
mydesktopservice
mysqld
mysqld-nt
mysqld-opt
ocautoupds
ocomm
ocssd
onenote
oracle
outlook
powerpnt
qbcfmonitorservice
qbdbmgr
qbidpservice
qbupdate
qbw32
quickboooks.fcs
ragui
rtvscan
savroam
sqbcoreservice
sqladhlp
sqlagent
sqlbrowser
sqlserv
sqlserveragent
sqlservr
sqlwriter
steam
supervise
synctime
tbirdconfig
thebat
thebat64
thunderbird
tomcat6
vds
visio
vmware-converter
vmware-usbarbitator64
winword
word
wordpad
wrapper
wxserver
wxserverview
xfssvccon
zhudongfangyu
zhundongfangyu

Figure 17. The processes that HavanaCrypt terminates

It should be noted that this list includes processes that are part of database-related applications, such as Microsoft SQL Server and MySQL. Desktop apps such as Microsoft Office and Steam are also terminated.

After it terminates all relevant processes, HavanaCrypt queries all available disk drives and proceeds to delete the shadow copies and resize the maximum amount of storage space to 401 MB.

Figure 18. HavanaCrypt deleting shadow copies and resizing the maximum storage space of available drives to 401 MB

It also checks for system restore instances via Windows Management Instrumentation (WMI) and proceeds to delete them by using the SRRemoveRestorePoint function.

Figure 19. HavanaCrypt deleting system restore instances via WMI

It then drops copies of itself in the %ProgramData% and %StartUp% folders in the form of executable (.exe) files with different file names containing between 10 and 15 random characters. Their attributes are then set to “Hidden” and “System File.”

Figure 20. HavanaCrypt dropping copies of itself in the %ProgramData% and %StartUp% folders

Figure 21. HavanaCrypt setting the dropped files as “Hidden” and “System File”

HavanaCrypt also drops a file named “vallo.bat” onto %User Startup%, which contains functions that can disable the Task Manager.

Figure 22. HavanaCrypt dropping vallo.bat onto %User Startup%

Figure 23. The content of vallo.bat

Gathering of machine information

HavanaCrypt uses the QueueUserWorkItem function to implement thread pooling for its other payloads and encryption threads. This function is used to execute a task when a thread pool becomes available.

Figure 24. The QueueUserWorkItem function as it is used by HavanaCrypt

It also uses the DebuggerStepThrough attribute, which causes it to step through the code during debugging instead of stepping into it. This attribute must be removed before one can analyse the function inside.

Figure 25. The DebuggerStepThrough attribute as it is used by HavanaCrypt

Before it proceeds with its encryption routine, HavanaCrypt gathers certain pieces of information and sends them to its C&C server, 20[.]227[.]128[.]33/index.php. These are the unique identifier (UID) and the token and date.

UID

The UID contains the machine’s system fingerprint. HavanaCrypt gathers pieces of machine information and combines them, by appending one to another, before converting the information into its SHA-256 hash in the format:

[{Number of Cores}{ProcessorID}{Name}{SocketDesignation}] BIOS Information [{Manufacturer}{BIOS Name}{Version}] Baseboard Information [{Name}]

Figure 26. The function used by HavanaCrypt to gather machine information

Figure 27. HavanaCrypt converting its gathered machine information into a SHA-256 hash

The pieces of machine information that HavanaCrypt gathers include:

The number of processor cores
The processor ID
The processor name
The socket designation
The motherboard manufacturer
The motherboard name
The BIOS version
The product number

Token and date

HavanaCrypt replaces the string “index.php” with “ham.php” to send a GET request to its C&C server (hxxp[:]//20[.]227[.]128[.]33/ham.php) using “Havana/1.0” as the user agent.

Figure 28. The function used by HavanaCrypt to send a GET request to its C&C server

Figure 29. The response from 20[.]227[.]128[.]33/ham.php that we obtained via Fiddler, a web application debugging tool

HavanaCrypt decodes the response from ham.php in Base64 and decrypts it via the AES decryption algorithm using these parameters:

Aes.key: d8045c7174c2649e96e68a01a5d77f7dec4846ebebb7ed04fa8b1325c14d84b0 (SHA-256 of “HOLAKiiaa##~~@#!2100”)
Aes.IV: consists of 16 sets of 00 bytes

HavanaCrypt then stores the output in two different arrays with “–” as their delimiter. The first array is used as the token, while the second is used as the date.

Figure 30. The initialisation of parameters to be used by HavanaCrypt in AES decryption

Figure 31. Decryption by HavanaCrypt via AES

Using CyberChef, a web app that provides operations such as encoding and encryption, we replicated HavanaCrypt’s decryption routine using the response from 20[.]227[.]128[.]33/ham.php:

Output: d388ed2139d0703b7c2a810b09e513652eb9402c92304addd34679e21a826537-1655449622
Token: d388ed2139d0703b7c2a810b09e513652eb9402c92304addd34679e21a826537
Date: 1655449622

Figure 32. Our replication of HavanaCrypt’s decryption routine using the CyberChef app

After gathering all the necessary machine information, HavanaCrypt sends it via a POST request to hxxp://20[.]227[.]128[.]33/index.php using “Havana/1.0” as the user agent.

Figure 33. HavanaCrypt’s POST request to hxxp[:]20[.]227[.]128[.]33/index[.]php that we obtained using Fiddler

If the request is successful, HavanaCrypt receives a response that contains the encryption key, the secret key, and other details.

Figure 34. The response from hxxp[:]20[.]227[.]128[.]33/index[.]php that we obtained using Fiddler

HavanaCrypt checks whether hava.info is already present in “%AppDataLocal%/Google/Google Software Update/1.0.0.0”. If it does not find the file, it drops the hava.info file, which contains the RSA key generated by HavanaCrypt using the RSACryptoServiceProvider function.

Figure 35. The contents of hava.info that we obtained using HIEW, a console hex editor

Figure 36. HavanaCrypt’s generation of an RSA key using the RSACryptoServiceProvider function

Encryption routine

We have observed that HavanaCrypt uses KeePass Password Safe modules during its encryption routine. In particular, it uses the CryptoRandom function to generate random keys needed for encryption. The similarity between the function used by HavanaCrypt and the KeePass Password Safe module from GitHub is evident.

Figure 37. The functions used by HavanaCrypt in generating random bytes

Figure 38. A snippet of KeePass Password Safe’s code from GitHub

HavanaCrypt encrypts files and appends “.Havana” as a file name extension.

Figure 39. HavanaCrypt’s encryption routine

It avoids encrypting files with certain extensions, including files that already have the appended “.Havana” extension.

Figure 40. The function used by HavanaCrypt to avoid certain file name extensions

Figure 41. The file name extensions files of which HavanaCrypt avoids encrypting

HavanaCrypt also avoids encrypting files found in certain directories.

Figure 42. The directories in which HavanaCrypt avoids encrypting files

Figure 43. The function used by HavanaCrypt to avoid certain directories

Figure 44. Some files encrypted by HavanaCrypt

During encryption, HavanaCrypt creates a text file called “foo.txt”, which logs all the directories containing the encrypted files.

Figure 45. The foo.txt text file that contains logs of directories that contain encrypted files

Conclusion and Trend Micro solutions

The HavanaCrypt ransomware’s disguising itself as a Google Software Update application is meant to trick potential victims into executing the malicious binary. The malware also implements many antivirtualization techniques by checking for processes, files, and services related to virtual machine applications.

It is uncommon for ransomware to use a C&C server that is part of Microsoft web hosting services and is possibly used as a web hosting service to avoid detection. Aside from its unusual C&C server, HavanaCrypt also uses KeePass Password Safe’s legitimate modules during its encryption phase.

It is highly possible that the ransomware’s author is planning to communicate via the Tor browser, because Tor’s is amongst the directories that it avoids encrypting files in. It should be noted that HavanaCrypt also encrypts the text file foo.txt and does not drop a ransom note. This might be an indication that HavanaCrypt is still in its development phase. Nevertheless, it is important to detect and block it before it evolves further and does even more damage.

Organisations and users can benefit from having the following multilayered defence solutions that can detect ransomware threats before operators can launch their attacks:

Trend Micro Vision One™ provides multilayered protection and behaviour detection, which helps block questionable behaviour and tools early on, before the ransomware can do irreversible damage to the system.
Trend Micro Apex One™ offers next-level automated threat detection and response against advanced concerns such as fileless threats and ransomware, ensuring the protection of endpoints.

Additional insights by Nathaniel Gregory Ragasa

Indicators of compromise

Files

SHA-256	Detection name	Description
b37761715d5a2405a3fa75abccaf6bb15b7298673aaad91a158725be3c518a87	Ransom.MSIL.HAVANACRYPT.THFACBB	Obfuscated HAVANACRYPT ransomware
bf58fae4f2c96061b8b01e0f077e0e891871ff22cf2bc4972adfa51b098abb8e0	Ransom.MSIL.HAVANACRYPT.THFACBB	Deobfuscated HAVANACRYPT ransomware
aa75211344aa7f86d7d0fad87868e36b33db1c46958b5aa8f26abefbad30ba17	Ransom.MSIL.HAVANACRYPT.THFBABB	Deobfuscated HAVANACRYPT ransomware

URLs

http://20[.]227[.]128[.]33/2.txt

http://20[.]227[.]128[.]33/index.php

http://20[.]227[.]128[.]33/ham.php

Brand-New HavanaCrypt Ransomware Poses as Google Software Update App, Uses Microsoft Hosting Service IP Address as C&C Server

Arrival

Antivirtualization

Gathering of machine information

UID

Token and date

Encryption routine

Conclusion and Trend Micro solutions

Indicators of compromise

Authors

Resources

Support

About Trend

Resources

Support

About Trend

The Americas

Middle East & Africa

Europe

Asia & Pacific