Jump to content

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


carmik
 Share

Recommended Posts

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 by carmik
Link to comment
Share on other sites

  • carmik changed the title to After importing ESET HIPS rules (KB6119) high severity HIPS events are recorded
  • Administrators

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

  • Administrators

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by itman
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...