LockerGoga ransomware – how it works

The first confirmed attack by the LockerGoga ransomware was in January 2019 when Altran Technologies got hit. Earlier this week the Norwegian organization Norsk Hydro become the victim of a similar attack. There is at least one commonality between these recent events and that is the targeted nature of the attacks. In this blog we shall examine the charateristics of LockerGoga and review the evolution of the variants.

Infection vector

As of today, there are still more assumptions and less confirmed facts about how the ransomware initially got onto the network of these companies. For the Altran case some researchers claim it was done by phishing, while for Norsk Hydro the clues are pointing towards the involvement of Active Directory services and the use of scheduled tasks. In both case the attackers were trying to negotiate the price by asking the affected companies to contact them via email. There is no fixed price per infected computer nor was any cryptocoin wallet ID or URL provided. Combining this with the use of ProtonMail email addresses – which is an end-to-end encrypted email service – the intention is clearly to make their actions more difficult to trace.


There are only a limited set of samples so far for this family, however the main characteristics do not vary much. They have been written in C++ using some well-known helper libraries such as Boost and Crypto++ (CryptoPP). The inclusion of common crypto libraries is still popular amongst ransomware families, as re-implementing algorithms such as AES or RSA from scratch would be more time consuming and probably less secure at the same time. The executables were signed with valid certificates which are, thankfully, now revoked. This could greatly help their deployment as most security solutions trust executables with a valid certificate. They were issued to three different companies, MIKL LIMITED, KITTY’S LTD, ALISA LTD, and the common issuer was Sectigo (formerly known as Comodo).

Figure 1 – Example of one of the revoked certificates from VirusTotal

How it works

As for technical details, we are mainly describing how the latest variant used in the Norsk Hydro attack operates. The behaviour of other variants is very similar to this, with some minor exceptions.

Upon execution the malware would first move itself to the user’s TEMP directory by running the following command:

“cmd.exe /c move /y tgytutrcXXXX.exe %TEMP%\tgytutrcYYYY.exe”

Note that X and Y are randomly generated digits.

Once that is completed it will launch one “master” process of itself and several “slave” ones using commands as described below:

“tgytutrcXXXX.exe -m”

“tgytutrcXXXX.exe -i SM-tgytutrc -s”

The main purpose is the same as for any other ransomware family, looking out for a set of specific file extensions and encrypting the files with the use of both symmetric and asymmetric cryptographic algorithms. All of the samples we investigated used the same ransom note stating the usage of AES-256 and RSA-4096, however the embedded public keys in the binaries are RSA-1024. This isn’t as significant a difference as it might sound; RSA-1024 is still considered safe for most operations and the authors of the malware might not have wanted to further slowdown the encryption process by using a bigger key size. LockerGoga samples have a pre-defined list of file extensions to encrypt, however they are also capable of encrypting all files on a hard drive – which we have also observed. There is also the option to exclude directories from the encryption process such as the SystemRoot (%windir%). Files smaller than 256 bytes won’t be touched either.

Once the encryption is complete affected files will be renamed to *.locked and a ransom note will be dropped onto the desktop (README NOW.txt or README_LOCKED.txt). The note includes all the general information about encryption and also two email addresses to be used for contacting the operators of the malware. They prefer payments in Bitcoin and there is the possibility of negotiating the price depending on how quickly contact is established.

Figure 2 – Example of the ransom note

Command and control servers are not used by the samples we analysed.  The samples work in “offline” mode meaning the generated AES encryption keys are encrypted by the embedded RSA public key and are attached at the end of each encrypted file. There is a ‘GOGAXXXX’ marker used in recent samples (X is a hardcoded value in the ransomware binaries i.e. 1510, 1440, 1320) for storing this and other additional information such as the original file size.

Note that the malware would not check if files were already encrypted, multiple encryption is possible by another execution of the malicious code.

Figure 3 – Example of appended metadata at the end of an encrypted file

Evolutionary Steps

As stated earlier there are no major differences between variants of the malware, however some straightforward evolutionary steps could be witnessed. The earliest samples contained both the ransom note and email addresses in plain text. In more recent samples the ransom note is also encrypted but the email addresses are not. Internal strings of project names and paths were present in early builds, but in more recent builds they were changed and then completely removed.

Below you can see the various project names used by the different samples prior to removal:




There is some additional functionality deployed into the latest variant (used at Norsk Hydro) such as changing the password of all Administrator type of users to “HuHuHUHoHo283283@dJD” and enforcing a logoff once encryption finished.

Despite the ransom note explicitly stating not to reboot or shutdown, the PC would survive a reboot as critical Windows executables are not touched during the encryption process. Unfortunately, that does not mean that all applications will still be functional.

The password change is done by using the net.exe Windows command like below:

“net.exe user Administrator HuHuHUHoHo283283@dJD”

Figure 4 – Example of the process flow during execution


As always, we would never encourage anyone to pay cybercriminals. There is absolutely no guarantee that files will be decrypted once they’ve received the payment, and every cent (be that real money or Bitcoin) transferred is just reassuring operators of such malware campaigns that their business model is succesfull. From small businesses to large enterprises, having regular on-site and off-site backups must be part of one’s data retention and backup strategy. We can be certain that the ongoing shift is going to continue in the ransomware landscape, targeting specific sectors and wealthy companies by unique malware might turn out to be (much) more profitable than spreading it to the masses.

Protection Statement

Forcepoint customers are protected against these campaigns at the following stages of attack:

Stage 5 (dropper file) – protection from the deployed malware.

Indicators of Compromise

SHA1 Hashes














Email addresses found in the ransomware demand notes







Original Article posted by Robert Neumann and
Kurt Natvig at 

Leave a Reply

Your email address will not be published. Required fields are marked *