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

the problem is that if the payload was supose to connect to someones host and download things, than cis should block it or atleast show a popup indicating the connection attempt.

We agree that the detection should not be Trusted but for different reasons. The sample was uploaded to Comodo several hours after it was already "dead" (no payload available). Comodo analyzed only the sample, and it contained no active & malicious code. Anyway, the analyst should also check if the sample downloaded/executed the malicious payload in the past. Such information was already available on VirusTotal.

as cis just ignored it, than its an malware bypassing cis, right? remember that cis firewall too.

CIS ignored it because it did not do anything special.
When the sample was 1-hour malware it could be contained because initially it would be Unrecognized. Next, the sample would be uploaded to Comodo, but the analyst could see that it was a trojan downloader by analyzing the downloaded payload. Furthermore, even if the analyst made a mistake, this concrete sample could not infect Comodo users, because the sample was already "dead" after 90 minutes, long before the analyst could finish the analysis.
The design of Comodo's Auto-containment + Cloud analysis protects non-enterprise users against most malware, even when wrongly flagged as Trusted. Simply, most new malware are short-living, so they are Unrecognized and auto-contained.

edit.: as it seems, the file was sent to valkyrie way before i conducted the test and sent it to val.

Yes, but several hours after the payload disappeared from the malicious domain.

Edit 1.
In theory, such false negatives might be used in targeted attacks by reusing the sample with another payload.
Edit2.
I think that such incomplete malware should be removed from testing (except for very special false negative tests). The AV detection (not only Comodo's) will depend on the fact that the sample is complete (with payload) or incomplete (payload not available).
 
Last edited:
  • +Reputation
Reactions: simmerskool
Here is how the sample is detected after changing the hardcoded URL to unknown for AVs:

1734310375156.png


It looks like Xcitium can detect the sample as trojan even when the sample hash is changed.
 
  • +Reputation
Reactions: simmerskool
Here is how the sample is detected after changing the hardcoded URL to unknown for AVs:

View attachment 286637

It looks like Xcitium can detect the sample as trojan even when the sample hash is changed.
I see. So the file would probably download something that was really dangerous, but the remote server was down, and that's why CIS doesn't detect anything dangerous. Is that it?

If that's the case, then something doesn't make sense for two reasons:

1) If you look at VirusTotal now, you'll see that the number of engines detecting only this executable as a Trojan is increasing, and if the supposed remote server is down, it means that the engines are detecting the executable as dangerous and not what it would download from the remote server. Therefore, CIS failed to recognize this file as dangerous.

2) If the executable isn't dangerous, but rather some file that it would supposedly download, then CIS also failed to identify an attempt to connect to an unknown remote server. Even if the server is down, the executable hasn't been changed, so it would be trying to connect to this server, regardless of whether it's offline or not. At most, it would try to connect or check if the server is online and if it is not, it would not try to establish a connection. However, some network interaction would still be necessary for this verification and this interaction should be intercepted by the CIS and it should warn about it, which does not happen.

Considering what you explained, one could conclude that this could perhaps be classified as just an undesirable program and not as malware, but the identifications of more than 40 engines make it clear that it is a Trojan.

Considering everything you mentioned, a more detailed analysis that was being carried out until a few minutes ago and the results obtained by other engines, I will keep the video online because until proven otherwise, it is malware and Comodo Internet Security was not able to identify anything about it or its actions (or attempted actions), while many others identify it immediately. But I will add an update to the video description explaining this situation.

Or do you think I am wrong in this decision?
 
@vitao Please stop using that word and re-read through the Forum Policy rules. That language pretty much everyone here would deem it inappropriate: Forum Rules - Language

I was reading it. I understand and agree. From now on when i use this word ill change it to something not inappropriate. the meaning of it will not change as its part of the way of expressing myself on some cases. if that is not allowed, free expression, than its a problem. i dont think its by the forum rules to censure its users.
 
I'm with @ErzCrz on this one. You should not be using that word in any facet of your life and not here.
sorry man but people have no word on what i use or not for talkings and things on this matter. sure, we are in a forum and as some asked polited, and there are rules, ill comply to these rules and not use the word one dude had bad feelings about. ill respect this not for what that user said but for the rules of the forum, but i can not agree with this thing some are trying to force. and its funny how one topic about some security software somene came crying and offtopic about personal feelings.... anyway... right? lets get back to the topic?
 
CIS version: 12.3.4.8162 (last 2025 update released so far)

Test conducted in two parts.

1) CIS with its default config against the poc;
2) CIS with cruelsisters config + tweaks of mine + loyisa recomendations against his poc.

CIS fails in both scenarios. So Comodo did not solve anything related to "some containment issue" as they stated in their poor changelog.

Here is the video:



Ps.: Description and subtitles translated into many languages. If you need more, just say it.
 
Thank you for sharing your test results and the video. It seems like Comodo still has some issues to address. Your feedback is valuable and hopefully, it will help them improve their system. I'll pass this information to the relevant department.
 
If anyone is interested. Here is the new topic about the new cis release against the loyisa exploit/poc.
 
If anyone is interested. Here is the new topic about the new cis release against the loyisa exploit/poc.
 
I see. So the file would probably download something that was really dangerous, but the remote server was down, and that's why CIS doesn't detect anything dangerous. Is that it?

Yes and No. CIS did not encounter the full sample (initial sample + payload) but only the "currently unharmful" part of it (no payload).
Most AVs would detect such a sample as not harmful as I presented in my previous post (sample with changed URL to non-existent payload):
https://malwaretips.com/threads/com...one-malware-not-contained.134116/post-1111332


If that's the case, then something doesn't make sense for two reasons:

1) If you look at VirusTotal now, you'll see that the number of engines detecting only this executable as a Trojan is increasing, and if the supposed remote server is down, it means that the engines are detecting the executable as dangerous and not what it would download from the remote server. Therefore, CIS failed to recognize this file as dangerous.

You are wrong. The increasing number of detections is caused by borrowing detections from other AVs. Look at the detections in my previous post. The submitted sample is as malicious as your sample (no difference for AVs).

2) If the executable isn't dangerous, but rather some file that it would supposedly download, then CIS also failed to identify an attempt to connect to an unknown remote server.
Even if the server is down, the executable hasn't been changed, so it would be trying to connect to this server, regardless of whether it's offline or not. At most, it would try to connect or check if the server is online and if it is not, it would not try to establish a connection. However, some network interaction would still be necessary for this verification and this interaction should be intercepted by the CIS and it should warn about it, which does not happen.

AVs do not fail while allowing silent connections to unknown servers. In this way, most AVs would also fail as can be seen in the detection example from my previous post.

Considering what you explained, one could conclude that this could perhaps be classified as just an undesirable program and not as malware, but the identifications of more than 40 engines make it clear that it is a Trojan.

Yes, the sample should be detected as a trojan when full information about its history is known. CIS failed in some way, just as most AVs would fail in similar situations.

Considering everything you mentioned, a more detailed analysis that was being carried out until a few minutes ago and the results obtained by other engines, I will keep the video online because until proven otherwise, it is malware and Comodo Internet Security was not able to identify anything about it or its actions (or attempted actions), while many others identify it immediately. But I will add an update to the video description explaining this situation.

Or do you think I am wrong in this decision?

It is your video. I would keep the sample and use it to show that such incomplete samples can be problematic in tests (for any AV). With such samples, the AV detection result can depend on the moment when the sample was analyzed and not entirely on the AV capabilities.

Edit.
Still, I do not fully understand why Xcitium can detect by signature the sample with a modified URL, but your sample (which behaves in the same way) was considered Trusted by the Comodo analyst. It is possible that initially, Comodo could detect your sample as malicious too, and that detection would change to Trusted after Valkyrie analysis. :unsure:
 
Last edited:
  • +Reputation
Reactions: simmerskool
Both Comodo defaults and custom settings tests show two files in the unrecognized files section, but nothing in the blocked applications section. Normally, files unknown to Comodo appear in both sections. If files appear in unrecognized files but not in blocked applications, it means that either Comodo already has the files as trusted in the file list or the user has ignored the files in settings. What are the Comodo "lookup" and "logs" verdicts for those two files in the unrecognized list?

Did you restart the system after applying proactive configuration? However, I don't think the PoC is running in the containment, so the test doesn't apply to the released containment fixes.
 
  • +Reputation
Reactions: ErzCrz
CIS fails in both scenarios. So Comodo did not solve anything related to "some containment issue" as they stated in their poor changelog.

Your conclusion is invalid because your video has nothing to do with "some containment issue" solved by Comodo. To see that "some containment" issue was solved, you should run the @Loyisa exploit from the first video.
The Comodo staff did not announce that they solved all of Comodo's issues. The "some containment issue" was related to escape from inside the sandbox. In the current video, nothing escaped from inside the sandbox because nothing was sandboxed. The attack vector presented in the current video is another kind and should not be messed with sandbox escape.

Except for the above, it is a nice video. :)
You are also right that Comodo could improve protection by auto-containing Unrecognized DLLs loaded by Trusted EXE files (like in Windows Smart App Control). However, this would require many additional resources. The bigger vendors like Microsoft, Avast, etc. did not do it too.
 
Last edited:
Non profits , schools and some enterprise use their enterprise product because they claim 100% bs and are cheaper then any alternative
I really like the idea of not full virtualization that comodo does because it uses less performance then virtualization but both their container can be escaped and trusted dlls ,exes ( trusted lolbins) are automatically run without containment while unlike Kaspersky , other av software it doesn't have good behavior detection to help against a bypass as viruscope is awful
I'm still using comodo on most my PCs (usually as a layer) so some bypasses might be stopped by either hitmanpro.alert or ESET on my system or checkpoint threat emulation that I have in the browser extension so I'm safe against 99.99%+ and I usually submit suspicious files to Broadcom before running them using Sample Submission | SymSubmission

But hopefully one day I could use only comodo comfortably if they do improve it as comodo has excellent performance usage and I have one low end 2gb ram with emmc laptop that can't run ESET on it without performance issues nor defender and comodo didn't seem to slow io , use much ram and it's a gift to low end machines making them mostly secure while not having to go chrome os route or any too restrictive policy config

So I definitely find comodo very useful and because it's not perfect if anyone uses comodo use it as a layer if possible with some free av (Kaspersky free, defender , bitdefender free ,avast free etc )
Machine Learning and Dynamic Behaviour Analysis is not good in Xcitium?
1734374705999.png

Bro what are you talking about i see VirusScope performing very good against unknown malware
 
  • Like
Reactions: simmerskool
Machine Learning and Dynamic Behaviour Analysis is not good in Xcitium?

Bro what are you talking about i see VirusScope performing very good against unknown malware

If it is similar to Comodo detections, then it is poor for DLLs. Did you test DLLs?
 
View attachment 286649
@vitao POC is fixed
conversation is done
no, its not and the conversation is not done. comodo can try to avoid this subject but we, users, will not. talk to loyisa and ask him for the latest poc. that is the one im running and latest cis did nothing about it. with default config and with recomended configs by cruelsistes/melih and loyisa himself/herself.

now i would like to ask: why the need of "ending the conversation" when the problem was not solved? what are you afraid of? o.O
 
  • +Reputation
Reactions: roger_m
Your conclusion is invalid because your video has nothing to do with "some containment issue" solved by Comodo. To see that "some containment" issue was solved, you should run the @Loyisa exploit from the first video.
The Comodo staff did not announce that they solved all of Comodo's issues. The "some containment issue" was related to escape from inside the sandbox. In the current video, nothing escaped from inside the sandbox because nothing was sandboxed. The attack vector presented in the current video is another kind and should not be messed with sandbox escape.

Except for the above, it is a nice video. :)
You are also right that Comodo could improve protection by auto-containing Unrecognized DLLs loaded by Trusted EXE files (like in Windows Smart App Control). However, this would require many additional resources. The bigger vendors like Microsoft, Avast, etc. did not do it too.
its the same poc but with changes on the dll and the exe. cis containment did not contain it, nor detect anything. if its the same poc, same problem. so, they didnt solve anything. in fact, the new edition has some regressions, but its not my subject of testing so, i dont care.

edit.: for what loyisa explained its the same technic but with changes in the dll and the exe so there is no need for downloading anything and there is no need for the files to be in some specific place. lets wait for the guy to talk a little more about it.
 
pocv3.jpg


from official comodo forum, in the official topic, from member of comodo team. not me saying nonsense.