Behind the Scenes of an Active Breach (Part 1): Establishing Persistence

Preventing a breach is every security leader’s top priority. Stopping modern adversaries means having visibility and insight into their tactics, techniques, and behaviors. This two-part series takes readers behind the scenes of a compromised network environment in which multiple endpoints were infected with malware. Part 1 focuses on steps the malware took to establish persistence, while Part 2 will focus on steps taken to evade defenses.

In this particular engagement, Red Canary was deployed to support response efforts rather than as a proactive layer of defense. This meant that the adversary was already deeply entrenched in the environment, enabling our Cyber Incident Response Team (CIRT) to observe a broad spectrum of adversarial behaviors. We will show numerous threats mapped to the MITRE ATT&CK™ framework, referencing the related technique with the following format: Txxxx.

Because of the extent of the breach, our observations have been split into chapters:

Chapter 1: Execution from Windows Admin Shares

The Red Canary detection engineering team was working events, and all was going as expected. Suddenly, there was a surge of events coming from one customer. It started as a trickle, then became a torrent as if the floodgates of malware hades had opened.

When first seeing glimpses of the infection, malicious files were initially executing from local file shares that included the admin$, c$, d$ and print$ drives (T1077). These shares are typically hidden network shares only available to those with administrator-level permissions.

Polymorphic malware has the ability to change quickly in order to make its eradication more difficult. Note that while the names of the files are different, the hash is the same.

When viewing a process that is suspect, Red Canary’s detection engineers will search for any open source intelligence (OSINT) available, but background data can sometimes be scarce. Fortunately, endpoint telemetry allows potential threats to be analyzed based on behavioral process analysis even if malicious file signatures or hashes do not yet exist. The behavior of this binary pointed to malicious behavior because it took numerous actions to persist in the environment. Because the executable was placed on the device’s local administrative-level share, it allowed the executable to access and write to all users of the workstation or server.

The malicious binary proceeded to create randomly named files in all the users appdata directories, a location often utilized by malware. The malware also created a link in the Windows Start Menu Startup Folder.

The startup link in the start menu folder ensures the malware will automatically start when a user logs onto the machine (T1060) and remain on the system through system reboot cycles. The malware continued to iterate through all the users on the endpoint by writing randomly named files into user directories, then continued to create start-up links in all of them.

Next, the original executable from the local admin share spawned PowerShell and made an external network connection to a malicious domain. The particular domain in the screenshot below was consistently accessed in this environment to download additional malicious code which modified the resulting behavior throughout this breach.

The IEX (Invoke-Expression) command allows a PowerShell expression to be run, which accepts a string to be executed as code. When placed into the context of the command, it instructed PowerShell to download a text file from the external domain and run the contents of the file as if it were a command. The resulting action created a randomized file in the temp directory, which resulted in two additional files being written to disk.

Malware also wrote dynamic-link library (DLL) files into each user’s directory. This allows the libraries to be accessed by the malware as it can utilize them with the respective user level permissions (T1129). It also allows the delivery of additional “portable” payloads as the adversary has delivered everything needed for a payload to execute instead of relying entirely on the victim system to have prerequisites met.

Chapter 2: Creating Scheduled Tasks

In the process of the compromise, it was demonstrated time and time again that the adversary gained administrator-level permissions in order to create scheduled tasks. After the malware wrote a malicious executable in the respective user’s appdata\roaming\microsoft directory, it leveraged the Task Scheduler Configuration Tool (schtasks.exe) to create a scheduled task (T1053).

The malware scheduled an executable file that it wrote into the users’ directories to be run at a specific date and time. Some were set to run weekly on Tuesday, while others were set to run every seven hours.

This created a heavy concentration of events on Tuesday. Multiple endpoints were afflicted with the malware, all at varying stages of the infection. Because Red Canary was dropped into the environment mid-breach, we observed scheduled tasks being executed on different endpoints.

The Task Scheduler Engine can be seen spawning rundll32.exe, which loaded a malicious .dll module. In the third timeline event below, the hash is also underlined in red and is marked as an indicator of compromise (IOC).

Intel on the hash of the .dll file yielded the following information that indicated association with Corebot.

Chapter 3: Executing Scheduled Tasks

We observed different types of scheduled tasks that began executing with the resulting actions below. A scheduled task was created and ran the Command Prompt to utilize the command-line version of the Windows Script Host (cscript.exe) that utilized JavaScript to execute a file with the .wpl extension on Tuesday at 12:00.

As expected, on Tuesday afternoon we began seeing events fired by the Task Scheduler (taskeng.exe) to spawn the command line, calling cscript to run the .wpl file.

The Command Prompt (cmd.exe) executed and made four external network connections. These four external network connections were visited in the same order and manner consistently from other endpoints in the environment.

Three of the four domains used in the screenshot above have been previously utilized in the malware associated with the PinkSlipBot and Qakbot (Qbot) trojan.

Chapter 4: What Kind of Outbreak Is This?

The outbreak was spreading rapidly across the customer’s endpoints. As threats are observed in customer environments, members of the CIRT will search for information to learn more about the respective behaviors to better understand and identify the threat.

The Service Control Manager was observed spawning an executable named with eight randomized digits. It immediately copied itself into another executable file with a different name. Researchers from Sophos found that the Emotet worm contained an embedded list of seed terms used for the filename executable. It combined the two seed terms based on certain conditions of the hard disk volume ID and used them for the resulting filename. We observed a similar naming convention. In this particular example, the two terms were combined into systemcart.exe. Other names that were seen in the environment were devicename.exe, comcrypt.exe, secdns.exe, storageenv.exe and others with a similar the same pattern. Note that while the name of the file changed, the hash (blue box) indicated that it was the same file.

The utilization of common system names is also a technique of masquerading (T1036) and helps the adversary to avoid detection and maintain persistence in the environment.

Chapter 5: Making External Command & Control Network Connections

In addition to behavioral indicators to better understand the nature of the outbreak, files associated with different malware families were observed making external network connections to many different Command and Control (C&C) servers (T1104).

Threat intelligence on external network connections to C&C servers included Emotet (as mentioned above), a Freodo variant, CoreBot, and PinkSlip Bot (also referred to as Qakbot or Qbot).

In the following example, we start with a similar pattern of an eight-digit naming convention for the initial .exe file, then see a file called storagenv.exe with the same hash, indicating that the same file was copied and renamed.

In the screenshot below, after an outbound connection was made to an IP associated with a Feodo Trojan C&C server, a temporary file was written, then the file integrity of storagenv.exe changed, as indicated by the hash.

The /scomma command above instructs the resulting file to be saved as a list of items in CSV format. These are indicators that the endpoint was communicating to a C&C server at the external IP and modifying its behavior.

While the malware had multiple methods of establishing persistence, there was another technique of defense evasion that made remediation more difficult.

Chapter 6: Receiving Instructions While Hiding in Plain Sight

The malware was highly adaptable and polymorphic, and utilized native Windows binaries to cover its tracks. In the screenshot below, a binary in the q$ share can be seen as a randomly named executable file. When the file hash was checked, however, it indicated that it was the Auto File System Conversion Utility, a native Windows binary.

The malware’s polymorphic ability to write over itself made remediation and eradication more difficult because the malware masqueraded as different core Windows files. In order to help combat this, the Red Canary timeline presents information to show exactly what happened.

The following screenshot shows the malware being overwritten with another native Windows binary. After making an outbound network connection, the Windows Command Line was utilized to ping itself through the local loopback, then redirected the contents of native Windows binary calc.exe to overwrite the original malware file.

After checking the new hash, it was confirmed that the exucsfq.exe file in the example above was the binary equivalent of calc.exe (T1107). While one of the original malware files was overwritten, because the malware had made numerous copies of itself (T1105), it had employed numerous mechanisms to maintain persistence by creating startup items and scheduled tasks.

As you can see, adversaries can perform a variety of techniques to establish persistence in an environment. We hope that by providing a glimpse into a real-world breach, security leaders can gain insight into how to detect and ultimately stop adversaries. In Part 2, we focus on defense evasion and look at the steps the malware took to access credentials and evade detection.

Head over to Part 2 or learn more about Red Canary.