There’s been quite a bit of media attention over the past few days on a new variant of malware that hit Norsk Hydro, with a great deal of concern about the apparent lack of detection by many security tools. In this post, we take a look behind how LockerGoga works and show how it is actually detected in the wild by the SentinelOne agent.
Norsk Hydro was not an accidental, “WannaCry” style indiscriminate attack, but a deliberate, targeted strike on critical infrastructure. Below, we provide a detailed analysis of the ransomware encryption process and its evasion techniques.
The binary contains statically-linked Boost and Crypto++ libraries that complicates the analysis; however, obfuscation, packing, or code encryption were not used in the samples.
The name of the ransomware originates from the project development strings found in the binary:
The first version has the following digital certificate issued to ‘ALISA LTD’, which was 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.
Codesigning is a relatively new technique malware authors use in order to bypass the kind of antivirus engine that assumes a signed file is benign because it appears to be produced by a legitimate software company. Whitelisting signed software saves these kinds of AV engines time and lowers their impact on the endpoint’s resources, but clearly the costs are counter-productive to security.
Numerous vendors on the dark web sell such certificates for a relatively cheap price of between 500 and 1700 USD, so signed ransomware is becoming increasingly common.
Below is an example of a seller providing this kind of “signatures-for-sale” service:
Certificates for signing code are used by developers to sign their software to prove that it (software) has not been modified or compromised by a third party. Although retail software is generally considered relatively safe, programs downloaded from the Internet are often questioned because of the widespread occurrence of viruses and malware. The presence of a digital certificate confirms the integrity (immutability) of the program code since its release. Accordingly, if your file is digitally signed, users will treat it with great confidence when downloading from the Internet or running.
A signed file bypasses blocking of many antiviruses, and EV CodeSigning allows you to bypass the SmartScreen without a set of certificate reputation!
Given the new rules for obtaining certificates, it is easier to buy from us than to bother yourself!
LockerGoga On Execution
During the infection process, the executable copies itself to the %TEMP% directory,
cmd.exe /c move /y tgytutrcXXXX.exe %TEMP%tgytutrcYYYY.exe
and upon execution clears the Windows Event Logs using the following command syntax:
"C:Windowssystem32wevtutil.exe" cl Microsoft-Windows-WMI-Activity/Trace
The executable then creates the ransom note and begins the encryption process. Multiple processes are used for the encryption, and encrypted files are renamed with the
There is currently no evidence of self-propagation over the network. Indeed, unlike most other ransomware, LockerGoga shows no network activity at all, nor does it link back to a C&C server with a payment note like other ransomware. Instead, the attackers use a manual process of email conversation with the victims, using numerous Protonmail, mail.com and o2.pl email accounts.
It’s also worth mentioning that they don’t specify the amount of the ransom, possibly in order to demand a variable amount based on the profile of the attacked target.
LockerGoga does not use the Windows Crypto API to encrypt the files. Instead, it uses the CryptoPP + Boost library. One possible reason for this might be to help it avoid detection by common heuristics that look specifically for that API.
LockerGoga creates a new process from the current executable with the
-m argument (“m” stands for “master process”); the sample we analysed also uses the
Boost.Process library to manage processes.
That process creates shared memory and writes file paths in
base64 encoded form.
For IPC (Inter Process Communication), it uses the
The child process decodes the file path from shared memory, generates a key pair using RNG, encrypts the file using AES/Rijndael, and then appends the encrypted key to the encrypted file.
Additional functionality involves changing the password of every Administrator user to “HuHuHUHoHo283283@dJD” and forcing a logoff:
net.exe user Administrator HuHuHUHoHo283283@dJD
LockerGoga does not check if files are already encrypted; thus, multiple encryption is possible by another execution of the sample, which may well complicate or even make impossible decryption even if the ransom is paid.
Currently there are 6 known samples of LockerGoga in the wild:
When news first started to emerge about LockerGoga, there were some inaccurate reports that the SentinelOne agent did not detect the ransomware. These mistaken stories were based on looking at the results in public sandboxes like VirusTotal.
Indeed the first submission of LockerGoga was not shown as detected by any of the antivirus engines used on VT
In fact, the results on VirusTotal only reflect our static engine, and what we offer on VirusTotal is not the same protection as provided in our Agents. Whenever looking at results from public sandboxes like VT, it’s worth remembering that they aren’t designed to host any type of behavioral engine, so this capability of the SentinelOne agent is not represented on their site.
Indeed, as the following demonstration shows, SentinelOne prevents LockerGoga from executing entirely.
If we change the file attributes and put SentinelOne in Detect / Detect mode for demonstration purposes, we can now execute the attack, but it is still detected:
Let’s see how this really plays out in action. In the video, we can see exactly how the SentinelOne agent detects, blocks and can even remediate an infection of LockerGoga ransomware, without even being connected to the cloud.
LockerGoga is different from other common ransomware and there are several factors that suggest the actors may be interested in targeting industrial facilities exclusively. First, it works in an offline mode, meaning the key generation occurs on the infected host. This is a clever tactic if you are targeting machines that may have limited or no access to the internet, such as air-gapped or strongly-guarded critical industrial endpoints. Second, the use of a codesignature is another tactic that could circumvent some corporate security policies which only permit signed executables to run.