Following the DearCry ransomware attacks reported on last week, another ransomware gang has also started to target vulnerable Exchange servers with another ransomware, called Black KingDom. Sophos telemetry began detecting the ransomware on Thursday March 18 as it targeted Exchange servers that remain unpatched against the ProxyLogon vulnerabilities disclosed by Microsoft earlier this month.
The Black KingDom ransomware is far from the most sophisticated payload we’ve seen. In fact, our early analysis reveals that it is somewhat rudimentary and amateurish in its composition, but it can still cause a great deal of damage. It may be related to a ransomware of the same name that appeared last year on machines that, at the time, were running a vulnerable version of the Pulse Secure VPN concentrator software.
Delivered through a webshell that was sent over Tor
The delivery of Black KingDom was orchestrated from a remote server with an IP address that geolocates to Germany, 185.220.101.204, while the attacker operated from 185.220.101.216. Unfortunately, because both IP addresses belong to a Tor exit node, it’s impossible to know where the attackers are physically located.
The threat actor exploited the on-premises versions of Microsoft Exchange Server, abusing the remote code execution (RCE) vulnerability also known as ProxyLogon (CVE-2021-27065).
After successfully breaching the Exchange server, the adversary delivered a webshell. This webshell offers remote access to the server and allows the execution of arbitrary commands.
The webshell ChackLogsPL.aspx was dropped here:
Other filenames of webshells we have observed being used by this adversary are ckPassPL.aspx and hackIdIO.aspx.
The webshell was written to disk by w3wp.exe, an Internet Information Server (IIS) Worker Process that hosts the Exchange admin center (EAC), which Microsoft has given the internal name ECP (Exchange Control Panel):
Ransomware execution and behavior
Following the deployment of the webshell, the attackers initiate the attack by issuing a PowerShell command (not shown here in its entirety due to size constraints):
This decodes to the following script (amended to enhance readability):
This script downloads the ransomware payload from:
hxxp://yuuuuu44[.]com/vpn-service/$(f1)/crunchyroll-vpn
The $(f1) part is generated by function f1, which generates a random string of 15 alphabet characters. So, ultimately, the exact web address looks something like this:
hxxp://yuuuuu44[.]com/vpn-service/ ojkgrctxslnbazd /crunchyroll-vpn
(As we went to press, the yuuuu44 domain was redirecting visitors to NASA.GOV)
The attackers store the ransomware payload in the \\[ComputerName]\c$\Windows\system32\ folder, with a random filename generated by that same function, f1. For example:
C:\Windows\System32\ojkgrctxslnbazd.exe
The script executes the ransomware by invoking Win32_Process via WMI, (the Windows Management Interface). The script includes the ability to upload the ransomware to other computers on the network and execute it.
Impact
The ransomware binary is based on a Python script that has been compiled into an executable using a tool called PyInstaller. With some effort we were able to decompile the binary back into its original source code, which helped us understand the ransomware’s functionality. The creator named the source code 0xfff.py, the “fff” of which represents a hexadecimal value for the decimal number 4095. What the significance of this is remains a mystery.
The ransomware has a built-in block list of folders the contents of which it will not encrypt:
It attempts to stop services running on the machine with SQL in the service name, effectively terminating databases, presumably so they may be encrypted as well:
The encryption key is generated with the following code:
In the gen_string function call, the script generates a random string of 64 characters in length. The script then hashes this value with MD5, and converts that hash to hexadecimal characters, and uses that as the encryption key.
It also generated a gen_id, which is a victim identifier the ransomware embeds into the ransom note as a way for victims to let the threat actor know who the victim is, so they can purchase the correct decryption key.
The key and gen_id are then uploaded to an account on mega.io. However, if for whatever reason the ransomware is unable to upload this randomly-generated encryption key to Mega, it has a fallback in the form of a hardcoded, static key:
The base64-encoded key represents this hexadecimal value: eebf143cf615ecbe2ede01527f8178b3
The file system behavior of the file encryption function is straightforward: Read (original) > Overwrite (encrypted) > Rename:
This translates into the following file system activity:
The code for renaming the now-encrypted files chooses a random string between 4 and 7 characters and appends that to the filename, so its suffix no longer maps to the application it’s supposed to:
To prevent encrypted files from being attacked twice, ransomware generally appends the same uniquely chosen file extension to every encrypted file or places an indicator in the file header (or at the end). However, the Black Kingdom ransomware targeting Exchange servers doesn’t do this. It does not check if a file or the machine has been hit before – either by itself or by another ransomware. As a result, the encrypted files can become encrypted multiple times over, even by the same ransomware, making decryption extremely complicated. This oversight is probably unintentional, but could have been anticipated.
Our CryptoGuard protection caught the ransomware attempting to encrypt data. Below, raw telemetry from our signature-agnostic technology shows the ransomware binary being executed via WMI as documented above (read the Process Trace sequence backwards, from 3 to 1):
To further complicate and hinder incident response, the ransomware deletes the Windows Event logs:
Once the system is encrypted (or after 20 minutes of work), the ransomware runs this subroutine that disables the mouse and keyboard, and draws a full screen window on top of the desktop.
This generates a full-screen window that looks like this, complete with countdown timer:
Alongside the encrypted data a ransom note is stored in a file named decrypt_file.TxT:
Here is a current overview of the transactions received by the attackers’ cryptocurrency wallet, according to BitRef. It seems at least one victim has paid the ransom demand and the attackers have already withdrawn the money from the wallet:
Detection guidance
Users of Sophos endpoint protection products may see the webshells detected as any of the long list of detections in this post, and the ransomware payload may be detected as Troj/Ransom-GFU, Troj/Ransom-GFV or Troj/Ransom-GFP or by the CryptoGuard feature within Intercept X. SophosLabs has published indicators of compromise to the SophosLabs Github. Threat hunters using Sophos EDR may also use the queries posted in this article to find additional indicators of compromise on their networks.
Acknowledgments
SophosLabs would like to acknowledge the contributions of Vikas Singh, Alex Vermaning and Gabor Szappanos to this report.
Leave a Reply