Comodo Firewall-Harden with Heuristic Command Line Additions

Is there a good way to do this?

I have been asking myself for a long time how the heuristic command line monitoring works. What I would like to know most is whether there are applications that could be added to harden this type of monitoring. I have enabled all of the protections, including embedded for all the default applications in the list already. Can’t remember if the java exes are added by default. They are there in the list, but I many have added them. However, I don’t know if java script can be monitored this way.

More specifically, do the applications have to be a script host to add any protection or can adding other vulnerable processes make sense? For example, if I added something like vssadmin.exe or vssvc.exe, would I be alerted every time the process was found in a command line? There are a large number of processes in Windows like forfiles.exe and attrib.exe that could be a part of some script. Been trying to understand this for a couple of years now.

One other thing. In proactive in Comodo Firewall, is it true that command line heuristics only alert when a file is unknown? That makes sense I guess, but I like to keep up with what is happening on a system, so that’s why I am asking.

Thanks for any practical assistance.

What I would like to know most is whether there are applications that could be added to harden this type of monitoring
That depends if those other applications are capable of executing non-exe files and carrying out actions defined in those non-exe files.
Can't remember if the java exes are added by default. They are there in the list, but I many have added them. However, I don't know if java script can be monitored this way.
Java is added by default and is used to execute .jar files, javascript files executed locally is handled by default by wscript.exe
More specifically, do the applications have to be a script host to add any protection or can adding other vulnerable processes make sense? For example, if I added something like vssadmin.exe or vssvc.exe, would I be alerted every time the process was found in a command line? There are a large number of processes in Windows like forfiles.exe and attrib.exe that could be a part of some script.
Again it depends if they process files and perform actions on behalf of the non-exe file that is passed to its image command-line.
Again it depends if they process files and perform actions on behalf of the non-exe file that is passed to its image command-line.

I noticed that forfiles, which I have in a script for deleting logs, brings a notification with HIPs. forfiles is not signed even though it is a default MS\system32 file. As unsigned it is unrecognized normally, and the alert is expected. OK, so I guess command-line heuristics in contrast is not an “unrecognized” and/or “abusable” execution notifier based type of monitoring like with HIPs. It’s just…unrecognized is wanting to use a script engine…allow the tempscrpt, yes or no?

Not to harp on another’s software, but there is software by a small developer team that is kind of interesting. It allows a user to identify potentially abusable processes and then see a stop alert EVERY time the process runs standalone or is started by any other executable. At time of alert, user can allow and/or whitelist the activity by the command-liine that started the process. This means that even standard startup of a program from start menu, etc., can be monitored (and monitored as command-line) and its run activity wholly monitored and approved by command-line (also with knowledge of the parent)…even the startup of the program. Playing with that program to learn about command-line monitoring, I learned it is important what I classify as “abusable” (another term is used in the application) with that app, because it causes alerts. But, it is possible to see down inside the system when setting a hefty number of well constructed “abusables” and not many alerts really. Well, command-lines can also be whitelisted with support of wildcards, which is a whole another topic.

Just thinking about this now, it’s really interesting with regard to HIPS how Comodo HIPs doesn’t monitor the execution of the unrecognized app with the single command-line method, instead it focuses on what the app should be allowed to affect (via HIPs rules). The HIPs brings the possibility of exclusions, while the other app brings whitelisting via command-line monitoring. Yes, HIPs is more powerful o/c, but the command-line approach has helped me keep tabs on things. I suppose I was really wanting to see if I could ditch the other app. Seeing the command-lines is so valuable in terms of knowledge, however, that I don’t think so for now.

Is it true then to say that Comodo command-line heuristics is write based rather than execution based->no command-line heuristics alert/stop until there is an attempt to write? If so, then I guess I need to focus on executable apps for inclusion in heuristic c-l monitoring that could potentially issue a command line associated with writes rather than exclusively on potentiality for abuse of the app by another application. Or maybe I could say that command-line heuristics is sort of an extension of HIPs, in that it produces and alert based on the execution by unrecognized of a script or script contained within a file which leads to a write. HIPs then monitors the tempscrpt.

I really need to understand to visualize this type of under the current protection from Comodo. I have trusted some scripts I run, and I think command-line heuristics played a part in the original alerts for them (tempscrpts), and script in the .bat files is tempscrpted. So I guess that means the heuristiic command-line monitoring is handling them.

One other thing. In proactive in Comodo Firewall, is it true that command line heuristics only alert when a file is unknown? That makes sense I guess, but I like to keep up with what is happening on a system, so that's why I am asking.

I guess this is a no brainer looking at it a second time. The other program I mentioned turns my head around about Comodo, causing me to lose sight of the meaning of unrecognized. With the other program, I say which programs/apps are alerted every time (for the command line responsible for its start) and I get the alert every time…simple. With Comodo via HIPs, I decide which programs a program/app can start with command line monitoring there to monitor for script activity from the program/app->all for all unrecognized apps…idk maybe this is it ;D

I would like to get a meaningful dialog going on this topic. Not afraid to be totally off base, and I would like to understand the protection scope of the heuristics module. Don’t want to add a bunch of processes that have no potential for adding protection.

Thanks for taking the time to reply. Going through this issue is giving me a deeper appreciation of the choreography in Comodo…

Let me show you how command-line analysis and embedded code detection as it works for CIS. Create a new text document on your desktop and then open it, then use either process hacker or process explorer to find notepad in the process list, double-click on that notepad process and go to the general tab/image tab and look for the section called command line. If you have to maximize the process properties window to see the full contents of the command line for notepad. You will see the file path to notepad followed by the file path to the text document. With command-line analysis CIS will take the file that is passed to an applications command-line and use that file as the basis for HIPS, firewall, and auto-containment when the application is added to command-line analysis setting.

With embedded code detection CIS commands passed to an application are turned into a script file that gets treated like any other executable. For example open a command prompt and type powershell -c get-date and press enter. You will notice CIS turns it into a script and a HIPS alert will ask if you want to allow cmd.exe to execute C_powershell.exe_C66C06BE2EC4CBF37532B227506E4E19B256E0E9.ps1

In both cases the file hash is looked up in Comodo File Lookup Service (FLS) to see if hash is found to be trusted, malicious, unknown, or never seen before.

I understand what is happening, generally, but thanks for your patience. The above post is very clear and concise and well constructed. Thanks for that. Handling of command-line is tricky for me.

Please just take all this below with a grain of salt. Take a look when or if you have time and feel like doing so and then respond whenever. Thanks for the help so far. There seems to be a number of ways to say the same thing with command-line monitoring. Also, it seems easy to trip up when learning someone’s language for dealing with command-lines.

With command-line analysis CIS will take the file that is passed to an applications command-line and use that file as the basis for HIPS, firewall, and auto-containment when the application is added to command-line analysis setting.

By this I presume you mean simply that the process begins for the user to white/blacklist the application in the modules if the process is not trusted/recognized. This is why it makes sense to me to always run unrecognized in the container. Something can open harmlessly one time and then with potentially harmful command-line the next. I see how Comodo still has your back, though, considering any new file introduced by command-line activity will also have to be trusted in order to be of any malicious use and so on. Only problem would be if the program itself contains the malware or malicious instructions and then if the program has been issued trusted status by the user. OK, I think I get why this is a type of command-line monitoring with Comodo.

Back to the original question…so, unless an application is a script host, does it make sense to add the application to the heuristic command-line list of monitored applications? My understanding is, based on the first run of standard heuristic command-line analysis and based on the command-line of an application, user will configure security for the unrecognized application started as required and white or blacklist behaviors or whatever. Thereafter, in terms of this first type of monitoring, the command-line is irrelevant to the handling of the host (now trusted) application. Host might do something funny like execute a macro and then try to drop an executable and start it, but the chain restarts. This time it’s all about that executable. All the protections seem to be here, so I am a little bit fuzzy on how adding an application to heuristic command-line protection list would add much, unless the process were a script host/interpreter that could do something with the script->an interpreter object for the activity. Seems Comodo has added some new ones over the last several months, based on the risks they pose in this way I suppose.

The embedded I think of this way. You have already allowed everything to the point of the script alert (at least once). This includes any standard command-line analysis alerts that may be been generated. Comodo catches a recognized (for all practical purposes…at least allowed) and running application attempting to pass command-line to a script host. Operand of the script is captured and then kept in a tempscrpt file and becomes an unrecognized executable (to Comodo). I understand that part. I suppose then Comodo uses the file containing the operand to verify/allow that particular operation when it passes through the system…if user has allowed the script activity. Any other operands that show up in the script must be validated later in a separate tempscrpt I believe would be correct (important and I believe this is true). So, in the case of embedded monitoring, I’m really unclear about whether adding a process for monitoring for this type of activity would accomplish anything…unless it were a script host. I am kind of inclined to say that it seems to me that the list is really all about objects that can interpret and execute code…not about vulnerable processes. To protect vulnerables, I would need to set up some kind of process class for that, I suppose, and then handle it with the sandbox. Anything that starts->vulnerable process list->run in sandbox. This is a really interesting twist to me on HIPs potentially. Add a HIPs box for monitoring categories for this and then to the GUI a setting option, maybe something like a setting to protect the system from abuse of vulnerable applications->Sandbox/block/etc. Then block or exclude just like with the other HIPs categories.

I had picked up on some of the essentials of what you have said about both types of detection. I know where the tempscrpt folder is located and preview new detections (would be good to see a way to do this from the alert in CIS/CF btw). I would like to make two clarifications about HIPs, however:

  1. Does standard command-line monitoring work if HIPs is off? I know the setting was previously in the HIPs section of the program.
  2. Does embedded command-line monitoring work if HIPs is off?

You said that the files are sent to the various modules, but if HIPs is off I just want to clarify that the protection is still functional from Firewall and Containment. I’ve had this question for awhile and just never had time to ask.

unless an application is a script host, does it make sense to add the application to the heuristic command-line list of monitored applications
Yeah if it is not an interpreter for scripts then it won't really matter.
unless the process were a script host/interpreter that could do something with the script->an interpreter object for the activity
Bingo, executables such as wscript.exe, python.exe, cmd.exe, powershell.exe, etc are capable of doing just about anything when the script they process/interpret has code to do such actions. e.g. modify the file system or the registry, connecting to the network to download/upload files or data, etc. More importantly these interpreters are trusted and therefore you wouldn't normally under default settings be alerted by any action they carry out as a result of executing the contents of a script file. Now if the host process was not trusted then it wouldn't really matter if it was added to command-line analysis because the interpreter executable would either be auto-contained or generate HIPS alerts for any action it carried out by a script it is executing.

Embedded code detection was designed to cover cases where a trusted application was exploited to execute commands of a trusted command interpreter, e.g. powershell or the command prompt. Say you visit a website that exploits a new unknown vulnerability in your web browser, then instead of the payload being to download another executable which might get caught by the users security software, the payload is to execute commands which because the interpreter is also trusted, you wouldn’t know this was happening. Unless you set HIPS to paranoid mode to see the web browser attempting to execute powershell or whatever interpreter that is installed on your computer.

So again if an application doesn’t process commands that makes the application do certain actions then no it wouldn’t be necessary to enable embedded code detection for that application. Take python for example, it can either execute python code written inside a .py file or you can execute python by the command line by doing python -c ‘python code here’

1. Does standard command-line monitoring work if HIPs is off? I know the setting was previously in the HIPs section of the program. 2. Does embedded command-line monitoring work if HIPs is off?

You said that the files are sent to the various modules, but if HIPs is off I just want to clarify that the protection is still functional from Firewall and Containment


Yes both command-line analysis and embedded commands will both work even if HIPS is off. You could turn off every component and you would still see script files populate the file list and tempscript files will also be created in the tempscript folder along with being listed in the file list. Of course you have to select show all types from the drop down menu in the file list to see them, by default the file list is set to show executable files only.