Advice Request Comodo Embedded Code Detection -- How does it work?

[shmu26]

Does anyone happen to know how Comodo's embedded code detection actually works?
Sometimes it creates a script file, but doesn't actually block the action. Sometimes it doesn't even create a script file. And sometimes it does what you would expect: it creates a script file, and blocks the action.
This varied behavior has been confirmed on the Comodo forum, but after their terse explanations, I am still puzzled.
I can open a powershell console and enter a command to launch MS Word, and no script file is created.
I can open ConfigureDefender and change WD settings (this is done by powershell cmdlet) and it creates a script file, but does not block the action.

 

[Eddie Morra]

I don't think even COMODO knows.

Is this feature only present for Windows 10 systems? If so, then it probably works via AMSI.

I've never heard of the feature though, so I don't know.

 

[shmu26]

I don't think even COMODO knows.

Is this feature only present for Windows 10 systems? If so, then it probably works via AMSI.

I've never heard of the feature though, so I don't know.

It was before AMSI, as far as I know it works on all Windows systems. It began with Comodo 10, a couple years ago.
When a monitored app, such as powershell, runs a script, Comodo reads the script, writes it to a text file, and puts that text file in a special Comodo folder. If the script meets certain parameters, the script will be blocked, via the text file. It's not really a .txt file, but you can open it with notepad and read it in clear text.
That's about all I know about it.

 

[shmu26]

So forget about how it works -- can somebody tell me what is expected behavior?
What are the parameters of the scripts that it is supposed to block?

 

[Eddie Morra]

@shmu26

1. Run PowerShell.exe.
2. Do anything.
3. Check if a file was made for the script.

If Yes to 3, check the modules of PowerShell.exe in Process Hacker / Explorer... is there any DLLs from Comodo present?

I'm just curious as to whether they RCE into script interpreters or not - even if there are no DLLs present, it doesn't rule out them injecting because they can do it without a DLL file-lessly, but most AV vendors aren't going to go to the trouble of doing that to hide the injection and Comodo don't do it for their HIPS so I doubt they would for this if they are.

 

[shmu26]

I reinstalled Comodo and looked into embedded code detection a little further.
I have two corrections to make.

1 I described the scripts as being saved in a text file. This is not correct. They can indeed be opened in a text editor, but they are saved in the appropriate script format. If it is a cmd.exe script, it is saved as .bat. If it is a powershell script, it is saved as .ps1.

So apparently, what Comodo does is it writes the command line to a script file, and blocks the script file. Neat trick. Comodo is good at blocking files.

2 I wrote, "Sometimes it creates a script file, but doesn't actually block the action."
This, too, is not correct. I initially did not see any sign of blocking or breakage when running certain scripts, but when I retested it, and looked more carefully, I discovered that the scripts did not succeed in performing their task.

@Eddie Morra I am not so experienced with process hacker/explorer analysis. It is normal for Comodo to inject dlls into processes, and I would have a hard time telling the difference. I think a more experienced tester needs to take this one on.