Jump to content

Question about AVC real-world test


Recommended Posts

13 hours ago, 0xDEADBEEF said:

One solution is to constantly monitor the behaviors of untrusted programs even when it is in-flight

As I see it, there are two issues with Eset.

The first are the existing default HIPS rules. They appear to adequate in regards to detecting activity against system files, directories, and registry areas targeted by malware. They are lacking in detecting process memory modification activities such as dll injection and the like increasingly being deployed by malware.

The second issue is a "disconnect" so to speak in equating process reputational status to what type of HIPS monitoring should be performed.

In regards to the existing AMS protection which is post-execution detection, it appears primarily an anti-exploit mechanism and is geared toward memory heap spraying and like activities commonly used by exploits. Also for detecting packed and obfuscated code that decrypts in memory.

The solution as I see it is that HIPS monitoring status is conditioned by process reputational status. If an unknown application process starts execution, not only are the default HIPS rules applied but additional default rules applied to detect global hooking, application debugging, event interception, and application state modification by the unknown process. An unknown process is defined to be one that is unsigned, has an unknown hash value, and has never been LiveGrid ranked by Eset users. Any or all of the three previous criteria would be user selectable in determining what is an unknown process.

Link to comment
Share on other sites

Here's another "pet peeve" of mine that Eset refuses to budge on.

Below are links to two recent studies about fileless malware. The Symantec report was just published. The Trend Micro report was issued last month.



Both reports site specifics of PsExec,  a valid Microsoft signed utility process, being used maliciously. These instances are far from the ones in existence. Eset will let this utility run unchecked and unimpeded.

PsExec has no business being installed on an average home user PC. Additionally, it can run from any directory where it is downloaded to.

So one wants to create a HIPS rule, where the targeted process is C:\*\PsExec.exe to monitor/block its execution. Well, home users still can't do that since Eset's HIPS doesn't allow for file wildcard support! This request has been repeated ignored by Eset.

Eset - "get with program!" 

Link to comment
Share on other sites

  • Administrators

The problem is that malware could drop psexec under a different name to bypass such HIPS rules with wildcards. Only a true application control would be the ultimate solution. We've been working on HIPS which is also why wildcard support has not been added yet. We want to deliver true and complete solutions, not just partial ones and therefore some tasks have lower priority than others.

Link to comment
Share on other sites

On ‎7‎/‎18‎/‎2017 at 4:42 AM, Marcos said:

The problem is that malware could drop psexec under a different name to bypass such HIPS rules with wildcards

True for unsigned apps. But PsExec is a Microsoft code signed app. Also doesn't apply to situation where I would want to monitor for particular file extensions such as *.scr, etc..


On ‎7‎/‎18‎/‎2017 at 4:42 AM, Marcos said:

Only a true application control would be the ultimate solution. We've been working on HIPS

I assume this means a whitelist/blacklist scenario. The existing HIPS training mode just has to modified by developing a feature that would create an allow process startup rule for all existing processes. The user would then switch to interactive mode at which time an alert would be generated for any process startup for which a like existing HIPS does not exist. 

The above processing could be "conditioned" to monitor for Windows system and app update processing and auto switch to update training mode noted in below no. 5) until that processing is completed.

As far as non-Windows based app installers and updaters, those again could be conditioned on optional reputational determination methods such as signature status and/or, positive hash matching and LiveGrid status. The key point in this area is I want control over what is or is not allowed by reputation or if the feature is employed at all.

The above is far more advantageous than the existing HIPS training mode which creates multiple rules for a given process; one for every action the HIPS can monitor for. And as has been commented upon in previous postings, doesn't properly create the rules.


I also see no reason why the "whitelist" mode option cannot be deployed quickly.

1. The whitelist training mode and regular training mode would be mutually exclusive. You could only select one option.

2. When in whitelist training and subsequent alert mode, all other existing HIPS modes; auto or Smart would apply. As would all manually created user rules. All that whitelist mode is monitoring is process startup.

3. The "base" version of whitelist mode would be deployed first which of course would require the user to manually switch to learning mode prior to Windows updating or manually initiated application install or updating. He would then switch back to alert mode when updating has completed.

Since this could pose a problem in Win 10 with its auto updating, the user would be advised to switch to a metered connection and manual Win 10 update checking. Actually, update checking is not an issue since Eset will inform you when Win Updates are available.

4. The app updating "automation" aspects of whitelist mode could be introduced later when Eset has thoroughly tested those for effectiveness and problems. 

5. Also it should be noted that there would be two whitelist training modes. One that will create allow startup HIPS rules for all existing processes - usually only performed after Eset installation or major OS upgrade.

And a second "update" training mode that will only auto create allow startup rules for all new processes encountered while the mode is active. This mode would be deployed prior to Win updating and app installation and updating. In other words if an existing startup rule exists, leave it in place. Otherwise, create a new startup rule.

6. An Eset GUI/toolbar icon status indication should be provided to alert the user they are in whitelist mode training status. 


7. Finally, the whitelisting feature should have the following maintenance function which BTW is missing from existing HIPS processing that could be run on demand.

This function would scan for all existing HIPS allow startup rules and delete any for which no matching process could be found.

Additionally, an option should be provided to allow for the deletion of all HIPS allow startup rules. This option could be deployed prior to a Win 10 upgrade for example. When the upgrade is completed, the user could then switch on whitelisting initial learning mode to create a "clean slate" of whitelisted system and application process allow startup rules.

Note: this function would again only delete allow startup rules. Any user created ask or block rules in regards to process startup would remain in place.

Also although not explicitly stated previously, the whitelisting mode could be disabled entirely at any given time. If this is done, all existing HIPS allow startup rules would be active but no additional rules would be created or any alerts generated in regards to process startup. In other words, the HIPS will revert to auto or smart mode as if the whitelisting feature never existed. However and importantly, the above whitelisting maintenance deletion function would remain active.

Edited by itman
Link to comment
Share on other sites

This topic is now closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...