Crytek Hit With Egregor Ransomware And Suffers Data Theft

Game developer Crytek has confirmed that Egregor Ransomware hit their network a few months ago, and has now sent information to customers whose personal information was stolen. The company acknowledged the attack in breach notification letters sent to impacted uses last week. The details from the letter have been leaked by several victims online.

“We want to inform you that Crytek was the victim of a ransomware attack by some unknown cyber-criminals,” Crytek said in a letter mailed to one of their customers impacted in the incident.

“During that attack, certain data had been encrypted and stolen from our network. We took immediate action to prevent the encryption of our systems, further secure our environment, and initiate an internal and external investigation into the incident. Based on our investigation, the information in some cases included individuals’ first and last name, job title, company name, email, business address, phone number, and country”

Crytek tried reassured customers affected by the Egregor Ransomware breach, stating “the website itself was difficult to identify so that in our estimation, only very few people will have taken note of it.”

Crytek added downloading the leaked data would’ve also taken too long, which would have also likely represented a significant hurdle that stopped people from trying to grab it.

Most in the cybersecurity community consider this as the company downplaying the impact of the Egregor Ransomware attack, and such reassurances would only rest easily with individuals with little to no experience in using computers.

Crytek also believes that those who attempted downloading the stolen data were discouraged by the “huge risk” of compromising their systems with malware embedded in the leaked documents.

“While we are not aware of misuse of any information potentially impacted, we are providing this notice as part of our precautions,” Crytek added.

While it is unknown how many Crytek systems were encrypted, it is known the Egregor Ransomware attack had some degree of personalization by the hackers, as the encrypted was renamed to include the ‘.CRYTEK’ extension.

Egregor Ransomware Analysis

 

Note: This analysis was carried out by Minerva Labs.

The obfuscation Egregor Ransomware uses is similar to the one used in Maze ransomware. Researchers were able to modify Blueliv’s Maze deobfuscation script to fit Egregors obfuscation patterns, which allowed for easier analysis of the ransomware.

TheEgregor Ransomware loader checks for the command line “–nop” and exits if it exists.

As for further unpacking, a large blob of data is decrypted with the following steps:

• The blob is xor decoded with a hardcoded key (0x4 in our sample).
• The xor’ed data is then Base64 decoded using the windows API function CryptStringToBinaryA.
• A hardcoded key and IV is initialized for the ChaCha20 algorithm, which is then used for the final decryption of the payload. The malware authors decided to change the number of rounds of key rotations from the default of 20 to only 4.
• After decrypting the second payload, a DLL file, it is copied to a new allocation that is created using VirtualAlloc with the page permissions RWX.

The last stage of the initial loader is the preparation of the payload in memory.Egregor Ransomware reflectively loads the decrypted payload and uses the function CreateThread to transfer execution to its next stage.

The next stage parses the command line, looking specifically for the parameter -p, which contains a password that is used for the decryption of the ransomware binary. The ransomware is decrypted using a stream cipher that shares some of its constants with Rabbit cipher:

Egregor Ransomware is compiled as a DLL file with only one export named “DllEntryPoint”. The function creates a thread that executes the main subroutine of the ransomware.

Before starting the ransomware’s malicious procedure, a function is called to determine the locale of the workstation. The ransomware uses three different Windows API functions to make sure it is not encrypting a computer located in Russia or any other CIS country:

After the locale check, the ransom configuration will be decrypted from a buffer located in the data section of the executable. The first 8 bytes of the encrypted configuration starts with a PNG header which is skipped by the parser before its decryption. The subsequent DWORD contains the size of the configuration to decrypt. Starting from offset 12, the configuration will be decrypted using round-modified ChaCha20 and a hardcoded key and IV.

The ransomware uses the API functions GetLogicalDriveStrings and GetDiskFreeSpace to identify the names and types of the logical disks connected to the device in addition to the amount of free space available in them.

For each execution, a pair of private and public keys are generated. The public key is used for encrypting the symmetrical keys that would later be used for encrypting each file. A unique symmetrical key is generated for every file to be encrypted.

Egregor’s key generation scheme is as follows:

• A 2048-bit RSA key pair is generated using CryptGenKey – this is the session key.
• The key is then exported using the API CryptExportKey.
• The exported private key is encrypted with ChaCha using a randomly generated key and IV.
• The ChaCha keys are encrypted using the function CryptEncrypt and the configuration-embedded RSA public key.
• The encrypted ChaCha key and the encrypted session key are saved to disk in a hardcoded path, which in our case is %ProgramData%\dtb.dat.
• It is worth noting that the ransomware encrypts the session key with the same protocol that is used to decrypt the ransomware payload (Rabbit Cipher).

The ransomware will stop certain processes and services before encrypting the machine. A list of hardcoded process names is stored in the encrypted configuration file and the malware uses NtQuerySystemInformation to enumerate the running processes and terminates them using the function NtTerminateProcess.

Egregor has the capability to contact hardcoded HTTP URLs. If the offset 0x3a31e and 0x32fb in the configuration does not contain 0, the ransomware will contact IP address/DNS names (which are also embedded in the configuration), and decode their content using the same modified-ChaCha20/Base64 combination used before.