enSilo Protects Against Shamoon-Related Attacks
Earlier this month the security community discovered a third variant variant of the Shamoon, also known as Disstrack malware, dubbed Shamoon version 3. This version immediately received the spotlight because, unlike its predecessors, it destroys files and data on all systems affected by it before overwriting the Master Boot Record (MBR). Previous versions of Shamoon were associated with the threat group APT33. The APT33 classification was given to an Iranian threat group specialized in targeting organizations geographically located in the Middle East.
The mission of these attacks was to destroy intangible assets and prevent availability of resources. When comparing the different Shamoon versions, some online resources suggest that Shamoon v3 and Shamoon v2 share similar code. In addition, Shamoon v3 also contains an ASCII art resembling the Arabic language. Though Shamoon v3 is yet to be attributed directly to any Iranian threat group, the code similarities between the different Shamoon versions, the techniques, tactics and procedures (TTPs) of Shamoon 3 and the targeted sector and geographical location of organizations affected by this malware could suggest otherwise.
According to Italian oil service company SAIPEM, its servers located in the Middle East were affected by Shamoon v3. According to Reuters, the attack was very destructive that it required SAIPEM to perform the restoration of data for approximately 300 endpoints (the majority were servers). Clearly, the restoration required a significant amount of resources, effort and money it to perform and bring SAIPEM systems back to full operation mode. Destructive attacks of this nature can cripple organizations especially if they are not prepared ahead of time to ensure their assets are protected accordingly.
The motive behind the Shamoon v3 is still unclear. However, its mission is to destroy and wipe data from assets affected by it. Due to that, the remaining question is still the same. How can organizations protect against these types of attacks and ensure the protection of their assets? At enSilo, we already know the answer to this question. The next section will provide details on how the enSilo Endpoint Security Platform can help organizations to protect against these types of attacks.
The security community reported several different variants of Shamoon v3 over the past month. Many of the reports like the one here provide great telemetry and code breakdown of each of the Shamoon v3 malware components. Hence, we won’t concentrate on the technical aspect of each component. Instead, we will discuss the attack workflow and provide information about blocking each component.
enSilo tested the components of the Shamoon v3 malware, especially those related to propagation and data wiping. The results show that the enSilo Endpoint Security Platform protects against the malware and prevents the spread of the wiper component to other systems. Also, the platform prevents the execution of the wiper component that is responsible for the distraction of data. The following information provides details about each component of Shamoon v3 and also demonstrates how enSilo Endpoint Security Platform with post-infection protection blocks this malware components operation in real-time.
The first component in the Shamoon v3 malware is the file OCLC.exe. The file OCLC.exe is a dotnet compiled Portable Executable (PE) that contains the following static characteristics:
Module Ver ID: f0c98123-da11-4b8a-99bb-c23bf4e47b3d
TypeLib ID: 32d0110b-5d90-4e9c-988a-2045187f5acd
Compiled Time: 2018-12-08 18:57:18
When executed, this PE file is responsible for several operations. However, one of its operations is to execute another dotnet compiled PE file called Spreader.exe. The Spreader.exe file contains the following static characteristics:
Module Ver ID: 231afc3d-b93d-414b-a23d-eac4981e2f27
TypeLib ID: 9d68e0f2-bd16-41e0-8a35-e52137ec6b2c
Compiled Time: 2018-12-09 18:05:26
The process executes via launching a command line process (cmd.exe) with the following command /c spreader.exe shutter\systems.txt. Essentially, the spreader.exe file executes along with a text file (the text file contains a list of hostnames) located in either the shutter or the light folders. As mentioned here, the spreader.exe file is responsible for spreading the wiper component to all the systems their hostname found in the text file. However, on enSilo protected systems, this execution operation is blocked during execution. As such, the spreading of the wiper component to other systems in the network is unsuccessful. The following figures illustrate how the enSilo Endpoint Security Platform visualizes the entire attack chain from detection to prevention:
Figure 1: Blocking the file OCLC.exe
Figure 2: Blocking the spreader.exe
In the next phase of this attack, the spreader.exe process launches another PE file called SpreaderPsexec.exe. This file is similar in its functionality to the known Sysinternal Psexec tool. The spreader.exe launches this file to execute the wiper component on each remote system. Finally, the wiper component PE file SlHost.exe launches. If this operation is successful, the wiper begins its destructive operation on each affected system. The SlHost.exe file contains the following static characteristics:
Module Ver ID: 125483dd-f8dd-470e-b1ee-6e8c04984036
TypeLib ID: 0b90d3c6-05c3-4200-9193-b4f1a67388b5
However, on an enSilo protected systems, this operation is blocked during execution as shown in the following figure:
Figure 3:Blocking the wiper
Figure 4: Tracking File Deletion
Every time this wiper component attempts to perform any manipulation to files (i.e., File Creation, File Write Access, File Rename, File Delete, etc.) on the volume, enSilo will detect this and visualize this operation. However, when the enSilo Endpoint Security Platform runs in full protection mode, this file manipulation process never occurs because enSilo blocks the wiper on execution.