Comodo Internet Security 2025 recognizes RANSOMWARE as a TRUSTED file (bypass, infection and lost of files)

[Andy Ful]

But if I were a paying enterprise customer well you better run away as there are endless better options

The enterprise version may be free of that bug. Also, if I correctly recall, @Loyisa posted that the enterprise version is better for fighting DLL hijacking.

 

[Vitali Ortzi]

I downloaded the very latest Comodo 2025 a while back and it's at Cruel settings.

I know this is off topic but digging into advanced protection, I see something called Intel TDT. Should it be checked, since this laptop has Intel aboard?

Yes it helps a lot against ransomware unless you use defender /other av that already has TDT then it should be on (you will get a notification from comodo that some other program is using TDT ) and since it runs on the graphic cores it's very efficient

 

[ErzCrz]

I downloaded the very latest Comodo 2025 a while back and it's at Cruel settings.

I know this is off topic but digging into advanced protection, I see something called Intel TDT. Should it be checked, since this laptop has Intel aboard?

TDT is unchecked by default but it's dependent on your intel chip being compatible (vPro INtel Thred Detection Technology but only a handful of chips seem to be fully compatible with it. Just leave it unchecked unless you have at least 13th gen chip which is fully vPro compatible. Intel TDT Compatible Chips. CIS 2025 runs fine at my end in my tests with it.

 

[rashmi]

The enterprise version may be free of that bug. Also, if I correctly recall, @Loyisa posted that the enterprise version is better for fighting DLL hijacking.

A Comodo Forum moderator reported that they have fixed the issue in Xcitium. PoC bypass Auto-Sandbox CIS

Did @Loyisa or @vitao also test Comodo's default "run virtual" setting without the "restriction level"?

 

[bazang]

A Comodo Forum moderator reported that they have fixed the issue in Xcitium. PoC bypass Auto-Sandbox CIS

Did @Loyisa or @vitao also test Comodo's default "run virtual" setting without the "restriction level"?

InfoSec is not a Comodo forum moderator, I do not think.

You can see Melih's position with this post. "Legitimate workaround" means, to him, if he wants it fixed or not. And Melih's "fast" usually means months.

It is a software with $0 revenue. People are lucky that Melih makes it available at all. I do not see anybody do anything other than complain about bugs, but nobody is sending donations to Comodo so that Melih will assign a dedicated developer staff to the code base.

There is no dedicated Comodo developer team! There never has been!

Melih has developers on staff, many of which are subcontract and not located in the U.S. He moves them around from project to project, if, when, and how he sees fit. Comodo has never followed a dedicated product team model. There is no dedicated Comodo developer staff!!

 

[ErzCrz]

A Comodo Forum moderator reported that they have fixed the issue in Xcitium. PoC bypass Auto-Sandbox CIS

Did @Loyisa or @vitao also test Comodo's default "run virtual" setting without the "restriction level"?

The "restricted level" unchecked or not set will just default to Partially Limited which is the issue. The flaw is the restriction level being ignored. One can hope the fix filters through to CIS/CF but it'll be low priority as always. When there was a bypass back in 2018, the enterprise products got a fix 2 weeks before the consumer version. We'll see how long it takes to come through.

 

[Vitali Ortzi]

InfoSec is not a Comodo forum moderator, I do not think.

You can see Melih's position with this post. "Legitimate workaround" means, to him, if he wants it fixed or not. And Melih's "fast" usually means months.

It is a software with $0 revenue. People are lucky that Melih makes it available at all. I do not see anybody do anything other than complain about bugs, but nobody is sending donations to Comodo so that Melih will assign a dedicated developer staff to the code base.

There is no dedicated Comodo developer team! There never has been!

Melih has developers on staff, many of which are subcontract and not located in the U.S. He moves them around from project to project, if, when, and how he sees fit. Comodo has never followed a dedicated product team model. There is no dedicated Comodo developer staff!!

View attachment 286216

Lol bringing your own driver , dll with most extreme (proactive)
Isn't legitimate poor enterprise customers no wonder it's one of the cheapest products

 

[rashmi]

The "restricted level" unchecked or not set will just default to Partially Limited which is the issue. The flaw is the restriction level being ignored. One can hope the fix filters through to CIS/CF but it'll be low priority as always. When there was a bypass back in 2018, the enterprise products got a fix 2 weeks before the consumer version. We'll see how long it takes to come through.

The default setting is "run virtually," which means "full virtualization," with the "restriction level" deactivated. A Comodo Forum moderator clarified the UAC issue affects the "restriction level" setting, not the "default" setting. The moderator's post explained, "Also UAC doesn’t apply when not using restriction levels as the the default setting is to run virtually."

 

[bazang]

Lol bringing your own driver , dll with most extreme (proactive)
Isn't legitimate poor enterprise customers no wonder it's one of the cheapest products

When Melih created Comodo, his intention was never to sell it to home users (consumers) and enterprises. So the intention was never to generate revenue. Without revenue there is no money to pay for the development and other teams to fully support the product(s).

Everybody that complains about Comodo bugs - why don't they send donations to Comodo? Why do they expect Melih to fund the entire Comodo code base and infrastructure out of his own pocket? If the situation were reversed, and the complainers were placed in Melih's shoes, they would not spend millions of dollars to fix bugs. LOL. No. They. Would. Not.

"Subscriptions" are for the support, not the software. It says this in every single one of Comodo's various EULAs and Terms of Service (TOS).

Melih makes what he thinks is good enough. He's said it himself: "Don't like it? Then don't use it. I'd rather you go use something else. Please. Go away."

 

[ErzCrz]

The default setting is "run virtually," which means "full virtualization," with the "restriction level" deactivated. A Comodo Forum moderator clarified the UAC issue affects the "restriction level" setting, not the "default" setting. The moderator's post explained, "Also UAC doesn’t apply when not using restriction levels as the the default setting is to run virtually."

Thanks. I read that post but also thought the containment level that was set was also ignored. Anyway, I'll have to re-watch video to comment to OP and get back on topic.

 

[rashmi]

Thanks. I read that post but also thought the containment level that was set was also ignored. Anyway, I'll have to re-watch video to comment to OP and get back on topic.

Could the UAC and restriction level problem be affecting the "run virtually" key setting? This is the reason I posed the question, "Did they also test the default, which involves running virtually with the restriction level deactivated?"

 

[wat0114]

My next new AV.

You could probably use this and nothing would change. You still won't get compromised, and it will have nothing to do with your "next new AV" It will instead have everything to do with whats between your ears

 

[Andy Ful]

It looks like a few possible Comodo bypasses recently posted on MT might discourage some readers from using CIS. I do not think that it is justified.
CIS on default settings is as good as any popular AV on default settings. Indeed, the Comodo detection is rather poor, but it is strongly supported by the auto-containment.
If one wants very strong protection then the below solutions are very similar (high number of false positives):

1. Microsoft Defender (ConfigureDefender HIGH or MAX settings) + Smart App Control.
2. Kaspersky (paid) with @harlan4096 settings.
3. Microsoft Defender + Comodo Firewall (@cruelsister settings) + Script Analysis tweaks (or Defender ASR rules).

I am not sure about the setup similar to point 3 based only on CIS. I cannot evaluate the impact of the attacks based on pure DLL hijacking (benign EXE + malicious DLL and nothing else). The detection of DLLs by CIS is poor, and containment cannot help either. So, the protection against such attacks depends mainly on HIPS. There are no tests that could show how effective can be HIPS. However, pure DLL hijacking attacks are probably very rare in the non-enterprise environment, so it is possible that CIS protection can be similar to those previously mentioned. I mentioned Microsoft Defender because from my tests it follows that it has the top detection of malicious DLLs, so it can support the potential weakness of Comodo.

I am not going to discuss other aspects like detection, usability, performance, etc. Some people like the protection model of CIS, and many probably do not. But all can live in peace.