Sophos XG Firewall XG Firewall stops ransomware getting on, and moving around your network. Deep learning detects and blocks ransomware at the gateway, while lateral movement prevention and RDP management stop hackers progressing their attacks.

• Sophos Home’s malware detection technology makes use of highly evolved artificial intelligence with deep learning to catch not only known malware, but also never-before-seen threats. It also blocks malware execution, ensuring your system remains clean and uninfected.
• The main menu lists the functions available to you in Sophos Central. The Dashboard is the start page of Sophos Central and lets you see the most important information at a glance. Either in response to a detection or in advance of any detection. Stop detecting ransomware.

This is what happens when we detect ransomware and what to do about it.

If you know a detection is a false positive, see Deal with false positives.

When we detect ransomware:

• We check whether it's a legitimate application like a file/folder encryption product. If it isn't, we stop it running.
• Files are restored to their pre-modification state.
• The end user is notified.
• A threat case is generated. This helps you decide whether to take additional actions.
• A scan starts to identify and clean up any other malware on the device.
• The device's health state returns to Green.

What to do if you see “Ransomware detected”

If you still need to clean up, do as follows:

Sophos Anti Ransomware

• If automatic sample submission isn't enabled, send us a sample of the ransomware. We'll classify it and update our rules: if it's malicious, Sophos Central will block it in future.
• Move the computer temporarily to a network where it is not a risk to other computers. Go to the computer and run Sophos Clean (if it isn't installed, download it from our website).

  You can run Sophos Clean on a server from Sophos Central.

• Go to Sophos Central, go to Alerts, and mark the alert as resolved.

What to do if you see 'Remotely-run ransomware detected'

We detected ransomware running on a remote computer and trying to encrypt files on network shares.

We have blocked write access to the network shares from the remote computer's IP address. If the computer with that address is a workstation managed by Sophos Central, and Protect document files from ransomware (CryptoGuard) is enabled, we clean up the ransomware automatically.

You need to do as follows:

• Find the computer where the ransomware is running.
• If the computer is managed by Sophos Central, make sure that Protect document files from ransomware (CryptoGuard) is enabled in the policy.
• If cleanup doesn’t happen automatically: Move the computer to a network where it is not a risk to other computers. Then go to the computer and run Sophos Clean (if it isn't installed, download it from our website).
• Go to Sophos Central, go to Alerts, and mark the alert as resolved.

What to do if you see 'Ransomware attacking a remote machine detected'

We have detected that this computer is trying to encrypt files on other computers.

We have blocked the computer's write access to the network shares. If the computer is a workstation, and Protect document files from ransomware (CryptoGuard) is enabled, we clean up the ransomware automatically.

You need to do as follows:

• Make sure that Protect document files from ransomware (CryptoGuard) is enabled in the Sophos Central policy. This provides more information.
• If cleanup doesn’t happen automatically: Move the computer to a network where it is not a risk to other computers. Then go to the computer and run Sophos Clean (if it isn't installed, download it from our website).
• Go to Sophos Central, go to Alerts, and mark the alert as resolved.

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:

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.

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.

Sophos Malware Detection

Acknowledgments

SophosLabs would like to acknowledge the contributions of Vikas Singh, Alex Vermaning and Gabor Szappanos to this report.