Speared in a Click: Documents with Executables

Clicking on an attached document or link in an email can be the initial action that brings down a network. In the second it took you to read the first sentence, that click could have set off a chain of quiet, unseen commands. It could have executed PowerShell commands in the background, downloaded and executed additional payloads from an external domain, or begun reconnaissance actions in your internal network environment to gather information in order to move laterally.

This post will walk through actions that took place when a weaponized document executed as part of a spearphishing attack. We’ll look at how different threat techniques were detected, focusing on the use of the Host Process for Windows Services (svchost.exe). We’ll also cover how Microsoft URL Security Zone Identifiers can be used to harden a network environment. In this particular case, after the initial compromise, two separate trojans were downloaded, then the adversary began to perform reconnaissance to set the stage for lateral movement before the endpoint was isolated.

Without further ado, let’s jump into the detection!

Threat Detection 8671: Spearphishing Attack

Microsoft’s Outlook, commonly used in the enterprise environment for email, spawned the Internet Explorer web browser, and downloaded a document that was labeled as an “invoice.” Adversaries often use terms like “invoice,” “check,” or even “resume” as a method of social engineering, enticing the user to click on a document in order to execute the commands embedded in the document. These emails are often from previously unknown contacts.

The screenshot above shows two instances of the .doc file being created in the temporary internet files directory, along with a zone identifier. When a document is downloaded via Internet Explorer, it is written with an alternate data stream (ADS) named zone.identifier. The zone.identifier ADS is used by numerous controls within Windows to determine actions on a downloaded files. We’ll return to the zone.identifier in a later section when we dig into the steps you can take to better defend a network.

In this detection example, the Microsoft Word application opened the file, then executed an embedded macro. In the following screenshot, the /n tells it that a new default document does not need to be created, and gives the location of the newly downloaded document to execute. Word spawned PowerShell and executed an obfuscated command.

In the interest of space, the screenshot has been truncated; however, you can see that an XOR bitwise operation was used at the end of the file (below). If you’re curious about the full command, it’s the same as this one and contains a macro that executes when the document is opened.

As a result of the execution, WinWord.exe created a seemingly random file in the customdestinations directory. According to Microsoft, Custom Destinations creates entries in a user’s “jump list.” The d93f411851d7c929 part of the customdestinations file is the jump list app ID for PowerShell when it is installed in the default location of %SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe. This is an artifact of usage by the application.

Simultaneously, an outbound connection was made to a content delivery network (CDN). It’s important to note that the connection was made over port 443, which decreases the efficacy of network-based detection due to the usage of encryption. Further research indicated the IP address associated with the network connection has been linked to various types of malware campaigns. After the network connection, a secondary payload named as a randomized number was written to the device.

PowerShell made another outbound network connection to a .ru domain and executed a known malicious payload. Up to this point, all indicators have been based off of behavior and process-state.

When examining the last event tagged as both malicious and as an indicator of compromise (IOC), the hash of the binary, combined with the associated behavior, pointed to a potential Emotet injection. We’ve identified Emotet in other environments before; it is frequently used as a dropper to download additional malware. Emotet has trojan traits and can be used to record user actions and copy sensitive information from a victim’s computer. It also takes steps to hide its existence from defenders, and will often make multiple copies of itself before the initial downloaded file is deleted. The numbered executable created a new file, then deleted the first instance.

The numbered binary spawned a new executable, which has a file hash that is exactly the same as the initial payload file. After the newly written file executed, it made another outbound network connection and downloaded an additional payload.

The next payload’s binary hash indicated that it was a potential variant of the Kryptik trojan. Note that the hash of the binary identified below is different from those above.

It created an additional executable, then began making network connections to other devices in the internal address space. This follows a trend that is consistently observed across environments that have similar outbreaks: executables are downloaded from external sites, the original executable is copied or replaced, then additional binaries with new hashes are executed.

Recall at the beginning of the story, that a user’s click started these actions. The timeline items that were shared above took place in less than a couple minutes. After this detection was written, the customer was notified, and the endpoint was isolated from the rest of the environment.

Catching the Phish: How Was This Threat Detected?

Different detection strategies and sources of threat intel can be utilized to to identify suspicious or malicious behavior. One method that helped to detect this threat identifies suspicious instances of the Host Process for Windows Services (svchost.exe). It is used to implement many Windows services, and as a result, there are often many instances of svchost.exe running, making it difficult to trace which processes belong to which host processes. Adversaries take advantage of this in an attempt to obfuscate the use of malware on a system. In order to identify potentially malicious processes, it is important to know where svchost.exe launched from, as well as what processes spawned it.

Svchost.exe typically exists in the %SystemRoot%\System32\Svchost.exe or %SystemRoot%\SysWOW64\Svchost.exe. In this case, the location was as expected. Svchost.exe is also typically launched by the Service Control Manager (services.exe) and it’s suspicious to see it launched by anything else. Finally, legitimate instances of svchost.exe typically have a command line argument “-k” to specify which service is executing within. In this case, svchost.exe was launched as a child process by the malware identified above and was missing the legitimate command line options.

It is also highly suspicious when Word or any Microsoft Office document spawns a PowerShell command, and it’s even more suspicious when it is followed by an external network connection. Looking at these behaviors helps to identify potentially malicious behavior. The noise associated with this strategy will vary in specialized environments, but we’ve found it to be highly effective in most of our customers’ environments.

Why the Attack Exists

Adversaries often use a spearphishing attachment or spearphishing link to obtain initial access to an environment. As long as the endpoint is connected to the network and humans interact with applications like email and web browsing with the outside network, adversaries can use these techniques to target unsuspecting users. This can result in devastating effects on businesses and organizations.

Macros and another tool called Dynamic Data Exchange (DDE) can also be used for good purposes, which is why the functionality still exists. Microsoft developed the tools to increase Office productivity to allow repetitive tasks in documents or spreadsheets to automatically execute. For example, when a user wants to add the same formula to multiple cells in a spreadsheet, it can be programmatically added by using a macro. The DDE functionality allows data to be updated automatically from one document to another.

While macros and DDE are helpful aspects of the Microsoft Office suite, it’s important to know how to harden your network to prevent abuse.

How to Defend Against Office Macro Exploits

Remember the zone.identifier that was attached to the downloaded document?

Zone.identifiers can be used by network administrators with URL security zone templates to allow specific actions to be taken, depending on the level of trust that is associated with the specific URL security zone. Depending on how they have been configured, the templates can be used to restrict or allow certain actions to be taken on URLs visited based on the level of trust given to the security zone. This way, Internet Explorer can be used to restrict users from performing certain actions. For example, it could give the user other notification options, or users could be prevented from enabling macros even when they are prompted to do so.

Utilize Microsoft’s URL security zone templates within the Security Manager Core to configure settings customized to your users and network environment needs will help to fine tune how your users interact with Microsoft documents.

Similarly, edge or firewall devices can have filters or access control lists (ACLs) configured to allow specific actions to be taken on certain domains, segments of the network, and encrypted web traffic. Depending on your legal restrictions, network controls may be limited in their effectiveness concerning encrypted traffic. Learn about the tools that are already in use within your environment and check to see if they are proactively configured and optimally tuned for users in your environment.

Here are some additional steps you can take:

• Disable macros for documents downloaded from the Internet, preferably using Group Policy Objects.
• If your organization doesn’t utilize macros, turn off the ability for users to enable macros when they are prompted to enable it from an email.
• If macros must be used in your business environment, use signed macros in documents that originate from trusted sources.
• Use email authentication, or Domain-based Message Authentication, Reporting and Conformance (DMARC), which combines the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) in Microsoft Office 365. This helps users identify untrustworthy emails.

Protecting Your Network

Remember that macOS users are NOT immune to this attack. For years, many macOS users reveled in the idea that they were somehow immune from the ravages of the open Internet. This is not the case. Adversaries are targeting Mac users with weaponized Office documents that utilize Python scripting (installed on all macOS systems). All users can benefit from training and should be very suspicious when being prompted to enable macros, regardless of the platform used. We previously wrote about a weaponized Microsoft Excel sheet executing on a macOS system, and there are also specific macOS hacker toolsets like the post-exploitation surveillance framework EggShell.

Last but not least, follow the tried and true advice for mitigating phishing risk: user training. Train users not to click on attached documents, especially from people they do not know, regardless of labels or filenames. Nurture and create a working environment where users can learn from each other’s mistakes to build a stronger organization. If someone does click on a weaponized document, let others know about how it arrived in the environment, what it was labeled as, and what happened as a result. In this way, other users can apply the relevant information as cautionary advice to avoid doing it on their workstations.