Serious Discussion Comodo discussions

Comodo
40 Replies 5,402 Views
rashmi said:
@Andy Ful, Most malware DLLs drop in Temp/AppData, while legitimate DLLs stay in System32/Program Files. Is it correct?
Click to expand...

Most malware drops temporary payloads in the %LocalAppdata% or installs in UserSpace (user AppData, ProgramData, etc.).
Dropping payloads in the system folders (SystemSpace) requires higher privileges.

Legitimate DLLs can stay anywhere, depending on the software. The software installed for all users (systemwide), mainly keeps executables (including DLLs) in SystemSpace. Applications installed for a particular user mostly use only standard privileges, so the executables are dropped/located mostly in UserSpace.
 
Would this method be useful against DLL hijacking? (If it functions properly in Comodo)

File Groups and Paths
Trusted DLLs Locations
C:\Windows\System32\*.dll
C:\Program Files*\*.dll
C:\Program Files (x86)\*.dll
Untrusted DLLs Policy
*.dll

Auto-Containment Rules
Ignore > File Group > Trusted DLLs Locations
Run Virtually > File Group > Untrusted DLLs Policy
 
I attempted to run the portable version of HDSentinel Pro from my PortableApps directory (C:\PortableApps), a program already on my system and in the Comodo whitelist. Comodo contained "detect.dl," a file listed in the Comodo File List as trusted. This method appears functional and could be useful for mitigating DLL hijacking, assuming minimal impact on usability.
 
rashmi said:
Would this method be useful against DLL hijacking? (If it functions properly in Comodo)

File Groups and Paths
Trusted DLLs Locations
C:\Windows\System32\*.dll
C:\Program Files*\*.dll
C:\Program Files (x86)\*.dll
Untrusted DLLs Policy
*.dll

Auto-Containment Rules
Ignore > File Group > Trusted DLLs Locations
Run Virtually > File Group > Untrusted DLLs Policy
Click to expand...

I am not sure. You may check it by using the method from:
malwaretips.com

Advice Request - Testing DLL Search Order Hijacking against security features.

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

The problem is that in DLL hijacking, already trusted processes load DLLs. In my previous tests, Comodo with autocontainment did not contain DLLs except when:
  • the DLL was flagged as malicious,
  • the trusted executable that ran the DLL (like RunDll32) was restricted by Script Analysis settings.
 
rashmi said:
I attempted to run the portable version of HDSentinel Pro from my PortableApps directory (C:\PortableApps), a program already on my system and in the Comodo whitelist. Comodo contained "detect.dl," a file listed in the Comodo File List as trusted. This method appears functional and could be useful for mitigating DLL hijacking, assuming minimal impact on usability.
Click to expand...

This suggests that it works, although the whitelist looks too simplistic.(y)
 
rashmi said:
You'll definitely enhance and complete it, I'm sure. :)
Click to expand...

Not soon. Currently, I do not use/test Comodo.
The DLL block rule (*.dll) looks very strong (can block Trusted DLLs), and many system DLLs are outside your whitelist. The usability of such restrictions will depend on the Comodo Profile and user whitelist. Depending on the Comodo Profile, different system and non-system locations can be whitelisted by default for DLLs.

You should copy the folder with HDSentinel to some other locations and check if the rules work as intended:
  1. C:\ProgramData\
  2. C:\Users\*\AppData\Local\
  3. C:\Users\*\AppData\Local\Temp\
  4. C:\Users\*\AppData\Roaming\
If the DLLs are blocked in those locations, almost all application installations/updates will fail.
I am not sure about Windows Updates.
I am not sure if the block rule is overridden for signed DLLs by whitelisting the vendor.
 
Last edited:
Andy Ful said:
Can you run PowerShell console with those restrictions?
Click to expand...
Yes, Windows PowerShell.

Andy Ful said:
Not soon. Currently, I do not use/test Comodo.
The DLL block rule (*.dll) looks very strong (can block Trusted DLLs), and many system DLLs are outside your whitelist. The usability of such restrictions will depend on the Comodo Profile and user whitelist. Depending on the Comodo Profile, different system and non-system locations can be whitelisted for DLLs.

You should copy the folder with HDSentinel to some other locations and check if the rules work as intended:
  1. C:\ProgramData\
  2. C:\Users\*\AppData\Local\
  3. C:\Users\*\AppData\Local\Temp\
  4. C:\Users\*\AppData\Roaming\
If the DLLs are blocked in those locations, almost all application installations/updates will fail.
I am not sure about Windows Updates.
I am not sure if the block rule is overridden for signed DLLs by whitelisting the vendor.
Click to expand...
The "untrusted policy" prevents/virtualizes DLL execution from non-whitelisted locations. We can either expand the whitelist or use high-risk locations (remove *.dll) for the untrusted policy.

I'm also not sure about Windows updates, but checking for them works.
I only tried the stated containment rules to see if they work.
 
Last edited:
rashmi said:
Yes, Windows PowerShell.


The "untrusted policy" prevents/virtualizes DLL execution from non-whitelisted locations. We can either expand the whitelist or use high-risk locations (remove *.dll) for the untrusted policy.

I'm also not sure about Windows updates, but checking for them works.
I only tried the stated containment rules to see if they work.
Click to expand...

The crucial thing is the ability to override the general block DLL rule by the Trusted Vendors List. Otherwise, the general block DLL rule will be hard to manage in practice.
 
Andy Ful said:
The crucial thing is the ability to override the general block DLL rule by the Trusted Vendors List. Otherwise, the general block DLL rule will be hard to manage in practice.
Click to expand...
How about these locations for the whitelist?
C:\ProgramData\*
C:\Users\rashmi\AppData\Local\*
C:\Users\rashmi\AppData\Roaming\*
C:\Windows\Installer\*
C:\Windows\Temp\*
 
rashmi said:
How about these locations for the whitelist?
C:\ProgramData\*
C:\Users\rashmi\AppData\Local\*
C:\Users\rashmi\AppData\Roaming\*
C:\Windows\Installer\*
C:\Windows\Temp\*
Click to expand...

It should be OK (I use similar whitelisted locations in the WHHLight WDAC and Hard_Configurator).
I hope that Comodo by default whitelists the necessary system locations.
 
I am not sure how those rules can impact the Comodo Script Analysis settings (script, scriplet restrictions). But, there are high chances that the scripts and scriptlets will still be blocked. In WHHLight, the problem is solved by using different security layers for PE files and others.
 
Andy Ful said:
I am not sure how those rules can impact the Comodo Script Analysis settings (script, scriplet restrictions). But, there are high chances that the scripts and scriptlets will still be blocked. In WHHLight, the problem is solved by using different security layers for PE files and others.
Click to expand...
I won't just copy the WHHLight whitelist, but it's an excellent place to start.
 
rashmi said:
Oh yes, I can use your WHHLight whitelist for security and usability, right?
Click to expand...
:) (y)
1752417777103.png
1752417848456.png

1752417895963.png
 
@rashmi,
If I correctly recall, Comodo uses many rules to properly whitelist the system processes. It would be necessary to check if your general DLL block rule does not break them.
 

Recently browsing

Members who viewed this thread in the last 5 minutes

You may also like...

Back
Top