Cisco Talos, USA
Copyright © 2018 Virus Bulletin
This year’s Winter Olympic Games took place in Pyeongchang, South Korea. Several media outlets reported that technical issues – believed to be caused by a cyber attack – had occurred during the opening ceremony. In this paper we will present the malware that we have identified – with moderate confidence – as having been used in the attack. First, we will describe the malware’s propagation techniques and its destructive capabilities. The second part of the paper will be about attribution and how, in this particular case, the attacker included several false flags in order to point to other well-known threat actors. We will conclude by opening a discussion about how hard attribution can be, and presenting our view concerning the future of this discipline.
In February 2018, the Olympic Games in Pyeongchang, South Korea were disrupted by a cyber attack. Reportedly, the attack resulted in the official Olympic Games website being taken offline, meaning that spectators could not print their tickets. Media reporting at the opening ceremony of the Games was also impaired due to the Wi-Fi failing within the Olympic Media Centre. On 12 February, Talos published a blog post [1] detailing the functionality of the malware that we had identified with high confidence as having been used in the attack. We named the malware Olympic Destroyer.
This attack gained traction through the press, and several different media outlets published conflicting stories in relation to attribution.
Figure 1: Different media outlets published conflicting stories in relation to attribution.
In the first part of this paper we will provide technical details of Olympic Destroyer, the wiper involved in the case, and in the second part we will discuss the attribution. Indeed, the malware did not write itself, the incident did not happen by accident, but who was responsible?
The initial sample (edb1ff2521fb4bf748111f92786d260d40407a2e8463dcd24bb09f908ee13eb9) is a binary that, when executed, drops multiple files onto the victim host. These files are embedded as obfuscated resources within the binary. The embedded files have randomly generated file names, however we found during our analysis that, when written to disk, the hashes of these files were the same on multiple instances. As a binary file, the initial sample could have been delivered in a multitude of ways – the most likely is via a spear phished email with Olympic Destroyer as a malicious attachment.
Two of the dropped files (the stealing modules) are executed with two arguments: 123 and a named pipe. The named pipe is used as a communication channel between the initial stage and the dropped executable. The same technique was used in BadRabbit and Nyetya.
The initial stage is responsible for propagation. Network discovery is performed using two techniques:
The network propagation is performed using PsExec and WMI (via the Win32_Process class). Figure 2 shows the code executed remotely.
Figure 2: Code executed remotely.
This code is responsible for leveraging cmd.exe to copy the initial stage to a remote system in %ProgramData%\%COMPUTERNAME%.exe and executing it via a VBScript.
Lateral movement within an environment is achieved in a number of ways. Generally speaking, there will either be one or more exploits used to allow remote code execution without credentials or we will see credentials/tokens being used within a piece of malware. These credentials/tokens may either already be known or they may be harvested during infection. With Olympic Destroyer we see the use of on-the-fly patching for credentials. Olympic Destroyer obtains these credentials from the infected systems, both previously compromised and currently compromised, to hard code a set of credentials into the binary to allow lateral movement. The binary contains 32k bytes of space, located from offset 0x26F1A to offset 0x2EF1A, to allow for the patching of these credentials. Talos identified 44 unique credentials within the samples analysed relating to Olympic Destroyer.
Figure 3: Talos identified 44 unique credentials within the samples analysed.
The burning question is: how did Olympic Destroyer obtain those credentials? The embedded resources mentioned earlier contain a couple of different credential-stealing modules.
To obtain the credentials Olympic Destroyer uses a browser stealer and a system stealer. This means that Olympic Destroyer attempts to harvest both from the browsers and from the operating system on the victim machine.
Olympic Destroyer drops a browser credential stealer with the final payload embedded in an obfuscated resource. As mentioned previously, the sample must have two arguments to be executed. The stealer supports Internet Explorer, Firefox and Chrome. The malware parses the registry and queries the sqlite file in order to retrieve stored credentials. SQLite is embedded in the sample.
Figure 4: SQLite is embedded in the sample.
In addition to the browser credential stealer, Olympic Destroyer drops and executes a system stealer. The system stealer attempts to obtain credentials from LSASS with a technique similar to that used by Mimikatz. Figure 5 shows the output format parsed by the initial stage.
Figure 5: Output format parsed by the initial stage.
Using these two methods the malware is able to obtain additional credentials to support further lateral movement within the environment.
The initial execution of the malware results in multiple files being written to disk, as discussed. Following this, the malware begins its destruction element. By leveraging cmd.exe from the host the malware first deletes all possible shadow copies on the system using vssadmin:
C:\Windows\system32\cmd.exe /c c:\Windows\system32\vssadmin.exe delete shadows /all /quiet
Next, once again leveraging cmd.exe on the host, we see the author using wbadmin.exe. For those not familiar with wbadmin, this is the replacement for ntbackup on modern operating systems:
C:\Windows\system32\cmd.exe /c wbadmin.exe delete catalog -quiet
This step is carried out to ensure that file recovery is not trivial – WBAdmin can be used to recover individual files, folders and even whole drives so this would be a very convenient tool for a sysadmin to use to aid recovery.
The next step the attacker takes in this destructive path is once again to leverage cmd.exe, but this time using bcdedit, a tool used for boot config data information, to ensure that the Windows recovery console does not attempt to repair anything on the host:
C:\Windows\system32\cmd.exe /c bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no
The attacker has now attempted to make recovery extremely difficult for any impacted hosts. To further cover the malware’s tracks and make analysis more difficult, the System & Security Windows event log is deleted:
C:\Windows\system32\cmd.exe /c wevtutil.exe cl System
C:\Windows\system32\cmd.exe /c wevtutil.exe cl Security
Wiping all available methods of recovery shows that this attacker had no intention of leaving the infected machine useable. The purpose of this malware is to perform destruction of the host, leave the computer system offline, and wipe remote data. We can see these functions within the Olympic Destroyer sample in Figure 6.
Figure 6: The purpose of this malware is to perform destruction of the host, leave the computer system offline, and wipe remote data.
To finish its destructive phase Olympic Destroyer then disables all available Windows services.
The malware uses the ChangeServiceConfigW API to change the start type to 4 which means: ‘Disabled: Specifies that the service should not be started’ (see Figure 7).
Figure 7: The malware uses the ChangeServiceConfigW API to change the start type to 4.
Additionally, the malware lists mapped file shares and for each share, it will wipe the writable files (using either uninitialized data or 0x00 depending on the file size). The purpose is to destroy the files as quickly as possible. With this method, the malware can cause as much disruption in as little time as possible.
Finally, after modifying all the system configuration, the destroyer shuts down the compromised system.
Olympic Destroyer also drops the legitimate, digitally signed, PsExec file in order to perform lateral movement. The use of this legitimate tool from Microsoft is an example of an attacker leveraging legitimate tools within their arsenal. Using legitimate tools like PsExec will save the adversary time by eliminating the need to write their own tooling. A free alternative they can wrap up within their malware is a much easier option in this instance.
Figure 8 presents a summary of the global workflow of the malware, starting with the initial stage (Winlogon.exe) and the different modules.
Figure 8: Summary of the global workflow.
Attributing attacks to specific malware writers or threat actor groups is neither simple nor an exact science. Many parameters must be considered, analysed and compared with previous attacks in order to identify similarities. As with any crime, cybercriminals have preferred techniques, and tend to leave behind traces, akin to digital fingerprints, which can be found and linked to other crimes.
In terms of cybersecurity incidents, analysts would look for similarities or attributes such as:
One of the great things about software engineering is the ability to share code, to build applications on top of libraries written by others, and to learn from the successes and failures of other software engineers. The same is true for threat actors. Two different threat actors may use code from the same source in their attacks, meaning that their attacks would display similarities, despite being conducted by different groups. Sometimes threat actors choose to include features from another group in order to frustrate analysts and try to lead them to make a false attribution.
In the case of Olympic Destroyer, what is the evidence, and what conclusions can we draw regarding attribution?
Without contributions from traditional intelligence capacities, the available evidence linking the Olympic Destroyer malware to a specific threat actor group is contradictory, and does not allow for unambiguous attribution. The threat actor responsible for the attack has purposefully included evidence to frustrate analysts and lead researchers to false attribution flags. Attribution, while headline grabbing, is difficult. This must force one to question attribution that is purely software based.
The Lazarus group, also referred to as Group 77, is a sophisticated threat actor that has been associated with a number of attacks. Notably, a spinoff of Lazarus, referred to as the Bluenoroff group, has been identified as having conducted attacks against the SWIFT infrastructure in a bank located in Bangladesh.
The filename convention used in the SWIFT malware, as described by BAE Systems [2], was: evtdiag.exe, evtsys.exe and evtchk.bat.
The Olympic Destroyer malware checks for the existence of the following file: %programdata%\evtchk.txt.
There is a clear similarity in the two cases. This is nowhere near proof, but it is a clue, albeit a weak one.
Further clues are found in similarities between Olympic Destroyer and the wiper malware associated with Bluenoroff, again described by BAE Systems [3]. In the example shown in Figure 9, the Bluenoroff wiper is on the left, and the Olympic Destroyer wiper on the right.
Figure 9: Left: Bluenoroff wiper; right: Olympic Destroyer wiper.
Clearly, the code is not identical, but the very specific logic of wiping only the first 0x1000 bytes of large files is identical and unique to the two cases. This is stronger evidence than the file name check.
However, both the file names used by Bluenoroff and the wiper function are documented and available to anyone. The real culprits could have added the file name check and mimicked the wiper function simply in order to implicate the Lazarus group and potentially distract from their true identity.
Olympic Destroyer sample: 23e5bb2369080a47df8284e666cac7cafc207f3472474a9149f88c1a4fd7a9b0
Bluenoroff sample #1: ae086350239380f56470c19d6a200f7d251c7422c7bc5ce74730ee8bab8e6283
Bluenoroff sample #2: 5b7c970fee7ebe08d50665f278d47d0e34c04acc19a91838de6a3fc63a8e5630
Kaspersky Lab identified [4] another link between Olympic Destroyer and samples used for the SWIFT attacks. This link is located in the header of the samples. More specifically in the Rich header. Indeed, the Rich header of the Olympic Destroyer sample and Bluenoroff sample #1 are identical. The checksum (and XOR key) located after the ‘Rich’ magic value is exactly the same (see Figures 10 and 11).
Figure 10: Olympic Destroyer. ae9a4e244a9b3c77d489dee8aeaf35a7c3ba31b210e76d81ef2e91790f052c85.
Figure 11: Bluenoroff. ae086350239380f56470c19d6a200f7d251c7422c7bc5ce74730ee8bab8e6283.
If we look at the information stored in this header, we can see that the compiler is Visual Studio 2003. This information is true concerning the Bluenoroff sample, however if we look closely at the Olympic Destroyer sample, it’s wrong: based on Universal C Runtime (CRT) Olympic Destroyer was compiled with Visual Studio 2010. The author simply copied and pasted the header from Bluenoroff to Olympic Destroyer. This action is strange and extremely specific – an actor has gone out of their way to perform this action. The tools using code similarities generally ignore the Rich header and only work on the subsequent code.
Intezer Labs [5] identified code sharing between Olympic Destroyer and malware used in attacks attributed to the APT3 and APT10 groups.
Intezer Labs discovered that Olympic Destroyer shares 18.5% of its code with a tool used by APT3 to steal credentials from memory. Potentially, this is a very strong clue. However, the APT3 tool is, in turn, based on the open-source tool Mimikatz. Since Mimikatz is available for download by anyone, it is entirely possible that the author of Olympic Destroyer used code derived from Mimikatz, knowing that it had been used by other malware writers.
Intezer Labs also spotted similarities in the function used by Olympic Destroyer to generate AES keys and that used by APT10. According to Intezer Labs, this particular function has only ever been used by APT10. Maybe the malware writer has let slip a possible vital clue to their identity.
The use of code derived from Mimikatz to steal credentials was also seen in the Nyetya [6] (NotPetya) malware of June 2017. Like Nyetya, Olympic Destroyer spread laterally by abusing the legitimate functions of PsExec and WMI. Like Nyetya, Olympic Destroyer uses a named pipe to send stolen credentials to the main module.
Unlike Nyetya, Olympic Destroyer didn’t use the EternalBlue and EternalRomance exploits for propagation. However, the perpetrator has left artifacts within the Olympic Destroyer source code to insinuate the presence of SMB exploits.
Olympic Destroyer includes the definition of these four structures, as shown in Figure 12, that can also be found in the public EternalBlue proof of concept [7], as shown in Figure 13.
Figure 12: Olympic Destroyer includes the definition of four structures that are also found in the EternalBlue proof of concept.
Figure 13: Public EternalBlue proof of concept.
These structures are loaded during runtime, when Olympic Destroyer is executed, but remain unused. Clearly, the author knew of the EternalBlue PoC, but the reason why these structures are present is unclear. It’s likely the author wanted to lay a trap for security analysts to provoke a false attribution. Alternatively, we could be seeing the traces of functionality which never made it into the final malware.
Attribution is hard. Rarely do analysts reach the level of evidence that would lead to a conviction in a courtroom. Many were quick to jump to conclusions, and to attribute Olympic Destroyer to specific groups. However, the basis for such accusations are frequently weak. Now that we are seeing malware authors placing multiple false flags in their code, attribution based on malware samples alone has become even more difficult.
For the threat actors considered, and with the evidence which we have available, there is no clear smoking gun indicating a guilty party. Other security analysts and investigative bodies may have further evidence to which we do not have access. Organizations with additional evidence, such as signal intelligence or human intelligence sources, which may provide significant clues to attribution, may be the least likely to share their insights so as not to betray the nature of their intelligence‑gathering operation.
The attack which we believe Olympic Destroyer to have been associated with was clearly an audacious one, almost certainly conducted by a threat actor with a certain level of sophistication who did not believe that they would easily be identified and held accountable.
Code sharing between threat actors is to be expected. Open‑source tools are a useful source of functionality, and adopting techniques from successful attacks conducted by other groups is likely to be a source of misleading evidence leading to false attribution.
Equally, we can expect sophisticated threat actors to take advantage of this, and to integrate ‘evidence’ into their code that is designed to fool analysts, leading the analysts to attribute the attacks to other groups. It is likely that, threat actors take pleasure in reading incorrect information published by security analysts. This could even be taken to the extreme of a country denying an attack based upon evidence presented by an unwitting third party due to false attribution. Every time there is misattribution it gives adversaries something to hide behind. In this heightened era of fake news, attribution is a highly sensitive issue.
As their skills and techniques evolve, it is likely that we will see threat actors further adopting ruses to complicate and confuse the process of attribution. Attribution is already difficult. It is unlikely to become easier.
[1] Mercer, W.; Rascagneres, P. Olympic Destroyer Takes Aim At Winter Olympics. Talos Intelligence blog. 12 February 2018. https://blog.talosintelligence.com/2018/02/olympic-destroyer.html.
[2] Shevchenko, S. Two bytes to $951M. BAE Systems Threat Research Blog. 25 April 2016. https://baesystemsai.blogspot.com/2016/04/two-bytes-to-951m.html.
[3] Shevchenko, S. Cyber heist attribution. BAE Systems Threat Research Blog. 13 May 2016. https://baesystemsai.blogspot.com/2016/05/cyber-heist-attribution.html.
[4] The devil’s in the Rich header. Kaspersky Lab SecureList. 8 March 2018. https://securelist.com/the-devils-in-the-rich-header/84348/.
[5] Rosenberg, J. 2018 Winter Cyber Olympics: Code Similarities with Cyber Attacks in Pyeongchang. Intezer Blog Cybersecurity DNA. 12 February 2018. http://www.intezer.com/2018-winter-cyber-olympics-code-similarities-cyber-attacks-pyeongchang/.
[6] Chiu, A. New Ransomware Variant “Nyetya” Compromises Systems Worldwide. Talos Blog. 27 June 2017. https://blog.talosintelligence.com/2017/06/worldwide-ransomware-variant.html.
[7] GitHub. MS17-010/zzz_exploit.py. https://github.com/worawit/MS17-010/blob/master/zzz_exploit.py.
