Threat Spotlight: Tycoon Ransomware Targets Education and Software Sectors

Overview

Tycoon is a multi-platform Java ransomware targeting Windows® and Linux® that has been observed in-the-wild since at least December 2019^[1]. It is deployed in the form of a Trojanized Java Runtime Environment (JRE) and leverages an obscure Java image format to fly under the radar.

The threat actors behind Tycoon were observed using highly targeted delivery mechanisms to infiltrate small to medium sized companies and institutions in education and software industries, where they would proceed to encrypt file servers and demand a ransom. However, due to the reuse of a common RSA private key it may be possible to recover data without the need for payment in earlier variants.

Delivery

The BlackBerry Research and Intelligence Team in partnership with KPMG’s UK Cyber Response Services recently unearthed a new ransomware strain written in Java. The ransomware was deployed in a targeted attack against an organization, where the system administrators had been locked out of their systems following an attack on their domain controller and file servers. After conducting forensic investigations of the infected systems, it became apparent that the initial intrusion occurred via an Internet-facing RDP jump-server.

The following illustration demonstrates how the attackers managed to gain initial access and started infecting systems across the estate:

Figure 1: Attack timeline

Post-incident analysis of the Internet-facing RDP server could not be performed as it had already been restored. However, our analysis of the victim machines revealed that some of the techniques used by the attacker were unusual and noteworthy:

• To achieve persistence on the victim’s machine, the attackers had used a technique called Image File Execution Options (IFEO) injection^[2]. IFEO settings are stored in the Windows registry. These settings give developers an option to debug their software through the attachment of a debugging application during the execution of a target application.
  
  
• A backdoor was then executed alongside the Microsoft Windows On-Screen Keyboard (OSK) feature of the operating system:
   

Figure 2: Registry key used to execute the backdoor

• The attackers disabled the organization’s anti-malware solution with the use of the ProcessHacker utility and changed the passwords for Active Directory servers. This leaves the victim unable to access their systems.
  
  
• Most of the attacker files were timestomped, including the Java libraries and the execution script, and had file date timestamps of 11th April 2020, 15:16:22:
   

Figure 3: File timestamp

Finally, the attackers executed the Java ransomware module, encrypting all file servers including backup systems that were connected to the network.

Execution

Tycoon ransomware comes in form of a ZIP archive containing a Trojanized Java Runtime Environment (JRE) build. The malware is compiled into a Java image file (JIMAGE) located at lib\modules within the build directory.

JIMAGE is a special file format that stores custom JRE images which is designed to be used by the Java Virtual Machine (JVM) at runtime. It encompasses resources and class files of all Java modules that support the specific JRE build. The format was first introduced in Java version 9 and is sparsely documented. Unlike the popular Java Archive format (JAR), JIMAGE is mostly internal to the JDK and rarely used by developers:
 

Figure 4: Malicious “modules” file; JIMAGE format uses a header starting with 0xDADAFECA signature

The OpenJDK9 jimage utility can extract and decompile Java image files:

After extraction, the ransomware image contains three modules related to a project called "tycoon":

Figure 5: Contents of the ZIP archive (left) and structure of the decompiled Java modules JIMAGE (right)

The ransomware is triggered by executing a shell script that runs the Main function of the malicious Java module using the java -m command.

The malicious JRE build contains both Windows® and Linux® versions of this script, suggesting that the threat actors are also targeting Linux® servers:
 

Figure 6: Shell scripts used to execute the ransomware, and Java “release” file

Configuration

The malware configuration is stored in the project’s BuildConfig file and includes information such as:

• The attacker’s email address
• The RSA public key
• The content of the ransom note
• The exclusions list
• The list of shell commands to be executed
   

Figure 7: Example configuration values
 

Figure 8: A fragment of BuildConfig file

Behavior

Upon execution the malware will run a set of shell commands specified in the BuildConfig file:
 

An install_id value will be generated for each victim using the first four bytes from a SHA256 hash of the system UUID value. To obtain the UUID the malware executes the following wmic command:

The list of paths to encrypt can be passed as parameter; alternatively, the malware will generate a list of all root paths in the system. A separate encryption thread will be created for each item in the path list.

After the encryption process is completed, the malware will ensure that the files are not recoverable by overwriting deleted files in each encryption path. It uses an embedded Windows utility called cipher.exe for this task:

Figure 9: Secure deletion of original files

File Encryption

The files are encrypted using an AES-256 algorithm in Galois/Counter (GCM) mode^[3] with a 16-byte long GCM authentication tag, which ensures data integrity. A 12-byte long initialization vector (IV) is generated for each encryption chunk using the java.security.SecureRandom function. The encryption chunk size is specified in BuildConfig and is set to 10 MB while a pattern setting specifies the pattern in which file chunks are to be processed. By skipping parts of the bigger files, the attackers speed up the encryption process while damaging the files and making them unusable.

For each encryption path, an array of AES-256 keys is generated using java.security.Secure.Random function. The maximum number of keys per path is set in BuildConfig and may differ between samples. Each file (or file chunk, in case of files bigger than the chunk size) is encrypted with a different AES key, then encrypted with the attacker’s RSA-1024 public key and saved in the chunk metadata block:
 

Figure 10: AES key generation

The metadata added to each encrypted chunk contains the following:

• Header value specified in BuildConfig
• Chunk index (8 bytes)
• Chunk size (8 bytes)
• Per-chunk generated AES IV (12 bytes)
• AES GCM tag (16 bytes)
• RSA-encrypted AES key scheme (128 bytes), containing:
     o   Victim ID (4 bytes)
     o   AES key (32 bytes)
     o   SHA512 hash of victim ID and AES key (64 bytes)
   

Figure 11: Encrypted file with highlighted metadata

Because of the use of asymmetric RSA algorithm to encrypt the securely generated AES keys, the file decryption requires obtaining the attacker's private RSA key. Factoring a 1024-bit RSA key, although theoretically possible, has not been achieved yet and would require extraordinary computational power.

However, one of the victims seeking help on the BleepingComputer forum^[4] posted a private RSA key presumably coming from a decryptor the victim purchased from the attackers. This key has proven to be successful in decryption of some of the files affected by the earliest version of Tycoon ransomware that added the .redrum extension to the encrypted files:
 

Figure 13: Recovering a .redrum file with the use of decrypted AES key

Unfortunately, it doesn't work for the more recent “happyny3.1” version that adds the .grinch and .thanos extensions to the encrypted files.

Conclusions

Malware writers are constantly seeking new ways of flying under the radar. They are slowly moving away from conventional obfuscation and shifting towards uncommon programming languages and obscure data formats. We have already seen a substantial increase in ransomware written in languages such as Java and Go. This is the first sample we've encountered that specifically abuses the Java JIMAGE format to create a custom malicious JRE build.

Tycoon has been in the wild for at least six months, but there seems to be a limited number of victims. This suggests the malware may be highly targeted. It may also be a part of a wider campaign using several different ransomware solutions, depending on what is perceived more successful in specific environments.

The overlap in some of the email addresses, as well as the text of the ransom note and the naming convention used for encrypted files, suggests a connection between Tycoon and Dharma/CrySIS ransomware.

Indicators of Compromise (IOCs)

JIMAGE module (lib\modules):
eddc43ee369594ac8b0a8a0eab6960dba8d58c0b499a51a717667f05572617fb

Email Addresses:

• pay4dec[at]cock[.]lu
• dataissafe[at]protonmail[.]com
• dataissafe[at]mail[.]com
• foxbit[at]tutanota[.]com
• moncler[at]tutamail[.]com
• moncler[at]cock[.]li
• relaxmate[at]protonmail[.]com
• crocodelux[at]mail[.]ru
• savecopy[at]cock[.]li
• bazooka[at]cock[.]li
• funtik[at]tutamail[.]com
• proff-mariarti[at]protonmail[.]com

Encrypted Files Extension:

• thanos
• grinch
• redrum

Encrypted Files Signature:

• happyny3.1
• redrum3_0

RSA Public Key (happyny3.1 version):

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDa+whJSxr9ngcD1T5GmjDNSUEY
gz5esbymvy4lE9g2M3PvVc9iLw9Ybe+NMqJwHB8FYCTled48mXQmCvRH2Vw3lPkA
TrQ4zbVx0fgEsoxekqtb3GbK2NseXEeavCi5lo5/jXZi4Td7nlWTu27CluyxRSgv
L0O19CwzvckTM91BKwIDAQAB

-----END PUBLIC KEY-----

RSA Private Key (redrum3_0 version):

-----BEGIN RSA PRIVATE KEY-----

MIICXQIBAAKBgQCyNELzNaPcGBlt2YEARamc+a+uyM8/mRadrMLLQ9tuzkppvdWI
iM/LH+xATZUgByknwzaMtRQZi6R2pQ8nBG6DxNtdhla33L+njQLTW+7wo1tSaaJz
6Of0FvCUZNPZ0mF5OrJO+Z6ZfDxafcwv653Ii7aTwaKlhjFoZijBMrA43wIDAQAB
AoGAPJ+I0yJBX0OXiwY+W3BXdj5+5LANyS30QqmeDvZDtRtat0RMW0lnn0t53JpI
DABDoPJJIW8MqnAWAALA994LFhk9jUtJTUgwsViyKL/Q/dOCeBPJU3xyXNkqhmCN
ImP4v7DxjvWp1pomrIIRCW68GkbB+cSGyLAzUo+1KHVh6LECQQDdL26UsVNsNYTX
rfv6BZItGO1HJHYTiz0cI82n4woZY2fS2lpBDEvy3Rl8E4Y7F9tQby4odDLHi/9l
RCeoif45AkEAzkDsPGauMmWsPXAbXrjzq3/0+MWgh7Vd8Gpgn83QUYjTO2RxtE1n
zAYzTLrFFtM8zmCAubpKM1dyi4Xs7hlv1wJBAJD5ofV8NT3b5nKn61z5gdJlYEEd
OPeecDOdlBLS0a/KZCbkT/wK300UdrvI4FajUHDsLsj9QLtim8f4YDYsHKECQQCX
R40+XD3mnyZvRbv9hQDMyKSglyvAfimxvgSzEZ17QDVWubygd6nrPpz/6XnH3RYb
dTLVhysHb1uHtKpslWGvAkAf0kivk9miSFnVeoO1XZumRAwrhTh6Rxhkg6MJCLBP
ThoY7wYXmV9zNPo02xYTvZlyhwnWspz4Kx4LsUutWmBs

-----END RSA PRIVATE KEY-----

Ransom Note:

Citations:

^[1] https://www.bleepingcomputer.com/forums/t/709143/help-me-to-identify-ransomware-with-redrum-extension/
^[2] https://attack.mitre.org/techniques/T1183/
^[3] https://en.wikipedia.org/wiki/Galois/Counter_Mode
^[4] https://www.bleepingcomputer.com/forums/t/709143/help-me-to-identify-ransomware-with-redrum-extension/page-2