Saturday 23 March 2019

Analysis of LockerGoga Ransomware

Картинки по запросу Norsk Hydro
Norsk Hydro back in 1905. 

This week BleepingComputer reported that LockerGoga ransomware was allegedly responsible for disrupting the Norsk Hydro's IT control system and forced the Norwegian industrial giant to switch to the manual operation mode. Later, according to Motherboard, this ransomware disrupted IT services of the two more US chemical companies Hexion and Momentive. Thus, it seems that the attackers behind LockerGoga target critical infrastructure and those mentioned above are not the only victims of the ransomware up to the moment. Further, we provide a detailed analysis of the ransomware encryption process.


Antivirus signature-based engines missed the LockerGoga sample supposedly because of the valid digital signature when it was first uploaded (March 8, 2019) to VirusTotal.


Later, the certificate was revoked.

Static analysis

The binary contains statically-linked Boost and Crypto++ libraries that complicates the analysis of the ransomware, even though, obfuscation, packing, or code encryption were not used.

The version 1320 has the following digital certificate issued to ‘ALISA LTD’ but revoked after the discovery of the attack. Other versions of LockerGoga were supplied with the certificates issued to Alina Ltd, Kitty's Ltd., Mikl Limited, and AB Simba Limited.


Once started, the cryptolocker copies itself to the %Temp% folder under the hardcoded name.

C:\Windows\system32\cmd.exe /c move /y "C:\LockerGoga ransomware" C:\Users\<USER>\AppData\Local\Temp\yxugwjud<ID>.exe
After that, it executes the master process with the ‘-m’ key.

Finding files for encryption

The master process creates a list of files to be encrypted. The version 1320 of the cryptolocker does not perform filtering of the files based on extensions and encrypts all accessible files on disks.

Interprocess Communication

The master process sends a task to a worker through the named shared memory created with CreateFileMapping providing a path to file for encryption. The worker gets access to the master’s named shared memory by calling the function OpenFileMapping using the identifier ‘Global\SM-yxugwjud’.

Then the master process starts workers with the parameter ‘-s’ also providing the identifier of the created named shared memory ‘-i Global\SM-yxugwjud’.

For example:

C:\Users\<User>\AppData\Local\Temp\yxugwjud1342.exe -i Global\SM-yxugwjud -s


The cryptolocker adds ‘.locked’ extension. AES is used for file encryption in CTR streaming mode and key length of 128 bits. The file’s key and IV are encrypted with RSA-1024 using the MGF1(SHA-1) mask generation function for the OAEP padding scheme. The encrypted file key and IV are stored in the file footer.

File operations

The worker tries to open the file by the path given by the master. Then, it requests write permissions for the target file using the boost library.

It deletes the ‘.locked’ version of the file if it exists before encryption.

After that, the worker renames a file to the one with the ‘.locked’ extension and starts encrypting the file content by 65,536-byte blocks.

File encryption

For file content encryption LockerGoga uses AES in the stream mode CRT and key length of 128 bits.

The file key and IV are generated using Windows CryptGenRandom function.

Crypto++ enables AES-NI acceleration:


Footer encryption

During the initialization phase, the worker instantiates an RSAFunction object and loads the hardcoded public key (Modulus and Public exponent) in the PEM format.

The cryptolocker uses RSA-1024 with the ‘MGF1(SHA-1)’ mask generation function for the OAEP padding scheme to encrypt 40 bytes buffer that contain first 4 zero bytes, 16-byte file IV, 16-byte file key, and the terminating 4-byte string “goga”.

Once encrypted, the footer is stored to the end of the encrypted file.

The low public exponent value (e=17) is mitigated by the OAEP randomizing padding scheme that can be identified by a different footer’s ciphertext appearing while a plaintext and public key are the same.

Ransom note

Once files are encrypted, the locker leaves the ransom note in 'README_LOCKED.txt' file:

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 general case, it is not possible to decrypt the affected files without the master private key. However, if you have a memory dump that was taken while the worker was encrypting a file, you can decrypt this particular file. The file path and corresponding AES key and IV can be found in the memory dump by searching ‘GOGA<VERSION_ID>’ and ‘goga’ strings.

To decrypt an encrypted file for which you have located the key and IV in the memory dump:
  1. Make a backup copy of the encrypted file.
  2. Delete the footer (last 148 bytes) from the encrypted file.
  3. Decrypt the encrypted file using any cryptographic tool. For example, to decrypt the file encrypted with the key and IV shown on the picture above, run:
$ openssl aes-128-ctr -d -in chs_boot.ttf.locked_nofooter -K F12D893D2B9E8CC639C2EE3B06617AAC -iv 44C5A7A5FBF58C0C91D16E075B130070 -out chs_boot.ttf


The LockerGoga breaks the patterns in ransomware development. First, it showed that malware does not need obfuscation, packing, and runtime encryption to successfully attack an organization. A digital certificate is a much more effective weapon in this regard. On the contrary, employing the conventional self-defense techniques may have an opposite effect, for example, high entropy can attract unnecessary attention from the antivirus heuristics.

Second, despite, hardcoded crypto functions and libraries have been already used by TeslaCrypt, MoneroPay, GlobeImposter, Locky ransomware for many years, static linking of the Crypto++ and Boost libraries, for which disassemblers have no signatures, complicates reverse engineering and obfuscate the execution flow. We discussed the problem of finding embedded crypto primitives in ransomware last year at VB2018.

Third, LockerGoga cares about performance. The multithreading in ransomware was first seen in TeslaCrypt 2.0 where different threads were responsible for killing the processes of the analysis tools, searching and encrypting files, and C&C communication. Here, the cryptolocker leverages multiprocessing and task distribution. Also, Crypto++ AES implementation enables AES-NI to improve the speed of AES encryption. Moreover, the low value of public exponent (e=17 instead of standard e=65537) improves the performance of RSA cipher and being balanced by the randomized padding OAEP does not significantly increase security risks (read more about attacks on RSA by Dan Boneh).


Reversing LockerGoga video tutorial on YouTube:

See also

No comments:

Post a Comment