Olympic Destroyer: A new Candidate in South Korea

Olympic Destroyer: A new Candidate in South Korea

Authored by: Alexander Sevtsov
Edited by: Stefano Ortolani

A new malware has recently made the headlines, targeting several computers during the opening ceremony of the Olympic Games Pyeongchang 2018. While Cisco Talos group, and later Endgame, have recently covered it, we noticed a couple of interesting aspects not previously addressed, we would like to share: its taste for hiding its traces, and the peculiar decryption routine. We also would like to pay attention on how the threat makes use of multiple components to breach the infected system. This knowledge allows us to improve our sandbox to be even more effective against emerging advanced threats, so we would like to share some of them.

The Olympic Destroyer

The malware is responsible for destroying (wiping out) files on network shares, making infected machines irrecoverable, and propagating itself with the newly harvested credentials across compromised networks.

To achieve this, the main executable file (sha1: 26de43cc558a4e0e60eddd4dc9321bcb5a0a181c) drops and runs the following components, all originally encrypted and embedded in the resource section:

  • a browsers credential stealer (sha1: 492d4a4a74099074e26b5dffd0d15434009ccfd9),
  • a system credential stealer (a Mimikatz-like DLL – sha1: ed1cd9e086923797fe2e5fe8ff19685bd2a40072 (for 64-bit OS), sha1: 21ca710ed3bc536bd5394f0bff6d6140809156cf (for 32-bit OS)),
  • a wiper component (sha1: 8350e06f52e5c660bb416b03edb6a5ddc50c3a59).
  • a legitimate signed copy of the PsExec utility used for the lateral movement (sha1: e50d9e3bd91908e13a26b3e23edeaf577fb3a095)

A wiper deleting data and logs

The wiper component is responsible for wiping the data from the network shares, but also destroying the attacked system by deleting backups, disabling services (Figure 1), clearing event logs using wevtutil, thereby making the infected machine unusable. The very similar behaviors have been previously observed in other Ransomware/Wiper attacks, including the infamous ones such as BadRabbit and NotPetya.

Disabling Windows services

Figure 1. Disabling Windows services

After wiping the files, the malicious component sleeps for an hour (probably, to be sure that the spawned thread managed to finish its job), and calls the InitiateSystemShutdownExW API with the system failure reason code (SHTDN_REASON_MAJOR_SYSTEM, 0x00050000) to shut down the system.

An unusual decryption to extract the resources

As mentioned before, the executables are stored encrypted inside the binary’s resource section. This is to prevent static extraction of the embedded files, thus slowing down the analysis process. Another reason of going “offline” (compared with e.g. the Smoke Loader) is to bypass any network-based security solutions (which, in turn, decreases the probability of detection). When the malware executes, they are loaded via the LoadResource API, and decrypted via the MMX/SSE instructions sometimes used by malware to bypass code emulation, this is what we’ve observed while debugging it. In this case, however, the instructions are used to implement AES encryption and MD5 hash function (instead of using standard Windows APIs, such as CryptEncrypt and CryptCreateHash) to decrypt the resources. The MD5 algorithm is used to generate the symmetric key, which is equal to MD5 of a hardcoded string “123”, and multiplied by 2.

The algorithms could be also identified by looking at some characteristic constants of

  1. The Rcon array used during the AES key schedule (see figure 2) and,
  2. The MD5 magic initialization constants.

The decrypted resources are then dropped in temporary directory and finally, executed.

Figure 2. AES key setup routine for resources decryption

Hunting

An interesting aspect of the decryption is its usage of the SSE instructions. We exploited this peculiarity and hunted for other samples sharing the same code by searching for the associated codehash, for example. The later is a normalized representation of the code mnemonics included in the function block (see Figure 3) as produced by the Lastline sandbox, and exported as a part of the process snapshots).

Another interesting sample found during our investigation was (sha1: 84aa2651258a702434233a946336b1adf1584c49) with the harvested system credentials belonging to the Atos company, a technical provider of the Pyeongchang games (see here for more details).

Hardcoded credentials of an Olympic Destroyer targeted the ATOS company

Figure 3. Hardcoded credentials of an Olympic Destroyer targeted the ATOS company

A Shellcode Injection Wiping the Injector

Another peculiarity of the Olympic Destroyer is how it deletes itself after execution. While self-deletion is a common practice among malware, it is quite uncommon to see the injected shellcode taking care of it: the shellcode, once injected in a legitimate copy of notepad.exe, waits until the sample terminates, and then deletes it.

Checking whether the file is terminated or still running

Figure 4. Checking whether the file is terminated or still running

This is done first by calling CreateFileW API and checking whether the sample is still running (as shown in Figure 4); it then overwrites the file with a sequence of 0x00 byte, deletes it via DeleteFileW API, and finally exits the process.

The remainder of the injection process is very common and it is similar to what we have described in one of our previous blog posts: the malware first spawns a copy of notepad.exe by calling the CreateProcessW function; then allocates memory in the process by calling VirtualAllocEx, and writes shellcode in the allocated memory through WriteProcessMemory. Finally, it creates a remote thread for its execution via CreateRemoteThread.

Shellcode injection in a copy of notepad.exe

Figure 5. Shellcode injection in a copy of notepad.exe

Lastline Analysis Overview

Figure 6 shows how the analysis overview looks like when analyzing the sample discussed in this article:

Analysis overview of the Olympic Destroyer

Figure 6. Analysis overview of the Olympic Destroyer

Conclusion

In this article, we analyzed a variant of the Olympic Destroyer, a multi-component malware that steals credentials before making the targeted machines unusable by wiping out data on the network shares, and deleting backups. Additionally, the effort put into deleting its traces shows a deliberate attempt to hinder any forensic activity. We also have shown how Lastline found similar samples related to this attack based on an example of the decryption routine, and how we detect them. This is a perfect example of how the threats are continuously improving making them even stealthier, more difficult to extract and analyze.

Appendix: IoCsdivider-2-white

Olympic Destroyer
26de43cc558a4e0e60eddd4dc9321bcb5a0a181c (sample analyzed in this article)
21ca710ed3bc536bd5394f0bff6d6140809156cf
492d4a4a74099074e26b5dffd0d15434009ccfd9
84aa2651258a702434233a946336b1adf1584c49
b410bbb43dad0aad024ec4f77cf911459e7f3d97
 c5e68dc3761aa47f311dd29306e2f527560795e1
 c9da39310d8d32d6d477970864009cb4a080eb2c
fb07496900468529719f07ed4b7432ece97a8d3d
Alexander Sevtsov

Alexander Sevtsov

Alexander Sevtsov is a Malware Reverse Engineer at Lastline. Prior to joining Lastline, he worked for Kaspersky Lab, Avira and Huawei, focusing on different methods of automatic malware detection. His research interests are modern evasion techniques and deep document analysis.
Alexander Sevtsov
Stefano Ortolani

Stefano Ortolani

Stefano Ortolani is Head of Threat Intelligence at Lastline. Prior to that he was part of the research team in Kaspersky Lab in charge of fostering operations with CERTs, governments, universities, and law enforcement agencies. Before that he earned his Ph.D. in Computer Science from the VU University Amsterdam.
Stefano Ortolani