Hot Take Comodo Internet Security 2025 was obliterated by an exploit!

vitao said:
but who said that?

comodo is lucrative as xcitium as itariam as valkyrie, as any other softwares from melih company.

the problem is really simple. they dont have people who know how to solve the issues and what they have are looking at xcitium. the prove of it is that the same exploit/poc that destroys cis containment do the same with xcitium and there is no response from xcitium nor comodo about it. the flaw exists. its a big problem. xcitium users, who are the paid ones, are not secured and even so, they dont get any update regardless this...
Click to expand...
Comodo products are not lucrative. They are what is called "loss leaders." Melih gives them away for free or charges very low subscription rates. That means he is selling them at a loss.

There are no dedicated Comodo developer teams! There never has been.

Here are the facts about Comodo's security products:

The fundamental issue with the product is a very simple one to understand: Melih owns the product, it generates virtually no revenue, and since Day 1 he has spent millions of his own money to subsidize the product and give it away. Well, he's not willing to spend any more on the product other than to keep it alive. There is no dedicated development team for the source code, and that means there is nobody to fix bugs and make the product more polished. Without a revenue stream to support its development, Comodo will never be any better than it is right now. Without bringing in substantial money, it shall always be a 1000-bug, broken feature freeware.

Melih earns virtually all of his money from digital certificates, venture capital and other services. He earns virtually $0 from Comodo security software.

Comodo companies do not operate like Avast, Bitdefender, Kaspersky and Norton. I don't blame people who do not understand this fact. It takes a lot of research to figure it out.

Melih has no obligation to fix anything. Anybody that installs Comodo software, the EULA says clearly "You accept this software AS IS and you use it at your own risk." This is true of every last software EULA out there. So Comodo is no different.

All Comodo software, including Xcitium, are very unprofitable for Melih. He loses money on them all. So that means he is personally subsidizing all these software out of his own pocket. CIS\CFW were never profitable. They have always been freeware.
 
Last edited:
  • Like
Reactions: Sorrento and roger_m
UPDATE: Fixed in Xcitium
This is not a Comodo config issue, but a containment security infrastructure issue, and you will have to wait for a CIS update to fix this.
So adding *\Device\NamedPipe\ntsvcs to protected files or protected com is currently useless until CIS gets a security update.
QQ20241119-231504.png
 
  • Like
  • Wow
Reactions: Andy Ful, simmerskool and Sorrento
Vitali Ortzi said:
What about andy ful challenge did they contact Andy to work on fixing it ?
Click to expand...
Why would anybody contact @Andy Ful ?

Submit bug report on COMODO forum. If it is fixed then great. If not, then ¯\_ (ツ)_/¯ . A person either accepts it or does not.

People/users want stuff fixed, but nobody is willing to pay for the fixes. That means COMODO will never be any better than it is at this moment.

Melih's philosophy is "If you want something for free, then you will have to accept whatever I decide to give you. If not, go use something else. Please because I do not want to be bothered with ungrateful, whiny, complaining users."
 
Vitali Ortzi said:
What about andy ful challenge did they contact Andy to work on fixing it ?
Click to expand...

No, they did not.
I use a different method that does not trigger containment. It is not exactly an exploit, but rather taking advantage of AVs ignoring some known (and unknown but signalized) attack methods until they are sufficiently prevalent. Furthermore, some methods are hard to fix, like DLL hijacking. Most AVs try to fight it by improving DLL detection, which is insufficient in targeted attacks.
In the case of Comodo, the attack that exploits vulnerable but trusted EXE can be especially successful due to two weaknesses:
  1. Poor detection of weaponized DLLs.
  2. Poor detection of some UAC bypasses.
At the same time, Comodo can block most attacks in the wild via Auto-containment and Script Analysis modules. So finally, the attacker must know that the target uses Comodo to have fair chances to pass by the protection.
 
Last edited:
  • Like
  • +Reputation
Reactions: porkpiehat, Loyisa, Gandalf_The_Grey and 2 others
vitao said:
sorry but its not fixed. you tested it with poc v2. try it with poc v3. cis continues to be r@ped by the poc, so they didnt solve anything...
Click to expand...
Please show it with video evidence and post on the fourm or someone else upload it if you're banned
 
Andy Ful said:
No, they did not.
I use a different method that does not trigger containment. It is not exactly an exploit, but rather taking advantage of AVs ignoring some known (and unknown but signalized) attack methods until they are sufficiently prevalent. Furthermore, some methods are hard to fix, like DLL hijacking. Most AVs try to fight it by improving DLL detection, which is insufficient in targeted attacks.
In the case of Comodo, the attack that exploits vulnerable but trusted EXE can be especially successful due to two weaknesses:
  1. Poor detection of weaponized DLLs.
  2. Poor detection of some UAC bypasses.
At the same time, Comodo can block most attacks in the wild via Auto-containment and Script Analysis modules. So finally, the attacker must know that the target uses Comodo to have fair chances to pass by the protection.
Click to expand...

Andy Ful said:
No, they did not.
I use a different method that does not trigger containment. It is not exactly an exploit, but rather taking advantage of AVs ignoring some known (and unknown but signalized) attack methods until they are sufficiently prevalent. Furthermore, some methods are hard to fix, like DLL hijacking. Most AVs try to fight it by improving DLL detection, which is insufficient in targeted attacks.
In the case of Comodo, the attack that exploits vulnerable but trusted EXE can be especially successful due to two weaknesses:
  1. Poor detection of weaponized DLLs.
  2. Poor detection of some UAC bypasses.
At the same time, Comodo can block most attacks in the wild via Auto-containment and Script Analysis modules. So finally, the attacker must know that the target uses Comodo to have fair chances to pass by the protection.
Click to expand...
Can comodo under user account with a separate admin stop all of your attacks , known ones and what recommendations you have for comodo users (I have a low end system where even defender and eset are too heavy )
 
  • Like
Reactions: simmerskool and Andy Ful
Vitali Ortzi said:
Please show it with video evidence and post on the fourm or someone else upload it if you're banned
Click to expand...

It is not necessary. The POC mentioned by @vitao does not trigger containment (contrary to the first POC) and the Comodo fix is only related to the containment escape.
 
  • +Reputation
  • Like
Reactions: simmerskool, ErzCrz and Vitali Ortzi
Vitali Ortzi said:
Can comodo under user account with a separate admin stop all of your attacks , known ones and what recommendations you have for comodo users (I have a low end system where even defender and eset are too heavy )
Click to expand...

The AV Challenge attack on the Standard User Account (SUA) will trigger the UAC Credential Prompt. If the user does not insert credentials, the attack will be blocked. When using SUA, most malware (including ransomware) are often less dangerous.
But, Comodo is still vulnerable to attacks via DLL hijacking. Examples of such attacks can be found in the wild against organizations, like PlugX RAT, AsyncRAT, or Kransom mentioned here:
unit42.paloaltonetworks.com

Intruders in the Library: Exploring DLL Hijacking

Dynamic-link library (DLL) hijacking remains a popular technique to run malware. We address its evolution using examples from the realm of cybercrime and more.
unit42.paloaltonetworks.com unit42.paloaltonetworks.com
any.run

Kransom Ransomware: Uses DLL-Sideloading to Abuse an RPG

Learn about Kransom, a new ransomware that uses the DLL-sideloading technique to hijack the popular game Honkai: Star Rail.
any.run any.run

However such examples are rare. In most cases, the attacks also use scripting that can be mitigated via Comodo's Script Analysis (tweaked). If the non-enterprise user wants to increase Comodo's protection against such threats, tweaking Script Analysis settings could help.
 
Last edited:
  • +Reputation
Reactions: simmerskool
Andy Ful said:
It is not necessary. The POC mentioned by @vitao does not trigger containment (contrary to the first POC) and the Comodo fix is only related to the containment escape.
Click to expand...
on my testings it seems containment continues to just ignore but there is something new: the dll (the ransom itself) shows at unrecognized list but not blocked not prompted for user decision, so it seems its the containment being evaded here, right? or am i getting it wrong?

ive already recorded the video with the test but i need to record the part with my talkings. ill try to do it by the weekend.

edit.: one thing that needs to be noted here. the dll is the ransomware itself and windwos defender block it by recognizing it as malicious but comodo antivirus just plays the dumb and ignores it. even kingsoft can recognize it as malware but cis... funny right?

edit2: the video testing it will have 2 parts. one showing the new cis with its default config. in the second one cis is with cruelsister config tweaked by me and with the part that loyisa said that had to be changed, the script analys that i checked every damn option there.

in both scenarios cis is r@ped by the poc in its v3. in both scenarios uac is turned off by windows settings (not by regedit, so its not fully off as many knows). i tried with uac on and the result was the same but as it was a short attempts it is not on the full video recorded before :P
 
  • Applause
Reactions: Vitali Ortzi
Andy Ful said:
The AV Challenge attack on the Standard User Account (SUA) will trigger the UAC Credential Prompt. If the user does not insert credentials, the attack will be blocked. When using SUA, most malware (including ransomware) are often less dangerous.
But, Comodo is still vulnerable to attacks via DLL hijacking. Examples of such attacks can be found in the wild against organizations, like PlugX RAT or AsyncRAT mentioned here:
unit42.paloaltonetworks.com

Intruders in the Library: Exploring DLL Hijacking

Dynamic-link library (DLL) hijacking remains a popular technique to run malware. We address its evolution using examples from the realm of cybercrime and more.
unit42.paloaltonetworks.com unit42.paloaltonetworks.com

However such examples are rare. In most cases, the attacks also use scripting that can be mitigated via Comodo's Script Analysis (tweaked). If the non-enterprise user wants to increase Comodo's protection against such threats, tweaking Script Analysis settings could help.
Click to expand...

Maybe you can help me a little bit.

In an recent video showing cis 2025 (the previous one) with its default config against 200 new malwares i was surprised by one little fella who bypasses everything but its marked in virustotal by many as malware. Can you say something about this file? After I did the testings I was going to record another video so i decided to update the malwares used on the tests and i forgot to save this file. now i can not find it anywhere to download it for study.

the video:

the sha256 of the file: 75d96dfe70912f3f2c5b669ebac010a83904daea9a908c5352063f1508d8ed58

edit> nvm. i just found the file on tria ge... :) ill do some more testings on it but if anyone can talk a little about this one ill be vary glad :D
 
  • Like
Reactions: Andy Ful
vitao said:
on my testings it seems containment continues to just ignore but there is something new: the dll (the ransom itself) shows at unrecognized list but not blocked not prompted for user decision, so it seems its the containment being evaded here, right? or am i getting it wrong?
Click to expand...

The containment was evaded because it was not triggered at all. The DLL is considered Unrecognized because it was scanned, and Comodo did not know it.
Comodo (by default) does not auto-contain trusted files and DLLs loaded by them, and the EXE used in the attack (StarRail.exe) is a well-known and trusted EXE from the original benign game. That is how DLL hijacking works: the EXE file must be well-known and benign.
 
Last edited:
  • +Reputation
Reactions: simmerskool
Andy Ful said:
The containment was evaded because it was not triggered at all. The DLL is considered Unrecognized because it was scanned, and Comodo did not know it.
Comodo (by default) does not auto-contain trusted files and DLLs loaded by them, and the EXE used in the attack (StarRail.exe) is a well-known and trusted EXE from the original benign game. That is how DLL hijacking works: the EXE file must be well-known and benign.
Click to expand...

hmmm.. so.. if this kind of thing goes live and people target cis users, just for fun, god help us... as comodo doesnt seems to care too much... right?
 
vitao said:
Maybe you can help me a little bit.
Click to expand...

The PowerShell script (detected by Kaspersky) was blocked by Comodo via Script Analysis. The PowerShell CmdLine was converted to PS1 script and copied to C:\ProgramData\Comodo\Cis\tempscript folder.
 
  • +Reputation
Reactions: simmerskool
vitao said:
hmmm.. so.. if this kind of thing goes live and people target cis users, just for fun, god help us... as comodo doesnt seems to care too much... right?
Click to expand...
I do not know if they care, but a non-enterprise user should probably live a thousand years to be a victim of such malware. :)
I am unsure if Xcitium also has this issue (poor DLL detection).
Other AVs also do not care about some rare attack vectors.
 
Last edited:
  • +Reputation
Reactions: simmerskool
Andy Ful said:
The PowerShell script (detected by Kaspersky) was blocked by Comodo via Script Analysis. The PowerShell CmdLine was converted to PS1 script and copied to C:\ProgramData\Comodo\Cis\tempscript folder.
Click to expand...
not the powershell. the exe that runs and cis do nothing about it. i posted the sha256 for the file
 
  • Like
Reactions: Andy Ful

You may also like...