Tech Blog

Tanium Incident Response updates: WMI, scheduled tasks and enhanced file search

On Friday, October 30, Tanium released an updated version of our Incident Response module. I’m excited about several of the new capabilities introduced by this point update, including the ability to hunt for malicious WMI event consumers, conduct at-scale analysis of scheduled tasks and search for files at rest within seconds. In this post, I’ll explain the technical basis and use-cases underlying each of these features.

Detecting Malware that Persists via WMI {#88c3.graf–h4.graf-after–p}

Windows Management Instrumentation (WMI) is a core system management technology present in all versions of Windows since XP and Server 2000. Among its numerous features, WMI includes a powerful event handling framework that can monitor for low-level system events and automatically initiate actions when they occur. These actions are implemented in the form of “event consumers” that launch an arbitrary command line or a Windows Scripting Host script (VBScript or JScript) when triggered. While the complexities of WMI eventing have allowed it to remain relatively obscure, recent research[1] has highlighted how attackers can abuse it as a covert storage and persistence mechanism for malware.

Fortunately, identifying malicious WMI event consumers is a great use-case for Tanium’s real-time search and stacking capabilities. A typical Windows environment has only a handful of default event consumers, and 3rd party applications rarely install additional consumers. So we built a solution to help our customers both instantly search their endpoints for rogue event consumers, and proactively monitor for the introduction of new, malicious entries.

Our new incident response sensor, “WMI Event Consumers”, examines all event consumers on a system and returns three key fields: consumer name, class (defining the type), and command line template (populated with either the command line for an CommandLineEventConsumer, or the script to be executed for an ActiveScriptEventConsumer). By default, this is a “counting” sensor — meaning that Tanium counts each unique combination of these fields across all queried systems. This allows you to easily spot the outliers with a low frequency of occurrence.

The screen capture below shows an example of the WMI sensor output across a small lab deployment of ~75 Windows systems. We set up a very obvious malicious Command Line Event Consumer, but note how the Count column, paired with the other fields, makes it easy to spot.

Analyzing Scheduled Tasks {#abce.graf–h4.graf-after–figure}

In contrast to WMI, Scheduled Tasks is a widely-known Windows feature that has been long-abused by attackers. Recurring scheduled tasks can serve as a persistence mechanism for malware, and remote tasks are an easy way to run a command or application during lateral movement. While Tanium previously included sensors that allowed users to search for specific tasks, we wanted to add the capability to quickly stack and analyze all existing task “job” files across every system in an environment. Incident responders often need to search for tasks that execute certain patterns of commands, follow certain naming conventions, or are otherwise outliers amidst the tasks that are legitimately installed by the operating system or 3rd party applications.

Our new “Scheduled Tasks” sensor supports this exact use-case. It enumerates all tasks from each system, regardless of whether they were created via the “at” command or “schtasks”. For each identified task, it outputs the job name and full command line for whatever it executes. Apart from basic searching, this makes it easy to separate tasks with a high-frequency of occurrence from those that are less common, and evaluate the command line executed for potentially anomalous entries.

The screen capture below shows an example of the output of this sensor. Nothing exciting going on in this particular demo environment, but we can see that a single system had a task to run the Dropbox setup installer, and a number of additional systems all have the Google Chrome updater components.

Enhanced Searching for Files at Rest {#3a10.graf–h4.graf-after–figure}

Incident responders are often faced with the need to search for files that may reside anywhere on disk — and across all systems — using basic criteria, such as a partial or complete name, path, or hash. Many products address this use-case by iterating through the entire contents of a drive, parsing files and calculating hashes every time a search needs to be performed. This tends to be both slow and resource intensive.

At Tanium, we wanted to solve this problem while adhering to our core tenets of speed and scale. Our solution is simply called “Tanium Index”, and is included as a part of our Incident Response and IOC Detect modules. When installed, Index uses a lightweight mechanism to build an initial catalog of every file on disk, along with accompanying metadata. It then uses low-level monitoring to efficiently update the index as new files are created, modified, renamed, or deleted. On average, the index only consumes a few dozen megabytes of disk space.

What’s the benefit to an investigator? It means that you can use Tanium to search all endpoints for any combination of the following criteria, and get answers in seconds:

• File name, extension, and path

• File hash (MD5, SHA-1, or SHA-256)

• File “magic number” (first four bytes)

• Created and Modified timestamps

As an example, the screen shot below shows the result of a simple Index search across an environment for a malicious MD5 hash. (File Creation timestamp has been omitted from display for space).

We’ll be building lots of additional Tanium capabilities that leverage Index for incident response, IOC searching, and other use-cases — so stay tuned!

Building atop the Tanium Platform {#e109.graf–h4.graf-after–p}

These new additions to our incident response capabilities, like any other Tanium capability, can be used to search, detect, and act upon environments of any size — from a single Tanium server. These searches take seconds to complete, regardless if you’re working with 1,000 or 400,000 systems. Users can drill down or construct merged questions to instantly collect more data from systems producing interesting results. Sensor questions can also be automated to run on a recurring basis and display aggregate results over time on a Tanium dashboard. Finally, the output of any saved question can easily be piped out to a SIEM or ticketing system via Tanium Connect, leveraging our “learning” capability to only surface new results or changes if desired.

We’re committed to continuing to expand Tanium’s ability to detect, investigate, and remediate against the latest attack techniques and threats. Keep an eye on this space for future updates and releases.

[1] https://www.blackhat.com/docs/us-14/materials/us-14-Kazanciyan-Investigating-Powershell-Attacks-WP.pdf

https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf

Like what you see? Click here and sign up to receive the latest Tanium news and learn about our upcoming events.

Featured Webinars

Upcoming Events

Contact Sales


Press Inquiries


Thank you for contacting us


Back to the Tanium Home Page