LockerGoga: When Ransomware Strikes Back
Ransomware attacks have made the headlines multiple times in the course of recent years. LockerGoga is yet another example. The malware disrupted the operation of a number of organizations (some researchers speculate dozens) in the industrial and manufacturing sectors. While initially lacking in sophistication, later versions can cause extensive damage.
This blog post introduces LockerGoga, details its main features, and presents a timeline of the attacks made public so far. It also points out the major changes observed between versions. We conclude with a recap of all available information.
While the initial infection vector is still unknown, it is believed that the attackers may have used a variety of techniques to get a foothold in target organizations’ networks, including phishing emails and exploiting vulnerabilities. LockerGoga does not self-propagate by infecting other hosts on the target network. Having said that, fellow researchers that linked LockerGoga to FIN6 threat group (known for point-of-sale attacks aimed at stealing financial information), have reason to believe that the propagation took place by means of batch scripts using the SMB protocol and ‘psexec’ to copy and execute the payload.
LockerGoga was first discovered in January of this year after it was allegedly used in an attack against Altran Technologies, a French engineering consultancy. On January 29th the company published a statement claiming that they suffered an attack on the 24th and, as a consequence, they had to shut down their systems to protect their clients’ data. On January 25th two samples were uploaded on VirusTotal (VT), from Romania and The Netherlands, indicating that the attack took place 4 days before the company published any statements.
A second attack took place on March 12th when, according to a post on BleepingComputer, two U.S. companies had been hit by the ransomware. Hexion and Momentive, controlled by the same investment fund, published a near-identical statement saying that the attack primarily affected corporate functions. Samples were uploaded to VirusTotal from several locations around the globe with only a few matching the physical locations of the two companies’ offices. All uploaded samples included a number of new features, validating LockerGoga as a fairly active actor in the threat landscape.
The latest attack took place on March 19th against the global aluminum producer Norsk Hydro. It started around midnight, local time, and escalated throughout the night. The company disclosed the attack the very same day and announced that they switched to manual operations. Multiple samples linked to the Norsk Hydro attack were made available. Confirming the trend, these new samples have been found to implement yet another batch of new features. While the first samples featured a sometimes sloppy implementation, it is now clear how the threat is becoming more and more sophisticated.
The sample (
73171ffa6dfee5f9264e3d20a1b6926ec1b60897) used in the attack against Altran Technologies became available on VirusTotal on January 24th. This version encrypts most of the files stored on the infected systems. As soon as the payload executes, a new process is started (the process uses a name similar to Microsoft system services, “svch0st.<random-number>.exe”) to query all files on the system and subsequently spawn a new process to encrypt each file separately, making it ultimately very slow (this was the sloppy aspect noted by many researchers).
The files that are targeted for encryption are DOT, WBK, DOCX, DOTX, DOCB, XLM, XLSX, XLTX, XLSB, XLW, PPT, POT, PPS, PPTX, POTX, PPSX, SLDX, and PDF files. Encryption is performed as follows:
- Each file is passed as a parameter
- A “.locked” extension is appended to its filename
- The file is mapped in memory and encrypted
- It gets unmapped and synchronized with the file on the disk
- The process terminates
Ultimately LockerGoga places on the desktop a ransom note that demands the user inquire about the price of the decryption tool. The victim can contact the attackers using the email addresses that are included at the end of the ransom note.
A quite interesting aspect of LockerGoga is that it initially came digitally signed by a UK company named “MIKL LIMITED”. The underlying reason is easy to guess: any digitally signed software is often able to bypass standard security solution just because of the signature itself. This also explains why VT coverage was, at first, quite sub-optimal: many researchers kept “discovering” new LockerGoga samples with zero detections on VT during the weeks following the first attack. The malware was immediately termed LockerGoga because of a debug path name that could be found within the binary of one of its variants: X:\work\Projects\LockerGoga\. As we will detail in the next section, further iterations of the malware (specifically the one used to attack Altran) seem to forego this specific string in the binary.
LockerGoga has been evolving since its first appearance. In this section, we present all major changes, and detail what version has been used in which attack. Figure 1 shows a timeline connecting all these events to the attacks.
Note that we extracted the version numbers from the PE header; while metadata cannot be normally considered as a trusted source, we found no reason to believe they have been tampered or forged by the attacker for deception purposes. We now summarize the main feature introduced by each version.
Version 0.9.9.0: This is an early version of the sample used to attack Altran. While it is not clear when (and if) this specific version had been used in the wild, VirusTotal recorded these samples as submitted from The Netherlands. It leaks its name in a string embedded in the binary (X:\work\Projects\LockerGoga\); unlike later versions, it is not signed and maybe for this reason ultimately less successful.
Version 220.127.116.11, 18.104.22.168, and v22.214.171.124: These are the versions used in the attack against Altran’s systems. The debug path included in the binary references an entirely new directory: “E:\crypto-locker”. There seems no real reason for this change besides suggesting some sort of link between LockerGoga and other disruptive ransomware families. These new samples became available on VT at different dates, both before and after the attack. The malware is signed with a certificate issued to “MIKL LIMITED”.
Version 126.96.36.199: In early February two new samples were uploaded, this time from Spain and Germany. The executables were identified as LockerGoga but signed with a new certificate issued to “KITTY’s LTD” (Comodo still being the certification authority). The binaries include yet a new path, “E:\goga”, suggesting that the developers settled on the name of the malware as they removed all references to “Locker” or “CryptoLocker.” This version did not introduce any new features.
Version 188.8.131.52: Within one month of v184.108.40.206 a new version appeared in the wild signed by yet another entity, “ALISA LTD.” While there is no pathname inside the binary, the executable is for some reason linked against a new library, WS2_32.dll. This library is responsible for sockets creation when establishing a new network connection. It’s too early to say whether this implies that the authors have been experimenting with self-propagation mechanisms. Another difference introduced by this version is a new name for the file containing the ransom note: README_LOCKED.txt. All these modifications make this version the most significant update so far.
Version 220.127.116.11: Two more variants were made available on VT less than 5 days later. The ransom note features the same filename, there is no new path hard-coded in the binary, and it is still signed by “ALISA LTD.” The samples were uploaded on March 12th and 19th respectively and have been deemed responsible for the attacks against US and Norwegian companies.
Version 18.104.22.168: The latest version of LockerGoga sample was uploaded just a few days after the previous one. It is not signed, but it is still linked against the WS2_32 library. In an expected turn of events, this version behaves more like a wiper than ransomware: it now forces a logout and changes all user passwords to “HuHuHUHoHo283283@dJD”. The consequence is that the victim is not able to view the ransom note, basically making the ransomware not monetizable by the attacker. If this is intentional, it implies that the attacker is actually more interested in causing a denial of service.
The creators of LockerGoga have been improving the capabilities of the malware by adding more and more features: linking against network libraries and changing the user password being the latest and greatest. All these additions indicate a level of sophistication that was not evident in the first version. While the network library might be an indication of some scheduled developments, changing the user passwords seem to suggest a more destructive aim. While there is no public information whether payments have been made and the victims managed to retrieve their files, this ransomware has already caused major disruptions and harm, leading to million-dollar losses.
All these new additions raise even more questions about the intentions of the threat actor. What are they trying to achieve? Are they merely motivated by disrupting operations? Has the motive always been financial profit?
Given the rapid evolution of this malware, signatures can hardly keep up. While signature-based detection provides good protection from known malware, behavioral detection techniques are required to deal with unknown threats. Our behavioral scanners (see Figure 2) identify all samples listed in this blog post as malicious, thus protecting our customers from known and unknown variants of LockerGoga. In the Appendix below we also provide a list of all indicators collected so far by our analysts. The e-mail addresses were extracted from the ransom notes.