Advice Request Testing DLL Search Order Hijacking against security features.

[Andy Ful]

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.

DLL Search Order Hijacking, Technique T1038 - Enterprise | MITRE ATT&CK®

attack.mitre.org

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.

The below screenshot shows that the fake version.dll is executed after running the CoreInfo tool..

 

[ForgottenSeer 85179]

You can take a look here Andy:

AdwCleaner 8.0.1 closes a DLL Hijacking vulnerability

[German]On December 17/18 2019 the tool AdwCleaner 8.0.1 was released by Malwarebytes. This update fixes a DLL hijacking vulnerability I reported to the developers. If Windows shows unwanted programs…

borncity.com

which speak about how identify DLL hijacking with easy:

Vulnerability and Exploit Detector

skanthak.homepage.t-online.de

 

[Andy Ful]

You can take a look here Andy:

AdwCleaner 8.0.1 closes a DLL Hijacking vulnerability

[German]On December 17/18 2019 the tool AdwCleaner 8.0.1 was released by Malwarebytes. This update fixes a DLL hijacking vulnerability I reported to the developers. If Windows shows unwanted programs…

borncity.com

which speak about how identify DLL hijacking with easy:

Vulnerability and Exploit Detector

skanthak.homepage.t-online.de

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.

 

[Gandalf_The_Grey]

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.

Cool that you added a checking procedure
That's in version 5.1.1.1?

 

[Andy Ful]

Cool that you added a checking procedure
That's in version 5.1.1.1?

Yes.

 

[simmerskool]

Yes.

...and if H_C determines settings were "tampered" with, does it give the user an alert, or does user have to dig into logs?

 

[Andy Ful]

...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:

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]

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."

https://www.bitdefender.com/files/News/CaseStudies/study/333/Bitdefender-PR-Whitepaper-Metamorfo-creat4500-en-EN-GenericUse.pdf

 

[fabiobr]

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.

DLL Search Order Hijacking, Technique T1038 - Enterprise | MITRE ATT&CK®

attack.mitre.org

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]

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.

 

[fabiobr]

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...

 

[Andy Ful]

This year, Microsoft decided to block by default the macros in MS Office documents downloaded from the Internet. Although this mitigation can be overcome by the attackers, it also caused an increase in other attack vectors like using archives with shortcuts combined with DLL hijacking. One of the examples is the recently discovered campaign of BRONZE PRESIDENT:
https://www.secureworks.com/blog/bronze-president-targets-government-officials

The infection chain:
Phishing email ----> RAR archive downloaded and unpacked by the user ---> LNK file (masqueraded as PDF or DOCX) + hidden folder with payloads ---> user opens LNK file ---> DLL hijacking is started

This attack method creates a legal process without child processes, so it can fool any protection based on monitoring EXE files and their child processes (some AVs use HIPS rules based on parent-child restrictions). Also, the protections based on the EXE file reputation lookup and many cloud sandboxes can be bypassed in this way.

The user can see only something that looks like a document.

The RAR archive is required to fool the mail-scanning protection by using several subfolders with special characters.
The shortcut file (NV 309-2022 HMA's departure.pdf.lnk) starts the DLL hijacking attack. The legal EXE (Opera.exe renamed to test.chm), malicious DLL, and another encrypted payload are located in the hidden folder with several subfolders:

Nowadays, this kind of attack via DLL hijacking can be easily used in widespread attacks on the home users.

 

[Andy Ful]

Another example of DLL hijacking in the wild:
https://blogs.blackberry.com/en/202...gitimate-apps-to-target-myanmar-based-victims
https://malwaretips.com/threads/mus...-apps-to-target-myanmar-based-victims.117675/

Figure 1 – Partial map of countries previously targeted by Mustang Panda


The infection chain:

This attack vector is usually related to phishing. The victim must be first convinced by the attacker to download and open the RAR archive. Using something like VirusTotal is not useful, because the EXE file is legit and signed. Furthermore, the DLL loader is not harmful without the DAT file, and the DAT file is encrypted.
In many cases, such files are properly detected on VirusTotal several days after the malware is already dead.

 

[Andy Ful]

Babuk Ransomware

https://blog.morphisec.com/babuk-ransomware-variant-major-attack
https://malwaretips.com/threads/new-babuk-ransomware-found-in-major-attack.119159/post-1014058

The attackers had network access for two weeks of full reconnaissance prior to launching their attack.
They have compromised the company’s domain controller and used it to distribute ransomware to all devices within the organization through GPO.

In the wild, the company domain controller was finally attacked by delivering two files BAT and MSI. Execution of the BAT file started the infection chain.
The same infection vector can be used in widespread attacks by using archives, ISO images, etc., which can be containers for BAT and MSI files. For example:

ISO (with embedded MSI and (or ) BAT) ------->
MSI execution ----->
files dropped to the disk: Legit EXE + "malicious" DLL + encrypted shellcode + encrypted payloads ----->
DLL hijacking ------>
shellcode + payload decrypted and executed in the memory of the legit EXE (no child processes).

The DLL used in the attacks is often not-truly-malicious - it cannot do any harm without encrypted shellcode or encrypted payloads.
MSI files can run scripts, so the essential code of the initial BAT file can be embedded in the MSI. Such a method has been used in the wild (Batloader, Zloader, etc.):

https://blogs.vmware.com/security/2022/11/batloader-the-evasive-downloader-malware.html

Post edited.

 

[upnorth]

Babuk Ransomware

https://blog.morphisec.com/babuk-ransomware-variant-major-attack
https://malwaretips.com/threads/new-babuk-ransomware-found-in-major-attack.119159/post-1014058

In the wild, the company domain controller was attacked by delivering two files BAT and MSI. Execution of the BAT file started the infection chain.
The same infection vector can be used in widespread attacks by using archives, ISO images, etc., which can be containers for BAT and MSI files.

Are you 100% sure?

Why I ask is because that's not how I interpreters the report. The exact attack on the DC ( domain controller ) itself seem left out.

The attackers had network access for two weeks of full reconnaissance prior to launching their attack. They have compromised the company’s domain controller and used it to distribute ransomware to all devices within the organization through GPO. At this time, we won't publish details about the full attack chain due to an ongoing investigation. Instead, we will dive into the ransomware itself.

 

[ForgottenSeer 97327]

Forgive my naive post in this thread. I thought that enabling safe search mode would stop DLL hijacking?

Spoiler: Registry key

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"SafeDllSearchMode"=dword:00000001

___________________
EDIT 1
According to Microsoft it is enabled by default now

Spoiler: SafeSearchDLL order

Safe DLL search mode is enabled by default.

If SafeDllSearchMode is enabled, the search order is as follows:

1. The directory from which the application loaded.
2. The system directory. Use the GetSystemDirectory function to get the path of this directory.
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
4. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

--------------------------
EDIT 2

I am understanding it now, by starting an application in a User folder, the replacement DLL hijacks the DLL loading because it is in the "The directory from which the application loaded."

Luckily my WDAC policy only allows Microsoft signed (and Syncback) DLL's to execute in user space.

 

[Andy Ful]

Are you 100% sure?

Why I ask is because that's not how I interpreters the report. The exact attack on the DC ( domain controller ) itself seem left out.

Your interpretation is correct and it is also compatible with my post.
The complete cyber attack against the company can last several days, weeks, or months. The last phase is usually the ransomware attack in the already compromised environment. My previous post focused on how this last phase can be used in widespread attacks. I intentionally skipped the details related to initial access and lateral movement (they can be found in the articles).
Anyway, to avoid misunderstanding I have slightly corrected my post by adding a citation from the article.

 

[Bot]

Thank you for sharing your insights on DLL Search Order Hijacking and testing security solutions against it. It is important to consider all possible vectors of attack, including less common ones like DLL hijacking, in order to better protect against malware. Your testing procedure and screenshots provide useful examples for others to follow and analyze their own security solutions. Keep up the good work!

 

[Andy Ful]

DETECTING DLL SIDELOADING TECHNIQUES FOUND IN RECENT REAL-WORLD MALWARE ATTACK CHAINS

Securonix Threat Research Knowledge Sharing Series: Detecting DLL Sideloading Techniques Found In Recent Real-world Malware Attack Chains

The Securonix Threat Research team takes a deep dive into this article in our knowledge sharing series on detecting DLL sideloading techniques found In recent real-world malware attack chains

www.securonix.com

 

[simmerskool]

DETECTING DLL SIDELOADING TECHNIQUES FOUND IN RECENT REAL-WORLD MALWARE ATTACK CHAINS

Securonix Threat Research Knowledge Sharing Series: Detecting DLL Sideloading Techniques Found In Recent Real-world Malware Attack Chains

The Securonix Threat Research team takes a deep dive into this article in our knowledge sharing series on detecting DLL sideloading techniques found In recent real-world malware attack chains

www.securonix.com

interesting curious & FWIW when I selected the above-referenced post to read, I got an alert from checkpoint harmony blocking a different website...
hxxp://skanthak.hier-im-netz.de

not saying the block is /was directly related to the that post, only that it was contemporaneous, and I was not doing anything else on the computer...