Don’t Get Hijacked! Searching for DLL Load Order Attacks With Tanium

Explaining DLL hijacking

DLL Hijacking, commonly referred to as load order or search order hijacking, is a well-documented malware persistence technique that continues to elude detection and pose a significant challenge for investigators. For anyone unfamiliar with this technique, have no fear! In this post we will discuss a brief background of load order hijacking and introduce a new Tanium capability for at-scale detection.

Windows does not require that applications specify a full path for dynamic-link libraries (DLLs) loaded at run time. When a full path is not provided, Windows attempts to locate the DLL by searching pre-determined locations in a predictable order. Therefore, it’s possible for an attacker to supplant this order by adding a malicious DLL, with the same name as the legitimate version, in a location ahead of the legitimate library; causing the operating system to inadvertently load the malicious DLL. If an application loads a DLL (e.g. ntshrui.dll) by just name, Windows follows a publicly defined order to identify and load the first library found with the name “ntshrui.dll”.

Assuming “Safe DLL search mode” is enabled (which it is by default) the operating system will first check if a DLL with the same name is already loaded in memory or If the DLL is defined in the “KnownDLLs” registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs). If neither of these conditions are met, Windows will load libraries using the following order:

1. The directory from which where the application was launched
2. The system directory (C:\Windows\System32)
3. The 16-bit system directory (C:\Windows\System)
4. The Windows directory
5. The current directory
6. Directories defined in the PATH variables

The load order is further detailed by Microsoft here:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

KnownDLLs Library

On any given Windows system the attack surface, represented by the number of potentially hijackable locations, is much higher than one might suspect. As a general rule, applications executed outside of “C:\Windows\System32” that load a library without providing the full path are potential targets. Note: The library in question must also not already exist in memory or be located in the KnownDLLs registry value. Even core system binaries, notably explorer.exe, have been shown to be vulnerable (https://capec.mitre.org/data/definitions/471.html).

A properly-designed malicious library can serve as a “pass through” for the legitimate library, preserving the stability of the vulnerable application that loads it. Simply enumerating running applications or common persistence locations are not effective means for detecting the attack. In total, the breadth of potentially exploited applications and loaded DLLs has vexed many investigators attempting to detect this technique.

Tanium’s Incident Response Module (version 2.3.1)

Tanium’s latest release of the Incident Response Module (version 2.3.1) includes a new sensor titled “DLL Load Order Hijacking Search”. This feature was designed to help organizations detect DLL Load Order hijacking at scale. The sensor functions by examining DLLs loaded by running processes and applies several heuristics and filtering steps to identify situations where hijacking may have occurred. When a potentially hijacked process is identified, the sensor returns information about the process and DLL to assist an analyst in determining the legitimacy of the hit. Specifically, the sensor returns the following information:

• Process Name & Path
• DLL Path
• DLL MD5 hash
• If the DLL is digitally signed
• Reason DLL is suspected of being malicious

Tanium completes this entire process, from search to producing results, in seconds, regardless of the scale of the environment.

The screen capture below shows an example of the DLL Load Order Hijacking sensor output across a small lab deployment. We created a staged detection where “Explorer.exe” loaded “ntshrui.dll” from the “C:\WINDOWS” directory, rather than “C:\WINDOWS\system32” on a single “infected” system.

In large enterprise environments, this sensor may produce some number of false positive results. Applications often load copies of legitimate libraries within the same directory via the expected DLL search order, in order to ensure that they may run consistently across different installations and versions of Windows. Tanium automatically provides frequency of occurrence data for each result in real-time, allowing analysts to easily dismiss common results in conjunction with the hash and digital signature data provided by the sensor. The screen shot below provides an example of a false positive that could have been excluded by filtering on the digital signature or frequency count data.

To help further reduce false positives, the sensor also allows users to define a whitelist of known good libraries. In fact, additional Tanium sensors can easily query all loaded or on-disk DLLs and their respective hashes across groups of known-clean systems to help users build and maintain whitelists that are custom-tailored to their environment.

The DLL Load Order Hijacking sensor is one example of our Endpoint Detection and Response team’s efforts to simplify incident investigations and help organizations proactively hunt for the “unknowns” in an environment.

In the coming months, we’ll be blogging about additional new capabilities and case studies on a regular basis.

Stay tuned!

Interested in seeing Tanium in action? Schedule a one-to-one demo or attend our weekly webinar. Talk to our Tanium experts at our upcoming events.