LockFile Ransomware Compromises Microsoft Exchange via ProxyShell
Hackers Encrypt Windows Domains by Making Use of Known ProxyShell Flaws.
A new malware that targets Microsoft Exchange servers and performs Windows domains encryption has been identified by security researchers. The LockFile ransomware takes advantage of the lately detected ProxyShell vulnerabilities.
About the LockFile Ransomware
According to BleepingComputer, a ransom note related to LockFile ransomware emerged in July. Its name has been identified as ‘LOCKFILE-README.hta’. However, it lacked any distinctive marking. The ransomware gang changed their method starting last week when they began making use of a ransom note with a logo, as stated in the reports received by the publication. Therefore, the gang calls itself LockFile.
‘[victim_name]-LOCKFILE-README.hta‘ is the naming convention that cybercriminals adopt in these particular ransom notes. The goal of these notes is to determine the affected person to engage in a ransom negotiation. How? Via Tox or email. The gang uses the following e-mail address: firstname.lastname@example.org
The ransom note indicates similarities in color style and regarding the name of the e-mail address with Conti ransomware. Nonetheless, following its methods and writing style, there is no confirmation that it’s the same operation.
It does not only shows a resemblance to Conti but also to LockBit ransomware.
The new LockFile ransomware uses a .lockfile extension that is added to the name of the encrypted files.
Michael Gillespie and BleepingComputer investigated the LockFile July variant and discovered that this caused computers to freeze and also compromised system resources.
How does this use the ProxyShell vulnerabilities? As per Symantec, the ProxySheel bugs are used by cybercriminals to get access to the on-premise server of Microsoft Exchange. Then, they take over the Windows domain by exploiting the PetitPotam flaw.
What Is ProxyShell?
ProxyShell is basically a set of 3 vulnerabilities classified CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207. The first two were patched in April by KB5001779, respectively KB5001779 and then the last in May by KB5003435. The exploitation of these vulnerabilities targets Microsoft Exchange that lets hackers perform remote code execution attacks.
These vulnerabilities were discovered by Orange Tsai, the principal researcher from Devcore, who demonstrated their effect at April’s Pwn2Own 2021 hacking contest. In order to do this, he took over a Microsoft Exchange server.
What’s the danger brought by these 3 vulnerabilities?
- Through them, hackers can skip ACL checks.
- Cybercriminals gain elevated privileges on Exchange PowerShell Backend.
CISA also declared that
An attacker exploiting these vulnerabilities could execute arbitrary code on a vulnerable machine.
These vulnerabilities were addressed by Microsoft and patched, but hackers went on with their malicious actions. By making use of these ProxyShell bugs, they scanned and breached Microsoft Exchange Servers. The successful exploitation of such a server led to web shells dropping. Why are these web shells useful? Using them, hackers can upload software and run them.
When the activity of dropping web shells was observed, Rich Warren communicated to BleepingComputer that the hackers’ goal was the deployment of a .NET backdoor. This had the task to download a malicious payload.
Another researcher shared his discoveries after that. By his name Kevin Beaumont, the expert determined that the ProxyShell vulnerabilities and Windows PetitPotam are the two means by which Lockfile ransomware leads its encryption tasks on Windows domains.
According to the same researcher, the following query can be used to establish if scans for ProxyShell flaws were performed on your Microsoft Exchange.
What Can Be Done Against LockFile Ransomware?
In order to mitigate the ProxyShell bugs, the installation of recent Microsoft Exchange updates is recommended.
In order to mitigate PetitPotam, a user can utilize either the 0patch’s patch, this being an unofficial remediation or the application of NETSH RPC filters could be useful. What the latter does is to prevent the access to MS-EFSRPC API’s sensitive functions.