Ransomware detections will trigger a clean up operation by default. To determine whether this has succeeded, open the Sophos UI on the affected computer, click on Events, and then check for the Event Threat cleaned up against the ransomware detection. If the ransomware is cleaned up. Abuse of legitimate tools. Adversaries are ramping up their abuse of otherwise legitimate tools to.
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, 184.108.40.206, while the attacker operated from 220.127.116.11. 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:
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:
(As we went to press, the yuuuu44 domain was redirecting visitors to NASA.GOV)
The attackers store the ransomware payload in the [ComputerName]c$Windowssystem32 folder, with a random filename generated by that same function, f1. For example:
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.
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:
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.
SophosLabs would like to acknowledge the contributions of Vikas Singh, Alex Vermaning and Gabor Szappanos to this report.
Editor’s note: This is one of a series of articles focused on the Conti ransomware family, which include a detailed analysis of a Conti attack, A Conti Ransomware Attack Day-By-Day, and a guide for what IT administrators can expect when Conti ransomware hits.
Sophos Malware Detection
For the past several months, both SophosLabs and the Sophos Rapid Response team have been collaborating on detection and behavioral analysis of a ransomware that emerged last year and has undergone rapid growth. The ransomware, which calls itself Conti, is delivered at the end of a series of Cobalt Strike/meterpreter payloads that use reflective DLL injection techniques to push the malware directly into memory.
Because the reflective loaders deliver the ransomware payload into memory, never writing the ransomware binary to the infected computer’s file system, the attackers eliminate a critical Achilles’ heel that affects most other ransomware families: There is no artifact of the ransomware left behind for even a diligent malware analyst to discover and study.
That isn’t to say there aren’t artifacts and components to look at. The threat actors involved in attacks using Conti have built a complex set of custom tooling designed not only to obfuscate the malware itself, when it gets delivered, but conceal the internet locations from which the attackers have been downloading it during attacks, and prevent researchers from obtaining a copy of the malware that way as well.
Two-stage loading process
The first stage of the Conti ransomware process involves a Cobalt Strike DLL, roughly 200kb in size, that allocates the memory space needed to decrypt and load meterpreter shellcode into system memory.
The shellcode, XORed in the DLL, unfurls itself into the reserved memory space, then contacts a command-and-control server to retrieve the next stage of the attack.
This C2 communication is distinctive for a number of reasons. First, the malware appears to be using a sample Cobalt Strike configuration script named trevor.profile, published on a public Github archive. The profile serves as a sort of homage to an incident in which security researchers attending a conference found an insect in a milkshake at a restaurant outside the conference center.
But it doesn’t appear that the Conti attackers have modified this sample script very much, which makes the C2 communication notable in two ways: The script designates certain characteristics used during this phase of the attack, including a User-Agent string (“Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko)“) that mimics that of a computer running Windows 7 but, distinctively, fails to identify the specific browser; and a static URI path (“/us/ky/louisville/312-s-fourth-st.html“) that includes the address of the infamous restaurant where the researcher discovered the bug in their shake.
Sophos Home Security
The initial connection to the C2 server is to a page named Menus.aspx on the server; That page delivers the next payload, which the first one loads into memory — another Cobalt Strike shellcode loader that contains the reflective DLL loader instructions.
If that works successfully, the malware then contacts the “312-s-fourth-st.html” page on the same C2 server. The attackers only trigger these chains of events during an active attack, placing the ransomware binary on the C2 server so that it can be retrieved by this process only while the attack is ongoing, and removing it immediately afterwards.
Elusive ransomware payloads
Because of the ephemeral nature of the placement of the ransomware payload, analysts had difficulty obtaining samples for research. But we were able to salvage some of the in-memory code from infected computers where the malware was still running.
The ransomware process is not particularly unique, but it does reveal the ransomware creator’s ongoing interest in thwarting analysis by security researchers.
The ransomware itself uses a relatively common anti-analysis technique sometimes referred to as “API-by-hash,” in which Conti uses hash values to call specific API functions; Conti has an added layer of encryption over the top of these hashes to futher complicate the work of a reverse engineer. The malware has to perform two cycles of decryption on itself in order to perform those functions.
Among the behavior observed by responders, the ransomware immediately begins a process of encrypting files while, at the same time, sequentially attempting to connect to other computers on the same network subnet, in order to spread to nearby machines, using the SMB port.
Conti’s developers have hardcoded the RSA public key the ransomware uses to perform its malicious encryption into the ransomware (files are encrypted using the AES-256 algorithm). This isn’t unusual; It means that it can begin encrypting files even if the malware is unable to contact its C2.
Unfortunately, that isn’t the only threat this ransomware poses to its targets: Conti ransomware has also adopted a “leaks” site like several other ransomware threat actor groups. The attackers spend some time on the target network and exfiltrate sensitive, proprietary information to the cloud (in recent attacks, the threat actors have used the cloud storage provider Mega).
Under a header labeled YOU SHOULD BE AWARE! , the ransom note threatens, “Just in case, if you try to ignore us. We’ve downloaded a pack of your internal data and are ready to publish it on out (sic) news website if you do not respond. So it will be better for both sides if you contact us as soon as possible.”
Conti ransomware, on its own, is unable to bypass the CryptoGuard feature of Sophos Intercept X; Our endpoint products may detect components of Conti under one or more of the following definitions: HPmal/Conti-B, Mem/Conti-B, Troj/Swrort-EZ, Troj/Ransom-GEM, or Mem/Meter-D. Network protection products like the Sophos XG firewall can also block the malicious C2 addresses to prevent the malware from retrieving its payloads and completing the infection process.
Indicators of compromise for malware samples examined in this research has been posted to the SophosLabs Github.