Wednesday, October 11, 2017

Spoofed SEC Emails Distribute Evolved DNSMessenger

Executive Summary

Cisco Talos previously published research into a targeted attack that leveraged an interesting infection process using DNS TXT records to create a bidirectional command and control (C2) channel. Using this channel, the attackers were able to directly interact with the Windows Command Processor using the contents of DNS TXT record queries and the associated responses generated on the attacker-controlled DNS server.

We have since observed additional attacks leveraging this type of malware attempting to infect several target organizations. These attacks began with a targeted spear phishing email to initiate the malware infections and also leveraged compromised U.S. state government servers to host malicious code used in later stages of the malware infection chain. The spear phishing emails were spoofed to make them appear as if they were sent by the Securities and Exchange Commission (SEC) in an attempt to add a level of legitimacy and convince users to open them. The organizations targeted in this latest malware campaign were similar to those targeted during previous DNSMessenger campaigns. These attacks were highly targeted in nature, the use of obfuscation as well as the presence of a complex multi-stage infection process indicates that this is a sophisticated and highly motivated threat actor that is continuing to operate.

Technical Details

The emails associated with this malware campaign were spoofed to make them appear as if they had originated from the Securities and Exchange Commission (SEC) Electronic Data Gathering, Analysis, and Retrieval (EDGAR) system. For those not familiar with this system, EDGAR is an automated filing platform that organizations can use to submit filings which are legally required to be performed by publicly traded companies. This was likely done to increase the perceived legitimacy of the emails and increase the chances that the recipient would open the email and associated attachments.

Figure 1: Example Malicious Email

The emails themselves contained a malicious attachment that when opened would initiate a sophisticated multi-stage infection process leading to infection with DNSMessenger malware. The malicious attachments were Microsoft Word documents. Rather than leveraging macros or OLE objects, which are some of the most common ways that Microsoft Word documents are leveraged to execute code, these attachments leveraged Dynamic Data Exchange (DDE) to perform code execution. A description of this technique has been published here. This technique has recently been publicized following a Microsoft decision that this functionality is a feature by design and will not be removed. We are now seeing it actively being used by attackers in the wild, as demonstrated in this attack.

Similar to the emails described above, the malicious attachments were made to appear as if they had originated from the SEC and include logos and branding as well as information that would be expected from any documents received from the SEC. When opened, victims would be greeted with a message informing them that the document contains links to external files, and asking them to allow/deny the content to be retrieved and displayed.

Figure 2: DDE Message Prompt

Figure 3: Example Malicious Document

In the case of this attack, if the user allows the external content to be retrieved, the malicious document will reach out to attacker hosted content to retrieve code that will be executed to initiate the malware infection. Interestingly, the DDEAUTO field used by this malicious document retrieved code that the attacker had initially hosted on a Louisiana state government website, which was seemingly compromised and used for this purpose. The DDEAUTO command that is executed is below:

Figure 4: DDE Code Retrieval Command

The aforementioned command results in the code hosted at the referenced URL to be downloaded and executed directly using Powershell. The contents of the code that is retrieved from the server is Powershell code and includes a code blob that is both Base64 encoded and gzipped. The code is retrieved, deobfuscated, then passed to the Invoke-Expression (IEX) cmdlet and executed by Powershell.

Figure 5: Stage 1 Code

The deobfuscated code is responsible for staging and kicking off subsequent stages of the infection process. It is also responsible for achieving persistence on systems. The code features a number of ways that persistence may be achieved depending on the operating environment of the malware. It determines the version of Powershell on the infected system as well as the access privileges of the user to determine how to proceed with achieving this persistence.

First, a blob of code called $ServiceCode, which is also both base64 encoded and compressed using gzip, is written to the Windows registry using the following Powershell command:

Figure 6: Registry Creation

A second block of code present in the Powershell is called $stagerCode and is responsible for extracting and decoding the code that was previously stored in the registry, then executing this code, first checking for the presence of the mutex '1823821749'. If this mutex does not exist, execution continues.

Figure 7: Mutex Check and Execution

The malware then attempts to write the contents of $stagerCode along with the appropriate PowerShell command to execute it to the following registry locations, creating a new registry key called "IE"

HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce

HKLM:\Software\Microsoft\Windows\CurrentVersion\RunServices

HKCU:\Software\Microsoft\Windows\CurrentVersion

HKEY_USERS\.Default\Software\Microsoft\Windows\CurrentVersion\Run

HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

HKLM:\System\CurrentControlSet\Services\VxD

HKCR:\vbsfile\shell\open\command

Figure 8: Registry Activity

The malware also creates a new scheduled task called "IE" that is responsible for executing $stagerCode each time the system boots, using a random startup delay period.

Figure 9: Scheduled Task Creation

The malware then queries the system to determine the characteristics of the environment in which it is operating to determine how to proceed. It specifically checks the version of Powershell that is installed on the system. If the system is running a Powershell version later than Powershell 2.0, the malware will write the contents of $ServiceCode to an Alternate Data Stream (ADS) of the the following file location:

%PROGRAMDATA%\Windows:kernel32.dll

The malware then checks to determine the privilege level of the user that was infected. If the user has administrative privileges on the infected system, it will set up a WMI event consumer and filter as an additional WMI-based persistence mechanism. The filter name is "kernel32_filter" and the consumer name is "kernel32_consumer". The Powershell code used for the performance of these tasks is below:

Figure 10: ADS and WMI Persistence

Once all of these tasks have completed, the malware then enters the next stage of the infection process by executing $stagerCode directly using the IEX Powershell cmdlet.

This next stage of the malware infection was heavily obfuscated with both variables and function names obscured. Most of the strings within this code were also base64 encoded. The code associated with this stage starts by defining an array containing a list of domains that will be used for subsequent Command and Control (C2) communications. A list of the domains in this array is included in the Indicators of Compromise section of this blog.

The malware also obtains the serial number of the system from the BIOS. It calculates the MD5 hash of the serial number and returns the first ten bytes.

Example S/N: VMware-56 4d 64 66 d0 7d f4 26-2c ad a5 8b f8 51 26 f8

Resulting Value: EFA29DD310

The malware then sets a counter value to zero. The aforementioned hash value, the hardcoded string "stage", the value of the counter, and a randomly selected domain from the array are then combined to create the initial hostname that will be used by the malware to start making DNS requests.

Example Hostname: EFA29DD310.stage.0.ns0.pw

At this point the malware enters a loop which will continue until it receives an A record lookup result of 0.0.0.0 or any lookup fails entirely. The A record result represents a checksum value, which will be explained below. The IPv4 value returned by the DNS server in response to the A record request is then converted to an integer, then a binary number.

Example IP: 107.50.99.116

Integer Value: 1798464372

Binary: 1101011001100100110001101110100

The same generated hostname is then used by the malware to make a TXT record request. The result of the TXT record query is then used to calculate an MD5 hash and the first eight bytes of the MD5 hash are then run through a checksum algorithm that returns an integer value which is converted into a binary number.

Once the malware has both the binary values from the A record response and the above checksum calculation, they are compared. If the A record response and the TXT record response match, the result of the TXT record query response is appended to the end of a final resulting string, a new domain is then randomly selected from the array and the counter value previously mentioned, and included in the hostname used for queries, is incremented by one. If they don't match, the queries continue in kind until they do.

This process continues until the result of the A record lookup is 0.0.0.0, which indicates a completion of the code collection via DNS, at which time the resulting string is returned for further processing. This result string is then decoded using Base64 and decompressed using gzip. It is then passed to the Powershell IEX cmdlet to execute the code that was retrieved using DNS.

During analysis of this specific attack, we were unable to obtain this next stage of Powershell code from the C2 servers. Given the targeted nature of this attack it is likely that the attacker is restricting these communications in an attempt to evade analysis by information security companies and researchers. It's been reported that the stage 4 payload is documented here.

Conclusion

This attack shows the level of sophistication that is associated with threats facing organizations today. Attackers often employ multiple layers of obfuscation in an attempt to make analysis more difficult, evade detection and prevention capabilities, and continue to operate under the radar by limiting their attacks to only the organizations that they are targeting. It is also important for organizations to be aware of some of the more interesting techniques that malware is using to execute malicious code on systems and gain persistence on systems once they are infected. In this particular case, the malware featured the capability to leverage WMI, ADS, scheduled tasks, as well as registry keys to obtain persistence. The use of DNS as a conveyance for later stage code and C2 communications is also becoming more and more commonplace. Talos continues to monitor the threat landscape for unique and targeted attacks such as this one so that customers remain protected as attackers change the techniques they use to perform their malicious activities.

Coverage

Additional ways our customers can detect and block this threat are listed below.

Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.

CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

We observed samples for this campaign that retrieve the 2nd stage PowerShell script from pastebin. If you want more details: https://blog.nviso.be/2017/10/12/yara-dde-rules-dde-command-execution-observed-in-the-wild/