Two weeks after the attack many Norsk Hydro facilities continued to use manual operations.  Pictured above is an extrusion plant in Portland, Oregon. Photo credit: Norsk Hydro


News of the ransomware attack on Norsk Hydro broke on March 19th and thanks to the admirable transparency shown by Norsk Hydro, the security world knows about the $41m USD in losses incurred in the first week, as well as the ways in which the company responded to the attack.

The CyberX Threat Intelligence team is proud to report that our ICS Malware Sandbox was one of the very few products to identify LockerGoga as ransomware out-of-the-box.  Here’s a screenshot from our Sandbox:

We detected the ransomware because of the large number of OT files including DLLs that were affected.

CyberX customers are also protected because our Threat Intelligence feed has now been updated to detect the LockerGoga malware.

How Did The Attackers Gain Access?

The attackers likely gained access to a system on the victim’s network through an exposed remote connection (e.g., RDP), likely using stolen credentials or a brute-force password attack. This is the same approach used in other recent targeted ransomware attacks such as the SamSam attack on the City of Atlanta.

If the initial entry point was on the OT network, CyberX would have detected the initial network intrusion as an unusual remote access connection.

What Has the CyberX Threat Research Team Found?

As of April 10th 2019, we have analyzed the following LockerGoga samples from VirusTotal:

The malware is written in C++ and uses the following public libraries:

  • BProcess — library to manage system processes
  • CryptoPP – C++ class library of cryptographic schemes
  • regex – C++ regex library

By looking at leftovers from the compiler we can see that this project was developed under few different directories:

  • E:crypto-locker
  • E:goga
  • X:workProjectsLockerGoga

The presence of the project on multiple drives indicate that there might be more than a single author, and each author saves it on his/her favorite drive with his favorite naming convention. For instance, one author names a folder “goga” in all lowercase, while the use of CamelCase on the X drive indicates perhaps a different author with different language idiosyncrasies.

We can see that most of the submissions are from Europe, and the Netherlands more specifically. Clearly the primary targets of the attackers are in Europe.

We observed that the first submission times to VT match the compilation times, and both look like the malware was first launched in January.

We also observed that there is a difference between the first submitted version and the last one, we clearly see here progress in the development of the malware.

Comparison of the first and the more recent sample:

First sample Recent sample
Hash 14e8a8095426245633cd6c3440afc5b29d
Compilation date 1/28/2019  8:13:06 PM 3/18/2019  11:07:54
Share Memory None SM-tgytutrc
Mutex None MX-tgytutrc
%Temp% folder naming svch0st.%random_number%.exe tgytutrc%randomnumber%.exe
User lockout Not implemented Changes password to [email protected]
and locks out user
Logging flag Exists Exists
Multi-processing encryption Exists Exists
Dry run (no encryption) Exists Doesn’t exist
Single file encryption Exists Doesn’t exist
Erase specific file Exists Doesn’t exist
Fill unused HD space Exists Exists
Ransom note Exists Exists
Built-in recovery code Doesn’t exist Doesn’t exist

Based on our analysis of the more recent sample listed above, we’ve observed that when the malware starts to run it takes the following steps:

  1. Calls CreateMutex – MX-tgytutrc”
  2. Runs the command “cmd.exe /c move /t %filepath% %temp% tgytutrc%randomnumber%.exe” in order to move itself to the temp folder
  3. Runs itself from the new location ( %temp%) and adds the argument -m to the command line.
    The tool executes commands in command line without using a console window. It seems likely that this is an oversight by the developers who used command line to debug the malware.
  4. The tool can use the following options:
    1. Log (-l) – create log file in c:.log
    2. master (-m) – The master process
    3. Slave (-s) – The slave process
    4. Ipc (-i) – The name of the share memory
  5. The master process (option -m):
    1. Uses the command logout.exe in order to logout the all users who are already logged in a windows session
    2. Uses the standard Windows command net.exe in order to change each user’s password to [email protected]
    3. Creates shared memory with the name SM-tgytutrc
    4. Spawns a new process with the option -s -i SM-tgytutrc in order to encrypt each file (option -m):
    5. Uses the shared memory to pass the path to the files which need to be encrypted to the new process
    6. Uses RSA4096 +AES 256 to encrypt every file in the computer
    7. Changes the extension to every file that it encrypts to .locked
    8. Uses cipher.exe /win order to wipe all the free space in the harddisk
    9. Creates the Ransomware note file with the name“README_LOCKED.txt” which contains the following message:

The malware samples from early January were less sophisticated than the most recent samples we analyzed, suggesting that the threat actors continue to develop the malware in order to improve it and to target new victims.

The older sample, which was compiled on January 28th, 2019 at 8:13:06 PM with the hash: 14e8a8095426245633cd6c3440afc5b29d0c8cd4acefd10e16f82eb3295077ca, had the following differences from the more recent sample:

  1. Doesn’t use mutex or Shared Memory
  2. Moves itself to the %temp% folder under the name %random_number%.exe
  3. Runs itself again with the parameter -w (instant of -m)
  4. Doesn’t create the process to change the user password and log him/her out
  5. Contains a different set of options in the command line:
    1. Help (-h)
    2. Version (-v)
    3. Log (-l) – creates a log with path c:cl.log
    4. Dry (-d) – runs without encrypting any files
    5. Worker (-w) –
      1. This command, with no string after the dash is the master process which manages the entire encryption process
      2. If there is a string after the dash the string represents the path to the file which should be encrypted
    6. File (-f) file encrypt specific file
    7. Jobs (-j) – number of parallel jobs
    8. Erase (-e) file to delete instant to encrypt
  6. Creates a new process for every file which it wants to encrypt
  7. Creates a file in the path c:wipe that contains random data. The file will be the same size as the free space on the harddisk in order to wipe the free space and disable the option to recover deleted files.
  8. Writes the file “README-NOW.txt” to the hard disk with the message:

The findings above, necessarily, include some speculation. The CyberX Threat Research team will continue to dig into new samples and create further intelligence in order to contribute to the body of knowledge about LockerGoga and best protect our current and future customers.

As mentioned above, the CyberX ICS Malware Sandbox was one of the very few tools to detect LockerGoga out-of-box.  More information about our Sandbox can be sound on our website, in our solution brief, and in our S4 presentation.  Current customers should know that our Threat Feed has been updated to detect LockerGoga.

What Can You Do To Protect Yourself?

We continue to get inquiries from security and OT professionals regarding best ways to protect themselves from future ransomware and other attacks.  To minimize the impact of LockerGoga or other types of ransomware, CyberX recommends the following steps:

  1. Implement a back-up and restore solution in the OT network and perform scheduled check-ups to ensure it is working properly
  2. Train employees to recognize and appropriately handle suspected phishing emails
  3. Continuously monitor OT networks for suspicious or unauthorized traffic (SMB, PsExec, RDP, etc.), protocol abuse, malware, and other behavioral anomalies.
  4. Separate OT Active Directory domains and IT Active Directory domains so that if the IT network gets compromised, it doesn’t easily spread to the OT network.
  5. Protect Windows endpoints from running malicious executables by implementing application whitelisting