Lockbit Ransomware
Lockbit is a well-known ransomware-as-a-service (RAAS) that first emerged in 2019. The Lockbit group threat actors or RAAS affiliates first target a system, once this system is compromised. Its file system is encrypted and a ransom note is dropped on the victim’s computer. This note contains instructions on how to make the ransom payment.
Lockbit operators are known to engage in a double-extortion tactic. This involves not only encrypting the files but also exfiltrating sensitive data before encryption. The Lockbit operators then threaten to leak the victim’s data unless the ransom is paid.
How this Lockbit Ransomware works
Lockbit ransomware is typically delivered (attack vectors) to the victim through various methods: phishing emails, malicious spam (malspam), software vulnerabilities, RDP exploitation, and post exploitation kits.
During this particular ransomware campaign, the ransomware was distributed to unsuspecting victims. They were tricked into opening a malicious Microsoft Word document named werili.docx. This malicious Word document contained the following social engineering images: “Select Enable Editing” and “Select Enable Content” (Figure 1), that enticed the unaware victim into enabling editing which then executed the embedded VBA macros, resulting in the encryption of the victim’s computer.
Figure 1: Word document contained social engineering images: “Enable Editing” and “Select Enable Content”, that goaded the unaware victims into enabling editing which then executed the embedded VBA macros.
Analysis of the Stage 1 loader – werili.docx
All office document files (i.e. docx, xlsx and pptx) are archive files. Meaning that you can change the extension to .zip and unzip it or it can be directly opened via tools like Winzip or 7zip to extract the contents of these files.
Threat actors often abuse the pre-built file templates called ./word_rels/settings.xml.rels or ./word/_rels/settings.xml.rels (Figure 2). These templates are created within the office document files and normally contain the remote or local path to another template with the extension .dotm that will be automatically loaded upon opening the document.
Figure 2: settings.xml.rels showed the target url that is hosting the template .dotm file.
After further review, I can see that the threat actors decompress the .docx file and change the Target value in the settings.xml.rels file to load their desired template and again compressed it to a .docx file.
Please, note that Target does not need to be local, it can be remote as well, in this case we can see a URL in Target value i.e. “Target=https[:]//learndash[.]825testsites[.]com/b/fgi5k8.dotm”(h converts to h).
We have two office document files: “werili.docx” and “fgi5k8.dotm” (template file). As the victim opens werili.docx it will download the template file (fgi5k8.dotm) along with its macros and as a result the macros will be automatically executed (Figure 3).
Figure 3: werili.docx downloading the template dotm file (fgi5k8.dotm) along with its macros and as a result the macros will get executed.
Analysis of the Stage 2 loader – fgi5k8.dotm
I utilized Microsoft Word’s Developer Tools to analyze the embedded VB macros from the downloaded fgi5k8.dotm file. A quick review of the VB macro after loading it I could see that it was obfuscated. So, to save time I decided to dynamically open and run the malicious Word document in debugger mode (Figure 4 & 5), then let CMD Watcher v0.3 capture (Figure 6) the malicious PowerShell script. Just from my past experience, I knew that the VB macros would ultimately invoke a PowerShell.
Figure 4: fgi5k8.dotm’s VB macros executed upon opening.
Figure 5: fgi5k8.dotm’s VB macros are obfuscated. I used Word’s Developer Tools to deobfuscate them.
Figure 6: CMD Watcher v0.3 captured a snapshot of the malicious PowerShell script.
After the VBA macros were executed a malicious PowerShell command was run. The PowerShell script utilized curl to download Lockbit payload from:
https[:]//learndash[.]825testsites[.]com/b/abc.exe
The downloaded Lockbit payload’s drop folder location (Figure 7):
C:\Users\Public\cw3fd.exe (Classification: Lockbit payload; abc.exe is renamed once dropped to disk: cw3fd.exe).
Figure 7: Downloaded Lockbit payload’s drop folder location.
Analysis of the Stage 3 payload – cw3fd.exe
After the Lockbit payload was dropped on the system, it ran and encrypted the victim’s file system. This variant is Lockbit 3.0, every encrypted file has a .ONa9v7hKI file extension (Figure 8) appended to the filename. Lockbit even changes the victim’s desktop wallpaper letting them know that they have been encrypted (Figure 10).
Figure 8: Lockbit encrypted the user’s files and appended a .ONa9v7hKI file extension to the filename.
Figure 9: This ransom note (ONa9v7hKI.READ.txt) was dropped in every directory.
Figure 10: Lockbit’s desktop wallpaper message to the victim.
A standard practice by many ransomware variant is to delete shadow copies. Lockbit does this as well, in order to prevent the recovery of encrypted files from shadow copies, Lockbit 3.0 terminates and deletes the VSS service (Figure 11).
Also, it disabled both Windows Service Center Service (Figure 12) and Windows Defender ATP Service (Figure 13), as well.
Figure 11: Process Hacker captured Lockbit deletion of the VSS (Volume Shadow Copy) Service.
Figure 12: Process Hacker captured Lockbit deletion of the Windows Security Center Service.
Figure 13: Process Hacker captured Lockbit deletion of the Windows Defender ATP Service.
Next, I started reviewing the code of cw3fd.exe, after looking at the strings using Bintext (Figure 14), this file was heavily obfuscated within each of the functions. This was definitely a packed file.
Figure 14: Review of strings using Bintext revealed this file was heavily obfuscated.
The next step was to look for the file’s unpacking routine using IDA Pro, which brought attention to the use of VirtualAlloc which is used by malware to allocate memory when it is ready to unpack itself into memory. The appropriate breakpoints were set and the file was able to be dumped. Review of contents in the Dump Window, showed the binary was an executable (File header: MZ) (Figure 15).
Figure 15: Review of contents in the Dump Window, showed the binary was an executable.
The Lockbit binary is now unpacked, it is known for its dynamic API resolution at runtime which makes reverse engineering the sample more difficult and helps conceal functions from debuggers (Figure 16).
Figure 16: This function dynamically resolves the APIs at runtime.
As mentioned earlier, Lockbit dropped a ransom note in every directory. The function builds the ransom note is shown below (Figure 17).
Figure 17: The function that builds the ransom note.
Lockbit is also known for its string obfuscation. The following function is a Base64 decoding function used to decode strings (Figure 18).
Figure 18: Base64 decoding function.
Lockbit is a ransomware that can compromise the security of a target system and then it encrypts the file system. To protect against Lockbit ransomware attacks, it is important to be aware of the signs of infection and implement best practices for cybersecurity. Organizations should implement a backup strategy that keeps backups offline, not connected to your network and if possible offsite in a different location. By staying informed and vigilant, organizations and individuals can reduce their risk of falling victim to Lockbit.
IOCs:
werili.docx (MD5: 244e475d884c455bb1fbad1a4294f21c); Classification: Lockbit Loader
fgi5k8.dotm (MD5: f2a9bc0e23f6ad044cb7c835826fa8fe) Classification: Lockbit Loader
cw3fd.exe (MD5: 7a83a738db05418c0ae6795b317a45f9) Classification: Lockbit payload
.ONa9v7hKI (Encrypted extension name)
ONa9v7hKI.README.txt (Ransom note file name)
Network IOCs:
https[:]//learndash[.]825testsites[.]com
http[:]//lockbitapt[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx].onion (ONION domain ([46 random characters]))
http[:]//lockbitapt[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx].onion.ly (ONION domain ([46 random characters]))