What No Beer? COVID-19 and Ransomware To Blaim?

What No Beer? COVID-19 and Ransomware To Blame?

Almost all of us have had the thought, … “If I do this, will I get caught?”, and for many, if the answer is “No”, we would probably have done a few things differently. But we are always brought back from the brink, and where we know if we are caught doing something bad, we are likely to end up in trouble. But there’s one crime which is almost perfect, and the chance of it paying back is extremely high, and the chances of getting caught are extremely low. And that is … ransomware.

If you have no back-ups, once your files are encrypted with a key, you have very little chance of getting them back. Here is a typical process, and where each file is taken, and then encrypted with AES (using GCM mode — to make things faster), and then where the key used is encrypted with the public key for the adversary (Eve):

But, you say, who cares? Well, at the most extreme case, the ransomware could cost lives, especially in a health care environment. And in Australia this week, the Lion brewer — one of the largest beer suppliers in Australia and New Zealand — was attacked with ransomware:

Our investigations to date have shown that a system outage has been caused by ransomware. The ransomware targeted our computer systems. In response, we immediately shut down key systems as a precaution.

So while they have been able to continue their supply chain within the COVID-19 pandemic, it is ransomware which has stopped their production from restarting. Along with this Lion’s production lines for dairy items has also been halted.

Recent ransomware

So let’s take a look at a recent ransomware threat.

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:

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 compiled 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 encryption 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 /quietwmic shadowcopy deletebcdedit /set {default} bootstatuspolicy ignoreallfailuresbcdedit /set {default} recoveryenabled nowbadmin delete catalog -quietnetsh advfirewall set currentprofile state offnetsh firewall set opmode mode=disable

The intruders need 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 reveals the UUID (red), the 256-bit AES key (green) and a 512-bit SHA hash (blue).

Conclusions

What no beer?