Thanks, that's true and I get that. I was wondering whether the untrusted file would then still be blocked despite the containment service being disabled.
The Comodo's challenge.
- Thread starter Andy Ful
- Start date
It is advised to take all reviews with a grain of salt. In extreme cases some reviews use dramatization for entertainment purposes.
Nothing will change because the file is not contained.
Thanks.
Yes, the file would not be contained because containment isn't being used and I get that this is still a bypass of Containment as the service is disabled but, am I right in thinking that the Document5 would still be blocked if you changed the setting to not show alerts and just block untrusted files?
Most of the time I prefer that a file is just blocked outright rather than run in a sandbox so I was just checking that this part of the containment element still blocks the untrusted file.
Can you pls test this malware vs 360 and Avast pro sandbox see if they can handle it?
I doubt setting to not show alerts-block would block the untrusted file because, after all, it's a containment/virtualization setting and would require the virtualization service enabled for any action. And from memory: (1) I think that setting applies to only unrecognized files with elevated prompts, and Document5 doesn't require elevated rights. (2) I think to block unrecognized files that don't require elevated rights, you need to set Auto-Containment - Run Virtually (rule) - Action:Block. But I think it won't block Document5 (like it didn't contain Document5 in the tests) with the virtualization service disabled.
I just checked this-
-if you want to "block" unrecognized files rather than contain, set Auto-Containment - Run Virtually (rule) - Action:Block. This setting also blocks unrecognized files with elevated rights, i.e., you don't need to change the containment settings.
-containment setting "do not show elevated prompts-block" will only block unrecognized files with elevated rights.
Nice one, thanks for the clarification. I'll have to look at implementing this block on next install.
It still doesn't solve the bypass but if at least the Document5 is blocked from running even though containment service is disabled, that's at least useful.
Interesting. Thanks for the info. Comodo is that configurable, I was trying to look at it from a different angle. The problem with LOLbins is even if you'd created a File Group in File Ratiing settings for all the system32 LOLBins and set as untrusted or unknown you run into all sorts of issues.Document5 will run without a problem (as I already explained).
Anyway, well done for bringing this to light and hopefully it's something that can be improved on in CIS / CF to protect itself from such attacks.
That's true. I'll experiment with adding all the LOLBins and then enable Embedded Code detection in batches to test out the impact.
Do you know how many LOLBins are in the system?
Do you know how many programs trusted by Comodo can be used instead of LOLBins?
Over 500 and just because a file is trusted doesn't mean it's allowed access everywhere. Just look at explorer.exe that gets a HIPS block when you import a configuration with hips enabled. What there needs to be is a rule or built in protection for Comodo files and processes but I can only see that being capable with HIPS or a separate containment rule. I'm testing Beta 3 now so will just see what options there are but at the end of the day I can always just harden the system with one of your programs and I'm covered
EDIT: I like to try and find solutions to things and so far not finding one within CIS but I'm not a programmer or expert, just enjoy what programs like this can do. I like my current MD/DefenderUI/CyberLock/WFC configuration but when some new bypass is identified, I like to see if I can find some sort of a solution with in the program itself as a temporary fix until Comodo comes up with a solution. Anyway, got to get on with work.
Last edited:
Hopefully he decides to share the attack details onces it's patched by a few vendors but seems he is afraid it would be used in malicious ways
(Personally I love project zero 90 day policy as it forces devs to fix the issues)
btw the excuse of because a human executed the file and it gained privileges (this case by the user and not an exploit)
Is ridiculous windows is very prone to escalations and memory based attacks (overflows)
F
ForgottenSeer 109138
Only sharing with the product devs is the responsible thing to do with such an item.
Best Practice for a person (or cat) that writes a new malware file is to never ever share it routinely and not even distribute it to a VT or similar as doing so could potentially lead to unforeseen consequences.
Even sending the exact file to a developer is not necessary as long as some explanation and video evidence of the attack is shared. That would normally be enough for those with the eyes to see (and for those still blind sending the actual file may still be of little value).
In the case of Comodo, weaving the malware with the UAC and Admin override along with the payload and trigger into a single file to be run without detection may be a bit more problematic (just sayin').
Even sending the exact file to a developer is not necessary as long as some explanation and video evidence of the attack is shared. That would normally be enough for those with the eyes to see (and for those still blind sending the actual file may still be of little value).
In the case of Comodo, weaving the malware with the UAC and Admin override along with the payload and trigger into a single file to be run without detection may be a bit more problematic (just sayin').
I agree with @cruelsister. It is not a problem to bypass the Comodo protection in the cruelsister settings and without the UAC bypass.
If I would try also to apply the UAC bypass, the attack could be contained by Comodo. I think that such an attack would also require lateral movement or exploiting a legal application.
In my opinion, the attack can be dangerous in targeted multistaged attacks on organizations. The idea is kinda similar to the attacks that abuse Microsoft Defender's exclusions.
If I would try also to apply the UAC bypass, the attack could be contained by Comodo. I think that such an attack would also require lateral movement or exploiting a legal application.
In my opinion, the attack can be dangerous in targeted multistaged attacks on organizations. The idea is kinda similar to the attacks that abuse Microsoft Defender's exclusions.
Last edited:
It's somewhat paradoxical that the attack without the UAC bypass might be easier to execute against home users. Most home users would kindly ignore the UAC prompt and run the file. Anyway, several more popular attacks make this particular one unlikely at home.
Last edited:
Comodo is blocking users from there forums who is trying to give suggestions and feedbacks for the improvement of the antivirus engine and realtime protection and overall protections for there upcoming CIS 2024 stable release, really concerning and not good at all. Recently some of my friends got blocked. They are arguing a lot when suggestions were given to them for improving the antivirus and then banning .
Attachments
You may also like...
-
-
This ransomware bypass every antivirus and removes antivirus- Started by HydraDragonAntivirus
- Replies: 59
-
-
Why Don’t Major AV Vendors Use Auto-Containment Like Comodo?
- Started by NoveyBoy
- Replies: 23
-
Protect Yourself From the macOS Flaw that Bypasses Apple Privacy Controls- Started by lokamoka820
- Replies: 1