Auto sandbox bat file of cis

This one worked for me

Yes, it works, but a little too well. It defeats the entire command line protection.

If the parent process is trusted and/or allowed, why its scripts are detected as unrecognized?

For example, with CIS 10 in Safe Mode I see the file C_powershell.exe_RANDOM_NUM.ps1:

"& """C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.VisualStudio.Debugger.JustInTime,version=15.0.26208.0\RegisterJustInTimeDebugger.ps1""" -Operation Uninstall -Inst

But Visual Studio is from Microsoft Corporation, that is a Trusted Vendor.
I’m seeing similar behaviours with git .exes, google drive nativeproxy.exe…

That’s because it does not identify parent process.

@futuretech provided a nice explanation/scenario in a similar topic.

Thanks for the explanation.
I understand that it is difficult to automate anti-exploit features, but this way everything is limited (whether an app is exploited or not) until the user unblocks manually. This is not an anti-exploit.

The need is clear, but the realization shows great design flaws.

Whilst I can see the merit of trapping unwanted and non-understood pieces of code I don’t think that creating a bat file within a folder structure which makes it clear to novices that it needs to be investigated is really that helpful. First of all it is in a CIS\tempscrpt folder, which on the face of it suggests it might be something that CIS needs on a temporary basis. Add to that the only option you have is to Unblock doesn’t help the case much. Even for somebody who might have some idea of what they are doing, the necessity to use a explorer to access the files is still fraught as they could be kicked off by double clicking them.

If these files really are unsafe then put them in a folder which suggest just that and don’t give them the ability to be run unless some specific and deliberate action is taken.

By default, the new version of Comodo turns off embedded code detection for cmd.exe.
This was causing most of the problems. So new users should be okay, until they get experienced enough to mess with the advanced protection settings.

Comodo CIS should be able to analyze its own .bat files that it creates to be able to put them on the white site so as not to generate an alert.
In addition, it should not take too much time to make a trusted whitelist based on the lines created and sorted by type and publisher.

I seem to be getting this same problem again with “Application Contained: CMD has been blocked” but I can’t find the setting for this in CIS v12.

Can somebody direct me to where this setting is now?
It was originally “Embedded Code Injection” but it no longer seems to exist, even though I have the same hiccup with it.

Hello MatrixShield,

In the general window of CIS 12, there is “Applications blocked” …

You click on it and you have the list of what CIS has blocked.

The problem is that if you allow for the future, it does not matter…

Advanced Settings > Miscellaneous

Thank you Ploget,

I chose to put Sticky Password in the list of exceptions, but that does not change anything… :-\

Nothing to do with script analysis/embedded code detection, it is caused by the new auto-containment rule to block files belonging to a file group when they are launched by web browsers.

I see. It was the embedded code injection that was causing the alert before and preventing the addon from working in my browser previously. I had to disable it in order for it to work.
That same issue has started again with v12 and only just recently (I have primarily been using FireFox for a long time and just been using the other Chromium based browsers for things I need, hence me running into this again.

In the interest of maintaining security, how would I go about preventing this with v12?
Do I just need to select “Do not isolate again” in the prompt?

Personally, I select “Do not isolate” in the prompt, but at each reboot, it’s the same problem …
In addition, it’s the same problem with all installed browsers … Chrome, Chromium, Firefox, Drago, and Ice Dragon …
I contacted the support of “Sticky Password” which generates the error, but no change … Neither on their side, nor on the side of Comodo …

It’s been a couple of months now and there has been no response or fixes to prevent this from being an issue.

Can anybody provide any insight or guidance as to how to prevent this problem from being a problem?

As stated I had fixed this previously but following the update the problem has returned, seemingly due to a different cause even though the behavior and result is the same. Any help here?

After finally getting a chance to have a mess around and test, the Auto-Containment of Pseudo File Downloaders File Group started by Web Browsers File Group (as was stated by @futuretech) is the culprit.

Disabling this rule (found at the bottom of the Auto-Containment section which is set to block by default) makes this problem vanish.

However, what would be the risks imposed by disabling this rule?
Is there a way to keep this rule enabled but with an exception for this extension?

Still an ongoing problem here with this issue.

Nobody has been able to inform me of how I can prevent this from being an issue, or what sort of risks could be made with disabling this rule?

disable auto containment if you dont use it