The Ransomware Resurgence Led By LockerGoga

The Blue Report 2024

Get a comprehensive analysis of over 136 million cyber attacks and understand the state of threat exposure management.

DOWNLOAD

An Unwelcome Comeback

After the all-time high of ransomware in 2017, it appears that ransomware infections have gone down. No major ransomware worms have been seen in the wild since WannaCry and NotPetya.

Ransomware has not completely disappeared but cybercriminals have shifted their focus temporarily onto banking trojans and crypto mining malware.

We have now observed a small resurgence in targeted ransomware attacks. Several industrial companies have been hit in recent weeks by ransomware. The most prominent attack was against Norsk Hydro – who can act as a role model when it comes to handling the infection, PR and incident response.

The infamous LockerGoga ransomware has been used in several of the recent attacks. The following companies are known to have been hit by LockerGoga: Altran, Hexion, and Momentive. All of these companies operate somewhere in the industrial supply chain of different industry verticals.

Cybercriminals know that industrial companies are particularly prone to ransomware attacks – production might be affected even if OT and ICS systems are not directly affected by the ransomware. An impact on industrial operations can be achieved by grinding regular office IT systems to a halt in some cases.

Further Technical Insights Into LockerGoga

At Picus Security, we regularly conduct analyses on the latest threats to make sure our customers are secure. Our analysis of LockerGoga has revealed some further interesting insights.

A part of what made LockerGoga so destructive is the fact that most Antivirus products did not recognize it as malicious when it hit its victims. LockerGoga uses several techniques that make it stealthier and less likely to be detected:

  • The CPUID anti-VM trick is used to avoid dynamic analysis from malware sandboxes by detecting processor features on the infected machine
  • It uses the anti-reverse engineering & anti-debugging technique SetUnhandledExceptionFilter
  • The malware is signed with a certificate that was originally signed by the issuer but has now been explicitly revoked. While this has backfired now with the revocation, a valid certificate decreases the initial detection drastically
  • LockerGoga queries kernel debugger information, the process list and the open application windows . It can use all of this information to determine the state of the victim machine to see if it is running in a sandbox
  • It also discovers the computer name, the cryptographic machine GUID, the WinSock2 settings, current volume information and the MountPointManager to get attached disks
  • LockerGoga changes the user’s password. To further avoid detection from EDR solutions that monitor common processes or process-chains, it uses net1.exe to change the password instead of the more commonly used net.exe to decrease the detection rate

The above information is based on the malware samples listed in the IoCs.

What makes the recent LockerGoga attacks more intriguing is that very little is known about other aspects of the malware. It is unclear how the above-mentioned companies got infected in the first place. Furthermore, the lateral movement techniques deployed during ransomware attacks are unknown. Although there is speculation about the lateral movement involved in the Norsk Hydro attack – propagation through Active Directory and GPO – the facts still remain unknown.

Facing Uncertainty

This uncertainty can pose a major risk for companies. If not all phases or techniques of an attack are known, it is impossible to tell if an organization could defend against such a threat.

As defenders, we almost always face a lack of information during a cyber-attack. Typical questions that we face are:

  • Is there an active infection in my environment?
  • Who is behind the attack?
  • What is the motivation of the attack?
  • Can we defend against such an attack?
  • How did lateral movement occur?

The cyber security industry is still not good at sharing threat intelligence (TI) or any other form of useful intelligence – MITRE is changing that slowly though by providing a great framework (ATT&CK) and a common language for defenders.

But sharing threat intelligence is not always the answer. Staying with our example of LockerGoga, even if TI was shared, it appears that LockerGoga was customized to some degree for each victim so TI sharing could not have prevented subsequent attacks.

Overcoming Uncertainty with Continuous Security Validation

Breach & Attack Simulation can help overcome this uncertainty. In the case of LockerGoga, Picus’ customers could test if their defenses protect them against LockerGoga hours after the initial malware samples became available. More importantly, Picus’ customers could not only test their defenses against this specific instance of LockerGoga, but they could also see if they were able to spot the generic Techniques, Tools & Procedures (TTPs) used by LockerGoga.

Instead of only testing for this iteration of LockerGoga, Continuous Security Validation can be used to test for varying techniques deployed in ransomware and other threats. As the lateral movement technique used in LockerGoga is still unknown, Picus’ customers can test their defenses against different lateral movement techniques such as Pass-the-Hash, Pass-the-Ticket, the abuse of PsExec, or the use of Mimikatz to steal credentials.

But testing against a specific threat is not sufficient in today’s fast-moving threat landscape – why not check your defenses by simulating all major ransomware attacks of late like other Picus’ customers do?

As we cannot anticipate tomorrow’s attacks, we have to continuously validate our security controls for known generic TTPs, such as the ones promoted by MITRE’s ATT&CK framework.

Get in touch with Picus (demo@picussecurity.com) today to run a free trial and see if your organization is resilient against the current devastating ransomware resurgence.

Indicators of Compromise (IoC)

c97d9bbc80b573bdeeda3812f4d00e5183493dd0d5805e2508728f65977dda15

f3c58f6de17d2ef3e894c09bc68c0afcce23254916c182e44056db3cad710192

c3d334cb7f6007c9ebee1a68c4f3f72eac9b3c102461d39f2a0a4b32a053843a

bdf36127817413f625d2625d3133760af724d6ad2410bea7297ddc116abc268f

ba15c27f26265f4b063b65654e9d7c248d0d651919fafb68cb4765d1e057f93f

8cfbd38855d2d6033847142fdfa74710b796daf465ab94216fbbbe85971aee29

7bcd69b3085126f7e97406889f78ab74e87230c11812b79406d723a80c08dd26

7852b47e7a9e3f792755395584c64dd81b68ab3cbcdf82f60e50dc5fa7385125

6e69548b1ae61d951452b65db15716a5ee2f9373be05011e897c61118c239a77