Atrás 
Summary
While many organizations are patching the two recent Apache Log4j vulnerabilities (CVE-2021-44228 and CVE-2021-45046), attackers have been racing to exploit them to deliver malware, such as botnets, backdoors, and cryptominers.
Among the threats delivered using Log4Shell exploits, a new ransomware family was found by Bitdefender: Khonsari. For now, only a Windows version of the malware was found, first spotted on December 11th, where attackers were using the CVE-2021-44228 vulnerability to deliver the executable. Microsoft has also spotted a few cases where Khonsari was being launched from compromised Minecraft clients.
At this point, Khonsari appears to be an individual effort, not working in the popular Ransomware-as-a-Service (RaaS) model, used by REvil, LockBit, BlackMatter, and Hive.
Log4Shell
The first file involved in the attack was named “Main.class”, which is a Java downloader being delivered through Log4Shell.
The Java file is a simple downloader, and two days after Khonsari was first spotted, December 13th, the attackers changed the “Main.class” file to deliver another malware known as Orcus RAT.
Khonsari Ransomware
The ransomware was developed in .NET, where the attacker has manipulated the compiled time date stamp to 46 years in the future.
The malware developer has used minor obfuscation to hide some classes, functions, and variable names.
All the strings used by the ransomware are encrypted, using a quite simple rolling XOR algorithm, which can be represented by the following Python code:
As soon as it runs, Khonsari sends a network request to an external server.
This is probably just for metrics, as no data is sent or received in this process. Also, we noticed that the process crashes if the URL doesn’t respond, meaning that this URL can be added to blocklists to prevent the ransomware execution.
After the network request, Khonsari enumerates all available drives that are different from “C:\”. Then, it creates a list containing the directories that will be encrypted, such as Downloads, Desktop, Videos, Pictures, etc.
With all the directories enumerated, Khonsari starts the encryption process (each step listed is highlighted in the figure below):
- Iterating over the files in each directory;
- Reading and encrypting the file contents;
- Renaming the file to add the “khonsari” extension;
- Once the loop is done, it creates the ransom note, opening it automatically.
Throughout this process, Khonsari also checks the file extension before encrypting it. In the binary we analyzed, it skips the encryption if the file ends with “.khonsari”, “.ini”, and “ink”.
The last one seems to be a typo, as the developer probably wanted to skip “.lnk” files. However, this one encrypts links anyway, as the string checked by the code is “ink”.
For encryption, Khonsari uses AES 128 to encrypt the files, and RSA to encrypt the keys. This is how the flow works:
- The AES key and IV is generated once Khonsari runs;
- AES is then used to encrypt all the files, using both the key and IV previously generated;
- Khonsari encrypts both AES key and IV using a public RSA key hardcoded in the binary;
- The encrypted key and IV are then encoded with base64 and stored within the ransom note.
Once done, Khonsari creates the ransom note with the instructions along with the information to recover the files (e