Advice Request Comodo and Weaponized Documents

[AtlBo]

Question for any Comodo insider. I have seen the videos and all, but how specifically does Comodo protect from weaponized documents? Does it wait for the download file, does this happen via another mechanism, such as "heuristic command line monitoring".

One other angle on this. I am wondering if Comodo HIPs views activity of MS Office files as unrecognized or as a trusted part of a trusted application.

 

[shmu26]

Comodo has two kinds of script analysis. One is "heuristic command line monitoring". That protects from script files. AFAIK it is the primary protection against weaponized documents. Most weaponized documents will drop a file, and Comodo is good at blocking unrecognized files.

 

[AtlBo]

Comodo has two kinds of script analysis. One is "heuristic command line monitoring". That protects from script files. AFAIK it is the primary protection against weaponized documents. Most weaponized documents will drop a file, and Comodo is good at blocking unrecognized files.

That's what I was thinking. Wish the alert would indicate that advanced heuristics generated the block. For now, I think the alert still shows up as HIPs, but I haven't paid attention to the few I have seen with scripts. I know the setting for heuristic command line was formerly in the HIPs section. Thanks for the reply...

One other thing, not precisely certain of how Comodo handles all this now. Personally, a document should auto-sandboxed in the case where it accesses a script host. I think this is what happens but not 100% sure. As you say @shum26, maybe it is the dropped file, idk. Maybe it's paranoid, but this kind of document should be auto-closed->reopened->auto-boxed no question in my mind. There are a number of little facts about protection of weaponized documents that seem important to get right and as importantly present properly on the alert, etc.

BTW, I am sure this is in one of CruelSister's vids for all to see lol...

 

[shmu26]

I remember several discussions with Sis in which she denied the very existence of "fileless" malware. She maintained that it was a misnomer, and all malware originates in a file. This was before Comodo 10 and its innovative "embedded code detection" that enables Comodo to deal with so-called fileless malware.
In any case, I don't think there was a major difference in CS vids between Comodo 9 and Comodo 10. It's the file-based detection that's doing it. Most weaponized docs are leveraging windows script host, which by default does not even have embedded code detection.
Maybe @Andy Ful has something to say about it.

 

[bribon77]

I remember several discussions with Sis in which she denied the very existence of "fileless" malware. She maintained that it was a misnomer, and all malware originates in a file.

I agree with @cruelsister

 

[AtlBo]

I agree in every case, except it occurs to me that the phrase may be describing the circumstance where there is an exploitable hole in the browser and or OS or other running application. In this case, perhaps the malware can run in the browser or OS app memory and with its security freedoms, but I don't know. I would have no problem calling this fileless. At any rate, these are basically unbeatable with anything but exploit protection. Yet, it seems even successful fileless intrusion will at some point likely generate a file as not many exploit faults would be large enough to allow for sophisticated system manipulation. In the end, I would, therefore, agree with you @bribon77 and with @cruelsister too.

 

[shmu26]

I agree in every case, except it occurs to me that the phrase may be describing the circumstance where there is an exploitable hole in the browser and or OS or other running application. In this case, perhaps the malware can run in the browser or OS app memory and with its security freedoms, but I don't know. I would have no problem calling this fileless. At any rate, these are basically unbeatable with anything but exploit protection. Yet, it seems even successful fileless intrusion will at some point likely generate a file as not many exploit faults would be large enough to allow for sophisticated system manipulation. In the end, I would, therefore, agree with you @bribon77 and with @cruelsister too.

There have been POCs for totally fileless malware.
But the more realistic problem is weaponized files that Comodo can't detect. Let's say MS Word has an unpatched vulnerability. I pack live content in a Word doc that leverages Windows script host to exploit that vulnerability. I can modify the system this way. I might be able to disable Comodo and the AV. Then I can download the payload, and trash the system.

Fortunately, malware coders are lazy and they don't work so hard. This kind of an exploit is difficult and expensive and will be used only in a targeted attack on a high-value target.

 

[shmu26]

Question for any Comodo insider. I have seen the videos and all, but how specifically does Comodo protect from weaponized documents? Does it wait for the download file, does this happen via another mechanism, such as "heuristic command line monitoring".

One other angle on this. I am wondering if Comodo HIPs views activity of MS Office files as unrecognized or as a trusted part of a trusted application.

@AtlBo you asked a good question here, and it doesn't look like you are getting many answers. Maybe the Comodo gurus are on the other forum? I wonder what would happen if you would post your question over there. I for one am curious to hear some informed answers, especially from active malware testers.

 

[AtlBo]

I have considered such, but I cringe a bit when thinking of posting on the Comodo forum. I have a difficult time getting on the same page with the moderators and their answers. Think it's because Comodo's GUI and alerts presentation are so full of undefined gray for me. Also, the help page is fuzzy and of marginal value with regards to details of protection mechanisms. It certainly doesn't inspire novel concepts or ideas with, for example, HIPs. I may still do so, and I will reply back with their answer.

 

[shmu26]

I have considered such, but I cringe a bit when thinking of posting on the Comodo forum. I have a difficult time getting on the same page with the moderators and their answers. Think it's because Comodo's GUI and alerts presentation are so full of undefined gray for me. Also, the help page is fuzzy and of marginal value with regards to details of protection mechanisms. It certainly doesn't inspire novel concepts or ideas with, for example, HIPs. I may still do so, and I will reply back with their answer.

I agree. The official Comodo forum is not the best place for this kind of a discussion. I meant to post on Wilderssecurity.

 

[AtlBo]

I agree. The official Comodo forum is not the best place for this kind of a discussion. I meant to post on Wilderssecurity.

Well, just posted on the Comodo forum basically word for word the initial post here. It should be interesting to hear from them, but I'll consider giving it a go at Wilders a little bit later today. Thx for the tip...

 

[AtlBo]

OK, a solid response from Comodo:

Comodo and Weaponized Documents - Install / Setup / Configuration Help - CIS

If you guys have any questions for them, please dive in any time. I might go astray with Comodo a little bit with these deeper issues...:emoji_fearful:

 

[bribon77]

I think the answer is clear from what I understand.
If the macro tries to execute powershell or other commands, then the embedded code detection will activate and convert those commands into a script file. If a document is specially designed to exploit the vulnerability that allows the execution of the code, then if the payload of Shellcode is programmed to download and execute an executable, then that executable will be made like any other application, for example. HIPS execution alert, auto-sandbox of the exe, etc.

 

[AtlBo]

Yes, that's what I got, and it's more or less bullet proof I think. My question is in memory exploit that is able to do all the work without creating/downloading files. I'm specifially thinking of an exploit of Windows like with Eternal Blue/Double Pulsar. The attacks were stopped when a file was created (VoodooShield and some others). I think Cruelsister did a video on Comodo beating EB/DB can't remember. So the idea is exploited browser attempts to exploit Windows all from memory. I can see Comodo HIPs activating here, but, at the very least, I would like to see an auto-block of the activity, even though Chrome as the example is a trusted application.

I know Comodo HIPs (Safe Mode) will automatically respond if anything attempts to change the memory of anything in the Windows folder, but this is doomsday scenario here. That's why I feel that Comodo, as good as it is, might be able to go a little bit deeper with auto-blocks and maybe some kind of different alert (really a notification) of the block. This stuff is scary, and I know hackers are working around the clock to get to EB/DB types of exploits for then exploiting via meltdown and spectre...

I think heuristic command line on, Comodo is, again, bullet-proof, but you see so many files with so many strange names. For me, so many decisions about these files without some special type of warning and/or auto-block is a recipe for problems. I say so, not because users get too weary or even the risk of a mistake. It's just easy to get lost in all the alerts looking the same. I have numerous times been allowing a sequence of HIPs alerts, only to double-click and allow activity on a following alert which I didn't intend to allow. Sounds like a little thing, but, for me, it's super annoying when you are going to the lengths Comodo requires to keep the run-time environment clean and protected...

 

[shmu26]

If the macro tries to execute powershell or other commands, then the embedded code detection will activate

This will work only if the "other commands" are enabled for embedded code detection. By default, many important script interpreters do not have it enabled. For instance, Windows Script Host does not have it enabled. Cmd.exe does not have it enabled. Mshta does not have it enabled. Clearly, the default script protection is weak, as compared to other advanced security softs such as NVT ERP and VoodooShield and others.

Furthermore, I have yet to see a single test dedicated to embedded code detection. It sounds great on paper, but how well does it work? If you try to trigger it by running various scripts, you will see that its behavior is hard to understand.
For instance, rundll32 is enabled for embedded code detection. But what file type is associated with it? Obviously, this rule is not triggered every time a dll runs. So when is it triggered?
This brings me to the larger question: which LOL bins can be controlled by embedded code detection, and which not? The list is customizable, but we need guidelines for what works and what doesn't.

I personally am not super impressed by Comodo script protection. I rely on Hard_Configurator for that. I tried to get clarification on the Comodo forum, but they turned unfriendly pretty fast.

 

[AtlBo]

This brings me to the larger question: which LOL bins can be controlled by embedded code detection, and which not? The list is customizable, but we need guidelines for what works and what doesn't.

I'm not relying on it HC-L, but I feel like it's the actual beast in the barrel if you will with Comodo. By this I mean, "is it the pivot point around which the whole protection revolves?" For me it seems so, because it is really is the only first defense against in memory script activity from an exploit. This is a super good warning of a potential problem, and, also, it separates the command line activity from the files already on the system->gives the command line its own file, even if the script existed only in memory.

Just for the record, it works. I have scripts that run once in awhile for various things, and they will once trigger the HC-L alert, until I allow and remember. Bascially, a tempscrpt file is created in the Program Data->Comodo->CIS directory. This file is a snippet of the code or whatever, but Comodo won't let the code execute without referencing its rules for the snippet. So Comodo treats the tempscrpt file as a file, and it gets its own rules. As you say @shmu26, none of this is explained to users, even though some may need to take their security to deeper a level.

I am not 100% sure what was meant by the Comodo agent when explaining how to use HC-L with PowerPoint. Otherwise, not having any luck achieving what interested me the most in the thread...that is autocontain of certain types of documents. Think it's kind of an interesting way to think. Obviously a loaded file might be of any type if there is an application that will open the file. However, the common ones are far and away the most widely abused, so. I know I can just sandbox Microsoft Office. I'd still like that to be on a file type basis though.

I suppose I could be creating a completely virtual doomsday scenario for myself from the idea of "in memory" threats. With a program like Comodo, HC-L is not all there is to the protection. I do think its presence helps clear up confusion about the use of cmd.exe and the others that are in the list. So, personally, the protection seems important to me. Anyway, I might look at Hard Configurator for that control @shmu26 so thanks. I don't turn them off, however. By the way, here is the list the way it looks on my PCs. Suprisingly, I get very few alerts from this dialog. Not 100% sure of the dynamic behind the protection. This primarily came from the old bouncer vulnerables list:

 

[shmu26]

I'm not relying on it HC-L, but I feel like it's the actual beast in the barrel if you will with Comodo. By this I mean, "is it the pivot point around which the whole protection revolves?" For me it seems so, because it is really is the only first defense against in memory script activity from an exploit. This is a super good warning of a potential problem, and, also, it separates the command line activity from the files already on the system->gives the command line its own file, even if the script existed only in memory.

Just for the record, it works. I have scripts that run once in awhile for various things, and they will once trigger the HC-L alert, until I allow and remember. Bascially, a tempscrpt file is created in the Program Data->Comodo->CIS directory. This file is a snippet of the code or whatever, but Comodo won't let the code execute without referencing its rules for the snippet. So Comodo treats the tempscrpt file as a file, and it gets its own rules. As you say @shmu26, none of this is explained to users, even though some may need to take their security to deeper a level.

I am not 100% sure what was meant by the Comodo agent when explaining how to use HC-L with PowerPoint. Otherwise, not having any luck achieving what interested me the most in the thread...that is autocontain of certain types of documents. Think it's kind of an interesting way to think. Obviously a loaded file might be of any type if there is an application that will open the file. However, the common ones are far and away the most widely abused, so. I know I can just sandbox Microsoft Office. I'd still like that to be on a file type basis though.

I suppose I could be creating a completely virtual doomsday scenario for myself from the idea of "in memory" threats. With a program like Comodo, HC-L is not all there is to the protection. I do think its presence helps clear up confusion about the use of cmd.exe and the others that are in the list. So, personally, the protection seems important to me. Anyway, I might look at Hard Configurator for that control @shmu26 so thanks. I don't turn them off, however. By the way, here is the list the way it looks on my PCs. Suprisingly, I get very few alerts from this dialog. Not 100% sure of the dynamic behind the protection. This primarily came from the old bouncer vulnerables list:

View attachment 212422

1 Does HC-L mean "heuristic command line" analysis? I am asking because "embedded code detection" is the mechanism that catches the in-memory scripts, whereas "heuristic command line" is for blocking actual vbs files and bat files and PS1 files, etc.

2 Does your extended script protection list work for the added entries, in the cases where it is an in-memory script? I trust "heuristic command line" analysis, which is file-based, but I am interested to know how well "embedded code detection" works.
For instance, I have programs that call rundll32 and pass to it a command line to load a certain dll. Comodo never catches these command lines, but my other advanced security apps do catch them.

 

[AtlBo]

1 Does HC-L mean "heuristic command line" analysis? I am asking because "embedded code detection" is the mechanism that catches the in-memory scripts, whereas "heuristic command line" is for blocking actual vbs files and bat files and PS1 files, etc.

2 Does your extended script protection list work for the added entries, in the cases where it is an in-memory script? I trust "heuristic command line" analysis, which is file-based, but I am interested to know how well "embedded code detection" works.
For instance, I have programs that call rundll32 and pass to it a command line to load a certain dll. Comodo never catches these command lines, but my other advanced security apps do catch them.

No idea on either, @shmu26. I never got so far as you have with the analysis. I added to the list based purely on curiosity and for testing purposes. Now that you make mention of the fact, I have never noticed a single tempscrpt alert from Comodo that wasn't generated by a file based script. Also, I don't recall any activity being generated from any of the processes I added to the list, even file based. I don't personally know of a way to test this at this time.

I use NVT OSArmor to filter all command line at this point. Would you say this is enough to handle the in memory scripts you are referencing? Curious if you would be comfortable saying here in a thread which programs you run that reference .dlls this way. I'd like to know, so I could perhaps test better.

You mention Hard Configurator. Will this application "filter" in memory command lines? I would definitely like to look into this more. I used to value NVT ERP for this. I think this will do as you say with in-memory. One question about ERP, I wonder if there is a way to set v4.0 up to monitor only vulnerables.

EDIT...forgot to say. HC-L is just my vague reference to all of the protections in the "heuristic command line analysis" setting area. Think it's now under "Script Analysis" in "Advanced Protection". Apologies for any confusion. I have both protections enabled for all of the processes for the record as indicated in the picture.

 

[shmu26]

OSArmor is good for most in-memory scripts but it does not monitor rundll32. The same can be said about Hard_Configurator. OSA monitors even scripts running with high privileges, H_C does not. But H_C blocks a long list of file types, at all levels of privilege. 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.

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

I think you can set up ERP the way you want, but check with the ERP gurus. I am out of practice with ERP.

 

[shmu26]

a tempscrpt file is created in the Program Data->Comodo->CIS directory. This file is a snippet of the code

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.