Following on from our last blog post, where we covered off proof of concept code for the HAFNIUM linked Exchange server intrusions. We are now diving deeper into DearCry, a new strain of ransomware that several threat actor groups are deploying.
Reports are mixed about tactics, techniques, and if UK companies are currently targeted, or if DearCry is something to worry about. Threat actors follow the money and the path of least resistance to monetise an attack. We know there are exposed Exchange servers in the UK address space, and not everyone has been able to patch yet.
We covered off Exchange server vulnerability mitigation on LinkedIn last week. Now it is time to step up the use of automation and deploy additional custom detection rules using Microsoft Defender for Endpoint.
Microsoft reported ransomware was being deployed after the initial compromise of servers. Microsoft’s named the ransomware – Ransom:Win32/DoejoCrypt.A – ‘DearCry’.
Thousands of publicly exposed web shells, placed by HAFNIUM, are being used to deploy ransomware.
A web shell is a malicious web-based shell-like interface that enables remote access and control to a web server by allowing execution of arbitrary commands.
Why do this? It saves effort by leveraging existing compromised servers with HAFNIUM web shells and using them as a foothold into networks. It is a lot easier to scan the internet (reconnaissance), find one of the thousands of exposed Exchange servers, gain access to the web shell, then move to a hands-on keyboard attack to move laterally within the environment, exfiltrate sensitive data, and deploy ransomware. This is a much faster path to profit as it saves the first step of initial compromise of your victim.
What have we observed?
Tiberium Cyber Defenders have analysed three samples (1,2,3) of DearCry that have been submitted to Virus Total. A key observation is the modification of a service called “msupdate”, this is not new technique and has been used as far back as 2012 by DeepPanda.
The ransomware samples uploaded to VirusTotal are MingW-compiled executables. Upon execution, DearCry attempts to shut down the “msupdate” Windows service. The ransomware uses a combination of AES-256 and RSA-2048 encryption algorithms. From there, the ransomware begins to encrypt files individually and appends them with the “.CRYPT” extension. Once the encryption is done, DearCry displays a ransom note, named “readme.txt,” that supplies instructions on how to reach out to the ransomware operators.
What can we do to prevent, detect, and react to DearCry?
Prevention requires patching and removing any web shells from your Exchange servers. A number of scripts exist to find them but we recommend this one (although heads up that Defender is now detecting this as a web shell!)
Detection “should” be taken care of by your endpoint security tool. But not all are up to scratch and if the threat actors up their level of sophistication they may incorporate AV bypass techniques or more likely simply disable detection tooling! To prevent this in your environment where Microsoft Defender is deployed, we strongly recommend enabling Tamper Protection.
Leveraging the power of Azure Sentinel and Microsoft Defender, we can create custom rules to detect the initial stages of DearCry deployment by monitoring for the “msupdate” service creation.
The following is rough and quick custom detection that can be seen as a “back stop” or “last chance detection”.
In theory, Microsoft Defender detects DearCry as “Ransom:Win32/DoejoCrypt.A – ‘DearCry’” but, if the threat actors change their variant so that it bypasses detection, we can still detect based on their techniques instead. Or, if you do not have tamper protection enabled it is possible the threat actor may disable your anti-virus entirely. We also realise techniques could change, do this rule should be seen as a short-term detection to give visibility until you are able to patch.
Deploying custom detection in Microsoft Defender
DeviceEvents | where ActionType == "ServiceInstalled" | where AdditionalFields contains "msupdate"
Run the query for the past 7 days. If you get any results, investigate further immediately.
Select “Create Detection Rule” and follow through the configuration steps.
Detection Name: DearCry Service install attempt Frequency: Every Hour Alert Title: DearCry service install attempt Severity: High Category: Ransomware Description: Detects the creation of a new service called "msupdate" which is known to be used by DearCry threat actions leveraging left over HAFNIUM web shells on compromised Exchange servers
Save your rule and review the summary to ensure everything is correct.
Now, the most important part! Automation to do something like this…an actual response, fast.
We recommend the following automated actions to isolate impacted devices, run a full scan, collect an investigation package, and mark the user as compromised.
Note, this is a very restrictive response and will fully lock down a machine and user if the “msupdate” service is detected.
We suggest testing this on a small number of test or dev servers first. Automated actions are very powerful, and Microsoft Defender has immense and much needed capabilities here.
Often this is used during incident response engagement when you have a high-fidelity IOC (Indicators of Compromise) or known hash that if found confirms a user or device is compromised. You can create custom detection rules to quickly assess the scale of impact within your entire environment, and do something about it to stop malware in its track or cut off a threat actor (but beware of forcing their hand to more stealthy techniques).
What about Azure Sentinel?
For HAFNIUM we already covered this off in earlier LinkedIn posts. But, if you do not have Microsoft Defender installed and do have Azure Sentinel you can use the following KQL (Kusto Query Language) to create a detection rule for service creation, you can then enable a playbook to auto trigger blocking a user in AAD (Azure Active Directory) and responding that way. Drop me a message on LinkedIn if you need help deploying it.
SecurityEvent | where EventID == "4697" | where ServiceName =~ "msupdate"
Windows Event ID requires your Azure Sentinel “Security Event” connector to be set to “All Events” or “Common” as shown below. If set to “Minimal” you will not receive this event and your rule will not trigger.
Summary and IOC
Patch your Exchange servers, if that is not practical configure these mitigations, deploy Microsoft Defender for EndPoint, check your Azure Sentinel logs, and finally as a last resort deploy our custom DearCry detection rule in Defender.
Load the following IOC into your current endpoint solution to prevent and block DearCry.
If you need help with any deployment, investigation, or immediate incident response services please do get in touch.