Behind the Scenes of an Active Breach (Part 2): Evading Defenses

This is Part 2 in a two-part series that examines actions taken by adversaries in a breach. In Part 1, we covered steps taken to establish persistence in the environment. This post will dive into steps the malware took to evade defenses as it disabled security tools, masqueraded as Windows binaries, accessed credential management libraries, and moved laterally across the network. A weaponized document was also observed executing obfuscated payloads in the environment late in the compromise assessment. This was likely one of the initial vectors; however, because Red Canary was not deployed in the environment prior to the breach, we do not have the endpoint data to determine root cause with certainty.

As in the previous post, we will show numerous threats mapped to the MITRE ATT&CK™ framework, referencing the related technique with the following format: Txxxx. Our observations have once again been split into chapters:

• Chapter 7: Disabling Windows SpyNet and Defender
• Chapter 8: Accessing Windows Credential Libraries
• Chapter 9: Moving Laterally
• Chapter 10: The Likely Delivery Mechanism – Weaponized Document
• Chapter 11: Masquerading as Windows Binaries
• Chapter 12: Steps to Protect a Network

If you missed the backstory, be sure to check out Part 1 to get insight on the steps that the malware took to persist.

Chapter 7: Disabling Windows SpyNet and Defender

Malicious binaries were observed creating modifications to antivirus and anti-malware software reporting mechanisms. In the following screenshot, the malware utilized the Windows registry to make changes to Microsoft’s AntiMalware SpyNet software by modifying it to have a value of “0” reporting capabilities. This effectively prevented the submission of new malware samples to Microsoft for analysis from this endpoint (T1089).

The malware continued to write copies of itself into user directories, then utilized the registry to create exclusion paths. In the screenshot below, the malware executable called cowvtvec.exe was written into the “tech” user’s directory. (Note: this is the same hash as the exucsfq.exe file above.) Once there, it wrote an exclusion path for the malware, then created a startup link to maintain persistence.

A similar pattern was observed as the malware modified the reporting ability for Windows Defender. In the screenshot below, malware can be seen executing from the g$ local file share, then accessing the Security Access Manager (samlib.dll), a library associated with authentication and security on Windows devices to gain the permissions needed to modify the Windows registry. It then added an exclusion path for itself in Windows Defender, then simultaneously wrote a copy of the malicious file (with the same file hash as the originating file) to the “tech” user’s directory with the same exclusion path. It also created a startup link in the user’s folder to maintain persistence.

Through access and modification of core Windows services, the malware targeted different tools for defense evasion.

Chapter 8: Accessing Windows Credential Libraries

Shortly afterward, external network connections were made. When this occurred, the Dynamic-Link Libraries (DLL) associated with user credential and authentication processes were loaded into memory. This was another indicator that the C&C servers were actively modifying the malware’s behavior.

The following screenshot shows the malware accessing the kerberos.dll, samlib.dll and vaultcli.dll authentication libraries.

Kerberos is used by Windows authentication for Active Directory services. It’s known as the “ticket granting service” that allows users to authenticate to a domain. This is the service that allows one person to authenticate to different workstations across an organization. As a general rule, it’s very bad when Kerberos is accessed by malware. In addition, samlib.dll and vaultcli.dll were loaded into memory. Processes accessing these modules indicate the execution of credential-stealing activities, and is an example of direct account manipulation (T1098). After loading the modules into memory, the malware wrote a named pipe.

Chapter 9: Moving Laterally

The malware was observed using a named pipe from one machine to another, indicating that the adversary was likely moving laterally through the network. The naming convention also indicates that the first endpoint referenced is likely a domain controller.

In other instances when credential libraries were loaded into memory, additional malicious DLL files were written into user directories.

The screenshot below shows a 001.ps1 file being downloaded from an external site and was likely a PowerShell implementation of Mimikatz, a tool often used to extract password hashes and Kerberos tickets from memory.

Accessing the credential libraries then writing files into users’ respective appdata directories allowed the malware to access resources within specific user contexts.

After writing the files, utilizing a measure to clean up after itself and evade defenses, the recently downloaded .txt file (seen being created in the screenshot above after visiting the external domain) was deleted (T1107).

Chapter 10: The Likely Delivery Mechanism – A Weaponized Document

While it may seem out of order to address the delivery mechanism at the end of this analysis, recall that Red Canary was not in the environment prior to the breach. The likely initial vector that allowed the adversary to enter the network environment was observed after being in the environment for almost one month. We’ll look at the weaponized Word document along with other types of persistence mechanisms, such as the resulting scheduled tasks.

In the screenshot below, note that the .doc file was labeled as an invoice. This method of social engineering is often used by adversaries to get past edge devices like firewalls, proxies, and other intrusion detection and prevention system (IDPS) devices because email and web browsing are necessary business functions and are often open to the Internet. Delivering a malicious document in this manner entices a user to click on and unwittingly execute the commands embedded in the document.

In this case, the process was started by the Firefox web browser. Microsoft Office was then used to open a Word Document (winword.exe) that wrote another file to disk. When the .doc file hash above was checked on VirusTotal, it returned information that it was the Emotet document downloader.

Documents that have embedded macros will carry out a predetermined set of executable actions when it is opened (T1203).

The next screenshot shows the malware utilizing PowerShell to run an obfuscated command, which resulted in external network connections being made.

Using obfuscated files (T1027) is another method used by adversaries to avoid detection. While the code is obfuscated, its resulting actions can be seen below. The malware made several outbound network connections, then wrote the Emotet malware to the “public” user’s directory.

The outbound network connections are indications that malware was continuing to communicate with an outside entity, receiving instructions and modifying its behavior.

Chapter 11: Masquerading as Windows Binaries

The screenshots below show malicious DLL files that were written by the malware. They masqueraded as legitimate Windows files; a United Kingdom keyboard layout file, and Microsoft® Visual Studio 2015. Note, however, that the hash and the names don’t quite match up.

In the following screenshot, the DLL states that it is a part of Microsoft Visual Studio as a modified MFC (Microsoft Foundation Class library) Language Specific Resource, yet the high detection ratio indicates that it is a malicious file.

As malicious behaviors were written up in detections to guide remediation actions and response efforts, the high severity detections decreased over time. The image below was taken from the Red Canary customer portal and shows the decrease in detections by week. This decrease indicated that the spread of malware had stopped or slowed.

The red color indicates a high severity in detections, yellow indicates medium, and grey represents detections of low severity that indicates potentially unwanted software like adware.

Chapter 12: Steps to Protect a Network

In this two-part post, we’ve covered various techniques that malware uses to maintain persistence as well as evade detection. We hope that digging into the behavioral aspect of adversarial activities observed in a breached environment helps organizations understand what to look for and how to respond.

These steps can be taken to help harden or mitigate the damaging actions that adversaries can take in a network.

• Educate users so they do not open email or click on links from unfamiliar people, and teach them to be wary of downloading documents from the Internet.
• Use strong, unique passwords. This malware was observed writing to shares such as ADMIN$ and C$, and once on the system, will attempt to brute force other admin accounts to gain system-wide access.
• Do not give administrative access to all users. Use the principle of least privilege and only give the appropriate access levels needed to accomplish a job.
• Closely monitor administrative-level accounts and close or disable user accounts when someone leaves the organization or moves into another role.
• Segment network environments so one network segment does not have default access rights to other segments of the network.
• If the macro or DDE functionality in Word documents is not needed, these should be disabled via Group Policy Objects or other configuration management tools so embedded executables do not automatically execute when these types of documents are opened.
• Familiarize yourself with the tactics adversaries use so that you know how to spot suspicious behavior. Ensure you have the tools, processes, and expertise in place to gain visibility across your environment.

Learn how Red Canary helps defenders identify and eradicate threats >>