RSS Security

❌ About FreshRSS
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


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:

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:

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.


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

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
  • 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
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:


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.


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.


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

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.


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


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

Analysis of LooCipher, a New Ransomware Family Observed This Year

5 December 2019 at 15:00

Co-authored by Marc RiveroLopez.

Initial Discovery

This year seems to again be the year for ransomware. Notorious attacks were made using ransomware and new families are being detected almost on a weekly basis.

The McAfee ATR team has now analyzed a new ransomware family with some special features we would like to showcase. LooCipher represents how a new actor in an early stage of development used the same techniques of distribution as other players in the ransomware landscape. The design of the ransomware note reminded us of the old times of Cerber ransomware, a very well impacted design to force the user to pay the rescue.

Thanks to initiatives like the ‘No More Ransom’ project, one of the partners involved has already provided a valid decryptor to restore files encrypted by LooCipher.

McAfee Telemetry

Based on the data we manage, we detected LooCipher infections in the following regions:

Campaign Analysis:

Based on the analysis we performed, this ransomware was delivered through a DOC file. The content and techniques used with this MalDoc are quite simple compared to other doc files used to spread malware, such as Emotet. No special social engineering techniques were applied; the authors only put a simple message on it – “Enable macros”.

The file is prepared to download LooCipher from a remote server upon opening the file. We can see the Sub AutoOpen function as a macro in the document:

LooCipher will start its encryption routine using a predefined set of characters, creating a block of 16 bytes and using the local system hour:

The ransomware will use the AES-ECB encryption algorithm in the process and the key is the same for all the files which facilitates the file recovery process. Other ransomware families use a different key for each file to avoid the possibility of a brute force attack discovering the key used during the infection.

In the encryption process, the ransomware will avoid 3 special folders in the system so as to not break their functionality.

Encrypting key files and folders was one of the mistakes we highlighted in our analysis of LockerGoga; that ransomware was completely breaking the functionality of the system. Some binaries found were encrypting all the system, including the LockerGoga binary file.

Regarding the extensions that LooCipher will search and encrypt in the system, the list is hardcoded inside the binary:

It is quite interesting see how LooCipher searches for extensions that are not present in Windows systems like “.dmg.” This suggests that the authors may just be going to code sites to find extension lists.

In the analysis we found a PDB reference:


It is interesting to note that the reference found contains Spanish words, as if the user was using folders named in Spanish, however, the system is configured in English. We currently have no idea why this is so, but it is curious.

BTC payment is the method chosen by LooCipher authors to get money from the victims. So, at the end of the file’s encryption, the ransomware will show a rescue note to the user:

LooCipher decryptor will pop up in the system as well with a specific countdown:

In the ransom note LooCipher says the BTC address is specifically generated for the user but that is not true; all the BTC addresses we have seen are hardcoded in the binary:

This is another special characteristic for this ransomware. Normally, this workflow is providing an email address to contact the authors so they can provide the instructions to the victim, or at least a BTC address to make payment (if there is not a unique BTC address provided to every victim), something that is the main difference between RaaS and one-shot campaigns.

If we apply static analysis in the binaries we have, the same bundle of BTC addresses is included across most that we spot in the wild:

None of the BTC addresses found regarding LooCipher showed any transactions so we believe the authors did not monetize the campaign with the binaries we analyzed.

LooCipher and Network Traffic:

In the encryption process, LooCipher will contact the C2 server and send information about the victim:

The data sent to the server is:

Here, a copy of the network traffic could help the user to know the encryption key used.

Decryptor Fallback Mechanism Implemented by LooCipher

The LooCipher authors provide a fallback mechanism to help victims access the instructions and the decryptor again, in case they close the LooCipher window when it appears in the system after encrypting the files:

The mechanism sees the LooCipher binary uploaded to the Mega platform. In case the user wants to get the BTC address or decrypt the files after making the payment, they can download this binary and use it. If the files were previously encrypted by LooCipher they would not be encrypted again according to the ransomware’s authors.

I’m Infected by LooCipher. How Can I Get my Files Back?

McAfee is one of the founders and contributors of the ‘No More Ransom’ project. One of our fellow stakeholders created a decryptor for all the files encrypted by LooCipher:

So, if you are infected with LooCipher, it is possible get your files back.


LooCipher authors are not a sophisticated actor compared to other families like Ryuk, LockerGoga or REVil. They tried to spread their ransomware combining the infection with an Office file with a simple macro.

It will be impossible for the authors to come back to the scene if they do not change how the ransomware works.

The McAfee ATR Team advises against paying the ransomware demands and, instead, recommends:

  • Saving a copy of your encrypted files – sometimes in the future a decryptor may be released
  • Having a solid backup workflow in the company
  • Implementing best practices in terms of Cybersecurity


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

MITRE ATT&CK Coverage:

  • Hooking
  • Defense Evasion
  • Network Service Scanning
  • System Information Discovery
  • Data Compressed

McAfee Coverage:

  • Artemis!02ACC0BC1446
  • Artemis!12AA5517CB7C
  • Artemis!1B1335F20CD0
  • Artemis!362AB3B56F40
  • Artemis!64FCC1942288
  • Artemis!8F421FE340E7
  • Artemis!983EF1609696
  • Artemis!A11724DBE1D6
  • Artemis!A7ABF760411F
  • Artemis!B9246AA9B474
  • Artemis!F0D98A6809C1
  • McAfee-Ransom-O
  • Ransomware-GNY!3B9A8D299B2A
  • Ransomware-GNY!66571E3C8036
  • Ransomware-GNY!9CF3C9E4A9B5
  • Ransomware-GNY!A0609D7AD404
  • Ransomware-GNY!A77FDEFE40BE
  • Ransomware-GNY!A9B6521FF980
  • Ransomware-GNY!D3CE02AD4D75
  • Ransomware-GNY!DC645F572D1F
  • RDN/Generic Downloader.x
  • RDN/Generic.ole























































































The post Analysis of LooCipher, a New Ransomware Family Observed This Year appeared first on McAfee Blogs.

Spanish MSSP Targeted by BitPaymer Ransomware

8 November 2019 at 12:00

Co-authored by Marc RiveroLopez

Initial Discovery

This week the news hit that several companies in Spain were hit by a ransomware attack. Ransomware attacks themselves are not new but, by interacting with one of the cases in Spain, we want to highlight in this blog how well prepared and targeted an attack can be and how it appears to be customized specifically against its victims.

In general, ransomware attacks are mass-spread attacks where adversaries try to infect many victims at the same time and cash out quickly. However, this has significantly changed over the past two years where more and more ransomware attacks are targeting high-value targets in all kinds of sectors.

Victims are infected with a different type of malware before the actual ransomware attack takes place. It looks like adversaries are using the infection base to select or purchase the most promising victims for further exploitation and ransomware, in a similar way to how the sale of Remote Desktop Access on underground forums or private Telegram channels is being used for victim selection for ransomware attacks.

In the following paragraphs, we will take you step by step through the modus operandi of the attack stages and most important techniques used and mapped against the MITRE ATT&CK Framework.

The overall techniques observed in the campaign and flow visualization:

Technical Analysis

The overall campaign is well known in the industry and the crew behind it came back to the scene reusing some of the TTPs observed one year ago and adding new ones like: privilege escalation, lateral movement and internal reconnaissance.

Patient 0 – T1189 Drive-by Compromise

The entry point for these types of campaigns starts with a URL that points the user to a fake website (in case the website is compromised) or a legitimate page (in case they decided to use a pay-per-install service) using social engineering techniques; the user gets tricked to download the desired application that will use frameworks like Empire or similar software to download and install next stage malware which, in this case, is Dridex.

First infection – T1090 Connection Proxy

These types of attacks are not limited to one type of malware; we have observed it being used by:

  • Azorult
  • Chthonic
  • Dridex

It is currently unclear why one would select one malware family above the other, but these tools allow for remote access into a victim’s network. This access can then be used by the actor as a launchpad to further exploit the victim’s network with additional malware, post-exploitation frameworks or the access can be sold online.

For quite some time now, Dridex’s behavior has changed from its original form. Less Dridex installs are linked to stealing banking info and more Dridex infections are becoming a precursor to a targeted ransomware attack.

This change or adaptation is something we have observed with other malware families as well.

For this campaign, the Dridex botnet used was 199:

Information Harvesting – T1003 Credential Dumping

From the infection, one or multiple machines are infected, and the next step is to collect as many credentials as they can to perform lateral movement. We observed the use of Mimikatz to collect (high privileged) credentials and re-use them internally to execute additional software in the Active Directory servers or other machines inside the network.

The use of Mimikatz is quite popular, having been observed in the modus operandi of more than 20 different threat actors.

Lateral Movement – T1086 PowerShell

The use of PowerShell helps attackers to automate certain things once they are in a network. In this case, we observed how Empire was used for different sock proxy PowerShell scripts to pivot inside the network:

Extracting information about the IP found in the investigation, we observed that the infrastructure for the Dridex C2 panels and this proxy sock was shared.

PowerShell was also used to find specific folders inside the infected systems:

A reason for an attacker to use a PowerShell based framework like Empire, is the use of different modules, like invoke-psexec or invoke-mimikatz, that can execute remote processes on other systems, or get credentials from any of the systems where it can run Mimikatz. When deployed right, these modules can significantly increase the speed of exploitation.

Once the attackers collected enough high privileged accounts and got complete control over the Active Directory, they would then distribute and execute ransomware on the complete network as the next step of their attack, in this case BitPaymer.

Ransomware Detonation – T1486 Data Encrypted for Impact

BitPaymer seemed to be the final objective of this attack. The actors behind BitPaymer invest time to know their victims and build a custom binary for each which includes the leet-speek name of the victim as the file extension for the encrypted files, i.e. “financials.<name_of_victim>”.

In the ransomware note, we observed the use of the company name too:


  • One of the remote proxy servers used in the operation shares the same infrastructure as one of the C2 panels used by Dridex.
  • We observed how a Dridex infection served as a launch point for an extensive compromise and BitPaymer ransomware infection.
  • Each binary of Bitpaymer is specially prepared for every single target, including the extension name and using the company name in the ransomware note.
  • Certain Dridex botnet IDs are seen in combination with targeted BitPaymer infections.
  • Companies must not ignore indicators of activity from malware like Dridex, Azorult or NetSupport; they could be a first indicator of other malicious activity to follow.
  • It is still unclear how the fake update link arrived at the users but in similar operations, SPAM campaigns were most likely used to deliver the first stage.

McAfee Coverage

Based on the indicators of compromise found, we successfully detect them with the following signatures:

  • RDN/Generic.hbg
  • Trojan-FRGC!7618CB3013C3
  • RDN/Generic.dx

The C2 IPs are tagged as a malicious in our GTI.

McAfee ATD Sandbox Detonation

Advanced Threat Detection (ATD) is a specialized appliance that identifies sophisticated and difficult to detect threats by executing suspicious malware in an isolated space, analyzing its behavior and assessing the impact it can have on an endpoint and on a network.

For this specific case, the ATD sandbox showcases the activity of Bitpaymer in a system:

We observe the use of icacls and takeown to change permissions inside the system and the living off the land techniques are commonly used by different type of malware.

ATD Sandbox extracted behavior signatures observing Bitpaymer detonation in the isolated environment:

Having the opportunity to detonate malware in this environment could give indicators about the threat types and their capabilities.

McAfee Real Protect

Analysis into the samples garnered from this campaign would have been detected by Real Protect. Real Protect is designed to detect zero-day malware in near real time by classifying it based on behavior and static analysis. Real Protect uses machine learning to automate classification and is a signature-less, small client footprint while supporting both offline mode and online mode of classification. Real Protect improves detection by up to 30% on top of .DAT and McAfee Global Threat Intelligence detections, while producing actionable threat intelligence.


We have a YARA rule available on our ATR GitHub repository to detect some of the versions of BitPaymer ransomware.


  • 3ab42ca8ce81f9df0c4f7cd807528c5dd0fb5108
  • 4862fbb188285586218cd96e69a2e4436827d2fe
  • c1ad6c3ab06fc527c048cd15c6fc701b5a74a900
  • 1d778359ab155cb190b9f2a7086c3bcb4082aa195ff8f754dae2d665fd20aa05
  • 628c181e6b9797d8356e43066ae182a45e6c37dbee28d9093df8f0825c342d4c
  • bd327754f879ff15b48fc86c741c4f546b9bbae5c1a5ac4c095df05df696ec4f
  • 0f630aaf8b5c4e958445ec0c2d5ec47e
  • 9b982fa4b42813279426449ddd6a1dbe
  • c46ad4159c90bc11d6d94a28458553d7

A special thanks to John Fokker and Christiaan Beek for their assistance with this blog.

The post Spanish MSSP Targeted by BitPaymer Ransomware appeared first on McAfee Blogs.

LockerGoga Ransomware Family Used in Targeted Attacks

Co-authored by Marc RiveroLopez.

Initial discovery

Once again, we have seen a significant new ransomware family in the news. LockerGoga, which adds new features to the tried and true formula of encrypting victims’ files and asking for payment to decrypt them, has gained notoriety for the targets it has affected.

In this blog, we will look at the findings of the McAfee ATR team following analysis of several different samples. We will describe how this new ransomware works and detail how enterprises can protect themselves from this threat.

Technical analysis

LockerGoga is a ransomware that exhibits some interesting behaviors we want to highlight. Based on our research, and compared with other families, it has a few unique functions and capabilities that are rare compared to other ransomware families that have similar objectives and/or targeted sectors in their campaigns.

In order to uncover its capabilities, we analyzed all the samples we found, discovering similarities between them, as well as how the development lifecycle adds or modifies different features in the code to evolve the ransomware in a more professional tool used by the group behind it.

One of the main differences between LockerGoga and other ransomware families is the ability to spawn different processes in order to accelerate the file encryption in the system:

Like other types of malware, LockerGoga will use all the available CPU resources in the system, as we discovered on our machines:

Most of the LockerGoga samples work the same way but we observed how they added and removed certain types of functionality during their development lifecycle.

The ransomware needs be executed from a privileged account.

LockerGoga works in a master/slave configuration. The malware begins its infection on an endpoint by installing a copy of itself on the %TEMP% folder.

After being copied, it will start a new process with the -m parameter.

The master process runs with the -m parameter and is responsible for creating the list of files to encrypt and spawning the slaves.

The slave processes will be executed with a different set of parameters as shown below. Each slave process will encrypt only a small number of files, to avoid heuristic detections available in endpoint security products. The list of files to encrypt is taken from the master process via IPC, an interface used to share data between applications in Microsoft Windows. The communication is done through IPC using a mapped section named SM-<name of binary>.

Here is the IPC technique used by LockerGoga:

  • The master process (run as <LockerGogaBinary> -m) creates a named section on the system for IPC.
  • The section is named “SM-tgytutrc”.
  • The master ransomware process posts the filepath of the file to be encrypted to the named section “SM-tgytutrc”.
  • This section is used by the slave processes to pick up the filepath and encrypt the target file.

Sandbox replication of master process screenshot below showing:

  • Creation of the named section.
  • Subsequent creation of slave processes to encrypt target files on the endpoint.

Sandbox replication of slave process (encryption process) below showing:

  • Obtaining access to the section created by the master process.
  • Reading and encryption of a target file found based on the filepath specified in the named section.

The ransomware creates multiple slave processes on the endpoint to encrypt files. Some analysts believe this is the case simply because it speeds up the encryption process, but we are not convinced as the same outcome can be achieved via a multi-threaded approach in the ransomware process instead of a multi-process approach.

Instead, we suspect this approach is adopted for the following reasons:

  • Footprint: If every encryption process encrypts only a small number of files on the endpoint and terminates, then the overall footprint of the attack on the system decreases since it may be difficult to co-relate multiple encryption processes to the same threat.
  • Sandbox Bypass: Some sandbox-based detection systems monitor the threshold of the number of files written on the system and may co-relate it to the file extensions being written to. E.g. If a process reads, say, 200 files on the sandbox but only creates files with one specific extension (typical of ransomware – Extn “.locked” in the case of LockerGoga) then this can be considered anomalous behavior. LockerGoga may be able to bypass such detection techniques.
  • File I/O based detection bypass: A multi-process-based approach makes sure that the amount of I/O (File/Disk I/O etc.) for each encryption process is within a certain limit, thus bypassing detection techniques that monitor exorbitant I/O based detection.
  • Reliability: Even if one encryption process is manually terminated by an end-user, as long as the master ransomware process is running the files will continue to be encrypted by new slave processes. If the ransomware process does not use the multi-process approach, then terminating the ransomware process stops the encryption on the endpoint.

Username Administrator:

Username Tinba:

The author implemented a logging function that can be enabled if you callout the sample in execution using the parameter “-l” to store all the results in a file called ‘log.txt’ in the root C drive:

During execution we enabled the log function and saw how the ransomware encrypts the system, causing high CPU usage and opening the ransom note during the process. This is the aspect in an infected system:

As we executed the sample with the log function, we could access this file to check the status of the encryption. Obviously, this most likely a debug function used by the developer.

In order to know how the ransomware works, and with the help of the log function enabled, we could establish the order of LockerGoga to encrypt the system:

  • Log file creation in the C: drive
  • Folder and file enumeration
  • File encryption & ransom note creation in the desktop folder.

One interesting thing to mention is that, before encrypting any file in the system, the malware will search for files in the trashcan folder as the first option. We are not certain why it takes this unusual step, though it could be because many people do not empty their recycle bins and the ransomware is looking to encrypt even those files that may no longer be required:

LockerGoga will start to enumerate all the folders and files in the system to start the encryption process. This enumeration is done in parallel, so we can expect the process wouldn’t take much time.

After the enumeration the ransomware will create the ransom note for the victim:

The ransom note was created in parallel with the encrypted files, and it is hardcoded inside the sample:

Like other ransomware families, LockerGoga will create the ransom note file to ask the user to pay to recover their encrypted files. We highly recommend not paying under any circumstance so as not to continue funding an underground business model. In case of a ransomware infection, please check

Below is an example of the ransom note content on an infected machine:


There was a significant flaw in the security system of your company.

You should be thankful that the flaw was exploited by serious people and not some rookies.

They would have damaged all of your data by mistake or for fun.


Your files are encrypted with the strongest military algorithms RSA4096 and AES-256.

Without our special decoder it is impossible to restore the data.

Attempts to restore your data with third party software as Photorec, RannohDecryptor etc.

will lead to irreversible destruction of your data.


To confirm our honest intentions.

Send us 2-3 different random files and you will get them decrypted.

It can be from different computers on your network to be sure that our decoder decrypts everything.

Sample files we unlock for free (files should not be related to any kind of backups).


We exclusively have decryption software for your situation


DO NOT RESET OR SHUTDOWN – files may be damaged.

DO NOT RENAME the encrypted files.

DO NOT MOVE the encrypted files.

This may lead to the impossibility of recovery of the certain files.


The payment has to be made in Bitcoins.

The final price depends on how fast you contact us.

As soon as we receive the payment you will get the decryption tool and

instructions on how to improve your systems security


To get information on the price of the decoder contact us at:

In parallel of the ransom note creation, the files will start to be encrypted by LockerGoga with the .locked extension appended to all files. This extension has been broadly used by other ransomware families in the past:

LockerGoga has embedded in the code the file extensions that it will encrypt. Below is an example:

The sample has also configured some locations and files that will be skipped in the encryption process so as not to disrupt the Operating System from running.

All the files encrypted by this ransomware will have a specific FileMarker inside:

Note: The FileMarker identifies the ransomware family and the most likely version; in this case it is 1440.

During the investigation we identified the following versions:

  • 1200
  • 1510
  • 1440
  • 1320

Based on the binary compile time and the extracted versions, we observed that the actors were creating different versions of LockerGoga for different targets/campaigns.

After encrypting, LockerGoga executes ‘cipher.exe’ to remove the free space to prevent file recovery in the infected system. When files are deleted on a system, sometimes they are still available in the free space of a hard disk and can theoretically be recovered.

Samples digitally signed:

During our triage phase we found that some of the LockerGoga samples are digitally signed. We are observing from ATR that the latest ransomware pieces used a lower scale and more focused are released digitally signed:


Digitally signing the malware could help the attackers to bypass some of the security protections in the system.

As part of the infection process, LockerGoga will create a static mutex value in the system, always following the same format:


Examples of mutex found:




Interesting strings found

In our analysis we extracted more strings from the LockerGoga samples, with interesting references to:

  • LockerGoga
  • crypto-locker
  • goga












The malware developers usually forget to remove those strings in their samples and we can use them to identify new families or frameworks used in their development.

Spreading methods:

The malware is known to be spread in the local network through remote file copy. To do that, a set of .batch files are copied to the remote machines TEMP folder using simple copy:

  • copy xax.bat \\\c$\windows\temp

The malware will copy itself and the tool PSEXEC.EXE to the same location. Once all the files are copied, the malware will run the .BAT file using the following command:

  • start psexec.exe \\ -u domain\user -p “pass” -d -h -r mstdc -s accepteula -nobanner c:\windows\temp\xax.bat

Each of these .BAT files contain lines to execute the malware on remote machines. They use the following command:

  • start wmic /node:”″ /user:”domain\user” /password:”pass” process call create “cmd /c c:\windows\temp\kill.bat”

The batch file above attempts to kill several AV products and disable security tools. At the end of the script, the malware copy on the remote machine is executed from


Due to the presence of these batch files and the fact that the malware binary makes no direct reference to them, we believe that the spreading mechanism is executed manually by an attacker or via an unknown binary. The path, username, and passwords are hardcoded in the scripts which indicate the attacker had previous knowledge of the environment.

The following is a list of all the processes and services disabled by the malware:

One batch file found in the infected systems where LockerGoga was executed will stop services and processes regarding critical services in the system and security software:

net stop BackupExecAgentAccelerator /y net stop McAfeeEngineService /y
net stop BackupExecAgentBrowser /y net stop McAfeeFramework /y
net stop BackupExecDeviceMediaService /y net stop McAfeeFrameworkMcAfeeFramework /y
net stop BackupExecJobEngine /y net stop McTaskManager /y
net stop BackupExecManagementService /y net stop mfemms /y
net stop BackupExecRPCService /y net stop mfevtp /y
net stop BackupExecVSSProvider /y net stop MMS /y
net stop bedbg /y net stop mozyprobackup /y
net stop DCAgent /y net stop MsDtsServer /y
net stop EPSecurityService /y net stop MsDtsServer100 /y
net stop EPUpdateService /y net stop MsDtsServer110 /y
net stop EraserSvc11710 /y net stop MSExchangeES /y
net stop EsgShKernel /y net stop MSExchangeIS /y
net stop FA_Scheduler /y net stop MSExchangeMGMT /y
net stop IISAdmin /y net stop MSExchangeMTA /y
net stop IMAP4Svc /y net stop MSExchangeSA /y
net stop macmnsvc /y net stop MSExchangeSRS /y
net stop masvc /y net stop MSOLAP$SQL_2008 /y
net stop MBAMService /y net stop MSOLAP$SYSTEM_BGC /y
net stop MBEndpointAgent /y net stop MSOLAP$TPS /y
net stop McShield /y net stop MSSQLFDLauncher$TPS /y
net stop MSOLAP$TPSAMA /y net stop MSSQLFDLauncher$TPSAMA /y
net stop MSSQL$BKUPEXEC /y net stop MSSQLSERVER /y
net stop MSSQL$ECWDB2 /y net stop MSSQLServerADHelper100 /y
net stop MSSQL$PRACTICEMGT /y net stop MSSQLServerOLAPService /y
net stop MSSQL$PRACTTICEBGC /y net stop MySQL57 /y
net stop MSSQL$PROFXENGAGEMENT /y net stop ntrtscan /y
net stop MSSQL$SBSMONITORING /y net stop OracleClientCache80 /y
net stop MSSQL$SHAREPOINT /y net stop PDVFSService /y
net stop MSSQL$SQL_2008 /y net stop POP3Svc /y
net stop MSSQL$SYSTEM_BGC /y net stop ReportServer /y
net stop MSSQL$TPS /y net stop ReportServer$SQL_2008 /y
net stop MSSQL$TPSAMA /y net stop ReportServer$SYSTEM_BGC /y
net stop MSSQL$VEEAMSQL2008R2 /y net stop ReportServer$TPS /y
net stop MSSQL$VEEAMSQL2012 /y net stop ReportServer$TPSAMA /y
net stop MSSQLFDLauncher /y net stop RESvc /y
net stop MSSQLFDLauncher$PROFXENGAGEMENT /y net stop sacsvr /y
net stop MSSQLFDLauncher$SBSMONITORING /y net stop MSSQLFDLauncher$SHAREPOINT /y net stop SamSs /y
net stop MSSQLFDLauncher$SQL_2008 /y net stop SAVAdminService /y
net stop MSSQLFDLauncher$SYSTEM_BGC /y net stop SAVService /y
net stop MSOLAP$TPSAMA /y net stop MSSQLFDLauncher$TPS /y
net stop MSSQL$BKUPEXEC /y net stop MSSQLFDLauncher$TPSAMA /y
net stop SDRSVC /y net stop SQLSafeOLRService /y
net stop SepMasterService /y net stop SQLSERVERAGENT /y
net stop ShMonitor /y net stop SQLTELEMETRY /y
net stop Smcinst /y net stop SQLTELEMETRY$ECWDB2 /y
net stop SmcService /y net stop SQLWriter /y
net stop SMTPSvc /y net stop SstpSvc /y
net stop SNAC /y net stop svcGenericHost /y
net stop SntpService /y net stop swi_filter /y
net stop sophossps /y net stop swi_service /y
net stop SQLAgent$BKUPEXEC /y net stop swi_update_64 /y
net stop SQLAgent$ECWDB2 /y net stop TmCCSF /y
net stop SQLAgent$PRACTTICEBGC /y net stop tmlisten /y
net stop SQLAgent$PRACTTICEMGT /y net stop TrueKey /y
net stop SQLAgent$PROFXENGAGEMENT /y net stop TrueKeyScheduler /y
net stop SQLAgent$SBSMONITORING /y net stop TrueKeyServiceHelper /y
net stop SQLAgent$SHAREPOINT /y net stop SQLAgent$SQL_2008 /y net stop UI0Detect /y
net stop SQLAgent$SYSTEM_BGC /y net stop SQLAgent$TPS /y net stop VeeamBackupSvc /y
net stop SQLAgent$TPSAMA /y net stop VeeamBrokerSvc /y
net stop SQLAgent$VEEAMSQL2008R2 /y net stop SQLAgent$VEEAMSQL2012 /y net stop VeeamCatalogSvc /y
net stop SQLBrowser /y net stop VeeamCloudSvc /y
net stop SDRSVC /y net stop SQLSafeOLRService /y
net stop SepMasterService /y net stop SQLSERVERAGENT /y
net stop ShMonitor /y net stop SQLTELEMETRY /y
net stop VeeamDeploymentService /y net stop NetMsmqActivator /y
net stop VeeamDeploySvc /y net stop EhttpSrv /y
net stop VeeamEnterpriseManagerSvc /y net stop ekrn /y
net stop VeeamMountSvc /y net stop ESHASRV /y
net stop VeeamNFSSvc /y net stop MSSQL$SOPHOS /y
net stop VeeamRESTSvc /y net stop SQLAgent$SOPHOS /y
net stop VeeamTransportSvc /y net stop AVP /y
net stop W3Svc /y net stop klnagent /y
net stop wbengine /y net stop MSSQL$SQLEXPRESS /y
net stop WRSVC /y net stop SQLAgent$SQLEXPRESS /y net stop wbengine /y
net stop MSSQL$VEEAMSQL2008R2 /y net stop kavfsslp /y
net stop SQLAgent$VEEAMSQL2008R2 /y net stop VeeamHvIntegrationSvc /y net stop KAVFSGT /y
net stop swi_update /y net stop KAVFS /y
net stop SQLAgent$CXDB /y net stop mfefire /y
net stop SQLAgent$CITRIX_METAFRAME /y net stop “SQL Backups” /y net stop “avast! Antivirus” /y
net stop MSSQL$PROD /y net stop aswBcc /y
net stop “Zoolz 2 Service” /y net stop “Avast Business Console Client Antivirus Service” /y
net stop MSSQLServerADHelper /y net stop mfewc /y
net stop SQLAgent$PROD /y net stop Telemetryserver /y
net stop msftesql$PROD /y net stop WdNisSvc /y
net stop WinDefend /y net stop EPUpdateService /y
net stop MCAFEETOMCATSRV530 /y net stop TmPfw /y
net stop MCAFEEEVENTPARSERSRV /y net stop SentinelAgent /y
net stop MSSQLFDLauncher$ITRIS /y net stop SentinelHelperService /y
net stop MSSQL$EPOSERVER /y net stop LogProcessorService /y
net stop MSSQL$ITRIS /y net stop EPUpdateService /y
net stop SQLAgent$EPOSERVER /y net stop TmPfw /y
net stop SQLAgent$ITRIS /y net stop SentinelAgent /y
net stop SQLTELEMETRY$ITRIS /y net stop SentinelHelperService /y
net stop MsDtsServer130 /y net stop LogProcessorService /y
net stop SSISTELEMETRY130 /y net stop EPUpdateService /y
net stop MSSQLLaunchpad$ITRIS /y net stop TmPfw /y
net stop BITS /y net stop SentinelAgent /y
net stop BrokerInfrastructure /y net stop EPProtectedService /y
net stop epag /y net stop epredline /y
net stop EPIntegrationService /y net stop EPSecurityService /y

New ransomware, new features, but still room to improve

We will continue tracking LockerGoga, but we have already seen some interesting features never seen before, such as parallel tasking encrypting the system or log files for debugger purposes. We did not see any spreading method used to deliver LockerGoga so it would be fair to assume it is used in targeted campaigns after the attackers had access to the system. At the time of this analysis, all the samples are not packed, or have complex methods of protection from being executed inside a sandbox system, though this could change in the near future.

Also, during the analysis, we observed LockerGoga encrypting legitimate DLLs, breaking the functionality of certain applications in the system, and also ciphering itself during the process, causing a crash:

We expect all these errors will be fixed with further development of the malware.


The McAfee ATR team is observing how some new ransomware players in the cybersecurity field are reusing, or at least only making some minor modifications to, some features used by other ransomware families.

In the case of LockerGoga we can observe the following in:

  • Sectigo as a certificate, also used to digitally sign the certificate
  • Ransom note slightly modified from Ryuk Ransomware
  • Specific FileMarker used to flag the encrypted files
  • No BTC address used in the ransom note, meaning victims must make contact directly by email, something that we have seen elsewhere in our latest investigations.

MITRE ATT&CK Coverage:


Kernel Modules and Extensions

Process Injection

Code Signing

Query Registry

Process Discovery

Data Compressed

McAfee coverage:

Detection names: 
















Expert Rules

The following expert rules can be used in Endpoint Security to block the malware from spreading. These rules are aggressive and may cause false positives, so make sure they are removed once the environment is cleaned:

Rule {

Process {



Target {

Match FILE {

Include OBJECT_NAME { -v “c:\\windows\\temp\\*.exe” }

Include OBJECT_NAME { -v “c:\\windows\\temp\\*.bat” }

Include -access “CREATE”




Rule {

Process {

Include OBJECT_NAME { -v “WmiPrvSE.exe” }


Target {


Include OBJECT_NAME { -v “cmd.exe”}

Include -access “CREATE”




Customers can also add the following Access Protection rule to prevent the creation of encrypted files on the victim host:

Prescriptive guidance

It is advisable for customers to undertake appropriate risk assessment to determine if this threat has a high probability of targeting their environments.  Whilst the above detailed known samples are incorporated within McAfee technologies, customers can also add the following Access Protection rules to prevent the creation of encrypted files on the victim host:


  • Inclusion Status: Include
  • File Name or Path: *
  • SubRule:


  • Type: File
  • Operations: Create
  • Targets:
    • Target 1:
      • Include
      • Files: *.locked
    • Target 2:
      • Include
      • Destination file: *.locked

Customers can also add the following Access Protection rule to prevent the creation of encrypted files on the victim host:

  • File/Folder Access Protection Rule: Processes tInclude: *
  • File or folder name tblock: *.locked
  • File actions tprevent: New files being create

Access Protection Rules:

Customers can also add Access Protection rules matching these characteristics: Prevent Creation\Execution of:

  • c:\windows\temp\x??.bat
  • c:\windows\temp\kill.bat
  • c:\windows\temp\taskhost.exe

Prevent execution of binaries signed with SN:

  • C=GB, PostalCode=DT3 4DD, S=WEYMOUTH, L=WEYMOUTH, STREET=16 Australia Road Chickerell,
  • C=GB, PostalCode=WC2H 9JQ, S=LONDON, L=LONDON, STREET=71-75 Shelton Street Covent
  • C=GB, PostalCode=EC1V 2NX, S=LONDON, L=LONDON, STREET=Kemp House 160 City Road,


We have a YARA rule available on our ATR github repository:






















[email protected][.]com

[email protected][.]com

[email protected][.]com

[email protected][.]com

[email protected][.]com

[email protected][.]com

[email protected][.]pl

[email protected][.]pl

[email protected][.]pl

[email protected][.]pl

[email protected][.]pl

[email protected][.]com

[email protected][.]pl

[email protected][.]com

[email protected][.]pl

[email protected][.]com

[email protected][.]pl

[email protected][.]com

[email protected][.]com

[email protected][.]pl

[email protected][.]pl

[email protected][.]pl

[email protected][.]pl

[email protected][.]com

[email protected][.]com

[email protected][.]com

[email protected][.]com

[email protected][.]com

The post LockerGoga Ransomware Family Used in Targeted Attacks appeared first on McAfee Blogs.

On Drovorub: Linux Kernel Security Best Practices


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

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:


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

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.


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.


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


Size 70656 bytes
File-Type EXE
SHA 256 c21ecd18f0bbb28112240013ad42dad5c01d20927791239ada5b


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


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


Screenshot 2


Screenshot 3


Screenshot 4


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)


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