Automating Remote Remediation of TrickBot via Falcon’s Real Time Response API: Part 1

The combination of commodity banking malware and ransomware is nothing new in the threat landscape. Adversaries continue to develop new tactics that enhance their capabilities to quickly spread malware infections across an environment, seize control of systems and hold organizations hostage pending a ransom payment. The adversary tracked as WIZARD SPIDER has used “big game hunting” tactics to great effect against a diverse set of targets.

Part One of this two-part blog series covers the CrowdStrike® Falcon Complete™ team’s ability to remotely remediate TrickBot, a modular banking trojan that is particularly devastating when paired with Ryuk ransomware. This deep dive analyzes a recent TrickBot variant used in the wild and outlines a strategy for the remote identification and remediation of a TrickBot-infected host.

As the global workforce continues to transition to remote work from home, it is increasingly critical for defenders to leverage tools with remote detection and remediation capabilities. The remediation of dozens or hundreds of hosts individually is not practical or cost-effective for widespread infections — and this is especially true when the systems are widely distributed and not concentrated in a small number of locations or facilities.

A recovery approach that combines remote access with an automated methodology provides a powerful alternative that addresses the limitations of manual remediation and/or rebuilding systems on an individual basis. This blog provides deeper insight into utilizing the CrowdStrike Falcon® API (application programming interface) along with scripting via Python and PowerShell to remotely remediate infected systems at scale.

Threat Context: Organizations Get “Tricked,” Then Get “Ryuked”

WIZARD SPIDER’s TrickBot is often delivered to endpoints via email phishing campaigns and deployed as a secondary payload. TrickBot has been observed as a follow-on infection to a variety of initial compromises including Ursnif and BokBot (IcedID), but Emotet in particular is frequently observed as its precursor. Emotet is a malware downloader developed and operated by the criminal group MUMMY SPIDER. Emotet is known to deliver a wide variety of alternative payloads, but this partnership between the MUMMY and WIZARD threat groups appears to be consistently effective.

In addition to credential theft and wire fraud, TrickBot possesses modular capabilities that allow it to spread throughout a network through exploitation of SMB (Eternal Blue), brute forcing RDP (Remote Desktop Protocol), or via network shares. Once WIZARD SPIDER has gained a foothold within an environment with successful TrickBot infections, it conducts a manual review of collected system information and attempts to identify critical hosts. If a system appears interesting enough to them, attackers may then pivot to manually deploying Ryuk payloads and begin ransoming hosts. CrowdStrike has observed multiple instances of this infection pattern. Ryuk has impacted organizations in many industry verticals, including healthcare, government, education and the private sector, and is frequently used to target businesses or organizations that require high resource availability (i.e., more likely to pay ransom demands).

Overview: TrickBot Analysis and Remediation

TrickBot malware is fairly simple in its functionality, but its modular nature provides flexible options for its operators. Historically, it used two core modules, “injectdll” and “systeminfo.” The injectdll module is a classic banking module that is used to target financial institutions. Additional modules, such as “systemInfo,” fingerprint an infected system, while others such as “‘networkDll,” “wormDll” and “shareDll,” offer additional capabilities for network reconnaissance and lateral movement.

The illustration of the remote remediation process presented in this blog covers the basic steps required to complete the process manually via Falcon’s Real Time Response (RTR) console. In Part 2, the focus transitions to an explanation of the automated methodology. Mass remediation of TrickBot via an automated script process saves a significant amount of time and resources that can be better allocated for other risk reducing initiatives or priority recovery tasks.

The remediation of TrickBot can be broken into three distinct steps:

1. Killing the malicious processes (injected svchost)
2. Locating and removing the persistence mechanism (e.g., scheduled tasks, services)
3. Removing disk artifacts (e.g., binaries and directories).

The following offers details on each step.

TrickBot Step-by-Step Manual Remediation

Please note: Some of the examples in the following scenario have CrowdStrike Falcon configured with DETECTIONS ONLY and PREVENTIONS OFF for illustrative purposes. A properly configured Falcon instance would prevent the activity presented here.

STEP 1. Finding and Killing the Malicious svchost.exe Processes

In Figures 1 and 2, Falcon in detection-only mode will immediately detect the launch of TrickBot’s core binary as it performs a process injection into svchost. By leveraging Falcon’s process tree explorer, it can be seen that the parent and child processes of the TrickBot binary (2981732f7ee9fccd13797b2a8f91aa21ff08ff7d39823980882910d9a4992d4a.exe) are both, in fact, svchost.exe.

By drilling down into the process details in the Falcon UI, the process ID associated with the TrickBot binary that is masquerading as svchost.exe can quickly be identified. There are typically multiple copies of injected svchost, largely dependent on the number of modules that have been loaded.

Figure 1. Process Execution Tree Indicating svchost.exe Process Injection (Click image to enlarge)

Figure 2. Further Detail in Falcon UI Provides Additional Process and File Path Information (Click image to enlarge)

Following triage within the Falcon UI, the responder next pivots to a Real Time Response (RTR) session to begin the remediation process. First, the svchost.exe process that is being used to run the malicious TrickBot processes must be identified and terminated.

From the RTR session, the host can be queried for specific svchost.exe processes that are not associated with a named service. The svchost.exe process is the Windows Service Host, so if there is a running svchost.exe process that is not associated with a legitimate service, a likely conclusion can be made that those process IDs are malicious. These can be identified as any svchost.exe process with “N/A” associated.

Figure 3. Query to Output Service Name Associated with svchost (Click to enlarge image)

In this example, four malicious processes have been identified. It would certainly be possible to terminate each in turn, but it may be more efficient to identify the parent process, and then its entire tree can be killed in one fell swoop. A simple WMIC query can be used to identify the process IDs and associated parent process IDs as shown in Figures 4 and 5.

Figure 4. Query to Print Parent/Child PIDs as Output (Click to enlarge image)

Figure 5. The Identified Parent/Child PIDs for svchost.exe (Click to enlarge image)

The Process ID displayed in the original detection in the Falcon UI (in this example, the PID in question was 5400) can be used as an easy way to identify the parent process of malicious svchost.exe processes. The parent PID can then be referenced against the other malicious svchost.exe PIDs to confirm that it is the parent of all of them and the originally injected process.

Figure 6 shows that to terminate the malicious processes, the taskkill command can be used with the 5400 PID combined with the “/t” parameter, which provides the instruction to kill not only the PID specified but the entire “tree.” This terminates all of the malicious svchost.exe processes with one command.

Figure 6. Terminating Malicious svchost.exe PIDs (Click to enlarge image)

STEP 2a. Removing the Persistence

TrickBot typically employs a variety of persistence mechanisms on compromised hosts. Most commonly, this includes a scheduled task, although services are commonly observed, depending on which modules are loaded by the malware, and registry keys have been identified in some cases as well. For the purposes here, and what has been observed recently, focus will be applied to the scheduled tasks first and then persistent services.

Figure 7. Query to Find the Path for Scheduled Task Persistence Mechanism (Click to enlarge image)

Figure 7 shows a query for scheduled tasks on the affected host. The search can be assisted by data from the detection in the Falcon UI. The path and binary names previously identified in the Falcon UI can be identified from the rest of the data. Additionally, the scheduled task is found pointing to a path under C:\Users\*\AppData\Roaming\*, which is typical of TrickBot and many other malware variants.

The directory “extvisual” is a key indicator of compromise (IOC) and can be used later in the manual remediation process and as an integral search string in the automated processes. In the query shown in Figure 8, the parameter -context 10 shows the surrounding 10 lines and will reveal the actual name of the task that is required for removal.

Figure 8. Getting the Scheduled Task Details (Click to enlarge image)

The next step is to delete the scheduled task, as shown in Figure 9. CrowdStrike has observed recent variants of TrickBot dropping two tasks with the same name. One will run at system start-up, and one will run every minute. The implication here is that speed is of the essence during remediation, and the timing of deleting these artifacts must be considered in order to be successful.

Figure 9. Deleting the Scheduled Task Manually (Click to enlarge image)

STEP 2b. Removing the Persistence (Services)

In addition to scheduled tasks, TrickBot will often start a service to establish persistence. These can vary widely in number, name and/or location depending on the modules that are loaded by the malware. TrickBot’s malicious services will often point to binaries that have been written to C:\ or C:\ProgramData. The query to identify these services is shown in Figures 10 and 11.

Figure 10. Query to identify persistence via Services (Click to enlarge image)

Figure 11. Identified Path to Persistence via Services (Click to enlarge image)

In this example, only one service was identified, so manual removal is not entirely cumbersome, as shown in Figure 12. However, CrowdStrike has observed situations in which there are dozens of services established, making manual removal a slow and tedious process.

Figure 12. Deleting Malicious Service (Click to enlarge image)

STEP 3. Removing Remaining Artifacts

Now that the svchost.exe processes have been killed and TrickBot’s persistence mechanisms removed, it’s time to clean up and remove the remaining artifacts.

TrickBot has a few specific artifacts that it places on the host. The first one is the named folder located in C:\Users\*\AppData\Roaming, as shown in Figure 13. This is a dynamic indicator and will change frequently, but TrickBot does reliably create a directory in this location for the core binary, modules, configuration and data files that need to be removed.

Figure 13. Depicts the Folder Named “extvisual” and the TrickBot Binary (Click to enlarge image)

TrickBot will also commonly drop malicious binaries into the root of C:\ or C:\ProgramData. The query in Figure 14 can be used in RTR’s runscript console to search these locations.

Figure 14. Command Used to Search Other Likely Locations (Click to enlarge image)

The next artifacts to remove are the malicious binaries that were discovered in the initial triage phase of investigation by the first responder analysts. In the prior search, no artifacts were discovered here, so the only directory that needs to be removed is the main folder in \AppData\Roaming. There is a built-in RTR command for directory removal, as shown in Figure 15.

Figure 15. Removal of the Directory Containing Malicious .exe (Click to enlarge image)

The above steps outline the general process for identifying TrickBot artifacts and successfully remediating a host for the TrickBot malware. This process is quite effective in singular instances, but in reality, this is rarely the case due to TrickBot’s lateral movement capabilities. Multiple infections are commonly observed, and what can be done if an organization needs to remediate not one but dozens or hundreds of hosts? An automated script that can run against multiple hosts in sequence must be used.

Conclusion

CrowdStrike has observed multiple instances in which banking malware and follow-on ransomware has had a highly disruptive impact on an organization’s ability to operate. Remediating these types of infections becomes more complicated with these variants’ ability to spread to many hosts. Further, with a transition to a more remote workforce, the capability to remotely remediate infections on hosts that are geographically distributed will become increasingly important as rebuilding systems becomes impractical.

Stay tuned for the next part in this series, where we take this concept of remote remediation a step further and introduce the capability to automate the process and expand its scope to remediate large volumes of hosts at scale. This recovery strategy — which restores hosts without rebuilds — can save critical resources in times of crisis. By utilizing the CrowdStrike Falcon API along with scripting via Python and PowerShell to remotely remediate infected systems, organizations can get back on their feet as quickly as possible.

Recommendations

• Gain advanced visibility across endpoints with an endpoint detection and response (EDR) solution such as the CrowdStrike Falcon platform. Turn on next-gen antivirus (NGAV) preventative measures to stop malware.
• Keep systems up to date: Ensure systems are patched for CVE-2017-0144.
• Disable SMBv1 in the network and require at least SMBv2.
• Segregate the network where possible to limit lateral movement.
• Detect network scanning, and contain unapproved hosts as fast as possible.