Bypass CIS build 8088 by creating high-risk items in startup entry

  1. Sample: VirusTotal

  2. CIS version and configuration:
    Configuraion: COMODO Proactive security
    Antivirus: Enable
    HIPS: Enable
    Containment: Enable
    Firewall: Enable
    File Rating: Enable
    Advanced Protection: Enable

  3. Testing and result:
    Running the sample.
    Two .js files were created in the folder appdata\roaming.
    A .js item was added in startup C:\Users\test\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
    A wscript item was added in the registry …currentversion\run

1 Like

1 Like

Interestingly, it’s recognized as clean via Human Expert Analysis Overall Verdict. :rofl:


Lets define bypass:
Execution of malicious code with unfettered access.

Putting an entry in the startup on its own is not maliciuos but it might be linked to executing a code that is maliciuos…So its one step before the “bypass”.

There is a “delivery mechanism” and there is a “Payload”…
this JS you are talking about is the “delivery mechanism” it is NOT the “Payload”…

Payload is where Comodo kicks in by taking any “unknown executable” and running it in “containment”.

So try to get this JS to put some known or unknown malicious code at the start up and see if that code can by pass the system. That would be a good test.

How Comodo Innovation protects you even when Detection fails - #3 Here is a video explaining how it works.

after 5 months (First Submission
2023-03-29 on VT ) added detect :laughing:
Signature Based Detection 2023-09-03 15:20:45 Malware

@Petrovic Yes. It seems that the verdict is maintained by the Xcitium team. I reported this bypass in the Xcitium forum hours ago. Half another ago I was updated by the staff that this issue had been rechecked and flagged as malware.

how does this JS cause harm on the action it does?

Delivery vs Payload

Payload is what causes maliciuos activity.


I have a different result. The sample isn’t contained automatically here, which is different from yours. Hence those entries were added to the mentioned folders and registry. But the dropped file can be contained by the sandbox.

Hi cruelsister,

Thank you so much for the time and effort you took for this video.
Thank you for supporting us.


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: Redstraw


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.


Love your videos @cruelsister


@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.

  1. The last two items in the exclusions of the antivirus module are different from the tested sample.

  2. The “Do not virtualize access to the specified files/folders” items are default.

  3. 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)