A while back, I had a patch of cases where I was regularly looking at samples leveraging DLL Side loading (also called
Search Order Hijacking) as part of their setup phase. This vulnerability exists because of how Windows handles resolving libraries for applications and can be exploited to cause an application to inadvertently load (at the same privilege level) a malicious library. When a library is
loaded by an application (either delayed or at execution), Windows will check the following locations
in order for a copy of the library:
The above shows the locations checked when SafeDllSearchMode is disabled. When enabled, the current directory is checked fifth, instead of second.
This process can be exploited when a malicious library is added to one of these locations - before
the actual library natively resides. For example, if
MyApp.exe is attempting to load
which is located in SYSTEM32 (location #3 above) and an attacker deploys a malicious copy to the current working directory
(#2 above) - the malicious copy will be loaded, instead of the native copy.
Exploitation of this technique in the wild has been commonly used by attackers for mainly:
- Initial access deployment - In observed cases, a vulnerable legitimate and signed executable is bundled with a malicious
library and obfuscated payload inside of a Self-Extracting (SFX) RAR Archive.
- System persistence - Attackers install a malicious library to the same folder as a vulnerable application that is
regularly executed or run as a system service
Some have argued that DLL Side loading is an Antivirus (AV) vulnerability - based on the
assumption / that detection engines only look at the parent process and make a determination
based on that. While that may be the case for some AV products (and of those from 2005), the
vulnerability can be exploited for tactical uses, beyond a detection bypass. In addition to being
usable for persistence, because the side loaded libraries are run at the same privilege level as
the associated process, if loaded by a system services, it would be possible to escalate to
Following are two interesting applications I found that were vulnerable to DLL Side loading that
have finished the notification process and some analytical assessments of each:
While rebuilding a bare-metal sandbox, I ran the Dell Power Management Service Updater (
Dell-Power-Manager-Service_XJ50Y_WIN64_3.0.0_A00.EXE / SHA256 Hash
Siofra as a cursory check.
Following is the output from this check:
From the output, six of the dependencies of this installer were flagged as vulnerable. Using
Process Monitor when the installer was executed (from
C:\Users\User\Desktop\), the highlighted lines show the installer first attempting to open VERSION.dll from the same directory as the installer, before then moving on to SYSTEM32 - showing that the installer was highly-likely vulnerable.
In order to confirm fully this vulnerability, a PoC malicious library was written in Visual Studio with
the same exports as VERSION.dll linked to the original library. The main components of this
are DllMain, which contains a switch statement with a WinExec call to open calc.exe
whenever the library is loaded (shown first), and the links to the original library exports
BOOL APIENTRY DllMain( HMODULE hModule,
#pragma comment(linker, "/export:GetFileVersionInfoA=C:/Windows/System32/version.GetFileVersionInfoA")
The result of this is a beautiful waterfall of calc when the installer is loaded:
What makes this case interesting is that the vulnerable application is installed by default on some new Dell systems. For an attacker, this type of vulnerability could be trivially leveraged for persistence - given the large-installation base.
|2018 May 9||Reported to Dell|
|2018 May 9||Dell acknowledge receipt|
|2018 May 15||Dell re-acknowledge receipt|
|2019 May 20||Dell provides update stating review is in final review and release coming soon|
|2019 June 3||Dell provides update that another researcher has submitted additional information related to original vulnerability|
|2019 September 1||I Requested status update|
|2019 September 4||Dell states the review is in final review and update coming next week|
|2019 September 12||Dell publishes Security Advisory (DSA-2019-065 / CVE-2019-3726)|
While preparing for the 2019 Northeast Collegiate Cyber Defense Competition (NECCDC) I
found that several of the executable files (listed below) for OpenSSH for Windows (version
were also vulnerable to DLL Side loading, using the same method of identification with Siofra,
validation with ProcessMonitor and validation with a PoC.
In each of the vulnerable executable files, the following libraries could be used for exploitation:
Unlike the previous case, this vulnerability is inherently interesting because of the large base of potentially vulnerable systems. However, this vulnerability impacting OpenSSH allows for a number of theoretically possible attacks, that may not applicable to large-scale usage, but may be of high value in a targeted attack scenario.
|2019 March 11||Reported to Microsoft MSRC|
|2019 March 11||Received automated acknowledgement|
|2019 March 20||Received acknowledgement report was being reviewed|
|2019 March 28||Microsoft verified the issue, however determined it does not meet their bar for servicing via a monthly security update.|
As exploitation of these vulnerabilities require either existing system access or social engineering,
they are by no means the most critical out there. However, I feel @n0x00 described it best in a
GitHub thread: “it’s the XSS of thick client work”.