Andy Ful

Level 65
Verified
Trusted
Content Creator
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.

  1. Find a signed EXE file (with 0 VirusTotal detection) vulnerable to DLL hijacking (I used Sysinternals Coreinfo tool).
  2. 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).
  3. Rename the DLL to one of the system DLLs loaded by the EXE (I used version.dll).
  4. Put the vulnerable EXE and the fake DLL into one folder (but not the Windows folder).
  5. 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.
DLLHSmartscreen1.png


The below screenshot shows that the fake version.dll is executed after running the CoreInfo tool..
DLLHSmartscreen2.png
 
Last edited:

Andy Ful

Level 65
Verified
Trusted
Content Creator
You can take a look here Andy:
which speak about how identify DLL hijacking with easy:
I know these articles. The second article is for testing the vulnerable applications. So, you can find out in this way that Coreinfo.exe is vulnerable to DLL Search Order Hijacking. My test procedure starts from the point which is the end of Sentinel checking.
One has to be cautious when using Sentinel. When you use the Sentinel installation it uses Admin privileges to reset SRP and remove Hard_Configurator settings. In the newest beta, I added the checking procedure which can recognize if the H_C was tampered by another application. So, the newest H_C beta will remove Sentinel settings and reinstall SRP. Both H_C and Sentinel are highly incompatible.
 

Andy Ful

Level 65
Verified
Trusted
Content Creator
...and if H_C determines settings were "tampered" with, does it give the user an alert, or does user have to dig into logs?
Alerts are displayed, for example:

TAL.png

The info can be opened in the notepad too, because when the user will press the <Abort> button there is a procedure to follow (not easy to remember). This option is necessary to avoid problems with uninstalling the application which tampered SRP.
 

Andy Ful

Level 65
Verified
Trusted
Content Creator
Here is a creative example of how DLL hijacking can be used to hide the infection chain (the malicious DLL is embedded in the MSI installer so in most cases it will be blocked by SmartScreen, the infection chain uses also VBS scripting):

"During the time we monitored the Metamorfo campaign, we’ve seen 5 different software components, manufactured by respected software vendors, abused in the attack. They come from Avira, AVG and Avast, Damon Tools, Steam and NVIDIA "

"Metamorfo is a known piece of Banker malware that resurfaced at the end of last year and almost exclusively focuses on Brazilian victims. Novelty aside, the exciting aspect of this malware is the way it employs various techniques to evade malware defenses and the tremendous work put into finding executables from various well-known software vendors that are susceptible to DLL side-loading. But why would an actor put so much effort into finding these legitimate vulnerable executables when attackers could launch rundll32.exe or regsvr32.exe to load any DLL? The answer is that, this way, attackers increase their chances of evading user-suspicious detection. Anti-malware solutions generally monitor actions performed by Windows binaries like rundll32.exe or regsvr32.exe as they are the go-to tools for mainstream attackers. Also, executing their malware DLL with the help of these processes would raise a red flag for incident responders and threat hunters. Therefore, by choosing prominent software vendors to mask their actions, attackers can remain undetected. A digital signature and familiar name in Version Info might seem benign to casual users as well. The usage of COM objects for starting up the executables and loading the DLLs also helps actions go under the radar if the AV does not monitor them. Some variants have a second layer of defense evasion consisting of DLL injection into legitimate processes like wmplayer.exe or dllhost.exe, making the injection from a trusted AV component seem plausible, then masking malicious actions behind a seemingly benign Windows process. Metamorfo bypasses detection of AV vendors that whitelist applications based on trusted digital signatures. Bitdefender products employ advanced algorithms to monitor process behavior, and therefore are unaffected by whitelists."

 

fabiobr

Level 10
Verified
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.

  1. Find a signed EXE file (with 0 VirusTotal detection) vulnerable to DLL hijacking (I used Sysinternals Coreinfo tool).
  2. 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).
  3. Rename the DLL to one of the system DLLs loaded by the EXE (I used version.dll).
  4. Put the vulnerable EXE and the fake DLL into one folder (but not the Windows folder).
  5. 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.
View attachment 240792

The below screenshot shows that the fake version.dll is executed after running the CoreInfo tool..
View attachment 240793
So how can it be detected by the most known techniques? Like this last discovered by Bitdefender's researches.
 

Andy Ful

Level 65
Verified
Trusted
Content Creator
So how can it be detected by the most known techniques? Like this last discovered by Bitdefender's researches.
As they say:
"Metamorfo bypasses detection of AV vendors that whitelist applications based on trusted digital signatures. Bitdefender products employ advanced algorithms to monitor process behavior, and therefore are unaffected by whitelists."

Most AVs with ATP uses behavior-based detections as Bitdefender does. This kind of malware will not bypass whitelisting in the home environment, because the DLL hijacking is not used on the first stage of the infection chain (it starts with MSI file). But if it would be successfully executed in the enterprise environment, then DLL hijacking could bypass the whitelisting on other machines if the malware would spread across the local network.
 
Last edited:

fabiobr

Level 10
Verified
As they say:
"Metamorfo bypasses detection of AV vendors that whitelist applications based on trusted digital signatures. Bitdefender products employ advanced algorithms to monitor process behavior, and therefore are unaffected by whitelists."

Most AVs with ATP uses behavior-based detections as Bitdefender does. This kind of malware will not bypass whitelisting in the home environment, because the DLL hijacking is not used on the first stage of the infection chain (it starts with MSI file). But if it would be successfully executed in the enterprise environment, then DLL hijacking could bypass the whitelisting on other machines if the malware would spread across the local network.
So if the enterprise uses ESET...