After importing ESET HIPS rules (KB6119) high severity HIPS events are recorded

[carmik 0]

I've imported and applied an ESET-provided HIPS rule to our LAN clients, as per KB6119. After doing so I'm bombarded by the following event types:

• C:\Windows\System32\cscript.exe trying to start C:\Windows\System32\cmd.exe
• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe trying to start C:\Windows\system32\ipconfig.exe
• C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe trying to start C:\Windows\System32\Conhost.exe

This behaviour seemed similar to the one described in:

 However, my own clients are normal PCs which are not connected to AzureAD but rather to our local AD servers (2019). Around 30 out of 120 systems are triggering this policy at the moment. Since I have just applied, I expect this figure to rise. I must say though that this policy has not been triggered on any of the IT stuff client systems. Which is a bit worrisome, suggesting that this might be something more than false positives.

I'll try to raise logging level as per the thread above, but I'd be grateful if someone could provide better instructions on how to do it.

Edited September 15, 2021 by carmik

[Marcos 5,074]

Of course importing the extra HIPS rules may generate tons of alerts or false positives especially in an environment where scripting is heavily used. The rules are not intended for everyone but rather for those who know how to react in case of false positives.

[carmik 0]

That's understood. However, in my setup it's not one or two systems generating alerts, but about half of my installed base, meaning I'd have to disable the rule completely until finding a way to tune it somehow. Otherwise, this policy defeats its merits, at least on my installation.

For example, I was blocked while interactively starting installation of the Microsoft windows installer cleanup utility (blocked wscript).

[Marcos 5,074]

As I mentioned, the rules are expected to be triggered seldom or often based on what scripts that you use do. If you get too many alerts, it's better to disable a particular rule if it cannot be tuned up, e.g. using a permissive rule for files or processes that you use.

[carmik 0]

12 minutes ago, Marcos said:

If you get too many alerts, it's better to disable a particular rule if it cannot be tuned up, e.g. using a permissive rule for files or processes that you use.

I'll follow that approach most likely.

[itman 1,659]

9 hours ago, carmik said:

After doing so I'm bombarded by the following event types:

• C:\Windows\System32\cscript.exe trying to start C:\Windows\System32\cmd.exe
• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe trying to start C:\Windows\system32\ipconfig.exe
• C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe trying to start C:\Windows\System32\Conhost.exe

Let's review how to resolve this. First, note that HIPS allow rules take precedence over ask or block rules.

The conhost.exe startup issue resolution from powershell.exe was discussed in the thread you link in your posted. A HIPS allow rule would have to be created to allow conhost.exe startup from powershell.exe.

Likewise, I don't see a major security issue allowing powershell.exe starting ipconfig.

As far as cmd.exe startup from cscript.exe, it will create a security vulnerability.

The problem here is the "stone age" feature capability of the Eset HIPS. One missing feature is the direct monitoring  of script execution. That is the capability to create for example, a rule to allow cscript.exe to execute a given script by name. This could be facilitate by allowing command line specification feature; e.g. wscript.exe scriptname.ws.

Note that Eset allow action is global in nature. In this case, the allow of the script execution, if possible, would allow cmd.exe within the script to also be executed.

-EDIT- Also the Eset HIPS needs whitelist capability in regards to scripts. Any scripts listed there would be allowed to run regardless of existing HIPS block rules in regards to their associated script engine executable's.

Edited September 15, 2021 by itman