Blogs
The latest cybersecurity trends, best practices, security vulnerabilities, and more
ARCHIVED STORY
Tales From the Trenches; a Lockbit Ransomware Story
By ATR Operational Intelligence Team · APR 30, 2020
Co-authored by Marc RiveroLopez.
In collaboration with Northwave
As we highlighted previously across two blogs, targeted ransomware attacks have increased massively over the past months. In our first article, we discussed the growing pattern of targeted ransomware attacks where the primary infection stage is often an info-stealer kind of malware used to gain credentials/access to determine if the target would be valuable for a ransomware attack. In the second part, we described the reconnaissance phase of an attacker that controls an infected host or a valid account to access a remote service. Many of them are using a similar manual modus operandi as we highlighted in the earlier blogs. We believe there is real opportunity to learn from incident response cases and previous attacks, hence why this blog is dubbed ‘tales from the trenches’. In collaboration with Northwave, this article describes a real-life case of a targeted ransomware attack. During one of their recent incident responses, Northwave encountered a relatively new family of ransomware called LockBit performing a targeted attack. First sighted in late 2019, under the name .abcd virus, this piece of ransomware was more a revision than evolution when compared with earlier attacks. Like the previous posts in this blog series, we describe the different stages of the attack and recovery, including a thorough analysis of the ransomware and the attackers behind it.
In this blog we’ll cover:
LockBit Telemetry Map
We gathered telemetry through our McAfee Global Threat Intelligence GTI database on the different LockBit samples we analyzed in our research. The global spread is currently limited as this ransomware is relatively new and heavily targeted.
Initial Access
As in all ransomware cases, the attacker has to gain initial access to the network somehow. In this particular case the attacker performed a brute force attack on a web server containing an outdated VPN service. Based on our research it took several days for the brute force to crack the password of the ‘Administrator’ account. With this account, belonging to the administrator group, the attacker immediately obtained the proverbial “keys to the kingdom” with all the necessary permissions to perform a successful attack. Unfortunately, this is not a unique case; external facing systems should always have multi-factor authentication enabled when possible. Besides, a security organization should have a least privilege strategy when it comes to accessing systems. Targeted ransomware attackers are successfully leveraging the “human factor” integrally. It is no longer the typical “end-user clicking on a malicious link” causing the complete lock-up of a company. The human factor in targeted ransomware attacks goes much deeper. Attackers successfully leverage weaknesses in security policy and misconfigurations across an entire organization; from end-user to Domain Administrator.
Infiltrating the Network
To infiltrate the network, the attacker had to take several steps to make sure the ransomware attack was successful. An attacker always wants to infect as many systems as possible to effectively halt the business process and urge the victim to pay the ransom.
Credentials & Privileges
As mentioned previously, the attacker was successful in guessing the password of the Administrator account using a brute force attack. With this, the attacker immediately had all the necessary privileges for deploying the ransomware successfully. In other cases, as we described in our second blog, the attacker often uses known post-exploitation frameworks, for privilege escalation, lateral movement and performing any additional actions on their objective. Since quite a few of these frameworks are readily available we often call this the “GitHubification” of attack tools. In this case however, the attacker could actually skip this step and continue with the network reconnaissance and deployment of the ransomware immediately, since a high privileged account was already compromised.
Lateral Movement
With the administrator-level account, the attacker used SMB to perform network reconnaissance, resulting in an overview of accessible hosts. Subsequently, the attacker used the internal Microsoft Remote Access Server (RAS) to access these systems using either the administrator or the LocalSystem account. The LocalSystem account is a built-in Windows account. It is the most authoritative account on a Windows local instance (more potent than any admin account). Using these accounts, the attacker owned these systems and could do anything they wanted, including turning off any end-point security products. Interestingly, both the lateral movement and the deployment of the ransomware was entirely automated.
Deployment of the Ransomware
This specific case was a classic hit and run. After gaining access to the initial system using the brute-forced administrator account, the attacker logged in and deployed the ransomware almost immediately. For the attacker, this was a relatively straightforward process since the ransomware spreads itself. The deployment of the ransomware on one single host remotely instructed the other hosts in the network to run the following PowerShell command:
This command retrieves a .png file from a website that has probably been compromised. There are two versions of the .png file, one for .NET version 4 and one for version 3.5. The PowerShell command checks which version it needs by getting the version number of the common language runtime that is running the current process. If this starts with ‘V4’, the .png for version 4 is downloaded; otherwise it downloads the .png for version 3.5 via the URLs below: https://espet[.]se/images/rs35.png https://espet[.]se/images/rs40.png What is interesting in this case is that each distinct host downloads the ransomware itself. Hence, the attacker only needed access to one system with an account having enough privileges to automatically make all other hosts in the network download and execute it.
Malware Analysis
For our analysis, we will use the file found in our investigation, the details of which are:
File name: rs35.png | |
SHA1 | 488e532e55100da68eaeee30ba342cc05810e296 |
SHA256 | ca57455fd148754bf443a2c8b06dc2a295f014b071e3990dd99916250d21bc75 |
size | 546.00 KB |
PDB | c:\users\user\work\code\dotnet\regedit-64\regedit-64\obj\release\rs35.pdb |
guid | 84e7065-65fe-4bae-a122-f967584e31db |
Technical Analysis
The file we found in our investigation was a dropper renamed as a .png file. When first opening the .png files we were expecting a real image file, with perhaps some steganography inside, but what we saw instead was the header of a portable executable, so no steganography pictures this time. The PE was compiled in Microsoft Visual C# v7.0 / Basic .NET, .NET executable -> Microsoft.
Entropy-wise it seems quite tidy too, not showing any stray sections or big spikes in the graph. This behavior indicates that the writer of the malware did not use obfuscation.
This file is a .NET launcher. Examining the Main() function in the code shows that an array containing a particularly long AES encrypted base64 string (in the variable named ‘exeBuffer’) carries the executable for the actual ransomware.
This encrypted string is decrypted using the key ENCRYPTION29942. The first 32 bytes of the long ExeBuffer string are used as the salt in the encryption scheme, where ENCRYPTION29942 is the passphrase.
Remarkably, the script checks for the existence of vbc.exe on its designated host. Usually, this binary is a digitally signed executable from Microsoft; however, in this case, the malware uses it for process hollowing.
By statically analyzing the file we can spot the usage of.
- NtUnmapViewOfSection
- LockBit uses this API in order to unmap the original code in execution
- NtWriteVirtualMemory
- The malware writes the base address of the injected image into the PEB via NtWriteVirtualMemory
- VirtualAllocEx
- To allocate the space before injecting the malicious code
The VBC utility is the visual basic compiler for Windows and LockBit uses it to compile and execute the code on the fly directly in execution. If the vbc utility does not exist on the system, the malware downloads the original vbc.exe file from the same malicious URL as seen before. After executing vbc.exe, the malware replaces the objects in memory with the code for deploying the ransomware (as deduced from the exeBuffer).
Payload Analysis
Analysis of the exeBuffer shows several appealing elements. It starts with a UAC Bypass via {3E5FC7F9-9A51-4367-9063-A120244FBEC7} exploiting the ICMLuaUtil elevated COM Interface-Object[1], as seen in other ransomware families like Trickbot and MedusaLocker. Subsequently, the script uses another variant of the UAC Bypass. The CLSID {D2E7041B-2927-42fb-8E9F-7CE93B6DC937} refers to the ColorDataProxy COM Object which is classified as the same Bypass method in hfiref0x’s UACME #43[2]. In order to be stealthier, LockBit ransomware loads its modules dynamically instead of having them hardcoded in the IAT and uses LoadLibraryA. This method is employed to avoid detection by static engines.
In execution, the malware accesses the Service Manager using the function “OpenSCManagerA” and saves the handle. It checks if it fails the last error with the “GetLastError” function, against the error ERROR_ACCESS_DENIED.
Upon access to the Service Manager, LockBit creates a thread to manage services, terminate processes and delete the shadow volumes plus the contents of the recycle bin. In this thread the malware has the name of services that it will try to manage hardcoded to try to make them more obfuscated:
The list of services LockBit tries to stop are:
- DefWatch (Symantec Antivirus)
- ccEvtMgr (Norton AntiVirus Event Manager)
- ccSetMgr (Common Client Settings Manager Service of Symantec)
- SavRoam (Symantec Antivirus)
- sqlserv
- sqlagent
- sqladhlp
- Culserver
- RTVscan (Symantec Antivirus Program)
- sqlbrowser
- SQLADHLP
- QBIDPService (QuickBooksby Intuit.)
- QuickBoooks.FCS (QuickBooksby Intuit.)
- QBCFMonitorService (QuickBooksby Intuit.)
- sqlwriter
- msmdsrv (Microsoft SQL Server Analysis or Microsoft SQL Server)
- tomcat6 (Apache Tomcat)
- zhundongfangyu (this belongs to the 360 security product from Qihoo company)
- vmware-usbarbitator64
- vmware-converter
- dbsrv12 (Creates, modifies, and deletes SQL Anywhere services.)
- dbeng8 (Sybase’s Adaptive Server Anywhere version 8 database program)
- wrapper (Java Service?)
If one of these services is found by the malware querying the status of it, with the function “QueryServiceStatusEx”, LockBit will get all the depending modules when correct and safe and it will stop the service with the function “ControlService”.
LockBit will prepare Unicode obfuscated strings that contain a command to delete the shadow volumes and disable the protections in the next boot of the system.
In our analysis, we saw how the ransomware dynamically uses the function “IsWow64Process” to check if the victim OS is running a x64 system and then uses the functions “Wow64DisableWow64FsRedirection” and “Wow64RevertWow64FsResdirection”. If the malware can access the functions, it will use the first to destroy all shadow volumes and the protections of the OS in the next boot and, later, will recover the redirection with the other function. In the case that it cannot get these functions, LockBit will delete the shadow volume directly through the function “ShellExecuteA” or with the function “CreateProcessA”. Deletion of files within the recycle bin is executed with the function “SHEmptyRecycleBinW”.
Another check made by the ransomware is for the existence of the SS2 set of instructions:
The Ransom Note
The ransom note is rather compact because the author hardcoded the content right in the code without using any obfuscation or encryption. The text file containing the ransom note is created in every directory after encryption and called Restore-My-Files.txt.
Lastly, after finishing the encryption, the desktop wallpaper is changed to a message for the user, saying that LockBit encrypted the host
SMB Spreading
Analyzing LockBit in our environment, we identified the possibility to spread locally in the same local network. Analyzing the network traffic, we spotted the use of multiple ARP requests to find other hosts in the same network segment.
If the SMB connection is successful, LockBit will execute the following PowerShell command to download the .NET launcher that will decompress and execute LockBit in a new system:
LockBit Ransomware Evolution:
LockBit is new on the scene, but we noticed the authors added several new features and improved the ransomware several times. That means there is an active group behind it which is probably getting feedback on its actions. This is an example of the development cycle; this graph was extracted, analyzing statically all the internal functions and comparing them across the samples:
For this investigation, we found different LockBit versions with different features between them:
LockBit Version 1
This first version contains unique features compared to other versions we found in the wild. These features are:
- IPLO (IPLogger geolocalization service)
- Persistence through the COM interface and the HIVE Current Version Run
- A different extension used in the encrypted files
- Debug file created for debugging purposes
- HIGH CPU Usage in the encryption process
- The reusage of a MUTEX observed in other ransomware families
IPLO.RU geo-localization service:
One of the interesting items we found was that LockBit tries to identify the victim’s geo-location, through the URL IPLO.RU, requesting a static TXT file in that service.
Analyzing statically the code in LockBit, we found that this URL is not resolved dynamically in execution; it is hardcoded in the binary:
LockBit also uses a reboot persistence method by using the Windows registry hive: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run Using the CurrentVersion\Run hive serves to survive the reboot if the system shuts down. LockBit is actually using two persistence methods, CLSID and CurrentVersion\Run
.abcd extension used:
The first version of LockBit uses the .abcd extension every time it encrypts a file; this is a unique difference between this version and the other versions found.
Ransom note used:
LockBit in this first version used a different ransom note with a different message:
High CPU usage:
We analyzed the performance of the encryption and we noted how LockBit uses the CPU heavily in the encryption process:
LockBit Version 2
This LockBit version came out with the following changes:
- Appended extension changed
- The debug function removed
- Some of the samples came packed wither with UPX or a Delphi packer
- One sample digitally signed
Appended extension changed:
For this version, LockBit started to append the extension .lockbit in all the encrypted files as a file marker:
Debug log function removed:
LockBit, in this new version, removed the functionality whereby it stored all the skipped files in the encryption process.
Sample delivery with different protections:
In this version we found LockBit samples packed in UPX and other custom packers, adding certain protections to the samples:
- Extensive usage of PEB during the execution
- The use of IsDebuggerPresent, OutputDebugString and GetLastError
All these protections are enabled by the use of packers in the delivery.
Mutex change:
The prior version of LockBit used a static mutex in all the encryptions but, in this release, it changed to be a dynamic value for every infection.
Samples digitally signed:
For all the versions we found for LockBit, only this version had a sample digitally signed:
LockBit debug enabled:
After all the hunting progress we made, we found several samples of LockBit with some kind of status feature enabled, showing a progress window during the encryption:
Figure 35: LockBit debug enabled
This mode was only available for certain sample compilations and the status screen was different depending on the LockBit sample analyzed:
RECENT NEWS
-
Dec 5, 2024
Trellix Named 2024 AWS Technology Partner of the Year Award Winner for Sub-Saharan Africa (SSA) Region
-
Dec 2, 2024
Trellix Achieves the AWS Generative AI Competency
-
Nov 21, 2024
Trellix Positioned as a Leader in the 2024 SPARK Matrix™ for Network Detection and Response by QKS Group
-
Nov 20, 2024
Trellix Uncovers Diversification of Ransomware Ecosystem as Cybercriminal Use of AI Expands
-
Nov 7, 2024
Trellix Achieves FedRAMP® High Authorization to Protect U.S. Government from Growing Cyber Threats
RECENT STORIES
Get the latest
Stay up to date with the latest cybersecurity trends, best practices, security vulnerabilities, and so much more.
Zero spam. Unsubscribe at any time.