Year: 2016

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]

It’s no doubt cybersecurity provides longevity to a business and can help differentiate it from its competitors – for both good and not so good reasons. Organisations, both in the public and private sector, need to have strong cybersecurity fundamentals to provide trust and confidence to citizens, businesses and customers alike.

As we have seen, though, the threat landscape is not abating and it will continue to evolve. Our cyber adversaries are becoming more sophisticated, sharing tools, exploits and attack methods, and automating their processes. In doing so, they have achieved a clear competitive advantage in cyberspace and are eroding trust in today’s digital age.

This new challenging reality is true for Australian organisations, as it is for global businesses alike. The Australian government is taking important steps to help raise its cyber resilience and approach to cybersecurity with the release of the Cyber Security Strategy in April 2016. As Australian Prime Minister Malcom Turnbull has said, “the Australian Government has a duty to protect our nation from cyber attack and to ensure that we can defend our interests in cyberspace. We must safeguard against criminality, espionage, sabotage, and unfair competition online.”

Australia’s Cyber Security Strategy has five main themes:

• A national, cyber public-private partnership
• Strong cyber defences (including cyberthreat information sharing)
• Global responsibility and influence
• Growth and innovation
• A “cyber smart nation”

These are laudable goals, but if we aspire to put an end to the breaches we read about in the headlines almost daily, a partnership is needed to achieve these.

One key way for industry to play a valuable role is to participate in voluntary cyberthreat information sharing. Operationalising threat information sharing, both within and across industries, and between the private and public sectors, will dramatically shift the balance of power, close the competitive gap, and realise exponential leverage against cyber adversaries by driving up the cost of successful attacks.

What Is Meant by Cyberthreat Information Sharing?

Cyberthreat information sharing is the sharing of information about threats and incidents so that all entities can better protect and defend their networks. The information in question is generally technical in nature, such as bot command-and-control servers, malware samples, malware analysis results, and indicators of compromise. In short, it is about sharing attack information. What’s most critical is to learn about the kinds of actors targeting organisations, the tools they have available, and the tactics they employ – all to help organisations to prevent attacks and defend their networks more effectively.

What to Share and How

First, let’s define the attributes of what should be shared:

• Threat Indicators: forensic artefacts that describe the attacker’s methodology.
• Adversary’s Campaign Plan: a collection of threat indicators for each link in the cyberattack lifecycle attributed to a specific adversary group.
• Context: additional non-campaign plan intelligence about an adversary group that is helpful for organisations to understand the adversary. This includes things like motivation, country of origin, and typical targets.
• Adversary Dossier: campaign plans + context: a collection of threat indicators attributed to a specific adversary campaign or playbook (campaign plans), plus any additional context about the adversary group.

Our mission should be to share all of the above but, most importantly, an adversary group dossier. Doing so will enhance the assessment of the adversary group’s potential, material impact to the targeted organisation, giving a better opportunity for that organisation to detect and prevent the attack, as well as deter an adversary.

The information itself is important – but it must be actionable. This means that it must arrive in as close to real time as possible. As we have observed in some of the largest breaches, the best resourced security teams cannot scale manual responses to automated threats — only through automating prevention and detection can organisations be fast enough to adequately secure networks. Thus, government and industry must collaboratively build a robust, automated information sharing architecture, capable of turning threat indicators into widely distributed security protections in near-real time.

Resistance to Sharing and Other Barriers to Success

Increasing cyberthreat information sharing in our country is easier said than done, for a number of reasons. First, there is apprehension amongst organisations that information sharing could negatively impact them. Many feel that that by sharing information that could be classified as sensitive and privileged, they would be giving the upper hand to their competitors. This sentiment from the business community is valid and should be acknowledged. But, as noted above, we should focus on sharing attack information – not information on who has been breached.

Some of the other challenges and perceived barriers to greater cyberthreat information sharing that will need to be addressed are:

• Privacy: Laws should not unduly prohibit the sharing of personal information that is necessary to identify and prevent attacks. At the same time, the Australian government should ensure that there are responsible privacy protections in place related to cyberthreat information sharing.
• Trust among private sector competitors: Some organisations consider cyberthreat information to be their own proprietary intellectual property (IP) and do not want to share it. We need to reverse this notion. The more we continue to treat this information as IP, and the more we keep it in silos within our own organisations, the greater opportunity the adversary has to strike again. Adversaries share tools, exploits and attack methods – so should we. Everyone should have access to the same body of threat information and collaborate to quickly translate it into security controls to use within their own organisations and their collective customer base.
• Antitrust concerns: There is a fear among some companies that sharing threat information between organisations makes them vulnerable to antitrust violations. The Australian government should clarify that cybersecurity threat information voluntarily shared, or received, by a private entity with another private entity is exempt from antitrust laws.
• Over-classification: The government, in some instances, may “over-classify” cyberthreat information it receives from both internal and external sources. It takes a significant effort —and valuable time — to declassify that same information to share with private companies and the public at large.

Where to Go From Here

We urge the Australian government as well as industry to quickly put into action the recommendations for greater cyberthreat information sharing as laid out in the new Cyber Security Strategy. Cybersecurity threat information sharing within and across industries and with the public sector must be embraced by everyone. The faster organisations can share information, the better we can serve to protect each other and push the cost back to the adversary. Until the public and private sectors truly collaborate to build systemic information sharing partnerships, it’s like we’re combating our adversaries with technological weapons that have no ammunition.

Sean Duca

[Palo Alto Networks Research Center]