Advice Request Comodo and Weaponized Documents

[AtlBo]

If you see this behavior, it means Comodo is catching an in-memory script. This is "embedded code detection" in action. It was added in Comodo 10. The older "heuristic command line analysis" will not catch an in-memory script and magically turn it into a file. It needs an already existing script file in order to work.
I hope this is clear.

OK, thanks for the clarification. I see numerous instances of tempscrpt with a script that generates a copy of a file, edits the file, and then replaces the file. Once I set the HIPs allow and containment ignore rules for each tempscrpt, Comodo, is quiet about them. This script sequence also references a .bat along the way using cscript and wscript to do the job. The edit is for an application setting .ini that seems to default sometimes. I run the script on a schedule to keep the .ini settings as I require them.

ERP catches the command lines passed to rundll32 to load a dll. Other programs that do this: ReHIPS, Voodooshield, Bouncer.

That's a very solid protection consideration from NVT, considering it's free. Unfortunately, I can't run VS with the scripts I have. It simply will not remember the allow (whitelist) rules I create for the scripts. I tried everything. Even won a year of free VS when Dan ran that giveaway a couple of years back. I tried excluding the folder and everything...still the alerts. Maybe it was something to do with the file drop in the script process.

The script process I have is kind of a nice way to get a look at your protection to see how it is functioning. I can pass the scripts to you if you like with a README. You would have to be able to edit one of them, so that the path of the file to be changed is correct. Also, you will have to edit the text string to be located in the target and then the change to the text to be made. Actually you could use the same phrasing in your target file used in the .ini here and simply do away with any need for this second edit to the script. Just set the value in the .ini (target) to a different value than the one in the .bat script. Next run the .bat and see if the file is edited. If you run it from the desktop, you might even see the drop happen. There is a second file that the .bat references called REPL.bat (short for Replace). It's used kind of like a .dll to actually add the functionality for the change to the very short initialization script. Only requirement for REPL.bat is that is must be in the location of the file to be edited. You could actually just put all 3 files on the desktop no issues.

Maybe I will get a chance to look at ERP 4.0 later. My ONLY issue is that I have ERP 3.1 running and keeping settings in SUA on this computer. No idea why it functions properly in SUA on this one computer, but I can't seem to achieve the same on any other machines here. Won't retain a password or any other settings in SUA. Yes, command lines, but that's all (I know 4.0 fixes this).

I have had the ERP protection disabled for months now, contemplating what to do with 3.1. I don't want to be hasty with a choice, because I'm not sure whether I might start the entire command line dialog over...it's getting a little bit long, etc. 3.1 with the LONG list of vulnerables I have does seem to do what I would like system-wise. Overall, however, it also does seem to bring occasional issues with things like changing from one account to another. This is due to the way it was initially configured. I ran it the first time for about 30 minutes and then turned off the "allow windows processes" rule. At that point, I hadn't changed from one account to another, so some Windows processes weren't auto-allowed. Anyway, CTRL+ALT+DEL seems to bring to the screen the NVT alert blocking things when something along these lines or during boot occurs.

Blocking high privilege scripts protects better against kernel exploits etc, but it can interfere with system processes if the program is missing internal rules to allow safe system processes. The required rules change with time.

This is the money option for me...blocking the high privilege scripts, because I run some software that isn't recognized or loved by the cloud in Comodo. Even with ERP and "Allow Windows processes" turned off, I have been satisfied with the alerts with ERP. I could trust it for command line parsing alerts. Just have to make up my mind about how to use the program and whether I should make the change to 4.0. It's difficult for me to find the time to approach the configuration process thoroughly and properly. Maybe I am beginning to see an opportunity to carve out a little time...just not sure when. In the end, I do not intrinsically like the idea of ERP and Comodo together, but limiting ERP to the monitoring of vulnerables, maybe even just the command line parsers, is an inviting concept to consider for me.

 

[shmu26]

It also references a .bat along the way using cscript and wscript to do the job.

I have seen Comodo perform well with scripts like that, assuming you have the relevant tweaks in embedded code detection, which you do have.

 

[AtlBo]

I have seen Comodo perform well with scripts like that, assuming you have the relevant tweaks in embedded code detection, which you do have.

Based on your experience, it seems Comodo will see this reference but not the reference of rundll32.exe to .dll. That is unusual, considering a reference of a .bat to a .bat is seen. Can't imagine a .dll that isn't considered on some level protected by HIPs at least...

 

[shmu26]

Based on your experience, it seems Comodo will see this reference but not the reference of rundll32.exe to .dll. That is unusual, considering a reference of a .bat to a .bat is seen. Can't imagine a .dll that isn't considered on some level protected by HIPs at least...

Comodo does have dll protection, in a certain mysterious way. In theory, it is supposed to monitor dlls, and block the unrecognized ones, but the actual behavior is hard to understand.

But Rundll32 is about more than just loading dlls. It can do a lot of nasty stuff, because it accepts command lines. Look in the advanced rules of OSA, and you will see some of the nasty things it can do.

IMHO Comodo is set up well to block typical malware attacks, but might fail when it comes to some of the more exotic types. If you tweak it, like you did, the protection is significantly improved. But I wish I knew how much improved...

 

[AtlBo]

IMHO Comodo is set up well to block typical malware attacks, but might fail when it comes to some of the more exotic types. If you tweak it, like you did, the protection is significantly improved. But I wish I knew how much improved...

100% agree. Wish I knew how much this improves protection for sure. Don't think it's on the order of ERP's vulnerables monitoring sadly.

On a completely separate subject, also wish I could explain the scope of vulnerables protection with respect to other settings choices in ERP. For example, does ERP alert activity of a vulnerable even if the vulnerable is listed in the list of allowed processes? This can happen unnoticed in practice under certain circumstances. I haven't been able to verify one way or the other. It's very difficult to organize for a test of these types of little application details, and I haven't been focused on this one issue enough to determine the answer during normal use of ERP.

 

[shmu26]

100% agree. Wish I knew how much this improves protection for sure. Don't think it's on the order of ERP's vulnerables monitoring sadly.

On a completely separate subject, also wish I could explain the scope of vulnerables protection with respect to other settings choices in ERP. For example, does ERP alert activity of a vulnerable even if the vulnerable is listed in the list of allowed processes? This can happen unnoticed in practice under certain circumstances. I haven't been able to verify one way or the other. It's very difficult to organize for a test of these types of little application details, and I haven't been focused on this one issue enough to determine the answer during normal use of ERP.

The new ERP sets the vulnerables to "alert", and this is a stronger rule than "allow". In order to override "alert", you need to make an "exception" rule (I think that's what it is called...)
If you have an alert rule and an allow rule for the same process, the alert rule wins.

 

[AtlBo]

I see, thanks for the information. Very helpful. I have worked only for a few hours on ERP 4.0 on a separate system. System has a flaky motherboard unfortunately, so I can't use it very much until I am able to find a new mb for the old PC. I like what I saw, except that the alerts aren't colored. Perhaps in a later version, at least for vulnerables. Actually, I find the rules options to be a little more than I think I would require. This is a small hold back for me, also. I am basically exclusively interested in the command lines of vulnerables from ERP.

 

[bribon77]

but Comodo has to protect the embedded code.
The only doubt is if it only acts with the HIPS activated

 

[AtlBo]

but Comodo has to protect the embedded code.
The only doubt is if it only acts with the HIPS activated

That's a good question @bribon77. I think it does act, anyway. This one I can test, so maybe I will try. I will set to another profile I guess Firewall and then make sure HIPs is off. If my scripts are alerted I will be able to say.

 

[shmu26]

It does not need HIPS. It is separate.

 

[AtlBo]

Not 100% conclusive, however, here is my surprise finding. I switched to firewall mode, HIPs and containment disabled, and NO alert for the .bat. Then I activated containment to see if that would respond by itself->again NO alert. So then I turned on HIPs in Safe Mode and voila->normal alerts.

One note, I did NOT see an alert for containment, even with Auto-contain enabled. OK, this causes me to question whether there are deeper settings in the "Firewall" profile configuration which are different than "Proactive". Also, maybe it is due to system/settings lag, idk. BTW, I am running version 10 still on this PC, while testing 11 on another. Don't think there is a difference, but...

If this is the way HIPs works in all profile configurations, it's clumsy. If it HIPs is required for heuristics, that would be in another direction clumsy and ugly too. Running Comodo without HIPs would be almost impossible. I would have to enable HIPs and then create a rule to allow without an alert all activity except command line in order to stop the module from blocking. I don't think that would be a simple matter, if even possible.

Something else crosses my mind. The container works for Cruelsister in Proactive mode with HIPs off. There must be a very deep difference between the default "Firewall" and "Proactive" settings profiles. Need to come up with another way to test in "Proactive". I'll look into saving settings and see if I can restore to defaults without too much trouble.

 

[AtlBo]

Reset Proactive to defaults. Set up with HIPs off there is an alert for the most basic of HIPs settings, which is start an executable. Don't know if any other HIPs alerts will appear. Auto-sandbox works just as seen in cruelsister's videos.

So the single HIPs alert will appear in concert with the auto-sandbox alert. I suppose this single HIPs rule will remain active, even though HIPs is off.

Right again @shum26, but ONLY in Proactive mode...

 

[shmu26]

In Firewall mode, autocontainment ignores files that are more than 3 days old. But it will alert for new files and files in suspicious locations. Check the rules and you will see.

 

[bribon77]

It is clear there is a big difference with proactive mode

 

[AtlBo]

In Firewall mode, autocontainment ignores files that are more than 3 days old. But it will alert for new files and files in suspicious locations. Check the rules and you will see.

Ever the fact machine @shmu26. I remember now seeing that setting back in the distant past one time when I was looking at the Firewall configuration. Thanks for the reminder...

 

[shmu26]

So I was trying out Firewall mode for a few days, it is supposed to be a little less aggressive. But I still got HIPS and firewall blocks for things like OneDrive, Chrome, a Windows Defender process, and "system". I got tired of that, so back to my non-Comodo security config, at least for now.

 

[oldschool]

So I was trying out Firewall mode for a few days, it is supposed to be a little less aggressive. But I still got HIPS and firewall blocks for things like OneDrive, Chrome, a Windows Defender process, and "system". I got tired of that, so back to my non-Comodo security config, at least for now.

That's what I never got about CFW. You need to be a Windows specialist to properly identify all the blocked files. For true Geeks only, I guess.

 

[shmu26]

That's what I never got about CFW. You need to be a Windows specialist to properly identify all the blocked files. For true Geeks only, I guess.

It's a mysterious software. No end to the surprises, always more dark crannies, fun to poke around.

 

[AtlBo]

That's what I never got about CFW. You need to be a Windows specialist to properly identify all the blocked files. For true Geeks only, I guess.

Could the specialist do this? I don't know lol. There are so many undetailed filters with little or no envision-able association to the protection scheme in Comodo. It's like someone sprayed a can of invisi-sol on the plate of spagetti. Smells good, but how am I gonna eat it? After I guess 4 years now, I can see why people get frustrated working with the program.

 

[stefanos]

That's what I never got about CFW. You need to be a Windows specialist to properly identify all the blocked files. For true Geeks only, I guess.

And I do not use it for that. It tired me