DLL protection

[shmu26]

What programs provide good DLL protection?
I know that Kaspersky Internet Security with Trusted Applications Mode enabled is very strict on loading of DLLs.
Any other apps that do it?

 

[Wave]

Emsisoft Anti-Malware/Internet Security (Behaviour Blocker) & SpyShelter Anti-Keylogger most likely supports protection against DLL injection also.

Without that being said, there are many different types of process manipulation/injection attacks aside from the common DLL injection methods.

 

[shmu26]

Emsisoft Anti-Malware/Internet Security (Behaviour Blocker) & SpyShelter Anti-Keylogger most likely supports protection against DLL injection also.

Without that being said, there are many different types of process manipulation/injection attacks aside from the common DLL injection methods.

I never saw DLL protection in SpyShelter.

 

[Wave]

I never saw DLL protection in SpyShelter.

Thanks for correcting me - I've never actually used it, however since it contains a HIPS module I assumed it would've included something like this.

Regardless, Emsisoft Anti-Malware/Internet Security definitely has protection against DLL injection.

 

[shmu26]

Thanks for correcting me - I've never actually used it, however since it contains a HIPS module I assumed it would've included something like this.

Regardless, Emsisoft Anti-Malware/Internet Security definitely has protection against DLL injection.

thanks.
I guess I was not so clear in my question.
I am asking more about protection against the loading of rogue DLLs.

 

[SHvFl]

Why do you care though? To load a dll something needs to be allowed to run, the dll will not automatically load on it's own. Usually security software monitors process manipulation , software execution, driver loading, service creation...

 

[Wave]

thanks.
I guess I was not so clear in my question.
I am asking more about protection against the loading of rogue DLLs.

If you're referring to the prevention of DLLs being loaded if they are malicious then it will depend on if the DLL is detected by the real-time scanner (so when DLLs are being loaded by programs they should be scanned by the product and if they are found to be classified as malicious then the module will be blocked from being loaded into the memory of the target process attempting to load the DLL).

However, if you're referring to preventing a DLL being loaded which has been hijacked (e.g. system DLL which is vulnerable and thus malware has successfully patched it so it executes malicious code when it's loaded by a process and then jumps to the original code), it really depends on the situation and the product - and I am unaware on specific software which support mechanisms for attempting to detect this behaviour.

Without that being said, Emsisoft Anti-Malware does support protecting against "patching" of other programs. Although, I am unaware if this feature supports protection against DLL hijacking attempts (e.g. replacing a DLL with another one with the same file-name to trick software into loading the rogue copy and executing the malicious code). The chances that it does include protection against DLL hijacking to an extent are high though.

Hopefully I didn't misunderstand you again...

 

[shmu26]

If you're referring to the prevention of DLLs being loaded if they are malicious then it will depend on if the DLL is detected by the real-time scanner (so when DLLs are being loaded by programs they should be scanned by the product and if they are found to be classified as malicious then the module will be blocked from being loaded into the memory of the target process attempting to load the DLL).

However, if you're referring to preventing a DLL being loaded which has been hijacked (e.g. system DLL which is vulnerable and thus malware has successfully patched it so it executes malicious code when it's loaded by a process and then jumps to the original code), it really depends on the situation and the product - and I am unaware on specific software which support mechanisms for attempting to detect this behaviour.

Without that being said, Emsisoft Anti-Malware does support protecting against "patching" of other programs. Although, I am unaware if this feature supports protection against DLL hijacking attempts (e.g. replacing a DLL with another one with the same file-name to trick software into loading the rogue copy and executing the malicious code). The chances that it does include protection against DLL hijacking to an extent are high though.

Hopefully I didn't misunderstand you again...

I must admit that I lack a proper understanding of DLL attacks, but I have read about attacks that utilize a script or a exploit to download malicious DLLs. If they are new, the antivirus won't detect them.

 

[Wave]

I must admit that I lack a proper understanding of DLL attacks, but I have read about attacks that utilize a script or a exploit to download malicious DLLs. If they are new, the antivirus won't detect them.

The AV will usually be aware of the DLL being loaded by a program into it's address space (memory) however depending on various factors it may not be able to identify the DLL as being malicious (containing malicious code).

Spoiler: Short Windows Internals information

Most AV products will be alerted of programs loading a DLL through a kernel-mode callback known as PsSetLoadImageNotifyRoutine: PsSetLoadImageNotifyRoutine routine (Windows Drivers) - they get a notification (the callback function becomes invoked) when an image is loaded/mapped into memory (therefore including DLLs being loaded by processes).

The security product will (or should) be alerted that a DLL is being loaded/mapped into memory. Afterwards, it will utilise it's detection methods against the DLL file - if the DLL is detected to be malicious then it'll be cleaned off the system. Of course, no security product can detect 100% malware and therefore if the checksum detection/heuristics (or any other detection methods it may incorporate) don't pick-up a detection for the DLL, then it'll bypass the detection and will be loaded to execute it's malicious code.

Without that being said, if your AV product supports behavioural zero-day components such as dynamic heuristics/BB/HIPS modules, they should still remain active for any code being executed by the newly loaded DLL - unless the code being executed uses a trick/method to bypass the AV monitoring (preventing the AV from restricting access/controlling execution flow for specific actions).

Not sure if I misunderstood you again but hopefully not!

 

[shmu26]

The AV will usually be aware of the DLL being loaded by a program into it's address space (memory) however depending on various factors it may not be able to identify the DLL as being malicious (containing malicious code).

Spoiler: Short Windows Internals information

Most AV products will be alerted of programs loading a DLL through a kernel-mode callback known as PsSetLoadImageNotifyRoutine: PsSetLoadImageNotifyRoutine routine (Windows Drivers) - they get a notification (the callback function becomes invoked) when an image is loaded/mapped into memory (therefore including DLLs being loaded by processes).

The security product will (or should) be alerted that a DLL is being loaded/mapped into memory. Afterwards, it will utilise it's detection methods against the DLL file - if the DLL is detected to be malicious then it'll be cleaned off the system. Of course, no security product can detect 100% malware and therefore if the checksum detection/heuristics (or any other detection methods it may incorporate) don't pick-up a detection for the DLL, then it'll bypass the detection and will be loaded to execute it's malicious code.

Without that being said, if your AV product supports behavioural zero-day components such as dynamic heuristics/BB/HIPS modules, they should still remain active for any code being executed by the newly loaded DLL - unless the code being executed uses a trick/method to bypass the AV monitoring (preventing the AV from restricting access/controlling execution flow for specific actions).

Not sure if I misunderstood you again but hopefully not!

I noticed that Kaspersky, when you enable TAM, seems to apply a sort of whitelisting approach to DLLs. I am not sure exactly how the system works, but it sure blocks a lot of DLLs for me, when the app is not on the KSN whitelist.

 

[509322]

AppGuard - blocks DLL loading from User Space and DLL injection (on both 32 & 64-bit systems).

 

[cruelsister]

Shmu- The most common ways that one gets a malware dll is either by injection (like the old DOJ ransomware)- here the process can be caught by HIPS and such. The other more current way is seen by stuff like Locky ransomware where a script is run, then connects to the Internet in order to download and drop the payload dll. In this case in addition to the methods of stopping it listed by posters above:

1). using an outbound firewall and denying the script getting out (as some malware vectors may include the dll within this may not be 100% effective) thus stopping the dll from being downloaded to your system
2). using a sandbox like Comodo which will sandbox the downloaded dll and render it ineffective
3). or just relying on your traditional AV (which will treat a malicious dll just like a malicious exe) to directly detect the dll- like here:

Antivirus scan for 5948ceff8012d80f9b2dcef7316aa94d3a171d309c78e6b021b6af6928f16a0d at 2016-10-26 20:26:23 UTC - VirusTotal
https://www.virustotal.com/en/file/...9c78e6b021b6af6928f16a0d/analysis/1477513583/
Hope that helped.

 

[shmu26]

Shmu- The most common ways that one gets a malware dll is either by injection (like the old DOJ ransomware)- here the process can be caught by HIPS and such. The other more current way is seen by stuff like Locky ransomware where a script is run, then connects to the Internet in order to download and drop the payload dll. In this case in addition to the methods of stopping it listed by posters above:

1). using an outbound firewall and denying the script getting out (as some malware vectors may include the dll within this may not be 100% effective) thus stopping the dll from being downloaded to your system
2). using a sandbox like Comodo which will sandbox the downloaded dll and render it ineffective
3). or just relying on your traditional AV (which will treat a malicious dll just like a malicious exe) to directly detect the dll- like here:

Antivirus scan for 5948ceff8012d80f9b2dcef7316aa94d3a171d309c78e6b021b6af6928f16a0d at 2016-10-26 20:26:23 UTC - VirusTotal
Hope that helped.

and what is done with the payload dll? Is a legit program forced to load it?

Is it downloaded to a suspicious location that a good BB will block?

 

[LabZero]

and what is done with the payload dll? Is a legit program forced to load it?

Is it downloaded to a suspicious location that a good BB will block?

Malware can load the payload dll into the same process, and then without “spawning” (slang, it means to be born again in an area after having died!) another process, which is very useful to avoid Whitelist of security applications, to bypass some HIPS and some antivirus that support, in bad way, the memory scan, especially if the process is authorized, signed, and only in a second time the dll is loaded inside it.

 

[shmu26]

Malware can load the payload dll into the same process, and then without “spawning” (slang, it means to be born again in an area after having died!) another process, which is very useful to avoid Whitelist of security applications, to bypass some HIPS and some antivirus that support, in bad way, the memory scan, especially if the process is authorized, signed, and only in a second time the dll is loaded inside it.

does the payload dll get placed in a suspicious location, so that a good BB will block it from being loaded?

 

[LabZero]

does the payload dll get placed in a suspicious location, so that a good BB will block it from being loaded?

Everything is possible, but if the malware uses specific evasion techniques such as I said above, it is unlikely.

 

[hjlbx]

does the payload dll get placed in a suspicious location, so that a good BB will block it from being loaded?

A behavior blocker - like Emsisoft's - or a HIPS like SpyShelter (32-bit systems only) - will block the DLL injection based upon the injecting process reputation|whitelisting - and not the location of the DLL on the system.

 

[DardiM]

and what is done with the payload dll? Is a legit program forced to load it?

Is it downloaded to a suspicious location that a good BB will block?

Often the dll downloaded isn't seen as dll : the script deobfuscate it before, once saved on the HD, and rundll32.exe is used to run the dll, with as parameter the function to call

About location, very often :

- %TEMP%

=> C:\Users\USER\AppData\Local\Temp

​

- %APPDATA%

=> C:\Users\USER\AppData\Roaming\Microsoft\ Folder created \ dll file (payload)​

​

- Recent examples I've seen :

rundll32.exe %TEMP%\WKEKTU.DLL,qwerty 323

=> calls the qwerty function of WKEKTU.DLL (a locky ransomware) with parameter 323

rundll32.exe %TEMP%\ file.dll,#1 parameter

​

- regsvr32.exe is also used​

 

[shmu26]

Everything is possible, but if the malware uses specific evasion techniques such as I said above, it is unlikely.

so it sounds like dll attacks can be pretty tricky.
what is best prevention, or maybe no need to worry about it, as @SHvFl suggested, because a default/deny setup will block the malicious process?

 

[hjlbx]

so it sounds like dll attacks can be pretty tricky.
what is best prevention, or maybe no need to worry about it, as @SHvFl suggested, because a default/deny setup will block the malicious process?

If you run default-deny, then you block the malicious process that will perform the DLL injection in the first place - and save yourself a whole lot of trouble.

In other words, you don't need a highly complex HIPS, Ai or behavior blocker to protect the system; you only need disciplined use of the simple default-deny protection model. If you are really paranoid, then combine default-deny with isolation, rollback or virtualization.

This is why default-deny is the "King" of physical system protection.