Auto sandbox bat file of cis


I always get messages about auto isolation of bat files. (see screenshot).

It appears they belong to CIS but are not recognized. Is it normal?

I have default settings.

Thanks ahead.

It is an intended behavior.

See this:

Understood, thanks!

It happens every time I open Chrome browser.

Does it say that my browser is infected??

I don’t think sandboxing CIS’s own scripts is an intended behavior. It just like saying that sandboxing CIS’s own executable files is an intended behavior(if it happen).
CIS should be smart enough to put its own scripts in trusted file list instead.

This is a new feature we have introduced to catch fileless malware. Fileless malware uses script interpreters such as powershell.exe to execute code through commandline. There are various ways. What CIS 10 does is it catches embedded commandlines and sandboxed them.
But while sandboxing them, we create a file out of them i.e. convert file-less scripts into files in C:\ProgramData\Comodo\Cis\tempscrpt. If is the command-line interpreter

CIS is not sandboxing itself, CIS converts a file-less script into a file, then sandbox that file (created by CIS, but which belongs to another app, the app that generated the file-less script)

To see embedded code detection in action open up a command prompt and run this

cmd /C echo hello

or from a command prompt run

powershell -Command Get-Date

You could then go to the tempscript directory to view the scripts and see that they contain the above commands echo hello and Get-Date

Yeah… its just the adobe acrobat reader plugin…


this is a very impressive feature. I like it.

does anyone know how code detection is triggered?
It doesn’t happen every time you run a script.
For instance, if I open the command prompt and run “tasklist /SVC”, or I open powershell and run “date”, there is no code detection

TaskList is not an internal command. It’s an external command supplied by external executable.

it is very annoying that comodo isolates “c_cmd.exe” and a pop up window appeares.

Is it possible to stop it???

How can I stop that the window shows that c_cmd is isolated?

Thank you for helping me.

Normally, you check the unrecognized files (in File List). To be more exact, the ones located under %ProgramData%\COMODO\Cis\tempscrpt. If appropriate, you change its rating to Trusted. Optionally, you can submit it for whitelisting like any other file.
If you do experience problems and you are unable to solve these with previous method then you can disable Detect embedded code detection option in HIPS.

I’ve just encountered an annoying problem with this after installing CIS v10.

I was using the previous version but decided to upgrade to the latest and greatest by uninstalling the old version of CIS and installing this new version.

But now, every time that I start any Chrome-Based browser that I have installed the StickyPassword plugin to I get a notification about a batch file being sandboxed and I can’t use the plugin.

It doesn’t matter how many times I close and re-open the browser after setting the batch file to trusted. Every new execution of the browser ends up with a new unique batch file.

I have looked into the Detect Embedded Code Injection but I don’t even have HIPS enabled. Tried disabling it anyway but it made no difference.

The plugin is trusted by Comodo, just as the whole of StickyPassword is. But this is stopping the plugin from being able to “Talk” with the main program so the plugin doesn’t work.

A little help to stop this would be great as I have lost all functionality and access to my database due to this behaviour.

Your best bet would be to create an ignore auto-sandbox rule. You can do this by typing in the file location box under criteria: C:\ProgramData\Comodo\Cis\tempscrpt*.bat

This rule will prevent the auto-sandbox from sandboxing bat files created by the chrome extension.

I suspect it’s a different issue/question (not related to current discussion) if disabling embedded code detection has no effect.

Just tried doing as you suggested and it still occurs.

I even went so far as setting it to not virtualize access to the entire folder and its contents, but it still produces the popup stating that it has been sandboxed and prevents the extension from being able to talk with the main program.

Starting to feel this way myself.
I’m going to look at getting a bug submitted for this and see what they say.

Thanks for your feedback, guys.


I’ve just done some further testing and managed to stop this from happening.

I don’t know if I have altered a setting, but this is dependent on the Enable Embedded Code Detetion under HIPS, correct?

HIPS is disabled but Enable Embedded Code Detection was enabled (even though I had felt for sure that I had disabled it previously to test - possible that I may have clicked the cancel button by mistake).

I have disabled Embedded Code Detection again after removing the exclusion of the tempscrpt folder from virtualization and I no longer get this issue.

Note: This is with HIPS being disabled. I can enable Embedded Code Detection to have this occur, and disable it to prevent it.

I am not sure if this is intended behaviour. I assumed that disabling HIPS also disables all child features of HIPS. But this now makes me a little wary of any risk of exposure to malicious scripts that Embedded Code Detection was designed to detect, especially as I never had a problem with this enabled in the previous version of CIS and that it seems to work independently of HIPS.

Any further information would be greatly appreciated.

Thanks in advance.

It is intended behavior.

Hope it helps.

(as untested alternative) You could try excluding “StickyPassword” from “Detect shellcode injections” option under HIPS. Could you kindly confirm if it works?

Thanks for clearing that up. I assumed but assumed wrong :slight_smile: I’ll have to bear this in mind if I run into any other oddities regarding other settings. Thanks again.

Just tested that right now.

I enabled “Embedded Code Detection” again and included the whole StickyPassword folder as an exclusion in “Detect Shellcode Injections”.
Executed the browser and it still intercepted the script and sandboxed the batch file. Extension not functional.

Closed the browser and executed it again after enabling HIPS itself. I got a prompt asking me what I wanted to do with the batch file that was created so I allowed it. The execution of the batch file continued but was sanboxed, as before.

I disabled HIPS again after closing the browser, executed the browser once more as a final test but same result.

It looks as if the only way to stop the StickyPassword extension from being blocked in a Chromium based browser is to disable “Embedded code Detection”. The StickyPassword extension doesn’t encounter this issue in Firefox.

The batch file in "C:\ProgramData\Comodo\Cis\tempscrpt" is “C_cmd.exe_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.bat” with the “x” being a random series of alphanumeric characters - a new file is created with every execution of the browser.

The script is as follows:
C:\Program Files (x86)\Sticky Password\spNMHost.exe" chrome-extension://kaafoaobjaplofpihlhbcbcjhmgnjplf/ --parent-window=0 < \.\pipe\ > \.\pipe\chrome.nativeMessaging.out.xxxxxxxxxxxxxxxx

The “x” here are alphanumeric characters that change for each new batch file created.

Solving this one could be a headache for the developers, but I’m sure they could ■■■■■ it. For now though, it looks like I just have to keep the “Embedded Code Detection” checkbox unticked for now.