Learning more about HIPS rules and scope

[Parsh 0]

I would like to understand a few things about the HIPS rules and scope:

1. Does enabling option "Modify State of Another Application" include monitoring and asking/blocking of process hollowing and other ESET-known process injection techniques, among the in-memory attack detection that the option resembles? 
2. What HIPS rules (if feasible, and what could be their scope if used) can be used when surfing the web, to always ask/block (1) all detected drive-by downloads and (2) various in-memory attacks (ESET-HIPS-known)?
3. Does the HIPS in Smart Mode alert of very suspicious activities of unknown/less reputed applications only, or are trusted applications monitored too?
4. Do the new parameters (Aggressive/Balanced...) for the "Suspicious applications" in the Detection Engine tab belong to the Deep Behavioral Inspection/HIPS, or no?
5. I've set "block" rule for "Modify State of Another Application" to protect Edge and Vivaldi. Everytime I start the browser, I get a notification "svchost" blocked because of this rule. Can someone explain in short why svchost needs to do this and is it safe to let it be blocked? In the sense if this is a windows security mechanism that is being broken.

I'm aware that ESET by default monitors for browser exploits, known process injection mechanisms and such. However, my questions revolve around whether hard HIPS rules can be set to deal with the same and get ask/block alerts in respective cases above. I have set rules with these regards, however not sure about the scope and efficacy.

Eg. If a trusted application has been maliciously modified (say supply chain attack) and a part of it does something unexpected, something malicious. Will that be monitored and likely alerted about?

Eg. In the browser case, I'm trying to figure out if ESET HIPS rules could more or less achieve what Excubits MemProtect application does. To cage internet facing app processes like the browser and prevent other processes from modifying its memory/ perform code injection. And also not allowing the browser to do so with other processes (exclusion to allow the browser, browser_proxy & the updater to modify the browser...)

Thank you very much!

 

[Marcos 5,074]

1, It's a highly technical information intended for programmers. I'm not sure if it could be answered publicly and possibly the behavior could change over time via module updates. You could raise a support ticket to find out more.
2, I'm afraid I don't get your question by detected drive-by downloads and what downloading files should have to do with HIPS. Downloaded files are scanned by Web access protection.
3. No.
4, The settings have nothing to do with DBI or HIPS.
5, Since svchost is a system process, I assume you should ask Microsoft to find out what exactly svchost does when a browser starts.

[itman 1,659]

I'll answer two of these questions.

3 hours ago, Parsh said:

Does enabling option "Modify State of Another Application" include monitoring and asking/blocking of process hollowing and other ESET-known process injection techniques, among the in-memory attack detection that the option resembles? 

Most definitely. Have yet to find something that can get around it.

3 hours ago, Parsh said:

I've set "block" rule for "Modify State of Another Application" to protect Edge and Vivaldi. Everytime I start the browser, I get a notification "svchost" blocked because of this rule. Can someone explain in short why svchost needs to do this and is it safe to let it be blocked? In the sense if this is a windows security mechanism that is being broken.

First, Eset HIPS is not a "full feature" HIPS along the lines of Comodo's Defense+ or OutPost's now default HIPS. The Eset HIPS lacks features such as a Trusted Publishers feature and the like that auto allow trusted System processes and the like.

"The rub" is when you start monitoring a process for modification, you also must also manually create allow rules for trusted processes that do likewise. This means you must have the technical knowledge to know what those trusted processes are and if its normal activity for them to perform such modification. And in reality, it doesn't end here. Those trusted processes could be possibly be injected by malware, so those should also be monitored ........ ad infinitum.

Most browsers are sandboxed; e.g. Edge's AppContainer, or run at low Integrity level which prevents malware from infecting the rest of the system. There are also products designed for this like Sandboxie although it appears, its days are numbered.

Edited March 28, 2020 by itman

[Parsh 0]

12 hours ago, Marcos said:

1. It's a highly technical information intended for programmers. I'm not sure if it could be answered publicly and possibly the behavior could change over time via module updates. You could raise a support ticket to find out more.

I agree about the technicality part. However I believe this is not a sensitive info. I wondered about this since Kaspersky's 'Application Control' rights customization for individual apps has a section of "Intrusion into other processes" that states "Perform code injection" and "Modify memory of other processes" as two different sub-entries, among others.

Hence, whether code injection is a part of the "Modify state of another application" or not in ESET HIPS is doubtful but important to learn for a user relying on the same.

12 hours ago, Marcos said:

2, I'm afraid I don't get your question by detected drive-by downloads and what downloading files should have to do with HIPS. Downloaded files are scanned by Web access protection.

Sorry about having complicated my query. It's not about files a user downloads and that get scanned by the static engines.

Whether some HIPS rules can be made to prevent different in-memory attacks to some level (limited to the scope of ESET's knowledge)?

An analogy could be that, say if I block browser from "starting new apps" and from "modify memory of other processes" etc, it would probably limit/block browser attacks from affecting other processes ie. non-browser processes. This - by creating a wall, instead of just detecting specific attacks and allowing the rest of activities not known as malicious.

12 hours ago, Marcos said:

3. No.

You answered the latter part? means that activities of trusted/reputed processes are not monitored by Smart Mode right?

12 hours ago, Marcos said:

5, Since svchost is a system process, I assume you should ask Microsoft to find out what exactly svchost does when a browser starts.

Sure thing. Thank you. I see it's a common scenario with browsers and blocking it doesn't affect the browser usability at least.

Edited March 29, 2020 by Parsh

[Parsh 0]

  

11 hours ago, itman said:

Most definitely. Have yet to find something that can get around it.

Thanks! I have read quite a few observations of yours on WS. However, I see a lot of them were about you experimenting with custom rules

11 hours ago, itman said:

First, Eset HIPS is not a "full feature" HIPS along the lines of Comodo's Defense+ or OutPost's now default HIPS. The Eset HIPS lacks features such as a Trusted Publishers feature and the like that auto allow trusted System processes and the like.

"The rub" is when you start monitoring a process for modification, you also must also manually create allow rules for trusted processes that do likewise. This means you must have the technical knowledge to know what those trusted processes are and if its normal activity for them to perform such modification. And in reality, it doesn't end here. Those trusted processes could be possibly be injected by malware, so those should also be monitored ........ ad infinitum.

Most browsers are sandboxed; e.g. Edge's AppContainer, or run at low Integrity level which prevents malware from infecting the rest of the system. There are also products designed for this like Sandboxie although it appears, its days are numbered.

Yes. I do that. While I've restricted modification (some checkmarks from file ops and some from application ops) of browsers and browsers from modifying others, some actions like the updaters and msedge_proxy are allowed to modify the browser. And the browser is allowed to only start print spooler. Similar thing with WPS Office. I will confirm the svchost thing from MS support. 

Allowing svchost to modify browser in usual case could be fine. But as you rightly said, the svchost could have been maliciously injected and it might be difficult to categorize it even keeping a watch on svchost (perhaps not if you have a profound knowledge about the activities). Ad infinitum for sure! I try to compensate by monitoring firewall connections of such processes (possible attacker-victim chain) carefully. I have limited for sure, but decent idea of the uses of such system processes and related services.

I had read that "AppContainer" flag has been set default in chromium browsers and the optional is GPU-AppContainer Lockdown. However, PE or PH does not show integrity of any browser process as 'AppContainer", except for the GUI process that is set when the optional "GPU AppContainer Lockdown" is turned on.

Sandboxie now has its processes set to untrusted, so better than before. It's not being actively developed but a very occasional fixes is a sight from Sophos. I have been contemplating - if using the "Application operations" from the HIPS rules settings on the browser processes could more or less act like a sandboxie replacement.

[Parsh 0]

Hello folks! I could not gather an explanation regarding point 5.

I wonder whether svchost is

• just launching a service required by the browser OR 
• trying to inject a DLL
  • indirectly required by the browser itself OR
  • Windows Security does it (though I've removed exploit protection rules) OR 
  • done by ESET (eplgChrome.dll / eOppMonitor.dll) ... 

The last point is mostly not the case because if the 2 DLLs failed to load due to Code Integrity Guard (now disabled), I used to get an error that I now don't. The browser works well. My concern is that an essential security mechanism should not get broken.

ESET generates a similar alert that svchost is trying to modify Adobe Reader process space when launching it.

@itman I tried allowing svchost to modify the browser, and protecting it from modification - this as you say, could be ad infinitum. I am however not getting any alert that a process is trying to modify an svchost process.

Have you set rules to block other processes from modifying the browser or vice versa? If yes, could you share an insight into that and the exceptions you've used? Thank you.

[itman 1,659]

15 hours ago, Parsh said:

@itman I tried allowing svchost to modify the browser, and protecting it from modification - this as you say, could be ad infinitum. I am however not getting any alert that a process is trying to modify an svchost process.

Have you set rules to block other processes from modifying the browser or vice versa? If yes, could you share an insight into that and the exceptions you've used?

At the stage you are presently at with the HIPS, all I can say is "everything is trial and error" in regards to what you are doing. Hopefully, you won't bork your OS operations in the process.

To quote an American saying, "I've been there, done that, and ain't going there again."

Edited April 25, 2020 by itman

[Parsh 0]

On 4/26/2020 at 4:54 AM, itman said:

At the stage you are presently at with the HIPS, all I can say is "everything is trial and error" in regards to what you are doing. Hopefully, you won't bork your OS operations in the process.

To quote an American saying, "I've been there, done that, and ain't going there again."

 It's almost always trial and error when you dig deeper where potential is unlimited.

Thank you! I am keeping rules tested over a few weeks and the system is doing fine. Backups are on point. I do not like to keep fiddling with the rules, to be able to focus on my work projects. But every once in a while your hand itches to improve on something. I'm always open to learning from other's experiences 😄