RagnarLocker Ransomware Malware Analysis

RagnarLocker is a Windows based ransomware family that includes the ability to encrypt a systems files with the intention of financially extorting the victim for money. One of the most famous ransomware attacks involving Ragnar was the attack against the Portuguese company, EDP Group. During the attack, the Ragnar actors compromised the company’s network and later deployed the ransomware payload and demanded a payment of 1500+ Bitcoin. During the attack, the actors also exfiltrated around 10TB worth of internal documents from the company, which was used to doubly extort the victim. In order to regain access to their systems and to not have their internal, sensitive documents leaked, EDP Group would need to pay the ransomware actors. The malware sample analyzed in this post is one of the same samples involved in the EDP Group attack. The malware sample includes a EDP Group specific ransom note that can be obtain while decryption the configuration data from within the malware.

Key Findings

  • There is a decryption routine that at runtime will decrypt a list of process names, service names, public key, and ransomware note from the malwares internal encrypted configuration.
  • The malware builds a unique hash value based on specific system information data points (username, hostname, etc.) which is later used when created a new event on the system with CreateEvent. This is to ensure the malware is only run once on the system (like how ransomware typically uses mutexes)
  • The malware checks a list of hardcoded languages including Russian and Ukrainian, this is to avoid infected systems in those regions


According to DIE (Detect It Easy) the sample does not appear to be packed, the sample is matches the signature which detects it as being compiled/linked using Microsoft Visual Studio 2017. While the first stage (main payload) payload isn’t packed, that doesn’t mean that other aspects of the malware are not. At runtime the malware may unpack and decrypt configurations, or additional, smaller pieces of code.


According to other basic static analysis tools, the malware contains various suspicious function API imports, and libraries.The malware imports several API functions from the crypt32.dll cryptography library in addition to importing other suspicious functions. Imports such as:

  • OpenProcessToken, SetTokenInformation, and DuplicateTokenEx - these functions are commonly abused by malware for manipulating the security tokens of a process, this is typically used for enabling the SeDebugPrivilege or SeLoadDriverPrivilege if the malware wants to load a rootkit onto the system.
  • OpenServierA, OpenSCManagerA, EnumServicesStatusA - these functions all relate to abuse targeting the Windows Service Control Manager (SCM), these types of functions are commonly used for loading services for persistence purposes or for enumerating and terminating certain services by name for evasion purposes
  • And many more suspicious function API imports.

According to the section information for the binary, it includes a section called “.keys”, this is a good indication that the malware is embedding keys for the purpose of decryption some data such as an embedded configuration file or the public keys used for data encryption (due to this payload being ransomware).


The malware sample also includes debug information that states the binary was compiled on Monday, April 6th of 2020.


Technical Analysis

The samples entry function is responsible for carrying out the majority malicious activity.

On execution the sample first checks the installed languages on the victims system, this is done by calling the checkInstalledLanguages() function which calls the the API functions GetLocaleInfoW and compares the returned languages against a hard-coded array of language values. If a language on the “ignore” list is found, the executing process calls GetCurrentProcess to get a HANDLE to the calling process, and then calls TerminateProcess. This is a very common check performed by ransomware, typically EMEA based malware will ignore systems if they include language packs such as Russian,and others in the geographical region.

This version of the malware checks for:

Azerbaijani, Armenian, Belarussian, Kazahk, Kyrgyz, Moldavian, Tajik, Russian, Turkmen, Uzbek, and Ukrainian


After the initial language check occurs, if the victim does not include one of the “ignore” languages on their system, the malware gets the computers hostname, current users username, and queries a set of hard-coded Registry keys and values. The returned values from these queries are concatenated into a single variable which is then passed through a function responsible for generating a hash value.


  • The hash contains the systems hostname, the users username, the machines GUID value, and the value of “ProductName” (which includes a value such as “Windows 10 Pro”) in the CurrentVersion Registry key.
  • Prior to the hash encoding function is called, the unique ID is structured as <GUID><Product Name><Username><Hostname> and turned into a unicode string


The hash generation algorithm is done by taking the string, XORing it against the value 0xab01ff3, and then performing a set of mathematical operations against it, ultimately resulting in a unique identifier being returned back to the program.

  1. The unique set of information is passed into the function as param_1
  2. Memory is allocated to contain the result of the hash calculation using VirtualAlloc
  3. A counter is set to 0 and the length of the input string is set to a local variable
  4. If the string is greater than 0, the input equals the input + the counter value
  5. The counter is incremented and the the input is XOR’ed against the value of 0xab01ff3
  6. The value is multiplied by 0x2000 and rotated 13 places to the right
  7. The final hash is returned back into the allocated memory region via wsprintf in a hex format


This unique hash value is later used for creating a new event (by name) on the system using the value.



The malware continues multiple embedded encrypted strings in the form of a configuration datafile which at runtime decode using the decryption_routine1 function.

The first three occurrences of data decryption result in three parts of the configuration:

  1. A unique victim ID used for communicating with the actors when setting up a TOR based communication session on the Ragnar actor’s website
  2. A list of processes by name
  3. A list of services by name

ed2f0bcb6977478f808bfa7a779cd9ff 99266b1f94c34e1db4a923426596ee05