Andy Ful
From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
- Dec 23, 2014
- 8,550
The DLL Search Order Hijacking is a well known (but not common) vector of attack. It is often performed via a vulnerable Microsoft EXE file or EXE signed by the well known reputable vendor. A popular way of exploiting this vulnerability is based on loading by the vulnerable EXE, one of the system DLLs from a non-system folder which contains the vulnerable EXE. In this post I use a fake version.dll which normally should be loaded from "%WinDir%\system32", but in fact the fake version.dll is loaded from another location.
For many reasons this vector of attack is inefficient for infecting home users (so no worry), but it was used sometimes in the wild to infect enterprises.
The attackers know how to use DLL hijacking for years, so I can freely write something about it (nothing new). This method can be used to skirt around some security features focused on detecting/blocking 0-day malware. Many such features can detect/block only the EXE files and do not detect/block loading malicious DLLs by the EXEs. This method cannot be detected by monitoring the child processes. Such a security feature can see only the safe executable which is digitally signed by a very reputable vendor. The file is allowed to execute or the user can see the misguiding information that the file is safe to run. In this way, the DLL Search Order Hijacking can be used as a poor imitation of malware with the stolen high reputable certificate (without stealing any).
I tested several security solutions (AVs, Anti-EXE, and SRP). Some of them could not prevent such 0-day attacks, especially when a kind of reputation service was used only for EXE files. For example, the Hard_Configurator forced SmartScreen feature, could not prevent it up to the ver. 5.0.0.0. I fixed this in the beta version, because it was an easy fix (even if not necessary). I can note, that after informing the InnoSetup vendor about this vulnerability, it was fixed a week ago (InnoSetup installations are used in businesses).
How to test if the security feature can be bypassed? In my tests I used a very simple procedure, which can probably have to be slightly modified for other security solutions.
Here are the screenshots for testing SmartScreen (I added MOTW to the Coreinfo.exe, version.dll, and version.exe). Please note: However the DLL Search Order Hijacking allows the malware passing by SmartScreen, you probably never see it in the home environment, because there are much simpler methods of doing it.
The below alert is from SmartScreen to be sure that a fake version.dll (renamed to version.exe) is not recognized by SmartScreen.
The below screenshot shows that the fake version.dll is executed after running the CoreInfo tool..
For many reasons this vector of attack is inefficient for infecting home users (so no worry), but it was used sometimes in the wild to infect enterprises.
The attackers know how to use DLL hijacking for years, so I can freely write something about it (nothing new). This method can be used to skirt around some security features focused on detecting/blocking 0-day malware. Many such features can detect/block only the EXE files and do not detect/block loading malicious DLLs by the EXEs. This method cannot be detected by monitoring the child processes. Such a security feature can see only the safe executable which is digitally signed by a very reputable vendor. The file is allowed to execute or the user can see the misguiding information that the file is safe to run. In this way, the DLL Search Order Hijacking can be used as a poor imitation of malware with the stolen high reputable certificate (without stealing any).
I tested several security solutions (AVs, Anti-EXE, and SRP). Some of them could not prevent such 0-day attacks, especially when a kind of reputation service was used only for EXE files. For example, the Hard_Configurator forced SmartScreen feature, could not prevent it up to the ver. 5.0.0.0. I fixed this in the beta version, because it was an easy fix (even if not necessary). I can note, that after informing the InnoSetup vendor about this vulnerability, it was fixed a week ago (InnoSetup installations are used in businesses).
How to test if the security feature can be bypassed? In my tests I used a very simple procedure, which can probably have to be slightly modified for other security solutions.
- Find a signed EXE file (with 0 VirusTotal detection) vulnerable to DLL hijacking (I used Sysinternals Coreinfo tool).
- Find a non-malicious DLL which is detected by Virus Total and(or) when renamed with .exe extension it is detected by reputation service or AI checking. I used a well known AllTheThings.dll (Casey Smith).
- Rename the DLL to one of the system DLLs loaded by the EXE (I used version.dll).
- Put the vulnerable EXE and the fake DLL into one folder (but not the Windows folder).
- Run the EXE and watch if the fake DLL was loaded and executed. In my test I watched for an error message box, when the EXE tried to use the GetFileVersionInfoSizeW function from version.dll, but my fake version.dll did not have such function.
Here are the screenshots for testing SmartScreen (I added MOTW to the Coreinfo.exe, version.dll, and version.exe). Please note: However the DLL Search Order Hijacking allows the malware passing by SmartScreen, you probably never see it in the home environment, because there are much simpler methods of doing it.
The below alert is from SmartScreen to be sure that a fake version.dll (renamed to version.exe) is not recognized by SmartScreen.
The below screenshot shows that the fake version.dll is executed after running the CoreInfo tool..
Last edited: