Blog

On the 19th of July, the much discussed and anticipated Network and Information Security (NIS) Directive was published in the Official Journal of the EU. The Directive was developed to ensure that societies’ dependencies on technology undertake relevant cybersecurity activities to ensure resilience and confidence as we become ever more digitally dependent.

The most important aspect is when this comes into force, which is the 8th of August 2016. However, it is not immediately applicable: each member state then has a period in which to take the Directive and turn it into national legislation—that must be completed by the 10th of May 2018. It effectively then becomes live the following day.

As such, by the 11th of May 2018, you will need to be compliant if the Directive applies to your organisation; however, you should note that, although countries have until the 10th of May, they may choose to bring into force their own laws or regulations earlier, so now is the time to start engaging at your country levels to validate their planned timelines.

So what should be the next steps for any business’ cybersecurity team, now that the implementation timeline is defined and the Directive issued is final? Here are my suggestions:

1. Does it apply to your organisation? From research we are conducting with IDC, it is clear there is confusion. The Directive covers two distinct categories of entities:

• Operators of Essential Services – a public or private entity that “provides a service which is essential for the maintenance of critical societal and economic activities; depends on network and information systems; and where an incident to the network and information systems of that service would have significant disruptive effects on its provision.”

Action 1: Although the Directive lists industry sectors and sub-sectors considered operators of essential services, each Nation has the requirement to identify which organisations in its territories will be included, so you will need to validate with your relevant national authority if your company is included.

Just because an industry sector is not listed as an “essential service” in the Directive, that does not mean it is not subject to security requirements in the EU. The Directive recognizes that some sectors already are subject to sector-specific EU requirements for security that are either in-line with or potentially higher than those defined in the Directive. (Among other things, the Directive requires covered organisations to take measures that have regard to the “state of the art”.)

Action 2: Validate if your industry sector has been identified as already being effectively exempt due to existing legislative or compliance requirements meeting/exceeding the Directive’s objectives. 

• Digital Service Providers (online marketplaces, online search engines, and cloud service providers) – these companies also have security and incident notification requirements, although they are less stringent than for essential service operators. Further, for digital service providers, requirements do not apply to “micro” or “small” enterprises as defined by EU law.

Action 3: Member states will not further define digital service providers, so the definition in the Directive is set. As such you should be able to determine immediately if it applies to you.

Action 4: The security and incident notification requirements for digital service providers will be developed by the European Commission. If you believe you are covered, there is the opportunity to influence the requirements. As a first step, there is currently a survey being conducted by ENISA on the incident reporting scope (responses are due at the end of July 2016).

More information can be found here.

2. What should you do next? The Directive states that both operators of essential services and digital service providers must take cybersecurity measures with regard to state of the art and also has requirements to notify relevant national authorities of cyber incidents. 

Action 5: Now that the scope and timelines are defined, for those businesses that the Directive applies to, the next natural step is to start to complete the gap analysis.

• How near to or far from the requirements are you?

Security and incident notification requirements:

Operators of Essential Services (from Article 14)

“Member States shall ensure that operators of essential services take appropriate and proportionate technical and or­ganisational measures to manage the risks posed to the security of network and information systems which they use in their operations. Having regard to the state of the art, those measures shall ensure a level of security of network and information systems appropriate to the risk posed.”

“Operators must notify, without undue delay, to the competent authority or CSIRT incidents having a significant impact on the continuity of the essential services they provide.”

Digital Service Providers (from Article 16)

“Member States shall ensure that providers “identify and take appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems which they use in the context of offering [online marketplace, online search engine, cloud computing services] within the Union.”

“Digital service providers must notify, without undue delay, to the competent authority or CSIRT any incident having a substantial impact on the provision of a service [search, online marketplaces, cloud] that they offer within the EU.”

• What will be your strategy where you are required to become compliant?
• Do you have budget assigned and the appropriate business support to achieve this?
• How will you ensure you can validate and maintain the state of the art?

3. How do you leverage the resources that will be available to you? Each nation will be required to have a CSIRT, and the CSIRTs are encouraged to share among each other non-confidential information on cyber incidents and associated risks. These potentially will be able to provide great insight on what and where some of the key cyber risks are relevant to the businesses covered by the Directive. Likewise they should provide access to skilled resources that may be able to assist in the definition, testing and during incident response cycles.

Action 5: Do you know the CSIRT or competent national authority to which you may need to notify incidents? (Some CSIRTS/authorities may already exist; in other cases, member states will be establishing them.) How are you connected into them?

Action 6: Do you have an incident response strategy today. If not, how are you preparing for the requirement?

• How are you leveraging the skills, knowledge and resources that may be able to help you define, validate or support you during an incident?

It may seem like 2018 is a long way out yet, but 2017 is effectively the year I would consider in which businesses need to achieve the Directive’s requirements. The remainder of 2018 should be kept to validate and test your businesses capabilities, be they achieving state of the art or testing your incident response and notification capabilities.

Being part of the infrastructure and digital services that are deemed at core to society can seem like a great responsibility; however, with that comes support from national entities and their trusted providers. For some organisations this may be welcome relief, as they need to increase their capabilities; for others, it may require very little change at all.

What is key for every business is to understand if the new Directive applies to them and then work with the national entities and their trusted providers to use the time allocated to understand the requirements, complete the gap analysis, and use the coming period so that their cybersecurity capabilities have the required regard for the state of the art in place by the May 2018 deadline.

Greg Day

[Palo Alto Networks Research Center]

Unit 42 has recently discovered a new variant of PowerWare, also known as PoshCoder, imitating the popular Locky ransomware family. PoshCoder has been encrypting files with PowerShell since 2014, and the new variant named PowerWare was reported in March 2016. The malware is responsible for encrypting files on a victim’s machine and demanding a ransom via the Bitcoin cryptocurrency.

In addition to using the ‘.locky’ filename extension on encrypted files, this PowerWare variant also uses the same ransom note as the Locky malware family. This is not the first time PowerWare has imitated other malware families, as earlier versions have been known to use the CryptoWall ransom note. Other instances of ransomware have also been known to borrow code from others, such as the TeslaCrypt ransomware family.

Unit 42 has written a Python script that will recursively seek out .locky files on a victim machine and restore them to their original state. The decrypter can be found here.

Analysis

Initial analysis of PowerWare showed that this sample is a .NET executable. After careful inspection of the malware using a .NET decompilation program named dnSpy, we witnessed the word “PowerGUI” from Quest Software. This allowed us to immediately know that the malware was using the PowerShell script editor that converts PowerShell scripts to Microsoft executable files.

Figure 1 PowerGUI referenced within the decompiled malware variant

Figure 2 Decompiled Main() function

Upon closer inspection of the .NET executable file, we discovered that it’s using ScriptRunner.dll to unpack a PowerShell script, named fixed.ps1. This unpacked file is dropped to the following location:

%USERPROFILE%\AppData\Local\Temp\Quest Software\PowerGUI\51daca6d-6a9a-44c8-9717-f8cc5c68d10e\fixed.ps1

In reality, this .NET Microsoft Windows executable is only responsible for unpacking an embedded script and running it with PowerShell.exe. The script resides inside a ZIP file, named Scripts.zip. This file is located in the resources section of the file as shown in Figure 3.

Figure 3 Scripts.zip embedded within the malware’s resource section

As the Scripts.zip file is embedded within the malware without any obfuscation, we can easily extract this ZIP file using dnSpy. This in turn allows us to obtain the compressed PowerShell script within.

The PowerShell script is very similar to other PoshCoder/PowerWare variants. This sample uses AES-128 encryption with a hard-coded key, which would allow victims to decrypt files without paying, as seen in Figure 4. It doesn’t include a network beacon that tries to transmit randomly generated bytes for the key like some variants have been known to do.

Figure 4 Encryption setup for PowerWare variant

The PowerShell script automatically scans the victim’s machine for files with the extensions listed below and then proceeds to encrypt them.

Figure 5 List of file extensions encrypted by PowerWare

PowerWare then appends the .locky extension to the files it encrypts like the infamous Locky malware. It also writes a HTML file with the name ‘_HELP_instructions.html’, which is identical in wording to the Locky ransomware family. This ransom note is dropped into folders containing encrypted files.

Figure 6 PowerShell code used to mimic the Locky malware family

Figure 7 PowerWare ransom note using same wording as Locky

In the event users wish to pay the ransom, they may navigate to a provided website, such as the one below. The site provides instructions on how Bitcoin may be purchased, and once again we see references to the Locky ransomware family, which this variant is clearly mimicking.

Figure 8 Decryption website

Decryption

As mentioned previously, since the malware uses a static key, decryption of victim’s file is possible. The malware actually only encrypts the first 2048 bytes of the targeted files, as witnessed in Figure 9.

Figure 9 Example of a file encrypted with the PowerWare variant

The following screenshot shows an example of the script running on an infected Windows machine.

Figure 10 Decrypter script being executed

It is our hope that this script will assist victims that have been affected by this variant of PowerWare.

Conclusion

While this sample may appear to be new, it is in fact a variant of the previously discovered PowerWare malware family. Unlike other variants, this sample purports to be the Locky malware family.

Palo Alto Networks customers are protected from this threat in the following ways:

• All domains and IP addresses associated with this malware are correctly flagged as malicious.
• All samples encountered within this campaign are correctly identified as malicious by WildFire.
• An AutoFocus tag exists for the tracking and identification of this malware family.

Indicators of Compromise

URLs

hxxp://bobbavice[.]top/RY.exe
hxxp://p6y5jnjxpfiibsyx.tor2web[.]org
hxxp://p6y5jnjxpfiibsyx.onion[.]to
hxxp://p6y5jnjxpfiibsyx.onion[.]cab
hxxp://p6y5jnjxpfiibsyx.onion[.]link

SHA256 Hashes

RY.exe –
7f1023a3d523ab15fe3cceb7fde8038199510703a65dd03d78b9548eb2596b51

Dropped PowerShell

fixed.ps1
cd7ca159f8e8dd057b0591abc2e773d5651a27718eb72e26623e64af859d2826
%USERPROFILE%\AppData\Local\Temp\Quest Software\PowerGUI\51daca6d-6a9a-44c8-9717-f8cc5c68d10e\fixed.ps1

Written Files

_HELP_instructions.html
.locky

Tyler Halfpop and Jacob Soo

[Palo Alto Networks Research Center]

As mentioned in our previous blog, we observed the Sofacy group using a new persistence mechanism that we call “Office Test” to load their Trojan each time the user opened Microsoft Office applications. Following the report, we received several questions regarding this persistence method, specifically how it works and which versions of Microsoft Office were affected. This blog will serve as a technical analysis of this persistence method that security professionals and network defenders can use for awareness, as we believe it is likely additional threat groups will begin using this technique.

We have added a malicious behavior tag named OfficeDllSideloading to AutoFocus for Palo Alto Networks customers to track the usage of this persistence method.

Office Test Backstory

During our analysis of the delivery document used by the Sofacy group in recent targeted attacks, we saw the document create the following registry key:

HKEY_CURRENT_USER\Software\Microsoft\Office test\Special\Perf

Based on our analysis, adding a path to a DLL to this registry key would load the DLL each time a Microsoft Office application was opened. We had not seen this registry key used for persistence before, so we looked into how this registry key results in the execution of a malicious payload. We checked a clean system with Microsoft Office installed, and confirmed that it did not have the key in the registry, as seen in Figure 1.

Figure 1 Windows Registry does not have the “Office Test” key by default with Microsoft Office Installation

We checked our WildFire data and found only a handful of samples using this registry key for persistence, all of which were used to load the Carberp variant of Sofacy. At the time, we thought the Sofacy group had discovered a new persistence technique, but to our surprise,Hexacorn had revealed this registry key in an April 2014 blog post. This suggests that the Sofacy group may not have discovered this persistence technique themselves, and as threat actors often do, absorbed an existing technique into their playbook.

DLL Loading Process

To determine how this registry key executed the malicious DLL, we analyzed activities that occur when the user opens the Microsoft Word application. We chose to analyze Word because we knew from our research on the Sofacy attacks that Word loaded the Trojan’s malicious DLL; however, other Microsoft Office applications were also discovered to be susceptible to this persistence method, which we will elaborate on in the next section.

Figure 2 below shows the API function calls during the startup process that are related to the registry key. The API calls show Word (WINWORD.EXE) loading “wwlib.dll”, which is a legitimate library loaded by Word at runtime. The “wwlib.dll” library opens the registry key in question, queries its default value (NULL in Figure 2) and then loads the malicious DLL (“btecache.dll”) stored within this key using LoadLibraryW.

Figure 2 API functions called by Word that Loads Malicious DLL

The last activity seen by “wwlib.dll” in Figure 2 involves an attempt to open a handle to the same registry key within the HKEY_LOCAL_MACHINE hive, as follows:

HKEY_LOCAL_MACHINE\Software\Microsoft\Office test\Special\Perf

The attempt to open this key fails because the key does not exist with a default installation of Microsoft Office. In addition, using this registry key for persistence purposes is not ideal because the actor would need elevated privileges to modify registry keys in the HKLM hive. Instead, the threat actors created the “Office Test” registry key in the HKCU hive, which only requires the current account privileges to modify the key with a path to a malicious DLL.

In the Sofacy attacks, the actors added its loader Trojan named “btecache.dll” (Figure 2) to the “Office Test” registry key. The loader Trojan locates and loads a second DLL from “C:\ProgramData\svchost.dll” into Word, as seen in Figure 3 and exits. The “svchost.dll” contains the functional code of the Carberp variant of the Sofacy Trojan, which remains running in Word until the user closes the application.

 

Figure 3 The payload “svchost.dll” running within Microsoft Word

Purpose of the Office Test Key

Based on the activities in the startup process, we saw the legitimate “wwlib.dll” library loading the malicious DLL from the registry key. We wanted to know why “wwlib.dll” would load a DLL from a key that was not added to the registry during the installation of Microsoft Office. Static analysis of “wwlib.dll” revealed that the DLL loads the library from the registry key, then attempts to resolve and call an API function named “_GetPerfhostHookVersion@0” from the loaded library, as seen in Figure 4.

Figure 4 Code within wwlib.dll that loads a DLL from the registry and attempts to resolve and call _GetPerfhostHookVersion@0

When “wwlib.dll” uses the LoadLibraryW function to load the DLL from the registry key, it runs the DllEntryPoint exported function in the DLL. In the case of Sofacy’s “btecache.dll”, the DllEntryPoint function locates the second DLL called “svchost.dll”, loads and runs its functional code. The “btecache.dll” file does not contain an exported function named “_GetPerfhostHookVersion@0”, but this does not matter as the code in Figure 4 would fail to resolve the API function but would continue executing without calling the API.

In addition to “_GetPerfhostHookVersion@0”, the “wwlib.dll” library also attempts to resolve several additional exported functions from the DLL loaded from the registry, specifically with names that contain the following:

_InitPerf
_PerfCodeMarker
_UnInitPerf

It appears that Word (and other Microsoft Office applications) use this registry key to load DLLs in order to conduct performance evaluations and other debugging tasks during development or testing phases of the applications. This would explain the reason why the “Software\Microsoft\Office test\Special\Perf” registry keys are not created during the installation of Microsoft Office.

We also discovered that the library will attempt to load a DLL from the following registry key in the HKEY_LOCAL_MACHINE hive, whose key name “RuntimePerfMeasurement” further suggests that “wwlib.dll” uses these registry keys for performance testing and debugging purposes:

HKEY_LOCAL_MACHINE\Software\Microsoft\Office test\Special\Perf\RuntimePerfMeasurement

Susceptible Applications and Versions

To see which versions of Word were susceptible to this persistence mechanism, we checked “wwlib.dll” in the following Word versions: 2003, 2007, 2010, 2013, 2015 and 2016. We were able to confirm “wwlib.dll” from Office 2007, 2010, 2013, 2015 and 2016 would load a DLL from the “Office Test” registry key discussed in this blog. Office 2003 would not load a DLL from this registry key and it did not have a “wwlib.dll” file.

We also tested other Microsoft Office applications to see which would load a DLL from the “Office Test” registry key, which includes Word, Powerpoint, Excel, Outlook, OneNote and Publisher. It is interesting to note, that some applications in the Office suite do not need to call another DLL to load the malicious payload via the registry persistence mechanism (such as Word using wwlib.dll) and instead will load the malicious payload directly from the application. Figure 5 shows a graphical representation of applications loading the payload directly from the executable versus using a separate DLL file.

Figure 5 Office Test workflow

Simple Protection

During our research, we found that the “Office Test” persistence technique could be easily defeated by manually creating the registry key “HKCU\Software\Microsoft\Office test” and removing the current user’s account write permissions for this key. Microsoft Office does not require this registry key to operate and does not even create the registry key during installation; therefore, adding this key as read-only will have no effect on the usability of Microsoft Office applications. The steps taken to defeat the “Office Test” persistence mechanism will be outlined below and could also be easily scripted or pushed to systems via group policy.

Disclaimer: Modifying the registry can cause serious problems that may require you to reinstall your operating system. We cannot guarantee that problems resulting from the incorrect use of the registry can be solved. Use the information provided at your own risk.

First, we created the “HKCU\Software\Microsoft\Office test” via the “reg” command. Open a command prompt (cmd.exe) and input the following:

reg add “HKCU\Software\Microsoft\Office test”

Figure 6 The “reg” command used to create the “Office test” registry key

We then navigated to the newly created registry key using the “regedit” application. By right clicking on the key, we can access the permissions associated with the key, as seen in Figure 7.

Figure 7 Right clicking key allows access to permissions

The current user has “Full Control” permissions for this registry key, as seen in Figure 8. This permission allows an actor to write the path to the Trojan to the “Special\Perf” sub-key. The “Read” control in Figure 8 allows Microsoft Office to read the contents of this key and its sub-keys, which is how the actor leverages this technique to load a malicious DLL into Office applications. To defeat this persistence mechanism, we can remove the current user’s write permissions to this key by clicking the “Advanced” button.

Figure 8 Current user’s default permissions to the “Office test” registry key

The current user was granted “Full Control” permissions to this registry key because it inherited permissions from its parent object, which ultimately inherited its permissions from the HKEY_CURRENT_USER hive. To remove the user’s write permissions to this registry key, we first must remove the inherited permissions by unchecking the box seen in Figure 9.

Figure 9 Remove inherited permissions by unchecking this box

By unchecking the box in Figure 9, the dialog box in Figure 10 pops up, which provides options for “Remove” to remove all permissions from this key or “Add” to set specific permissions for the user.

Figure 10 Dialog box displayed after removing the registry key’s inherited permissions

Here we will click “Add”, select the current user, then press the “Edit” button to set specific permissions for this user. In the next dialog, click the “Clear All” button first to remove all existing permissions then select only “Read Control”, as seen in Figure 11.

Figure 11 Read-only permissions assigned to this key

With the “Read Control” permission, Microsoft Office products are still able to read from this registry key, but malicious documents will not be able to write to this key. We tested this simple registry modification against the delivery document used by Sofacy discussed in our previousblog and discovered that while the delivery document was still able to exploit our analysis system, the payload would not be able to run when the user opened Microsoft Office applications, thus creating a benign infection.

Autoruns Detecting Office Test

Unit 42 reached out to notify Microsoft of the Office Test persistence mechanism and its use by a threat group in targeted attacks. On July 4, 2016, Microsoft released a new version of Autoruns, specifically v13.52 that includes checks for the Office Test registry keys. We downloaded Autoruns v13.52 and tested both the GUI (Autoruns.exe) and CLI (autorunsc.exe) versions of the tool on a system compromised with the Sofacy tool that used this persistence technique. Figure 12 and Figure 13 below show the two Autoruns tools detecting the use of this registry key for persistence.

Figure 12 GUI version of Autoruns detecting Office Test persistence mechanism

Figure 13 Autorunsc detecting the Office Test persistence mechanism

Conclusion

The “Office Test” persistence mechanism allows threat actors to execute a Trojan each time a user runs any of the Office applications. This persistence mechanism loads a malicious DLL by leveraging a registry key that appears to be used during the development and testing of Microsoft Office applications. The use of this registry key for persistence is quite clever, as it requires user interaction to load and execute the malicious payload, which makes automated analysis in sandboxes challenging. Low awareness of this persistence method, coupled with the sandbox evasion obtained from user interactions, makes this a potentially attractive persistence method that we believe may be used in future attacks. Unit 42 suggests monitoring for systems that have this registry key already created, as it is possible a threat is already using the key for persistence purposes. Microsoft has added the “Office Test” registry keys to its Autoruns tool for detection purposes as well. Also, we suggest disabling this persistence method by creating the “Office test” registry key in read-only mode as outlined in this blog.

Robert Falcone

[Palo Alto Networks Research Center]