High severity HIPS event detected - how to work out cause?

[PuterCare 3]

I downloaded the recommended HIPS policy, uploaded to PROTECT and applied to one of my OUs. Since then I have received several of the same message from a few endpoints:

Source application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Executed operation: Start new application
Target: C:\Windows\System32\Conhost.exe
Action taken: Blocked

These are AzureAD joined laptops, the only agent on them is Eset and the only other unusual thing I can think of is an Outlook add-in that inserts email signatures.

I enabled "Log all blocked operations" in the policy but after the next email notification was received I ran the log collector task on that endpoint but there was nothing listed in the Logs, Diagnostic, HIPS section of PROTECT.

I spoke to the users and they did not see anything strange other than the Eset pop-up and had not ran anything themselves. One user said it happened as soon as they signed into the laptop. 

Is there a local HIPS log on the machine that I can view and work out what might be causing this? 

Thanks

[Marcos 5,074]

You should be able to solve it by disabling the rule "Deny child processes for powershell.exe".

[PuterCare 3]

1 minute ago, Marcos said:

You should be able to solve it by disabling the rule "Deny child processes for powershell.exe".

I figured it was probably a false positive but my thought was if Eset recommend those policies then best keep them in place if possible so I was trying to work out the cause first to see if it was anything important. Are there logs I can view on the local machine? Thanks

[itman 1,659]

First, what is conhost.exe:

Quote

The conhost.exe (Console Windows Host) file is provided by Microsoft and is usually legitimate and completely safe. conhost.exe needs to run to allow Command Prompt to work with Windows Explorer.

https://softwarekeep.com/what-is-conhost-exe

I have had this Eset Powershell HIPS rule in place for ages and never received "a peep" from it.

One example of conhost.exe starting from PowerShell.exe is when it is deployed by PowerShell Empire used maliciously:

Quote

Registry Run Key Persistence Testing

The PowerShell Empire powershell/persistence/elevated/registry* persistence module executes once the successful user logon takes place. In this test, I used the default settings of the module. I used Process Hacker to actively monitor the successful execution of the Run registry key persistence. Once executed, I confirmed the new persistent PowerShell Empire agent session was established on the C2 server.

Figure 1 – Registry Run Key Persistence Executed

https://www.trustedsec.com/blog/who-left-the-backdoor-open-using-startupinfo-for-the-win/

Edited September 13, 2021 by itman

[PuterCare 3]

Thanks for that info. Yesterday I tried to replicate the same issue on my system by rebooting and signing in but nothing happened, but this morning I have received the same message. I went into my Eset HIPS log and it is listed but doesn't have any more info than what was in the email alert from PROTECT. 

I browsed to the StartupInfo dir in that article but the latest date modified was yesterday.

I can just disable the rule but I like to try and work out the cause first, just not sure how I can do that in this case. I can compare what services each system runs and what startup items there are and look for clues. If it triggered on every boot then would be easier as I could adjust my startup items to test.

[Marcos 5,074]

You could create a permissive rule based on the rule "Deny child processes for powershell.exe" and add the path to conhost when specifying the path to target applications which would be safer than disabling the rule completely.

[PuterCare 3]

Thanks, I will try that. I just tried to run powershell and it was blocked by Eset with the same message so looks like something is running powershell in the background and it will trigger the rule. Not sure what that might be, a safe Windows component perhaps. 

[PuterCare 3]

I have gone into event viewer, the event is in the Eset log at 08:00:15 so I have filtered the Application and System log to only show 07:59:30-08:00:20 but the only event shown has a source of "Security-SPP" and details "Offline downlevel migration succeeded.".

Any ideas where else I can try to work out the source of this? I will set up the permissive rule anyway as I need access to Powershell.

[PuterCare 3]

I am unable to edit my last post, I added an allow policy for powershell to start conhost and now I can run powershell. Still not sure what was happening in the background to trigger this.

[PuterCare 3]

It is possibly connected to a Lenovo service such as one that Lenovo System Update runs, these are all Thinkpads. When I run System Update manually I get a lot of blocked processes. Could be unrelated but that is one thing all these endpoints have in common.

[itman 1,659]

4 hours ago, PuterCare said:

I am unable to edit my last post, I added an allow policy for powershell to start conhost and now I can run powershell. Still not sure what was happening in the background to trigger this.

I erred in my original posting in this thread.

I didn't implement Eset's recommended anti-ransomware HIPS rules per se. Rather, I made them more secure which suits me personally. One of the revisions for example is I monitor all Windows script executable's startup via a HIPS ask rule. This includes PowerShell.exe startup. As such, there was no need to use the recommended rule of monitoring all child process startup from PowerShell.exe.

To use PowerShell legitimately, it must be allowed to start conhost.exe since it is the graphical interface element for PowerShell.

[itman 1,659]

Per the above TrustedSec article I linked to, the below is indicative of malicious conhost.exe usage. Eset HIPS rules do not have command line specification capability, so there is no way to monitor for its usage:

Quote

For me, the cool part here is the command line output that was successfully captured from the PowerShell registry Run key and payload executions. I was also interested in the \??\C:\WINDOWS\system32\conhost.exe 0xffffffff -ForceV1 execution and came across this stackexchange post that explained the execution to be affiliated with, “If there is no session attached to the physical console, (for example, if the physical console session is in the process of being attached or detached), this function returns 0xFFFFFFFF.”

[carmik 0]

@PuterCareI'm running into some similar issues, as outlined in

If you manage to find something that actually helps you here, please drop me a line!

[PuterCare 3]

It is possibly connected to a Lenovo service such as one that Lenovo System Update runs, these are all Thinkpads. When I run System Update manually I get a lot of blocked processes. Could be unrelated but that is one thing all these endpoints have in common.

I am also now receiving a lot of alerts for Powershell running dismhost.exe, I assume this could be Windows updates. After it gets blocked once, it gets blocked again but on each occasion the target is a different folder in the temp dir i.e.:

Source application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Executed operation: Start new application
Target: C:\Windows\TEMP\876F365A CA98 4687 91F5 43B7FAE16537\dismhost.exe

I also have wscript.exe trying to start cmd.exe. I am just concerned that some of these may be malicious processes, when I get time I will try to tweak with permissive rules or otherwise may just need to remove the policy.

[carmik 0]

Two thirds of my systems are dell optiplex desktops, whereas the other third consists of HP desktops.

No dism so far...

[itman 1,659]

4 hours ago, PuterCare said:

I am also now receiving a lot of alerts for Powershell running dismhost.exe, I assume this could be Windows updates. After it gets blocked once, it gets blocked again but on each occasion the target is a different folder in the temp dir i.e.:

Source application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Executed operation: Start new application
Target: C:\Windows\TEMP\876F365A CA98 4687 91F5 43B7FAE16537\dismhost.exe

To begin, dismhost.exe running from the user temp folder is OK.

I monitor dism.exe execution via Eset HIPS and the only thing that starts it on my Win 10 20H2 installation is cleanmgr.exe running from a Microsoft set up scheduled task.

The above said, PowerShell usage is "baked into" Windows and is used internally for many OS functions. As such, it is entirely possible Windows internally is initiating the above activity you posted. As I posted previously, I monitor all Powershell.exe startup via Eset HIPS. I also monitor my Windows Powershell event logs and I have multiple daily event log entries showing PowerShell running to perform required system maintenance activities. Also, I have never once received an alert from my Eset HIPS Powershell start up rule in regards to this activity. So however Windows is running Powershell in the background, the Eset HIPS doesn't detect this activity.

Bottom line is I have seen enough to state that the recommended Eset HIPS rule to monitor child process startup from Powershell wasn't thoroughly tested and should not be used.

Edited September 15, 2021 by itman

[carmik 0]

8 hours ago, itman said:

Bottom line is I have seen enough to state that the recommended Eset HIPS rule to monitor child process startup from Powershell wasn't thoroughly tested and should not be used.

I'll follow that route most likely, thanks!

[PuterCare 3]

10 hours ago, itman said:

To begin, dismhost.exe running from the user temp folder is OK.

I monitor dism.exe execution via Eset HIPS and the only thing that starts it on my Win 10 20H2 installation is cleanmgr.exe running from a Microsoft set up scheduled task.

The above said, PowerShell usage is "baked into" Windows and is used internally for many OS functions. As such, it is entirely possible Windows internally is initiating the above activity you posted. As I posted previously, I monitor all Powershell.exe startup via Eset HIPS. I also monitor my Windows Powershell event logs and I have multiple daily event log entries showing PowerShell running to perform required system maintenance activities. Also, I have never once received an alert from my Eset HIPS Powershell start up rule in regards to this activity. So however Windows is running Powershell in the background, the Eset HIPS doesn't detect this activity.

Bottom line is I have seen enough to state that the recommended Eset HIPS rule to monitor child process startup from Powershell wasn't thoroughly tested and should not be used.

Thanks for your time on this thread, I have disabled the powershell rule now. 

I have one remaining alert that only affects one Endpoint therefore it is possible this is a malicious process:

Source application: C:\Windows\System32\wscript.exe
Executed operation: Start new application
Target: C:\WINDOWS\System32\cmd.exe

I will see if I can find any clues in event viewer about this one. 

[PuterCare 3]

I've resolved this one now, in scheduled tasks I found "USER_ESRV_SVC_QUEENCREEK" which was set to run at logon. It would use wscipt.exe to run C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.vbs. That VBS file contained:

Set objShell = CreateObject("WScript.Shell") 
objShell.Run("C:\WINDOWS\System32\cmd.exe /c ""C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.bat"""), 0 
Set objShell = Nothing 

And task.bat just contained - "C:\Program Files\Intel\SUR\QUEENCREEK\x64\task.exe" 

Unsure why it is such a messy way to run task.exe. Uploaded the exe to Virustotal and it was clear. Removed Intel Driver and Support Assistant and Intel Computing Improvement Program, set Energy Server Service queencreek service to manual. The scheduled task was removed when uninstalling the software. 

[carmik 0]

8 minutes ago, PuterCare said:

I've resolved this one now, in scheduled tasks I found "USER_ESRV_SVC_QUEENCREEK" which was set to run at logon.

Very interesting! Have to ask: how did you isolate this task. That is, how did you go about investigating the cause of this?

[PuterCare 3]

5 minutes ago, carmik said:

Very interesting! Have to ask: how did you isolate this task. That is, how did you go about investigating the cause of this?

A bit of luck to be honest, I was looking through the event logs and nothing was of interest. I looked at the local Eset HIPS log to see if it happened at particular time intervals and it seemed random. I then went through scheduled task library looking at the action tab of each task hoping to find wscript.exe or a vbs file and I found this one. I then enabled history for the scheduled tasks, checked what the script did, checked the exe was clean and then ran the task manually which caused an alert to be sent and an entry was added to the HIPS log. I then searched the task name in Google to work out what it was for, looked in programs list and removed the Intel software and set the service to manual. 

I'd love to know if there was a more surefire way to diagnose these were the script not to be set up in task scheduler for example.

Edited September 16, 2021 by PuterCare

[itman 1,659]

For installations that employ scripts in daily use, I would recommend that Eset firewall rules to prevent ransomware be deployed: https://support.eset.com/en/kb6132-configure-firewall-rules-for-eset-endpoint-security-to-protect-against-ransomware . At least, the rules that apply to the Windows script processes; i.e. wscript.exe, PowerShell.exe, etc.. Then remove the associated HIPS script rules added. If one is using scripts that by design establish remote connections, it is much easier to create Eset firewall exception rules to allow that activity by IP address.

In regards to above, the objective is to prevent 0-day, in-the-wild, ransomware attacks. A number of these attacks use scripts to establish a remote connection to the attacker's C&C server to download the ransomware payload. The payload is then deleted from the targeted network after files are encrypted. This activity's objective to avoid having the payload discovered on the targeted network in effect, ending the ransomware use in future attacks.