Could anti-exe programs prevent applications from executing unknown dlls?

As far as I know, dlls also contain executable codes. So I am curious about whether anti-exe programs could prevent applications from executing the codes in unknown dlls.
It seems that nearly all anti-exe programs would monitor rundll32.exe, which means that they could stop rundll32.exe from loading unknown dlls.
But what would happen if an application rather than rundll32.exe (like the browser) is hijacked (if possible) to execute unknown dlls? Could anti-exe programs prevent this?

To see this, I write a very simple dll in C# which only could return a string, and a simple exe (in C# as well) to execute the dll and display the string on command-line console.
Here I test AppGuard (trial), Bouncer (demo), Exe Radar Pro (beta), SecureAPlus (prenium).
In particular:

• AppGuard is set in the Lock Down mode; I add the exe file into system space, while leave the dll file in the user space;
• Bouncer is set in the Lethal mode; I add the exe file into whitelist, while add the dll file into the blacklist;
• Exe Radar Pro is set in the Lock Down mode; I add the exe file into whitelist;
• SecureAPlus is set in the Lock Down mode; I set the trust level of the exe file to "Trusted Application", while the dll file is set to "Not Trusted";

In any of these tests listed above, the exe file could display the string correctly.
Does this mean that anti-exe programs cannot prevent applications from executing unknown dlls?

 

you should do another test with faronics anti-executtable. It has DLL protection built into it. If enabled it costs a bit more performance, however I'm curious about your results

 

i do not recommend such control. if only few libs were loaded, but modern programs use more libs, in most cases standard libs (qt, dotnet aso). to avoid injections tools like MBAE are first choice. HTH

PS i remember "Malware Defender" HIPS, any external action with a lib call has its own function. but it was to complicated to determine all by mind so MD has a learning mode for trusted apps. thats the intention about - trusted apps are ok, if you dont trust, forget it, uninstall. any other behavior i would call port of "paranoia".

 

When I'm using SRP I have control over dll loading enabled also. Sometimes SRP blocks non-whitelisted dlls but I don't know which function it is covering.

Malware Defender mentioned before had dll loading allowed by default, probably to prevent many popups and large rules database.

 

@Arcanez
Hi. Thank you for your suggestion. I might test it later.

@Brummelchen
Hi. I do not want to take a fine granular control over all dlls, since in fact I am not paranoia. I only hope to know whether it is possible to prevent exe files inside the system space from loading un-whitelisted dlls in the user space. I guess such a limitation would not interrupt the applications seriously (I should say I am not sure about that).

@Minimalist
Hi. Just now I have tested SRP (Software Restriction Policy). Particularly,

• In the dialog "Enforcement", I change the option "Applying software restriction policies to the following" from "All software files except lib files (such as DLLs)"(Default) to "All software files"
• In the dialog "Designated File Types", I add "DLL" into the list.
• The exe files is set to "Unrestricted", while the dll file is set to "Disallowed".

Result: The exe file still can display the string correctly.
I guess this means SRP might unable to prevent dll loading as well.

 

Can you show the screen shots of it being bypassed? Might try smart object blocker.

 

Yes, i believe Smart Object Blocker should be able to block it.

 

@Online_Sword I am also curious about the type of testing that you are doing. This is very interesting.

Just to confirm, the executable itself when run (without the DLL) does not contain or display the test string? So the test string is only contained within the DLL? And it is that specific executable that is calling that specific DLL (and not some other built-in Windows executable)?

Would you be willing to share this test executable and DLL? I am interested and curious about this testing scenario as well. I am wondering if certain things like hash-based might work better and so on.

 

Hi, @Infected . Hi, @flatfly . In the past, I have not ever tried SOB.
Just now, I install it on my virtual machine.
At first, I hope to know whether it is installed properly.
So I write a rule into the Process.DB file in the "Smart Object Blocker\Block" folder as follows:

And then save it.

The problem is...I can still launch ABC.exe...I don't know what happened...

@WildByDesign
Hi.

Yes. In fact, the executable file will corrupt when it fails to load the dll. This is just a small test so I have not written any code to handle the exception...So it simply corrupts.

At first I plan to upload it to share it, but wilderssecurity says that "The uploaded file does not have an allowed extension."

 

@Online_Sword You would have to upload to an external file hosting site. The best thing would be to add the executable and DLL to an archive file such as .zip or .7z, good idea to password protect the archive as well to prevent file hosting sites from taking it down thinking that it could be a virus. Then share the link here if possible. If that is not allowed, you might have to just share link as PM to whoever asks you. Thank you.

 

Thank you. I have sent you a PM.

 

Anyone who is interested in the test files, please send me a PM.

 

What about Voodooshield?

 

@Infected @flatfly: Hi, just now I finally make SOB work.
I mean, now I successfully block some exe files from running.

Sadly, it seems that SOB cannot block the dll, either.
The name of my dll is "HelloDll.dll".
I put the following rule in DLL.DB:

But the exe can still display the string returned by the dll correctly.

@Infected , I think you can reproduce it with SOB and the test files I sent to you...

@ifacedown: I have not tested VS yet, and I would do this later.

 

Yes, I remember that some HIPS added this feature but for me it was too intrusive, I don't see the need for it. You should worry more about dll-injection, a technique used by most advanced malware.

 

@Online_Sword Thank you, I appreciate that. I am doing some preliminary testing right now with your test files. And I think that it's a good method to test and see since malware could easily utilize something similar. This will help all of us, using different anti-exec/app whitelisting programs, to test our rule sets and make rule changes accordingly.

My preliminary testing so far has been with regard to Bouncer at the moment. Some key points that I've noticed so far:

• Enabling Parent Checking feature made quick work of blocking this.
• Under regular Bouncer [BLACKLIST] section you could also add *mscoree.dll to achieve similar blockage, blocking .NET execution.
• The separate drivers for MemProtect and CommandLineScanner provided more granular control to block this.

In this regard, it's good to see that Bouncer, in particular, has added Parent Checking to the current Beta which adds more granular control overall. But also, it would be good to see if the developer can add the CommandLineScanner driver's functionality into the main Bouncer driver for even more granular control.

I would like to do some testing with SOB later as well but likely wont get time until Monday. If I get time sooner, I will post results. I'm certain that SOB will block it as well but will need some specific rules.

 

@WildByDesign : Thank you very much for your tests.

Does this mean that, if the DLL files are written in C or C++ rather than C#, then we only have to use the Parent Checking feature to block them? (Sorry I know little about MemProtect and CommandLineScanner...)

 

I've tested it using SRP and Malware Defender.
I could not block it by SRP no matter how I set it up.
With Malware Defender I also didn't get notification about your dll. But I got notification about loading this libraries:


Maybe some function is used that MD is not monitoring? Or might it be the problem that .NET is used?

 

One more thing. I'm not a programmer but it looks like that dll is not loaded normal way. If you rename your dll file to HelloDll.exe you still get the message. Is this normal?

 

Sorry to chime it here, but a user asked me to give my 2 cents. I know your query is hypothetical (and interesting) , and it is fun to think about.

Really what it comes down to is this. Something has to call a dll for it to execute. If a whitelisted executable calls a dll then you WANT IT TO BE ALLOWED (in general), otherwise it can cause serious issues with other software, as Rasheed187 suggested.

However, if the executable is not whitelisted but still perform a dll injection, that is a totally different story... Assuming other built in protections to the security app does not block it first.

Here is some interesting reading: http://stackoverflow.com/questions/124549/what-exactly-are-dll-files-and-how-do-they-work

 

@Minimalist : Thank you for your test.

Yes, this is also what I found.

I am not sure about that. I should say that I know little about the mechanism of C#...
It seems that using C# to write the test files is not a good idea -- this makes our problem more complicated.
Maybe I will rewrite them in C or C++ later.

Em...I do not think it is normal.
Just now, I tried to remove the extension of the dll file, and to give it a random extension. But in such cases, CallDll.exe corrupts.
It seems that only the original extension (dll) and the "exe" extension work. I don't know why...

 

Thank you for your reply.
My problem is that, would it be possible or not that a whitelisted executable file is hijacked to execute an unknown DLL (in the user space) that any whitelisted executable actually DO NOT depend on?

 

I can't say for certain because I am not a programmer and have no knowledge of programming languages. But what this simple test reminded me of is, for example, have a whitelisted browser such as Chrome or Firefox, and for example add the Flash Player .DLL files to the blacklist during times of Flash exploits active in the wild. That is what came to my mind. But oddly, in those scenarios, the Flash .DLLs were blocked without any problem.

MemProtect and CommandLineScanner are just other projects of kernel-mode drivers made by the same developer as Bouncer. Similar purpose of a single-purpose, small yet efficient kernel driver.

 

Hi, malicious dll loading is not intercepted by classical HIPS. The reason is obvious. It will give literally hundreds of pop up alerts that is practically not feasible to deal with by any user. ( Malware Defender and older version of Comodo Defence Plus had this function but it was disbled by default atleast in Comodo).

Online Armor added some interception for this but I am not sure how effective was this. Comodo people promised to fix this issue with some better alternative but they could never do it.

Recently I read some where that some HIPS( ESET HIPS? ..not sure) have solved this issue by allowing any executable to allow to load ONLY white listed dlls( by using a a builtin white list of dlls for any white listed exe) but I am not sure how robust this solution is.

In the past, I have done some testing with this as well.
https://www.wilderssecurity.com/threads/dll-exploit-lnk-exploit-mitigation-by-hips.284188/

 

Not that I can think of... First of all, the process that is doing the hijacking has to be whitelisted before it can even execute. Then if it can execute, it is limited to code and functions of the executable that it could somehow hijack... so why would it do this? I mean, if it can execute, then it would be a lot more efficient to simply run its own malicious code. This is why whitelisting is so powerful... It is kind of like the old saying "what comes first, the chicken or the egg?".

BTW, I have seen some pretty malicious dll's in the past that did a lot of damage, that were spawned through a rundll32 command, so that is a concern. But I imagine that all of the products in your tests protect against this type of an attack.