According to several media reports, on March 18, 2019, Norsk Hydro, one of the world’s largest integrated aluminum groups, suffered ransomware attacks in several factories in the US and Europe , leading to IT system unusable, causing multiple plant shutdowns and partial plant switching to manual operation mode. The company temporarily shut down multiple plants and changed the plant operating model portion of countries such as Norway, Qatar and Brazil to the “usable” manual mode to mitigate the impact on production. The ransomware seems also attacked the US chemical companies Hexion and Momentive, resulting in some employees can not log in to the system. 
360 Threat Intelligence Center conducted a further detailed analysis of the ransomware (LockerGoga) and found that the ransomware is likely to be a destructive ransomware for directed attacks. It traverses files in the virus parent process and then encrypts them in multiple child processes. The way files are used to increase the speed and efficiency of encryption, taking full advantage of the multi-core nature of the CPU to speed up the destruction efficiency (the number of child processes will always equal the number of processors).
360 Threat Intelligence Center conducted a detailed analysis of the relevant samples, and the analysis report is as follows.
PE basic information
The sample is digitally signed and the basic properties are as follows:
It can be seen from the tool that it is a 32-bit executable compiled by VS2015:
Introduction to the execution process:
Lockergoga will move itself to the %UserTemp% directory when it first runs. The moved file is renamed to zzbdrimpxxxx.exe (xxxx is 4 random numbers), and the renamed program will be started and passed in the parameters. -m”. The process will traverse the file and start more child processes with “-iSM-zzbdrimp -s” as parameters to encrypt the user files.
After the program runs, it will get the command line parameters and execute different processes according to different parameters:
The string associated with the parameter:
then checked the parameters, and the program will exit directly if the parameters are not valid:
Finally, the function is dynamically called according to different parameters to execute the corresponding process:
Detailed analysis of parameters
The process with -m as the parameter is mainly for scheduling: first create a mutex (MX-zzbdrimp), then create a thread to traverse the disk file, and then enter a loop, in this loop will be “-iSM-zzbdrimp -s “Create more child processes for the parameters. The parent process detects the number of child processes and the state of the child processes to ensure that the number of child processes is the same as the number of CPU cores.
The child process with the parameter “-iSM-zzbdrimp -s” is used to encrypt the file. The path to be encrypted is provided by the parent process, and the communication between them is synchronized by the mutex (MX-zzbdrimp). The parent process performs Base64 encoding on the path of the file to be encrypted and passes it to the child process. The child process uses the randomly generated AES key to encrypt the file using the AES_128 algorithm. The AES key is encrypted by the built-in RSA public key and appended to the end of the encrypted file.
No command parameters
The corresponding routine function performs various permission adjustments firstly:
Then generate the target file name, the creation process moves itself to the current user’s Temp directory:
Then run the moved program with -m as the parameter:
Finally, call the function at address 0x410D40, create and write in the user documentation, which is the README_LOCKED.txt file on the desktop:
First create a mutex (MX-zzbdrimp) for synchronization with the child process:
Then create a thread to traverse the disk file:
Then start looping to create the child process and pass in the parameter “-iSM-zzbdrimp -s”, the code will ensure that the number of child processes does not exceed the number of cores of the processor.
Also monitor the status of the child process and recreate it if it is aborted:
Parameter -i SM-zzbdrimp -s
Firstly try to open the named mutex (MX-zzbdrimp) to get the handle of the mutex, if it does not exist, it will cause the function to go wrong, the program will exit directly:
The child process obtains the path of the file to be encrypted that is passed in from the parent process, and the path name needs to be decoded by Base64:
Next, load the Rstrtmgr.dll dynamic library, call the RmStartSession, RmRegisterResources, and RmGetList functions to undo the use of the encrypted file, preventing the encryption from failing because other programs are using the file:
When encrypting, firstly generate a 32-byte random number for AES key generation:
Then the hard-coded RSA public key in the decoding program:
The corresponding content of the public key is:
—–BEGIN PUBLIC KEY—–
—–END PUBLIC KEY—–
The encrypted file name is suffixed with .locked:
LockerGoga encrypts files using the CES mode AES algorithm, with the first 16 bytes of random number as the initial vector iv and the last 16 bytes of random number as the key:
The AES key and the initial vector (ie the generated 32-byte random number) will be encrypted by AES and appended to the end of the corresponding file:
Use the Ollydbg script to test the parameters and found that only 3 parameters are valid:
-i SM-zzbdrimp -s
-m SM-zzbdrimp -s
-l SM-zzbdrimp -s
After testing, there is no difference with the first two parameters. The third parameter will create a C:\.log file in the root directory of the C drive to record how many files have not been encrypted, as shown in the following figure:
Encrypted file types
LockerGoga compares file suffixes when encrypting files, but we found that all types of files are encrypted (including exe and dll, etc.) during actual debugging, and some files may be encrypted multiple times.
After analysis, LockerGoga encrypts various types of files, including PE files, system directories, and files in the startup directory, so it is very destructive. It increases the speed and efficiency of encryption by traversing files in the parent process, then encrypting files in multiple child processes, and leveraging multiple cores of the CPU (the number of child processes is always equal to the number of processors). In response to the characteristics of this virus technology and the combination of past virus transmission methods, we give the following safety recommendations:
- Do not run unknown software
- Update operating system security patches in time to prevent virus exploitation
- Install 360 Total Security and introduce threat intelligence, scan the computer regularly, update the virus database in time to keep the anti-virus software running well.
- Improve safety awareness, maintain good online habits, and back up important data
. https://mp.weixin.qq.com/s/_LYg3kuKdeTyqPR1r0IWpA . https://www.recordedfuture.com/lockergoga-ransomware-insight/
Learn more about 360 Total Security