Normal view

There are new articles available, click to refresh the page.
Before yesterdayMcAfee Blogs

Are Virtual Machines the New Gold for Cyber Criminals?

AI Cyber Security

Introduction

Virtualization technology has been an IT cornerstone for organization for years now. It revolutionized the way organizations can scale up IT systems in a heartbeat, allowing then to be more agile as opposed to investing into dedicated “bare-metal” hardware. To the outside untrained eye, it might seem that there are different machines on the network, while in fact all the “separate” machines are controlled by a hypervisor server. Virtualization plays such a big role nowadays that it isn’t only used to spin up servers but also anything from virtual applications to virtual user desktops.

This is something cyber criminals have been noticing too and we have seen an increased interest in hypervisors. After all, why attack the single virtual machine when you can go after the hypervisor and control all the machines at once?

In recent months several high impact CVEs regarding virtualization software have been released which allowed for Remote Code Execution (RCE); initial access brokers are offering compromised VMware vCenter servers online, as well as ransomware groups developing specific ransomware binaries for encrypting ESXi servers.

VMware CVE-2021-21985 & CVE-2021-21986

On the 25th of May VMware disclosed a vulnerability impacting VMware vCenter servers allowing for Remote Code Execution on internet accessible vCenter servers, version 6.5,6.7 and 7.0. VMware vCenter is a management tool, used to manage virtual machines and ESXi servers.

CVE-2021-21985 is a remote code execution (RCE) vulnerability in the vSphere Client via the Virtual SAN (vSAN) Health Check plugin. This plugin is enabled by default. The combination of RCE and default enablement of the plugin resulted in this being scored as a critical flaw with a CVSSv3 score of 9.8.

An attacker needs to be able to access vCenter over TCP port 443 to exploit this vulnerability. It doesn’t matter if the vCenter is remotely exposed or when the attacker has internal access.

The same exploit vector is applicable for CVE-2021-21986, which is an authentication mechanism issue in several vCenter Server Plug-ins. It would allow an attacker to run plugin functions without authentication. This leads to the CVE being scored as a ‘moderate severity’, with a CVSSv3 score of 6.5.

While writing this blog, a Proof-of-Concept was discovered that will test if the vulnerability exists; it will not execute the remote-code. The Nmap plugin can be downloaded from this location: https://github.com/alt3kx/CVE-2021-21985_PoC.

Searching with the Shodan search engine, narrowing it down to the TCP 443 port, we observe that close to 82,000 internet accessible ESXi servers are exposedZooming in further on the versions that are affected by these vulnerabilities,  almost 55,000 publicly accessible ESXi servers are potentially vulnerable to CVE-2021-21985 and CVE-2021-21986, providing remote access to them and making them potential candidates for ransomware attacks, as we will read about in the next paragraphs.

Ransomware Actors Going After Virtual Environments

Ransomware groups are always trying to find ways to hit their victims where it hurts. So, it is only logical that they are adapting to attacking virtualization environments and the native Unix/Linux machines running the hypervisors. In the past, ransomware groups were quick to abuse earlier CVEs affecting VMware. But aside from the disclosed CVEs, ransomware groups have also adapted their binaries specifically to encrypt virtual machines and their management environment. Below are some of the ransomware groups we have observed.

DarkSide Ransomware

Figure 1. Screenshot from the DarkSide ransomware group, explicitly mentioning its Linux-based encryptor and support for ESXi and NAS systems

McAfee Advanced Threat Research (ATR) analyzed the DarkSide Linux binary in our recent blog and we can confirm that a specific routine aimed at virtual machines is present in it.

Figure 2. DarkSide VMware Code routine

From the configuration file of the DarkSide Linux variant, it becomes clear that this variant is solely designed to encrypt virtual machines hosted on an ESXi server. It searches for the disk-files of the VMs, the memory files of the VMs (vmem), swap, logs, etc. – all files that are needed to start a VMware virtual machine.

Demo of Darkside encrypting an ESXi server: https://youtu.be/SMWIckvLMoE

Babuk Ransomware

Babuk announced on an underground forum that it was developing a cross-platform binary aimed at Linux/UNIX and ESXi or VMware systems:

Figure 3. Babuk ransomware claiming to have built a Linux-based ransomware binary capable of encrypting ESXi servers

The malware is written in the open-source programming language Golang, most likely because it allows developers to have a single codebase to be compiled into all major operating systems. This means that, thanks to static linking, code written in Golang on a Linux system can run on a Windows or Mac system. That presents a large advantage to ransomware gangs looking to encrypt a whole infrastructure comprised of different systems architecture.

After being dropped on the ESXi server, the malware encrypts all the files on the system:

The malware was designed to target ESXi environments as we guessed, and it was confirmed when the Babuk team returned the decryptor named d_esxi.out. Unfortunately, the decryptor has been developed with some errors, which cause corruption in victim’s files:

Overall, the decryptor is poor as it only checks for the extension “.babyk” which will miss any files the victim has renamed to recover them. Also, the decryptor checks if the file is more than 32 bytes in length as the last 32 bytes are the key that will be calculated later with other hardcoded values to get the final key. This is bad design as those 32 bytes could be trash, instead of the key, as the customer could make things, etc. It does not operate efficiently by checking the paths that are checked in the malware, instead it analyzes everything. Another error we noticed was that the decryptor tries to remove a ransom note name that is NOT the same that the malware creates in each folder. This does not make any sense unless, perhaps, the Babuk developers/operators are delivering a decryptor that works for a different version and/or sample.

The problems with the Babuk decryptor left victims in horrible situations with permanently damaged data. The probability of getting a faulty decryptor isn’t persuading victims to pay up and this might be one of the main reasons that Babuk  announced that it will stop encrypting data and only exfiltrate and extort from now on.

Initial-Access-Brokers Offering VMware vCenter Machines

It is not only ransomware groups that show an interest in virtual systems; several initial access brokers are also trading access to compromised vCenter/ESXi servers on underground cybercriminal forums. The date and time of the specific offering below overlaps with the disclosure of CVE-2021-21985, but McAfee ATR hasn’t determined if this specific CVE was used to gain access to ESXi servers.

Figure 4. Threat Actor selling access to thousands of vCenter/ESXi servers

Figure 5. Threat actor offering compromised VMware ESXi servers

Patching and Detection Advice

VMware urges users running VMware vCenter and VMware Cloud Foundation affected by CVE-2021-21985 and CVE-2021-21986 to apply its patch immediately. According to VMware, a malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. The disclosed vulnerabilities have a critical CVSS base score of 9.8.

However, we do understand that VMware infrastructure is often installed on business-critical systems, so any type of patching activity usually has a high degree of impact on IT operations. Hence, the gap between vulnerability disclosure and patching is typically high. With the operating systems on VMware being a closed system they lack the ability to natively install workload protection/detection solutions. Therefore, the defenses should be based on standard cyber hygiene/risk mitigation practices and should be applied in the following order where possible.

  1. Ensure an accurate inventory of vCenter assets and their corresponding software versions.
  2. Secure the management plane of the vCenter infrastructure by applying strict network access control policies to allow access only from special management networks.
  3. Disable all internet access to vCenter/VMware Infrastructure.
  4. Apply the released VMware patches.
  5. McAfee Network Security Platform (NSP) offers signature sets for detection of CVE-2021-21985 and CVE-2021-21986.

Conclusion

Virtualization and its underlying technologies are key in today’s infrastructures. With the release of recently discovered vulnerabilities and an understanding of their criticality, threat actors are shifting focus. Proof can be seen in underground forums where affiliates recruit pentesters with knowledge of specific virtual technologies to develop custom ransomware that is designed to cripple these technologies. Remote Desktop access is the number one access vector in many ransomware cases, followed by edge-devices lacking the latest security updates, making them vulnerable to exploitation. With the latest VMware CVEs mentioned in this blog, we urge you to take the right steps to secure not only internet exposed systems, but also internal systems, to minimize the risk of your organization losing its precious VMs, or gold, to cyber criminals.

 

Special thanks to Thibault Seret, Mo Cashman, Roy Arnab and Christiaan Beek for their contributions.

The post Are Virtual Machines the New Gold for Cyber Criminals? appeared first on McAfee Blog.

Tales From the Trenches; a Lockbit Ransomware Story

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.

Figure 1: Telemetry map

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:

Figure 2: PowerShell execution to download LockBit

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.

Figure 3: Static analysis of LockBit

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.

Figure 4: Entropy analysis

Figure 5: Portex visualization of LockBit

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.

Figure 6: .NET launcher buffer

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.

Figure 7: Launcher calls & functions

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).

Figure 8: If VBC does not exist, the launcher will download it

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.

Figure 9. Name of the modules in the code

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.

Figure 10. Access to the Service Manager

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:

Figure 11. Hardcoded service names

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”.

Figure 12. Stopping target service

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.

Figure 13. Prepare the commands to delete shadow volumes and disable protections on boot

The malware has these strings in the rdata section, as widely observed in all malware families, and in its own code as show in the previous screenshots. The malware uses both strings.

During its execution, LockBit will create a snapshot of the processes running in the system and will search to see if certain processes are part of this list with the function “OpenProcess” and, in case the process is present, it will finish it with the “TerminateProcess” function.

The list of processes that LockBit will check are:

wxServer wxServerView
sqlservr RAgui
supervise Culture
RTVScan DefWatch
sqlbrowser winword
QBW32 QBDBMgr
qbupdate QBCFMonitorService
axlbridge QBIDPService
httpd fdlauncher
MsDtSrvr tomcat6
zhudongfangyu vmware-usbarbitator64
vmware-converter dbsrv12

This “process check function” is performed through a trick using the “PathRemoveExtensionA” function and removing the .exe extension from the list. Using this technique, the check process is more obfuscated.

Figure 14. Remove extension and check the process name

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”.

Figure 15. Delete the contents of the recycle bin

Static analysis of the sample shows that LockBit will check the machine to see if it has support for  AES instructions in the processor with the “cpuid” opcode.

Figure 16. Check for AES instruction support in the CPU

Another check made by the ransomware is for the existence of the SS2 set of instructions:

Figure 17. Check for SSE2 instructions in the CPU

After finishing this process, the malware will try to delete itself with the next command using “ShellExecuteExW”:

Image 18. Auto-deletion of the malware

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.

Figure 19: Content that is placed in Restore-My-Files.txt

Victim Information Stored in the Registry Key

LockBit in execution will create two keys in the infected system with the values full and public.

Those keys are created in the following hive HKEY_CURRENT_USER\SOFTWARE\LockBit. The data stored in these keys belongs to the infected victim in order to be able to identify them in the future.

Figure 20: LockBit registry keys

Lastly, after finishing the encryption, the desktop wallpaper is changed to a message for the user, saying that LockBit encrypted the host.

Figure 21: LockBit wallpaper after encryption

LockBit Filemarker

Some of the ransomware we analyzed shares a common file marker across all the encrypted files in order to verify the origin. This digital marker can be used there in the control panel in order to verify that this was the ransomware that encrypted the files.

This is an example for the first version of LockBit, where file marker was using:

C8 41 D0 BE AB 3F 0D 59 7B BF CF 40 C8 81 63 CD

If we compare two encrypted files, we can spot how the file marker matches in both encrypted files:

Figure 22: File marker used by LockBit

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.

Figure 23: LockBit ARP traffic captured in the analysis

If these ARP requests finally find a host alive, LockBit will start a legitimate SMB connection to be able to deploy the ransomware in other machines.

Figure 24: LockBit SMB traffic captured in the analysis

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.

Figure 25: LockBit IPLO.RU geolocation traffic captured in the analysis

The communication to this page is through HTTPS; we intercepted the traffic to get the reply from the remote server:

Figure 26: SSL decrypted traffic

Analyzing statically the code in LockBit, we found that this URL is not resolved dynamically in execution; it is hardcoded in the binary:

Figure 27: Hardcoded URL of IPLO service

Creating persistence through Current version Run and COM task schedule:

There are many ways to gain persistence in a system. This first version of LockBit uses a task schedule through the COM interface to gain persistence.

Figure 28: Persistence using the COM interface

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:

Figure 29: LockBit ransomware note

Debug file created in execution:

LockBit’s first version has some files that are skipped in the encryption process and every time it skips one it will create resultlog6.reg with the log information:

Figure 30: Debug file created by LockBit

High CPU usage:

We analyzed the performance of the encryption and we noted how LockBit uses the CPU heavily in the encryption process:

Figure 31: LockBit performance in execution

PhobosImposter static MUTEX used:

In October 2019, the community saw how PhobosImposter was using the mutex XO1XADpO01 in its executions and the same mutex is used by LockBit in this first version. We analyzed the base code of both samples and we did not find any code overlap but is a quite a random string to use casually.

This is the function used to create the mutex:

Figure 32. Creation and check of the hardcoded mutex

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:

Figure 33: LockBit sample digitally signed

LockBit Version 3

Ransomware note changed:

For this version LockBit adapted the ransomware note and used a new one:

Figure 34: LockBit 2nd version of the ransomware note

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:

Figure 36: LockBit sample digitally signed

Tales from the Underground

When we researched the underground community for LockBit we came across a posting on several popular underground forums.  A threat actor named Lockbi or LockBit is offering LockBit as a “bespoke” ransomware as a service for limited partners/affiliates. We suspect LockBit ransomware to be more “bespoke”, not only from its own announcements, but subsequently we have not seen any affiliate identifiers present in the ransomware, which is normally a clear sign of an actor trying to upscale operations and service a larger number of affiliates.

The advertisement provides a general description that matches the LockBit behavior we have seen in the wild and from our analysis. As many other cyber-criminal services, LockBit does not allow the use of the software in any of the CIS countries. This is commonly done to avoid prosecution if the threat actor resides in one of those nations.

What we also noticed was a mention around multi-threading. Ransomware families are often programmed to run multi-threaded to ensure quick and overall encryption and prevent the encryption process getting stuck on a large file. However, LockBit was specifically advertised as single threaded and the threat actor Lockbi ensures that there are no speed issues when it comes to its encryption capability.

Figure 37: The LockBit advertisement

In the advertisement it is listed that one of the features of the ransomware is a local subnet scanner and SMB propagation method, something we can confirm based on our analysis.

Also noteworthy is the use of a Jabber-bot to perform the essential functions, such as chatting, decryption and banning, replacing the need for a labor intensive admin panel that is hosted somewhere on the internet.

Figure 38: LockBit profile including the 10,5 BTC deposit

It seems that LockBit has joined the underground scene with a clear determination to do business; the authors have put a down a deposit in excess of 10,5 BTC, a bit shy of 75K USD. Putting a deposit in escrow is a way to demonstrate that the seller is invested financially and not out to scam potential partners. The seller would lose their deposit if they did not keep to their end of the deal. Our telemetry shows that LockBit activity is still limited today but we can definitely expect to see more bespoke LockBit attacks in the near future.

Recovery

Going back to the real-life case, there were no recent offline backups. So, with the backup servers (including the backups) encrypted as well and a complete rebuild not being an option, there was no way for a successful and swift recovery other than by paying the ransom.

Both McAfee’s and Northwave’s perspective is that ransoms should not be paid. Paying does not only support the criminal business model, but as we have shown in our research, it also finances other forms of crime, such as the online drug trade.

In this specific case the victim chose to pay the ransom. The first step for recovery was to get in contact with the hacker following the instructions from the ransom note (Restore-my-files.txt) as depicted below.

Figure 39: LockBit ransomware note

Interestingly, as opposed to earlier known cases of LockBit (or .abcd virus) where contact with the attacker occurred via email addresses mentioned in the ransom note, in this case, the attacker developed an online ‘help desk’ accessible via a .onion address. Helpful as the hacker is, they even provided clear instructions on how to access this .onion address with the Tor browser. Although the ransom note claims there was private data obtained, Northwave did not find any evidence for this on the compromised systems.

Figure 40: LockBit recovery page

The image above shows the helpdesk which the attacker uses for communication with their victims. It provides the functionality for a trial in which two files can be decrypted ‘for warranty’, showing that the attacker indeed has the correct key(s) for restoring the data. For this, it is always essential to test files from different (critical) servers since keys might differ per server. In negotiations with an attacker, always try to obtain this knowledge since it is also relevant for your recovery strategy. If it is only one key, you know you can use one tool for the entire network; however, if encrypted servers use distinct keys, recovery becomes increasingly more difficult.

After successful decryption of two different files (from distinct servers), the chat with the attacker began. They started by asking for a network domain name (to identify the correct victim), then the attacker addressed the ransom amount. Usually, the attackers do proper research on their victims and tailor the ransom amount accordingly, which was the case here as well. Hence, negotiating on the amount of the ransom did not prove to be useful:

“We know who you are, so don’t play negotiate games.”

Trouble in Hacker Paradise

Subsequently, making the bitcoin transaction to the provided address, the helpdesk page would automatically update after six confirmations and show the download link for the decryptor.

“After 6 transaction confirmations, in a few hours decryptor will be built automatically. Don’t worry you will get it instantly once it’s built.”

Since there was nothing else to do than wait and hope for the decryptor now, an attempt was made into obtaining some more information from the attacker by asking about their methods. See a snippet of this conversation below.

Figure 41: Attacker communication

The ‘weak passwords’ is, of course, entirely in line with the brute force attack mentioned earlier. Additionally, this conversation indicates that there is a larger group behind this attack, where roles between different participants are separated. The helpdesk seems to be an actual helpdesk, merely following a script of actions.

After waiting for several hours and six confirmations further, the decryption tool should have been ready for download. However, this is where things progressed differently. There seemed to be some technical issues causing the decryptor not to generate automatically for which the helpdesk kindly apologized. Unfortunately, this continued for two dubious days with multiple excuses before the attacker sent a link to the decryptor via the chat. It appeared that they were ineffective in solving the technical issues; hence they chose to send it via SendSpace.

Once downloaded, the recovery phase could start. In this phase, all servers were decrypted, scanned and cleaned (or rebuilt) in a quarantined network. Subsequently, after implementing the appropriate technical and security measures, each host joined a new clean network.

Conclusion

As we highlighted in the first two articles, targeted ransomware attacks have increased massively over the past months. Many of them are all using a similar, quite manual, attack pattern as we highlighted. In this article, we provided an in-depth view of a relatively new ransomware family named LockBit. Based on a real-life case as encountered by Northwave, we described a typical ransomware attack including the modus operandi of attackers, the recovery process, an insight in the underground that advertises the ransomware and a full technical break-down of the ransomware itself. Additionally, during our analysis, we were able to obtain multiple samples of the LockBit ransomware with which we could provide an extensive list of IOCs. McAfee will continue monitoring this threat.

Learn from the articles, identify which technology can give you visibility inside your network. What digital evidence sources do you have, and can you detect fast enough to preserve and respond? If you were not able to prevent the ‘initial access stage’, make sure to have a strong Defense-in-Depth by having multiple defence technologies in place. In case a ransomware attack does strike your organization, have a proper backup procedure in place to successfully restore operations on your own? For additional ransomware prevention tips please visit www.NoMoreRansom.org.

To learn more about how McAfee products can defend against these types of attacks, visit see our blog on how ENS 10.7 Rolls Back the Curtain on Ransomware.

MITRE TAXONOMY

Technique ID Technique Description
T1107 File Deletion
T1055 Process Injection
T1112 Modify Registry
T1215 Kernel Modules and Extensions
T1060 Registry Run Keys / Start Folder
T1179 Hooking
T1055 Process Injection
T1179 Hooking
T1124 System Time Discovery
T1046 Network Service Scanning
T1083 File and Directory Discovery
T1016 System Network Configuration Discovery
T1012 Query Registry
T1082 System Information Discovery
T1057 Process Discovery
T1063 Security Software Discovery
T1047 Windows Management Instrumentation
T1035 Service Execution
T1075 Pass the Hash

IOC’s

SHA256 Compile TimeStamp
ffbb6c4d8d704a530bdd557890f367ad904c09c03f53fda5615a7208a0ea3e4d 1992:06:20
286bffaa9c81abfb938fe65be198770c38115cdec95865a241f913769e9bfd3f 2009:02:12
76a77def28acf51b2b7cdcbfaa182fe5726dd3f9e891682a4efc3226640b9c78 2009:02:12
faa3453ceb1bd4e5b0b10171eaa908e56e7275173178010fcc323fdea67a6869 2009:02:12
70cb1a8cb4259b72b704e81349c2ad5ac60cd1254a810ef68757f8c9409e3ea6 2019:11:29
ec88f821d22e5553afb94b4834f91ecdedeb27d9ebfd882a7d8f33b5f12ac38d 2019:12:01
13849c0c923bfed5ab37224d59e2d12e3e72f97dc7f539136ae09484cbe8e5e0 2019:12:11
6fedf83e76d76c59c8ad0da4c5af28f23a12119779f793fd253231b5e3b00a1a 2019:12:17
c8205792fbc0a5efc6b8f0f2257514990bfaa987768c4839d413dd10721e8871 2019:12:18
15a7d528587ffc860f038bb5be5e90b79060fbba5948766d9f8aa46381ccde8a 2020:01:23
0f5d71496ab540c3395cfc024778a7ac5c6b5418f165cc753ea2b2befbd42d51 2020:01:23
0e66029132a885143b87b1e49e32663a52737bbff4ab96186e9e5e829aa2915f 2020:01:23
410c884d883ebe2172507b5eadd10bc8a2ae2564ba0d33b1e84e5f3c22bd3677 2020:02:12
e3f236e4aeb73f8f8f0caebe46f53abbb2f71fa4b266a34ab50e01933709e877 2020:02:16
0f178bc093b6b9d25924a85d9a7dde64592215599733e83e3bbc6df219564335 2020:02:16
1b109db549dd0bf64cadafec575b5895690760c7180a4edbf0c5296766162f18 2020:02:17
26b6a9fecfc9d4b4b2c2ff02885b257721687e6b820f72cf2e66c1cae2675739 2020:02:17
69d9dd7fdd88f33e2343fb391ba063a65fe5ffbe649da1c5083ec4a67c525997 2020:02:17
0a937d4fe8aa6cb947b95841c490d73e452a3cafcd92645afc353006786aba76 2020:02:17
1e3bf358c76f4030ffc4437d5fcd80c54bd91b361abb43a4fa6340e62d986770 2020:02:17
5072678821b490853eff0a97191f262c4e8404984dd8d5be1151fef437ca26db 2020:02:20
ca57455fd148754bf443a2c8b06dc2a295f014b071e3990dd99916250d21bc75 2020-02-20

 

The post Tales From the Trenches; a Lockbit Ransomware Story appeared first on McAfee Blog.

On Drovorub: Linux Kernel Security Best Practices

Intro

In a U.S. government cyber security advisory released today, the National Security Agency and Federal Bureau of Investigation warn of a previously undisclosed piece of Linux rootkit malware called Drovorub and attribute the threat to malicious actor APT28. The report is incredibly detailed and proposes several complementary detection techniques to effectively identify Drovorub malware activity. A multitude of investigative methods are suggested given that the common issue with rootkits is that large scale detection on a host can be a real challenge. The NSA and FBI have been explicit in their report that systems with a kernel version of 3.7 or lower are most susceptible to Drovorub malware due to the absence of adequate kernel signing enforcement.

Keeping a system updated and fully protected isn’t specific to Windows-based environments. Linux based systems are widespread within many enterprise organizations, requiring the same maintenance as any modern operating system. Linux offers a robust, secure computing platform which can meet many needs. As in most cases, proper configuration is key to the security of the platform.

For specific McAfee technology protections against Drovorub please visit the dedicated Drovorub KB article here.

In addition to the guidance provided in the  U.S. government report and our product specific knowledge base article, McAfee encourages organizations to take note of and apply the following best practices (where possible) for rootkit detection and kernel security.

Scanning for Rootkits

Just like a malware scanner, a rootkit scanner can scan low level processes to determine if any malicious code is loaded at bootup. For example, below are examples of software that can be used for general rootkit detection:

  • Chrootkit – A rootkit scanner for Linux to discover hard to find rootkits
  • Rkhunter – A rootkit scanner for Linux to discover backdoors and possible local exploits.

In this specific Drovorub case the advice is given to forensically analyze a machine’s memory with tools like Volatility. Using the Volatility plugin “Linux_Psxview” presence of the Drovorub client can be detected even though it doesn’t show up in the normal PSlist.

Linux Kernel hardening

Today’s advisory suggests that organizations enable UEFI Secure Boot in “full” or “thorough” mode on x86-64 systems. UEFI Secure Boot requires cryptographically signed firmware and kernels. Because no unsigned drivers can be loaded for hardware, this action will decrease the attack surface by making it more difficult for an attacker to insert a malicious kernel module into the system and for unsigned rootkits to remain persistent after reboot.

Organizations should take note, however, that Secure Boot is not integrated in all Linux distros. There are also some challenges with enabling Secure Boot. Often it requires manual intervention any time a kernel or module is upgraded or may prevent some products from loading. This knowledge base article from VMWare discusses ways to address these Secure Boot issues

Securing the kernel

There are several steps organizations can take to secure the Linux kernel and take advantage of the features that are provided. We will highlight some of the best-practices that can be used and applied. Please apply these within a test-environment before applying them in production.

Kernel module signing

Since Linux 3.7, the kernel has supported digital signatures on loadable kernel modules. This facility can be enabled in the kernel with settings in CONFIG_MODULE_SIG. These options can require valid signatures; enable automatic module signing during the kernel build phase; and specify which hash algorithm to use. Additionally, local or remote keys can be used. By requiring valid digital signatures, only known valid modules can be loaded, decreasing your system’s attack surface.

Module loading rules

Only known modules should be loadable. Limited module support can be enabled by default, disallowing kernel module loading and specifying which modules are exempt from the ban. The following command can be used to disable the loading:

sysctl kernel.modules_disabled=1

Some modules required for system operation may normally be loaded during system operation and not at boot.  To ensure these modules are available, they must be loaded at startup prior to when loading is disabled. To load these modules, list them in a file located in /etc/modules-load.d.

Disabling modules completely

Depending on the system in question, disabling all non-necessary hardware in the kernel configuration and building all required driver code directly into the kernel rather than using modules could allow for completely disabling loadable kernel module support. For special use systems, this may be a viable option. By disallowing modules entirely, your system’s attack surface can be drastically reduced.

Fully disabling kernel module support might only be possible for special purpose systems with a known usage pattern. General purpose, user-facing machines will likely need module support to support user access patterns.

Using Linux kernel Lockdown

The lockdown patches have been merged into the kernel since version 5.4. Even if Secure Boot is enabled, if not prevented, the root could still modify the kernel and, for example, apply a hot-patch and create a persistent process.  Lockdown was developed to provide a policy to prevent the root from modifying the kernel code. Lockdown has two modes: “integrity” and “confidentiality”. The community generally advises organizations to consider the “integrity” mode and use “confidentiality” mode for special systems.

Harden sysctl.conf

The sysctl.conf file is the main kernel parameter configuration point for a Linux system. By using secure defaults, the whole system will benefit from a more secure foundation. Example options include disabling IPv6 if not in use, ignoring network broadcast packets, enabling ASLR, and activating DEP/NX. (https://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-security-hardening/)

Enable SELinux or AppArmor

Modern Linux systems include the security enhancement systems of AppArmor or SELinux depending on the distribution. These allow for granular access control with security policies. SElinux is installed and enabled by default on CentOS and RedHat Enterprise Linux operating systems, while AppArmor is installed and enabled by default on Ubuntu and SuSE Linux Enterprise systems.

What we often observe is that people will decide to disable these security enhancement systems as soon as they run into an issue since they is easy to disable with root privileges. But taking the time to learn how to allow services and fix issues is very important to provide an additional layer of security on a Linux system.

AppArmor is a Linux kernel security module that provides capabilities similar to SELinux. While SELinux operates on files (specifically inodes) and requires filesystem support, AppArmor works on paths, while being file system agnostic. Considered by many to be easier to use, it is mostly transparent to regular users. While SELinux can be (potentially) more secure, the complexity of the system has many users preferring AppArmor.

Among the mainline Enterprise-level Linux distributions, RedHat embraces SELinux, while SuSE Enterprise embraces (and owns the trademark to) AppArmor. Canonical is a significant contributor to AppArmor as well, and supports it by default in Ubuntu.

Additional Linux System hardening

In light of today’s advisory, we have focused mostly on securing the Linux Kernel in this article. However, there are many best practices to secure Linux (or nearly any modern operating system), including:

  • Removal of unused software
  • Disabling unused services
  • Enabling auditing
  • Controlling API access
  • Limiting root account usage
  • Incorporating a least-privilege policy as much as possible
  • Backing up your system
  • Increasing ASLR entropy via sysctl to make reliable exploitation more difficult, by increasing the number of locations libraries that could be stored in memory.

Detailed hardening and securing guides for Linux distributions can be downloaded from:

https://www.cisecurity.org/cybersecurity-best-practices/

Conclusion

Linux Kernel and System hardening may prove to hold a learning curve for organizations and administrators more familiar with the configuration and use of Windows operating systems. However, given the information provided in the NSA-FBI publication and the adaptation of Linux-based malware by threat actors overall, we advise organizations remain vigilant, harden Linux systems as much as possible, and deploy adequate security products.

For specific McAfee technology protections against Drovorub please visit the dedicated Drovorub KB article here.

 

The post On Drovorub: Linux Kernel Security Best Practices appeared first on McAfee Blog.

Take a “NetWalk” on the Wild Side

How to check for viruses

Executive Summary

The NetWalker ransomware, initially known as Mailto, was first detected in August 2019. Since then, new variants were discovered throughout 2019 and the beginning of 2020, with a strong uptick noticed in March of this year.

NetWalker has noticeably evolved to a more stable and robust ransomware-as-a-service (RaaS) model, and our research suggests that the malware operators are targeting and attracting a broader range of technically advanced and enterprising criminal affiliates.

McAfee Advanced Threat Research (ATR) discovered a large sum of bitcoins linked to NetWalker which suggest its extortion efforts are effective and that many victims have had no option other than to succumb to its criminal demands.

We approached our investigation of NetWalker with some possible ideas about the threat actor behind it, only to later disprove our own hypothesis. We believe the inclusion of our thinking, and the means with which we debunked our own theory, highlight the importance of thorough research and we welcome further discussion on this topic. We believe it starts valuable discussions and helps avoid duplicate research efforts by others. We also encourage our peers in the industry to share information with us in case you have more evidence.

McAfee protects its customers against the malware covered in this blog in all its products, including personal antivirus, endpoint and gateway. To learn more about how McAfee products can defend against these types of attacks, visit our blog on Building Adaptable Security Architecture Against NetWalker.

Check out McAfee Insights to stay on top of NetWalker’s latest developments and intelligence on other cyber threats, all curated by the McAfee ATR team. Not only that, Insights will also help you prioritize threats, predict if your countermeasures will work and prescribe corrective actions.

Introduction

Since 2019, NetWalker ransomware has reached a vast number of different targets, mostly based in western European countries and the US. Since the end of 2019, the NetWalker gang has indicated a preference for larger organisations rather than individuals. During the COVID-19 pandemic, the adversaries behind NetWalker clearly stated that hospitals will not be targeted; whether they keep to their word remains to be seen.

The ransomware appends a random extension to infected files and uses Salsa20 encryption. It uses some tricks to avoid detection, such as a new defence evasion technique, known as reflective DLL loading, to inject a DLL from memory.

The NetWalker collective, much like those behind Maze, REvil and other ransomware, threatens to publish victims’ data if ransoms are not paid.

As mentioned earlier, NetWalker RaaS prioritizes quality over quantity and is looking for people who are Russian-speaking and have experience with large networks. People who already have a foothold in a potential victim’s network and can exfiltrate data with ease are especially sought after. This is not surprising, considering that publishing a victims’ data is part of NetWalker’s model.

The following sections are dedicated to introducing the NetWalker malware and displaying the telemetry status before moving on to the technical malware analysis of the ransomware’s behaviour. We will explain how the decryptor works and show some interactions between NetWalker’s operators and their victims. After this, we discuss the changes in modus operandi since September 2019, especially regarding payment behaviour. Then we show our attempts, unfruitful as they were, at discovering a link between NetWalker and previous, seemingly unrelated ransomware variants. Finally, we deliver an overview of IOCs related to NetWalker and its MITRE ATT&CK techniques.

Telemetry

Using McAfee’s billion Insights sensors, we can show the global prevalence of the NetWalker ransomware.

Figure 1. McAfee MVISION Insights shows global prevalence of the NetWalker ransomware

Technical Analysis

Ransom note (pre-March 2020)

Before March 2020, the NetWalker ransom note indicated how to contact the adversary directly using anonymous email account services with random names (such as [email protected] and [email protected]):

Figure 2. Example of ransom note prior to March 2020

Ransom Note (Post-March 2020)

On 12 March 2020, a researcher shared a screenshot of a new NetWalker ransom note in a tweet and we can see that the attackers have changed the contact method significantly. Email communication has been dropped completely with victims now required to make contact through the NetWalker Tor interface where, after submitting their user key, they will then be redirected to a chat with NetWalker technical support. This change in contact method coincides with underground forum postings where NetWalker revealed it was opening its RaaS up for new affiliates. The Tor page was not the only noticeable change we will highlight in this blog.

Figure 3. Example of ransom note after March 2020

NetWalker Analysis

Figure 4. NetWalker behavior

NetWalker Resource Analysis (Pre-March 2020)

The NetWalker malware uses a custom resource type (1337 or 31337) containing its entire configuration. This file is extracted to memory and decrypted using the RC4 algorithm with a hard-coded key in the resource.

Before 12 March 2020, NetWalker used the email contact process between its support operation and the victims to proceed with payment and send the decryption program. To do this, NetWalker used its configuration file in the resource to set its encryption mode, the name of the ransom note, etc., and email contacts.

Name wwllww.exe
Size 96256 bytes
File-Type EXE
SHA 256 58e923ff158fb5aecd293b7a0e0d305296110b83c6e270786edcc4fea1c8404c
Compile time 6 December 2019

Figure 5. NetWalker resource from wwllww.exe

Once decrypted, the configuration file reveals several parameters, allowing us to understand how it works (how it constitutes the ransom note, the number of threads allocated for encryption, etc.):

mpk Public key
mode Encryption mode
thr Allocated threads for encryption process
spsz Encryption chunk
namesz Name length
idsz  ID length
crmask .mailto[email].{ID}
mail Contact mail
lfile Ransom Note name
lend B64 encoded ransom note
white Encryption whitelist
kill Processes, tasks, service names to terminate
unlocker Decryption exclusion list

NetWalker Resource Analysis (Post-March 2020)

When Netwalker changed its contact mode and switched from email to the submission of the user key directly on the web portal of the group’s blog, the configuration file in the resource also changed.  We found changes in the configuration file, such as the disappearance of the contact “mail” and “crmask” fields (previously set as [email protected],[email protected], etc., and .mailto[email].{ID}). This field was replaced by “onion1” and “onion2”, and these fields are set with the NetWalker blog URL/payment page (hxxp://rnfdsgm<snip>drqqd.onion/). We also noticed that the NetWalker developers complemented their “unlocker” field with some specific values (e.g. “psexec.exe, system, forti*.exe, fmon.exe*, etc”).

Name cnt.ex
Size 70656 bytes
File-Type EXE
SHA 256 26dfa8512e892dc8397c4ccbbe10efbcf85029bc2ad7b6b6fe17d26f946a01bb
Compile time 2 May 2020

Figure 6. NetWalker resource from cnt.ex

Usually, attackers use RC_DATA or a malicious BITMAP. The latter can, for example, be a regular Bitmap (open matrix image format used by Windows) that can be used by malware to execute code or as a payload dropper. The image’s pixels are an actual binary representation of the payload. This process can be summarized as Exe -> Resources -> BMP with embedded data in pixels fetched and decrypted by, e.g. a DLL -> Payload), etc. However, in this case, they use this special custom type to increase obfuscation. The NetWalker developers chose custom types by using 1337 or 31337 structs, so the resource format does not change. However, as we said, several values have changed or been replaced:

mpk Public Key
mode Encryption mode
spsz Encryption chunk
thr Allocated threads for encryption process
namesz Name length
idsz ID length
lfile Ransom Note name
onion1 Blog URL 1
onion 2 Blog URL 2
white Encryption whitelist
kill Processes, tasks, service names to terminate
net Network resources encryption
unlocker Decryption exclusion list
lend B64 encoded ransom note

 

NetWalker Executable Analysis (Post-March 2020)

The malware sample used for this blog post has the same information:

Name c21ecd18f0bbb28112240013ad42dad5c01d20927791239ada5b

61e1c6f5f010

Size 70656 bytes
File-Type EXE
SHA 256 c21ecd18f0bbb28112240013ad42dad5c01d20927791239ada5b

61e1c6f5f010

Compile time 2 May 2020

The unpacked malware is a binary file of 32 bits that can be found as an EXE file.

Figure 7. Information sample of the malware

The malware’s first action is to combine all the required functions it needs into one large function, combining the modules already loaded in Windows with additional DLLs as described below.

Instead of searching for the function in the usual way, the malware makes a CRC32 hash of the name of each function and compares with hardcoded values. Additionally, instead of using the function “GetProcAddress”, the malware uses the Process Environment Block (PEB) to make analysis harder.

Figure 8. Get the module accessing the PEB and using a CRC32

If the module cannot be discovered, it will load with “LdrLoadDll”, a native function of Windows, to try avoiding hooks in the usual functions, e.g. “LoadLibraryW”:

Figure 9. Load library using LdrLoadDll

Figure 10. Get functions from module, e.g. using a CRC32 hash

If the malware fails to get a function, it will go to a “sleep” call and terminate itself.

Later, the malware extracts the configuration file from a resource with a custom type and a custom name using the functions “FindResourceA”, “LockResource”, “LoadResource” and “SizeOfResource”. The file extracted in memory is decrypted using the RC4 algorithm with a hardcoded key in the resource.

The struct of the resource is:

  • 4 bytes -> The size of the hardcoded key to decrypt the configuration file.
  • Variable size -> the hardcoded key to decrypt the configuration file.
  • Variable size -> the configuration file encrypted.

The malware reads the first 4 bytes and reserves memory with the size of the password and reserves memory of the resource minus 4 bytes and the size of the password. Finally, it decrypts the configuration file:

Figure 11. Get configuration file and decrypt it

If the malware fails to get the configuration file, it will terminate itself.

After getting the configuration file, the malware will parse it and save the fields in memory and write in the registry information to encrypt the files in the machine. The malware will try first to write in the registry-hive “HKEY_LOCAL_MACHINE” but if it cannot create it, it will use the registry-hive “HKEY_CURRENT_USER”:

Figure 12. Write in the registry

After the writing in the registry has been completed, it will get some privileges using a token as SE_DEBUG_PRIVILEGE and SE_IMPERSONATE_PRIVILEGE:

Figure 13. Get some special privileges in the token

Later, the malware creates three threads, one to get information about the machine, such as the operating system version, one to get processes and the last one to get services in the system.

After this step, it will get the system directory and use “VSSadmin” to delete the Volume Shadow copies of the system. Volume Shadow copies can contain copies of the encrypted files and would be an option to restore from if no backup exists.

Figure 14. Delete the shadow volumes

Later, the malware will enumerate the logical units, prepare the new extension for the future encrypted files, based on the size that is defined in the ransomware config with a random extension, and encrypt all files in the fixed type units and remote units with the new extension.

Figure 15. Crypt the files

After all these steps have been completed, it will create the ransom note on the desktop using the functions “SHGetFolderPathlW” and “CreateFileW”. Subsequently, it will write the ransom note from the memory into a new file with the function “WriteFile”. The malware will create the ransom note in the root folder (for example “c:\”) of each logical unit. Next, it will launch “notepad.exe” with an argument to the ransom note file to show the user what happened on the system:

Figure 16. Creation of the ransom note in the desktop and root units

Finally, after the encryption of the files and creation of the ransom note, the malware creates a bat file in the %temp% folder of the machine with a temporary name and writes the content to destroy itself using the program “taskkill”. The batch script will delete the malware sample with its path using the command “del” and finally delete the bat file with the command “del %0%”. Of course, as the malware uses the “del” command without destroying itself before the deletion, it can be recovered with some forensic tools with luck (the same can also be said for the bat file).

This way the malware tries to remove itself from the machine to avoid being detected and analyzed by security researchers:

Figure 17. Get Temp path and make a temporary file as a bat and launch it

Finally, the malware will finish with “ExitProcess”.

Decryptor

When a NetWalker victim goes through technical support (see an example of this below) and pays the ransom demanded by the group they will be able to download the decryptor to clean up their environment.

Figure 18. Conversation with NetWalker operators

The download is done directly from the NetWalker Tor site, where the payment page switches to a download page certifying that the payment was made and received:

Figure 19. Decryptor download

The decryptor is delivered in a zip archive containing the decryptor executable and a note explaining how to run the program correctly:

Figure 20. Decryptor delivery

The program launches a graphical interface allowing the user to decipher their workstation automatically or manually:

Figure 21. Decryptor execution

At the end of the decryption process, the program indicates the number of decrypted files, deletes the ransom note if the user has checked that option, and terminates, leaving the user to resume their work peacefully:

Figure 22. Decryptor has finished the decryption process

The decryptor program appears unique and is linked to one victim specifically. In our example, it only decrypts the files belonging to the victim who made the payment from the user key specified in the ransom note.

Underground Advertising

In March 2020, the moniker Bugatti began actively advertising the NetWalker Ransomware-as-a-Service on two popular underground fora. Bugatti seems to have joined the underground scene in February 2020 but claims to have been active with NetWalker ransomware since September 2019. We have seen NetWalker activity before March but there has been a noticeable uptick in larger victims since their advertisement. For a relatively new ransomware it has been well received and respected among other cybercriminals as compared to, for instance, Nemty ransomware. The strength of NetWalker’s reputation is such that our current hypothesis is that the individual behind Bugatti is most likely a well-respected and experienced cybercriminal, even though it is a new moniker.

Figure 23. Bugatti advertising NetWalker on an underground forum

Bugatti provides regular updates on the improvements in the ransomware, such as the popular Invoke-ReflectivePEInjection method, also commonly used by Sodinokibi. In addition to the improvements in the ransomware, open slots for new affiliates are advertised. Bugatti strongly emphasized that they are primarily looking for experienced affiliates that focus on compromising the complete networks of organizations as opposed to end users. NetWalker is clearly following in the footsteps of its illustrious targeted ransomware peers like Sodinokibi, Maze and Ryuk.

One forum message in particular caught our attention as it included screenshots of several partial bitcoin addresses and USD amounts. This was most likely done to showcase the financial success of the ransomware. We have seen a similar posting in the past with the influential Sodinokibi affiliate Lalartu, so we decided to follow the money once more.

Figure 24. Bugatti is looking for advanced affiliates and shows samples of BTC payments

With the help of CipherTrace software we were able to find the complete BTC addresses from the screenshot and investigate the ledger further:

Screenshot 1

3JHTYZhRmMcq7WCKRzFN98vWvAZk792w9J

Screenshot 2

39aovzbz5rGoQdKjDm6JiybkSu1uGdVJ2V

Screenshot 3

39NRnZtgACDVhhmc7RwmvH9ZDUKTNwwaeB

Screenshot 4

3L4AW5kHnUCZBBjg2j1LBFCUN1RsHPLxCs

Following the Money

In the transactions mentioned in the underground forum post, the ransom amount payed by the victims is presumably shown. Since the bitcoin blockchain is a publicly accessible ledger, we can follow the money and see where the ransomware actors are transferring it to. In the case of the four posted transactions above, the full amount payed by the victim was transferred to two addresses (these addresses begin with bc1q98 and 1DgLhG respectively). It is safe to say that these two bitcoin addresses are under control of the NetWalker actors. We then proceeded on to analyze all incoming transactions to these two addresses and we were able to make the following observations:

  • The first incoming transaction occurs on 1 March 2020.
  • On 30 March 2020 the first incoming transaction appears where the amount is split between 4 different bitcoin addresses. A split like this is typically seen in Ransomware-as-a-Service, where the ransom payment is split between the RaaS operators and the affiliate who caused the infection. In this first transaction, the split is 80%, 10% and two 5% portions. This split matches the advertisement on the underground forum (80% – 20%).
  • The two 5% portions of the ransom payments that are split, seem to be consistently transferred to the two bitcoin addresses we revealed earlier (bc1q98 and 1DgLhG).
  • While the beneficiaries of the 5% cuts remain the same, the beneficiary of the 10% cut seems to change over time. Based on the forum post we assume these addresses also belong to the NetWalker actors.
  • Payments to the bc1q98 and 1DgLhG addresses that are not being split continue up until the end of May. Possibly the initial NetWalker operators added a RaaS operation, while continuing to cause NetWalker infections themselves.
  • While analyzing the bitcoin addresses that received 80% or more of the transaction amount, we noticed that there are some addresses that receive payments multiple times. A possible explanation could be that the address is configured as payout addresses for a certain campaign or affiliate. We identified 30 unique bitcoin addresses that seem to be the beneficiary of this larger portion of the ransom transaction. Some of these only received one payment but there are several that received multiple payments.
  • In the two addresses uncovered by tracing the transactions a total of 641 bitcoin is held on 27 July 2020. Which at the current market value of bitcoin is worth well over 7 million USD.

Amounts Extorted

Working under the hypothesis that all the incoming transactions are ransomware payments; we can make the following observations:

  • We found 23 transactions where the ransom payments were not split up and the beneficiaries are the two bitcoin addresses found by following the transactions mentioned in the underground forum post. The total amount of bitcoin extorted this way between 1 March 2020 and 27 July 2020 is 677 BTC. Additionally, the amount received from remaining transactions following the Ransomware-as-a-Service scheme by these addresses between 1 March 2020 and 27 July 2020 is 188 BTC.
  • In the transactions that are split, the largest amount (usually 80% to 90% of the total transaction value) is presumably transferred to the affiliate that caused the infection. When we summed up these largest portions, we saw a total of 1723 BTC being transferred to affiliates.
  • The total amount of extorted bitcoin that has been uncovered by tracing transactions to these NetWalker related addresses is 2795 BTC between 1 March 2020 and 27 July 2020. By using historic bitcoin to USD exchange rates, we estimate a total of 25 million USD was extorted with these NetWalker related transactions.

Even though we do not have complete visibility into the BTC flow before NetWalker started ramping up, one thing is certain, this quarter alone it has been highly successful at extorting organisations for large amounts of money. All this at a time when many sectors are struggling because people are sheltering in place and governments are trying to keep businesses from going bankrupt. NetWalker is making millions off the backs of legitimate companies.

Figure 25. Overview of uncovered bitcoin transactions, highlighting the two identified actor addresses.

Observed Changes

While talking about the impact of NetWalker with our partners, we learned that the change in modus operandi not only affected the way the actors communicate with their victims. When there was a change from email communication to a dedicated Tor hidden service, the actors also moved away from using legacy bitcoin addresses to SegWit addresses. The benefits of using the newer SegWit addresses include faster transaction time and lower transaction cost. The NetWalker advertisement on the underground forum mentions instant and fully automatic payments around the time of this observed change. This makes us believe the ransomware actors were professionalizing their operation just before expanding to the Ransomware-as-a-Service model.

Comparison with Previous Ransomware

Given the sudden appearance of NetWalker ransomware and the associated threat actor, it suggests that some prior knowledge on ransomware development or underground presence had to be in place. Armed with this hypothesis, we searched for possible links to underground actors and other ransomware strains that might fit the bill. We came across one threat actor offering ransomware that caught our attention. It was the use of the name NetWalker, in combination with a strong ransomware connection, that sparked our interest.

Some years ago, a threat actor using the moniker Eriknetwalker was advertising ransomware on several underground forums. We found posts from 2016 and the latest public activity was around June 2019, several months before NetWalker ransomware made its appearance.

Figure 26. Eriknetwalker began advertising their ransomware in 2016 (Google-translated from Russian)

Based on our underground research, we linked the moniker Eriknetwalker to the development and/or distribution of Amnesia, Bomber and Scarab ransomware. Eriknetwalker stopped advertising ransomware around June 2019. Therefore, we decided to perform a comparative analysis between the different ransomware strains linked to Eriknetwalker and some of the earliest versions of NetWalker we could find.

The goal of this comparative analysis was to identify whether there was an overlap between source codes. Such overlap could suggest a stronger link between the current NetWalker version and the other ransomware versions from Eriknetwalker, possibly even explaining the name overlap.

To execute the analysis, we used several tools one of which was the binary visualization tool Veles, which dynamically translates binary information into an abstract visualization that allows us to identify and compare patterns.

The different types of ransomware we began analyzing were the variants of Amnesia, Scarab, and NetWalker.

Figure 27. Flat visualization of binary data of the different ransomware variants

Figure 28. 3D visualization of binary data of the different ransomware variants

Visualizing data in such a manner is a way to use the human brain to quickly identify patterns and be able to draw comparisons between objects. In our case, we see that, based on the binary data visualized in Figures 27 and 28, the ransomware binaries do yield differences that we cannot ignore.

Figure 29. Comparison of source code results

Figure 29 shows the results of a source code similarity analysis led on the different variants of ransomware named in the figure itself. Interesting enough, Scarab and Amnesia show a higher overlap with Buran and Zeppelin than the early NetWalker samples. The percentages shown are the amount of code that is similar between two variants.

As illustrated in the overview, the September 2019 NetWalker version has a different codebase from the ErikNetWalker-linked ransomware variants. This finding disproves our earlier hypothesis that NetWalker is linked to the older Amnesia variants based on code overlap.

Often, research teams do not publish their results when it disproves their own hypothesis. However, for the sake of transparency, we decided to include our research efforts.

YARA Rules

We uploaded a YARA rule to detect almost all the samples observed in the wild to date.

Indicators of Compromise

During our investigation we have observed numerous IoCs linked to NetWalker ransomware. To obtain them please visit our McAfee ATR GitHub site, or get the latest NetWalker IoCs and intelligence on many other threats with McAfee Insights.

MITRE ATT&CK Techniques

The below techniques were based on our research and complemented with research from industry peers.

  • Initial Access
    • Exploit Public-Facing Application (T1190) : Exploit Tomcat, Exploit WebLogic
    • Spear phishing Attachment (T1566.001): Phishing email
    • Valid Accounts (T1078): RDP compromised
  • Execution
    • PowerShell (T1059.001): PowerShell Script
    • Command and Scripting Interpreter: Windows Command Shell (003)
    • Service Execution (T1569.002): PsExec
    • Native API (T1106): Use Windows API functions to inject DLL
    • Windows Management Instrumentation (T1047)
  • Persistence
    • Registry Run Key (T1547.001): Place a value on RunOnce key
    • Modify Registry key (T1112): Create its own registry key in \SOFTWARE\<uniquename>
  • Privilege Escalation
    • Exploitation for Privilege Escalation (T1068): CVE-2020-0796, CVE-2019-1458, CVE-2017-0213, CVE-2015-1701
    • Process Injection (T1055.001): Reflective DLL Injection
  • Defense Evasion
    • Disabling Security Tools (T1562.001): ESET AV Remover, Trend Micro’s Security Agent Uninstall Tool, Microsoft Security Client Uninstall
    • Process Injection (T1055.001): Reflective DLL Injection
    • Deobfuscate/Decode Files or Information (T1140)
    • Obfuscated Files or Information (T1027): PowerShell Script uses Base64 and hexadecimal encoding and XOR-encryption
  • Credential Access
    • Credential Dumping (T1003): Mimikatz, Mimidogz, Mimikittenz, Windows Credentials Editor, Pwdump, LaZagne
    • Brute Force (T1110.001): NLBrute
  • Discovery
    • Network Service Scanning (T1046): SoftPerfect Network Scanner
    • Security Software Discovery (T1518.001)
    • System Information Discovery (T1082)
  • Lateral Movement
    • Third-Party Software (T1072): TeamViewer, Anydesk
    • Service Execution (T 1569.002): PsExec
    • Lateral Tool Transfer (T1570)
  • Collection
    • Data from information repositories (T1213)
    • Data from local system (T1005)
    • Data from network shared drive (T1039)
  • Command and Control
    • Ingress Tool Transfer (T1105)
  • Impact
    • Data Encrypted (T1486): NetWalker Ransomware
    • Inhibit System Recovery (T1490): Shadow Copies Deleted
    • Service Stop (T1489)

Conclusion

Ransomware has evolved into a lucrative business for threat actors, from underground forums selling ransomware, to offering services such as support portals to guide victims through acquiring crypto currency for payment, to the negotiation of the ransom. McAfee’s Advanced Threat Research team has analysed the NetWalker ransomware and have been following its evolution from the initial sighting of the Mailto ransomware to its redevelopment into the NetWalker ransomware. The recent shift to a business-centric model of Ransomware-as-a-Service is a clear sign that it is stepping up, so it seems that the NetWalker group is following in the footsteps of REvil and other successful RaaS groups. The ransomware developers have proven the ability to refocus and capitalize on current world events and develop lures to help ensure the effectiveness of the ransomware, which has allowed them to become selective of their affiliates by limiting access to the ransomware to only those with vetted access to large organizations. As development of the ransomware continues, we have witnessed recent shifts in activity that closely follow in the footsteps of other ransomware developments, including threatening victims with the release of confidential information if the ransom is not met.

McAfee ATR is actively monitoring ransomware threats and will continue to update McAfee MVISION Insights and its social networking channels with new and current information. MVISION Insights is the only proactive endpoint security solution that simultaneously prioritizes and predicts threats that matter to our customers while offering prescriptive guidance on what to do in their local environment. Want to stay ahead of the adversaries? Check out McAfee MVISION Insights for more information. If you want to experience some of the MVISION Insights capabilities, go the Preview of MVISION Insights where you can select the top threat information that is available.

Authored by: Thibault Seret, Valentine Mairet, Jeffrey Sman, Alfred Alvarado, Tim Hux, Alexandre Mundo, John Fokker, Marc Rivero Lopez and Thomas Roccia.

The post Take a “NetWalk” on the Wild Side appeared first on McAfee Blog.

❌
❌