Andy Ful
From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
- Dec 23, 2014
- 8,188
- Content source
- https://youtu.be/2aQS22ZuR8c
Can Comodo's Auto-Containment be bypassed?
They are not superior, they are necessary to allow the self-protection to observe kernel-level system calls, as well as suspicious memory manipulations and patching that can allow anything, from unhooking user-mode processes, thus tampering with behavioural blocking, to completely terminating security services.Kernel drivers are not the de facto decisively superior way to provide protection; anyone that says they are probably has an agenda and cannot be taken seriously.
Untrusted is the maximum restriction and allows very limited access rights compared to Restricted.Cruelsister's config, sandbox is set to "Restricted" not "Untrusted". But I don't know if it would make any difference.
@Andy Ful
My thoughts on watching this are that if a unknown file executed a cmd or svchost or any other program that could execute the code to disable the virtualization that both the unknown file an any process or file launched by that unknown file would be Contained. Sure, a user can run that cmd line they create on their own but do we have an example of malware or unknown file executing that code and successfully disabling containment?
This POC is no different than Cruelsis examples as she modifies them to bypass other products claiming them to be subpar.@Andy Ful Nice test of Comodo. It's impressive seeing that the Containment can be disabled by a cmd file.
My thoughts on watching this are that if a unknown file executed a cmd or svchost or any other program that could execute the code to disable the virtualization that both the unknown file an any process or file launched by that unknown file would be Contained. Sure, a user can run that cmd line they create on their own but do we have an example of malware or unknown file executing that code and successfully disabling containment?
I'm guessing most people would have clicked Fix to rectify the Comodo issue but useful to know that it's possible to disable the service and that Comodo doesn't pick this up with it's behaviour features. Hmm.
No.Hi @Andy Ful
not that it's crucial because the damage was already done, but would clicking on the Comodo "Fix It!" alert have aslo restarted the Comodo stopped service, or no?
Would it have made any difference if HIPS was enabled?
Would an HIPS alert be generated in this attack to alert the user that some application is tampering with the service?
Cruelsister's config, sandbox is set to "Restricted" not "Untrusted". But I don't know if it would make any difference.
Thanks!
1. From memory, some versions of Comodo had issues in VirtualBox. I don't know about the current stable and beta builds.
2. It seems you tested on Windows 11. It would have been better to test the latest beta build, which fully supports Windows 11.
3. I don't remember if Comodo notifies, but the configuration change to Proactive requires a system restart for proper functioning. I hope you restarted the system.
@Andy Ful Nice test of Comodo. It's impressive seeing that the Containment can be disabled by a cmd file.
My thoughts on watching this are that if a unknown file executed a cmd or svchost or any other program that could execute the code to disable the virtualization that both the unknown file an any process or file launched by that unknown file would be Contained. Sure, a user can run that cmd line they create on their own but do we have an example of malware or unknown file executing that code and successfully disabling containment?
Btw, I'm guessing big box anti-malware products could be bypassed in similar fashion with a customized bypass manually elevated by the user, or am I wrong in this assumption?
Xcitium is the best AVI think so. But as with many such attacks, this attack vector can be stopped via behavior-based detections after the first successful campaign.
The demo video looks to be that of a user thinking they are manually installing a legitimate program/app, and they have administrative rights to elevate the malicious file I_am_nice_and_clean.dat (LOL). In this case the auto-containment is bypassed innocently by the user. Maybe there's more to the malicious chain reaction than just the dat file(??), but that was all we can see.
Was the service stopped prior the reboot by the fileless attack (a pending service stop operation) or stopped by the fileless attack after the reboot? How would the fileless attack survive the reboot?Yes, if HIPS is not configured to allow cmd[.]exe.
No application is tampering with the service. The attack is fileless after Windows restart.