LockBit ransomware group is a malicious actor exceptionally active in the threat landscape. They were the most active group in 2022, in terms of claimed victims. LockBit relies on double extorsion to give more weight to their threat: on the one hand, encrypting the company’s data, and on the other hand, publishing the data online if the victim refuses to pay the ransom. In their 3rd version, they even leveraged a third extorsion technique in the form of DDoS attacks, as an added incentive to get the victim to pay the ransom.
Let’s have a closer look at an attack using LockBit’s affiliates modus operandi.
Disclaimer: For the purpose of this demonstration, remediation was not activated in order to identify all the steps that would trigger alerts and be detected by TEHTRIS XDR Platform. However, the threat would have been automatically stopped in the early stages of the attack chain.
Step 1: Initial access
The victim receives a phishing email that allows the threat actor to exploit the Follina vulnerability, known as CVE-2022-30190 (CVSSv3: 7.8), which was once a Microsoft RCE (remote control execution) 0day.
On the XDR Platform, two types of alerts are triggered:
- An alert on the known Follina exploit triggered by an Application Policy
- An alert on the suspect Spawn Tree, meaning that even if the exploit was still a 0-day, the process would have been detected (and potentially automatically suspended, depending on the configuration)
Note that if the correct settings are applied and remediation is activated, the attack would not have gone further than this first stage.
Step 2: Persistence
Once the attacker has gained access to a device, the next step is to maintain the foothold on the compromised system through a PowerShell backdoor execution. A heuristic alert is triggered on the TEHTRIS XDR (as well as automatic remediation depending on the configuration) on the malicious interactive PowerShell script.
Step 3: Privilege escalation
The following step is the tactic known as privilege escalation, where the adversary tries to gain higher-level permissions on the compromised system. In this scenario, the attacker abuses msiexec.exe, a component of Windows Installer, which triggers an alert based on an Application Policy configured beforehand on the suspicious use of msiexec.exe.
Step 4: Credential access
Then, the attacker tries to gain credential access stored in the process memory of the LSASS (Local Security Subsystem Service). LSASS process memory can be dumped from the target host and analyzed on a local system: this is the technique LSASS password dump, known as T1003.001 on the MITRE ATT&CK framework. However, an alert is immediately raised due to a forbidden LSASS access form an unsigned binary.
In a real-life set-up, and after an observation phase to avoid harming the systems, it would be relevant to implement a rule to automatically kill unsigned binaries that access LSASS.
Step 5: Impact
To increase the chances of being paid, the ransomware actor needs to make sure that the target won’t be able to recover their own data without the decryptor. To do so, the attacker deletes shadow copies to prevent recovery using Windows backup. An alert on the command to delete shadow copies is automatically triggered thanks to an Application Policy monitoring Windows Processes.
Note that TEHTRIS EDR will retrieve event logs from a workstation (and TEHTRIS SIEM will do so for servers) so that event logs remain available for analysis in case of the deletion of shadow copies.
Step 6: Defense evasion
The attacker attempts to evade detection using the following techniques:
- Impairing defenses, more specifically by disabling security tools (here, TEHTRIS EDR using third-party tool ProcessHacker.exe), which triggered two alerts. The first one is based on a high antivirus score for ProcessHacker.exe, the second one is an alert triggered by an Application Policy monitoring the technique.
- Removing indicators to avoid leaving traces and remove evidence of the attacker’s presence, which might cause events to go unreported or prevent complete forensic analysis. In this case, the attacker clears event logs abusing wevtutil.exe. An Application Policy raises an alert on the suspicious use of wevtutil.exe and identifies the commands as an attempt to remove indicators, giving maximum clarity to the analyst. Moreover, clearing event logs triggers an Event Log alert from the EDR and the SIEM.
Step 7: Data exfiltration
In the context of a double extorsion attack, important data must be exfiltrated from the targeted network as an incentive to get the victim to pay the ransom. To do so, the attacker uses rar.exe to compress data and exfiltrate it towards a server under their control.
Two alerts are triggered thanks to adequate Application Policies: one on the use of utility to compress archive data (identified as technique T1560.001 in MITRE’s ATT&CK framework), the other on the execution of a malicious link connecting to the C2 server.
Note that in the case of an attacker contacting a domain name to access the C2 server, TEHTRIS DNSF module detects it.
Step 8: Impact
The final stage of the attack consists in encrypting files (in this case, with the .lockbit extension). TEHTRIS tools would have detected this attack chain long before this step. However, alerts on the deletion of honeyfiles as well as sandbox analysis would raise alerts.
TEHTRIS keeps you safe
TEHTRIS XDR Platform protects your company at each step of the attack. By activating the option Terminate Process Tree on TEHTRIS EDR Process Monitoring, the suspicious spawn tree would have been automatically killed and the attack would have been stopped at its early stage.
Another way of making sure that the attacker would not even get access on your device is by enabling the kill on the Follina exploit Application Policy.
By activating automatic remediation, the attack would have been automatically killed at the first stage, leaving no chance to LockBit affiliates using this kill chain.