and thats the “payload”…
Delivery Mechanism vs Payload are two different things.
What matters is to make sure no Payload can execute outside containment.
1 Like
1 Like
Redstraw-I see what the problem is, and it is actually a VERY IMPORTANT point which sadly I never touched on in any of my previous videos but just released one here:
3 Likes
I was supposed to write yesterday just too, because I also checked this sample and it turned out that it is a matter of settings in the CIS, that’s why such discrepancies.
Yeah, Comodo is so elegantly coded that unlike other anti-malware products simplest is the best. Use my settings and be free.
2 Likes
@cruelsister Here it is. I have mentioned in my original post, that ALL the advanced protection functions are enabled. The sample is still not contained, which is different from yours. Have you tested the sample I sent you?
Just my 2p on this one.
I see you have two files as Exclusions in Script Analysis which needs clarification:
Can you advise what folders you have in Containment Do not virtualize…
You didn’t show your HIPS settings though that doesn’t matter.
Oh and you clicked “Allow” on the two alerts:
You also need to Reset Container to confirm if changes permanent.
-
The last two items in the exclusions of the antivirus module are different from the tested sample.
-
The “Do not virtualize access to the specified files/folders” items are default.
-
In the HIPS pop-up, the parent .js is the tested sample, and the child .js file was previously created in the startup folder by the sample (CIS didn’t take action to prevent/notice the creation operation in the startup folder or contain the test sample). Although allowed here, the child .js file can be contained successfully.
What I am concerned about in this post is why CIS didn’t take action to prevent/notice the creation operation in the startup folder and auto-run registry entries, as well as contain the test sample. I think the startup folder and the auto-run registry are very important locations that should be protected. Even though Melih emphasized that only limiting the loaded file can prevent damage to the OS and data, as bad files have been created in the startup folder and registry entry, they may start up with the OS.
I think autosandbox was not triggered and startup entry was created since the js file had a trusted verdict from comodo at some point. Probably not a bug or sandbox bypass in CIS code.
(Screenshot taken from video by Redstraw given below)
Exactly! The same applies to this sample: 14 security vendors and no sandboxes flagged this file as malicious & Comodo did not detect it also - Comodo Forum
As they were, they are still protected.
The issue is whether the executable file is trusted in the cloud or unrecognized, if the file is unrecognized, depending on the rules, actions will be taken against this execution.
It might be that it’s listed as Trusted in the File List for some reason.
Yes. They are listed in the protected objects.
As I found RedStraw’s issues to be a bit concerning, along with the sample he provided I included 2 other similars as well as some other .js and.jar (with Java Runtime installed for the latter jar malware) confirmed malicious files. Also included was the file Tachion mentioned in Post 21.
I proceeded as follows: both on W10 and W11, for both the currently released version 12.2.2.8012 and the Beta Build 8088.
In each case the setup was:
Configuration- Proactive Security
Containment- Enabled at Default
Hips- Enabled at Safe Mode
File Rating- Disabled
VirusScope- Disabled
In all if the js and jar files that I ran would get this initial Containment Block (so nothing actually went into Containment as the thingies were precluded from activating
(the executable from Tachion Just went into Containment to die).
However, when I disabled Containment I did see the a couple HIPS popups like this
which is the prelude to Payload drop and AutoStart modification.
So, for whatever reason it seems that in RedStaws case Containment did not activate. For any that would like to test if Containment is working without screwing around with malware, the 22.01 build of 7=zip which can be found here should work:
https://www.7-zip.org/download.html
I normally would make some sort of video at this point, but sadly I went Roller-Skiing in preparation for the coming Ski Season and fractured my wrist (surgery this afternoon and they will die if a scar is left!).
3 Likes
@cruelsister Thank you for continuing to follow up on this issue and wishing you a speedy recovery.
Strangely, I don’t know what goes wrong with the CIS in my case. I have noticed that the latest antivirus database can detect it. If the containment won’t work in such situation, the detection can play a role. Many thanks again 
W10 Famille - 22H2- 19045. 3324/ CFW : 12.2.2.8012
FW: safe mode, Auto-containement: enable, HIPS: safe mode, VirusScope: enable
When I download the zip and want to open the file, this popup appears:
If I click on “Block” this message appears:
If I Choose “Run in the container” my administrator pwd is required to run the program.
I didn’t get any notification and I noticed this message afterwards:
Cool-that’s exactly what should occur as the file, although totally legitimate, is not signed.Just wanted to verify that Containment on the system worked as a prelude for those not getting Containment for the J-Script malicious file previously discussed.
1 Like
Strange situation. Opening a zip archive should not launch the 7-zip installer.