.png){kind=logo}
Our investigation has revealed an innovative approach that leverages executables commonly found in the trusted WinSxS folder and exploits them via the classic DLL Search Order Hijacking technique. This method allows threat actors to circumvent high privilege requirements to execute malicious code in applications within the Windows folder, specifically WinSxS, and eliminates the need for additional binaries in the attack chain. Furthermore, it facilitates the execution of malicious code from any location, and it is compatible with both Windows 10 and 11.
Throughout the blog, we provide detailed explanations of the technical concepts and techniques required to understand the underlying principles of the proposed attack flow. We will discuss the pros and cons of the classic implementation of DLL Search Order Hijacking, comparing it to our state-of-the-art implementation. Additionally, we outline the capabilities and implications of this technique, shedding light on its effectiveness, potential impact, and opportunities for detection by defenders.
Armed with our own custom tool, we explored each of the binaries residing in the WinSxS folder and identified several executables available in such folder that can be abused to load and execute malicious files. This approach reduces the likelihood of detection by defense software and incident responders, when compared to the classic DLL Search Order Hijacking, as the malicious code is run from within the memory space of a trusted binary located under the Windows folder WinSxS.
This approach allows us to improve and simplify the general infection flow of the classic DLL Search Order Hijacking. While this activity can be detected, it is not a direct vulnerability of the OS; instead, this behavior is possible due to the way Windows natively behaves and the functionalities it offers to both developers and end-users.
The article in nutshell:
[1] Our research team has evolved the classic DLL Search Order Hijacking techniqu by deliberately targeting files located in the WinSxS folder.
[2] Our approach lowers the probability of detection compared to the classic DLL Search Order Hijacking, as the malicious code operates within the memory space of a trusted binary located in the Windows folder WinSxS.
[3] Unlike traditional methods, there is no requirement to introduce your own vulnerable binary, as Windows already includes various files stored in the WinSxS directory that can be leveraged.Security Joes is a multi-layered incident response company strategically located in nine different time-zones worldwide, providing a follow-the-sun methodology to respond to any incident remotely. Security Joes' clients are protected against this threat.
Contact us at response@securityjoes.com for more information about our services and technologies and get additional recommendations to protect yourself against this kind of attack vector.
DLL Search Order Hijacking
DLL Search Order Hijacking is a simple yet highly effective technique in the arsenal of threat actors. This technique exploits the way Windows applications load Dynamic Link Libraries (DLLs) and external executables, taking advantage of applications that do not specify the full path to the file (EXE/DLL) they require. Instead, these applications rely on a predefined search order to locate the necessary DLLs, making them susceptible to manipulation by threat actors.
According to MITRE ATT&CK, there are various methods that adversaries can employ to hijack the DLL loading process. However, all these methods share a common requirement: the targeted application should not specify the full path to the required content. This situation often arises due to oversights in software development. Subsequently, threat actors place a malicious DLL in a directory that is prioritized in the search order ahead of the legitimate DLL directory. Frequently, the preferred location for this manipulation is the working directory of the target application, as it holds a prominent position in the search order.
Understanding how Windows loads DLLs and executables is crucial for grasping this technique. When an application initiates the loading process, it adheres to a specific sequence, which dictates the steps taken by the system to locate and utilize the necessary components, such as DLLs and executables. This process ensures the efficient operation of applications, allowing them to access shared resources and functionalities seamlessly. It also provides an alternative method to recursively locate resources that may be needed but were not included by the developer in the installation package of an application.
The general flow followed by the Windows operating system when searching and loading external resources is as follows:
The directory from which the application is launched.
The folder "C:\Windows\System32".
The folder "C:\Windows\System".
The folder "C:\Windows".
The current working directory.
Directories listed in the system's PATH environment variable.
Directories listed in the user's PATH environment variable.
Manipulating this loading process allows threat actors to inject and execute unauthorized code within the memory space of a trusted process, effectively deceiving security tools and analysts.
As mentioned earlier, this technique is not new in the cybersecurity landscape and is widely used by threat actors regardless of their objectives, country of origin, or the types of tools employed. For reference, we have summarized some of the threat actors known to have used this technique in their intrusions, according to MITRE:
Group | Exploitation Method |
APT41 | APT41 has used search order hijacking to execute malicious payloads, such as Winnti RAT. |
Aquatic Panda | Aquatic Panda has used DLL search-order hijacking to load exe, dll, and dat files into memory. |
BackdoorDiplomacy | BackdoorDiplomacy has executed DLL search order hijacking. |
Evilnum | Evilnum has used the malware variant, TerraTV, to load a malicious DLL placed in the TeamViewer directory, instead of the original Windows DLL located in a system folder. |
menuPass | menuPass has used DLL search order hijacking. |
RTM | RTM has used search order hijacking to force TeamViewer to load a malicious DLL. |
Threat Group-3390 | Threat Group-3390 has performed DLL search order hijacking to execute their payload. |
Tonto Team | Tonto Team abuses a legitimate and signed Microsoft executable to launch a malicious DLL. |
Whitefly | Whitefly has used search order hijacking to run the loader Vcrodat. |
The motivations driving threat actors to employ DLL Search Order Hijacking are rooted in its subtlety and effectiveness. By manipulating trusted applications, threat actors can achieve unauthorized access, execute arbitrary code, and conceal their activities within seemingly legitimate processes. This technique just provides them with a stealthy means of compromising systems, evading detection, and achieving their malicious objectives.
What about WinSxS?
The WinSxS (Windows Side by Side) folder is a critical component in the maintenance and recovery of the Windows operating system, typically located at C:\Windows\WinSxS. Its primary function is to store various versions of important system files side by side. When Windows undergoes updates, it retains the previous versions of components within the WinSxS folder. As a result, the size of the WinSxS folder tends to increase with each Windows update.
The key purposes of the WinSxS folder include:
Version Management: It stores multiple versions of Dynamic Link Libraries (DLLs) and system files, ensuring efficient access as needed. This capability is crucial for maintaining compatibility with various applications, as different programs may require specific versions of the same component.
System Integrity: The WinSxS folder helps maintain the integrity of the system by preventing incorrect or corrupted versions of system files from replacing the correct ones. This safeguard ensures the stability and reliability of the operating system.
Dynamic Activation: The folder facilitates the dynamic activation or deactivation of Windows features, eliminating the need for separate installations. This flexibility allows users to enable or disable specific features as required.
In practical terms, during the installation of Windows components, updates, or software applications, files are systematically stored in the WinSxS directory. This directory acts as a centralized repository for system files, particularly DLLs, which are shared among various applications and components to ensure compatibility and prevent potential conflicts.
In server operating systems such as Windows Server, the WinSxS folder serves additional roles that enhance server capabilities. It holds critical files necessary for system restoration, aiding in recovery processes. Moreover, it functions as a protective mechanism, enabling users to revert from problematic system updates to a stable state when necessary, contributing to system resilience and reliability.
While exploits relying on the WinSxS folder are not entirely new and have been previously used to bypass User Account Control (UAC), this is the first instance in which the potential of this Windows functionality in red teaming operations or real attack scenarios has been extensively documented in conjunction with the classic DLL Search Order Hijacking technique.
Our Research: WinSxS Binaries Dependencies Hijacking
Our research team has advanced the classic DLL Search Order Hijacking technique by focusing on applications located in the Windows WinSxS folder. What distinguishes this approach from previously known implementations is the deliberate targeting of files residing in the WinSxS folder.
The key advantages of this approach include:
Circumventing High Privilege Requirements: By targeting applications in the WinSxS folder, our implementation eliminates the need for elevated privileges to execute malicious code within applications located in a Windows folder.
Eliminating the Need for Additional Binaries: Leveraging the WinSxS folder eliminates the requirement to introduce additional, potentially detectable binaries into the attack chain. Since Windows already indexes these files in the WinSxS folder, there's no need to bring our own vulnerable application.
Enhancing Stealth: Executing malicious code within the memory space of an application running from the WinSxS folder enhances stealth and minimizes the risk of detection. Security tools and analysts may be less likely to flag this approach as it leverages trusted components already present in the Windows environment.
By optimizing the classic DLL Search Order Hijacking technique in this manner, our research has uncovered a more effective and evasive method for compromising systems and executing unauthorized code within trusted applications. This discovery emphasizes the significance of comprehending the complexities of Windows components and their interactions for both defenders and security practitioners.
In the early phases of our investigation, our primary objective was to identify potential vulnerabilities within the binaries residing in the WinSxS folder. To achieve this, we utilized a combination of two key tools: Process Monitor and a custom development that we specifically developed for this investigative purpose. Our goal was to gain insight into the system's behavior when executing binaries located within the WinSxS folder and identify vulnerable files residing in this trusted Windows folder.
Once we identified a vulnerable binary, our attention shifted to comprehending the precise loading order that Windows adheres to when it searches for system files, including DLLs. As it was mentioned previously, sequence entails evaluating various locations, including the directory where the application was launched, several Windows folders, directories specified in the system's PATH environment variable, and notably, the current working directory.
Armed with this information, we concluded the exploitation process by strategically placing a custom DLL into our designated directory, closely mimicking the name of the legitimate DLL expected by the targeted binary. When the vulnerable binary is executed, it attempts to load the required DLLs. Windows systematically conducts this search based on the established loading order, with a crucial check of the current working directory early in the process. At this point, our custom DLL is discovered and loaded instead of the legitimate counterpart.
Proof of Concept (PoC)
We started creating filters within the Process Monitor to sift through outcomes featuring the values "PATH NOT FOUND", "CreateFile", and "NAME NOT FOUND". Additionally, we focused on the results containing the designated path "NOT_A_SYSTEM_FOLDER_MS”, which is a folder created on the desktop containing the files which will be used in research purposes.
Within our created folder, we have placed a custom DLL that will be injected into memory using the DLL Search Order Hijacking technique. In addition to the custom DLL, we have also developed an executable with the sole purpose of executing all other binaries located in the WinSxS folder and monitoring their operations. This executable is designed to identify vulnerable files residing in the WinSxS folder.
After the execution of our custom tool, we identified binaries such as "ngentask.exe" and "aspnet_wp.exe" that attempted to search for their respective DLLs within our current directory, labeled as "NOT_A_SYSTEM_FOLDER_MS". This observation indicated the potential for loading our custom DLL simply by renaming it to match the expected DLL file sought by these executables. Our research then focused on the "ngentask.exe" binary for further analysis.
In essence, we can trigger the vulnerability by simply launching a command line from a shell that uses our folder "NOT_A_SYSTEM_FOLDER_MS" as the current directory, without the need to copy or move the vulnerable file outside of WinSxS. This action will lead the targeted binary to execute our DLL since it will only locate it inside our directory. This highlights the power of our implementation, which only requires a command line and a DLL to be injected. There is no need to bring your own vulnerable application, as is often the case in attacks involving DLL Search Order Hijacking, such as the case of PlugX, reported in the past by TrendMicro, which abused a binary related to the open-source debugger x32dbg to load malicious code.
We successfully injected our custom DLL by renaming it to "mscorsvc.dll" and executing the previously mentioned command line from our current directory, specifically targeting the "ngentask.exe" process. By using the Process Explorer, we were able to verify the successful importation of our DLL into the "ngentask.exe" located in the WinSxS folder.
It's important to acknowledge that additional vulnerable binaries may be present in the WinSxS folder as the system undergoes new updates. Below we add a table summarizing the vulnerable executables located in the WinSxS folder during our research and the corresponding resources which are searched during its execution. It's important to clarify that the identification of these files doesn't automatically imply their vulnerability but rather serves as a strong indication, additional tests must be done in each of the binaries to confirm its vulnerability:
Process Name | Loaded Resource |
Conhost.exe | ClipUp.exe |
Conhost.exe | ipconfig.exe |
Conhost.exe | route.exe |
Conhost.exe | mcbuilder.exe |
Forfiles.exe | cmd.exe |
Iediagcmd.exe | ipconfig.exe |
Stordiag.exe | SystemInfo.exe |
Aspnet_wp.exe | webengine.dll |
Aspnet_wp.exe | webengine4.dll |
Aspnet_regiis.exe | webengine4.dll |
Aspnet_state.exe | webengine4.dll |
Csc.exe | VCRUNTIME140_1_CLR0400.dll |
Cvtres.exe | VCRUNTIME140_1_CLR0400.dll |
Ilasm.exe | fusion.dll |
Ilasm.exe | VCRUNTIME140_1_CLR0400.dll |
Ngentask.exe | mscorsvc.dll |
Ngen.exe | VCRUNTIME140_1_CLR0400.dll |
NisSrv.exe | mpclient.dll |
Proof-of-Concept Video
Detection Opportunities
We offer the following strategies to the community for effectively addressing this exploitation method within your environments. We encourage you to test and customize these approaches as necessary.
Parent Process Analysis:
Examine parent-child relationships between processes, with a specific focus on trusted binaries. Look for activity involving:
Unusual processes that invoke binaries from the WinSxS folder .
Legitimate binaries in the WinSxS folder spawning unexpected child processes.
Behavior Analysis:
Monitor closely all the activities performed by the binaries residing in the WinSxS folder. Focusing on both network communications and file operations. You can look for activity such as:
WinSxS binaries connecting to remote servers.
WinSxS binaries loading modules from uncommon folders.