What Ransomware Written in Java?

You should all know that ransomware is typically written in JavaScript, ActionScript, C#, C++ and even Golang. But a new family of…

What Ransomware Written in Java?

You should all know that ransomware is typically written in JavaScript, ActionScript, C#, C++ and even Golang. But a new family of ransomware aims to get under the detection radar by porting itself to Java. It is named Tycoon, and appeared in December 2019. As it is a Java executable, it is able to run on a range of systems including Windows and Linux.

As with many ransomware attacks, the malware tries to get into the network through RDP (Remote Desktop Protocol), such as using stolen credentials. Once the intruder gains the administration credentials, they then disable the anti-virus software and plant a backdoor onto the network:

Attack vector [here]

Then, typically on Day 7, the intruder makes RDP connections to machines on the network, and disables the AV software, and runs the ransomware. The method used to gain persistance on a machine is: IEFO (Image File Execution Options) — and which is normally used by developers to debug their code. A backdoor is then placed in Microsoft Windows On-Screen Keyboard (OSK) feature:

Sustaining access [here]

The ransomware itself ports as a ZIP file and is complied into an executable format that is hardly ever used: Java image file (JIMAGE). This image file allows the ransomware to use a trojanized version of the Java Runtime Environment (JRE). Once executed the ransomware encrypts targeted files and changes their extension to .redrum, .grinch or .thanos. The Bitcoin-sourced fee for the encyption key then increases over time (10% increase per day):

And there’s an additional feature, where the intruder will decrypt a few sample files:

Once installed the ransomware package reads a configuration file with: the intruder’s email address; the RSA public key; ransom note details; file exclusions list and a list of shell commands to be executed.

Overall it uses a number of 256-bit AES GCM key to encrypt the files — and with a 96-bit IV. These keys are encrypted with the public key of the intruder, and where the associated private key would be required to recover them. If the files are greater than 10MB, they are then split into 10MB chunks (and then encrypted individually), as this speeds up the encryption process. Each files or chunks then has additional metadata which defines: the chunk index, the chunk size, the IV value, and an RSA encryption version of: the Victim ID and AES key.

One thing the malware needs to avoid is to crash the system. The malware thus stays away from executable programs such as those with an extension of “mui”, “exe”, “dll”, “lolz”, and from various folders, such as:“Windows”, “Boot”, “System Volume Information”, “Program Files\\Common Files\\Microsoft Shared” and “Users\\All Users”. Along with this is will avoid key system files such as : “bootmgr”, “BOOTSECT.BAK”, and “pagefile.sys”.

Once in, it then disables the shadow copy option and the firewall:

vssadmin delete shadows /all /quiet
wmic shadowcopy delete
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {default} recoveryenabled no
wbadmin delete catalog -quiet
netsh advfirewall set currentprofile state off
netsh firewall set opmode mode=disable

The intruders needs a unique identifier for the infected machine, and this is generated from the first four bytes of the SHA-256 hash of the system UUID, and uses this command to get the UUID:

wmic csproduct get UUID

Once the encrypted key data has been decrypted, the metadata reveal the UUID (red), the 256-bit AES key (green) and a 512-bit SHA hash (blue).

Conclusions

Intruders are finding smarter ways to get under the radar, and the usage of Java is just another way to outsmarting the defenders.