Online Payment Protection Test - Disappointing

[itman 1,659]

This test was performed on fully patched Win 10 x64 1607 using Smart Security ver. 10.1.210 using IE11.

The purpose of this test is to determine if Online Payment Protection would protect against some 0-day banking resident malware injecting the browser's memory to perform malicious activities.

 

Background

The test tool used was developed by a security researcher at contercept.com and can be downloaded from GitHub here: https://github.com/countercept/doublepulsar-usermode-injector . There is a readme file that can be accesses at the GitHub site that fully explains the background in development of tool, what it is based on, and how it can be used for test purposes. I am also attaching a text version of the read file below:

readme.txt

The tool is based on the reflective .dll loader employed in the recent NSA DoublePulsar incident but running in user mode versus kernel mode. What is unique about this reflective loader is the use of APC calls to load a non-reflective .dll into a processes memory and run it. In other words, malware memory to targeted process memory code injection.

Try as I did, I could not get this tool to run a non-reflective .dll on my Win 10 x64 1607 installation. The tool would inject the process memory OK but every attempt to run the injected code resulted in a DEP stack hash error. Might have also something to do with Win 10's CFG protection. I have been in communication with the test tool developer whom stated he could get my non-reflective test .dll to run on his system after a minor revision to the tool. He did not clarify to me what ver. of Win 10 he was using. However, I did discover the test tool works fine with a reflective .dll using the APC call method. So I used that .dll in my testing. 

 

Tool Reputation

The below screen shot clearly shows the tool as an unknown process. However Eset let the tool run uncontrolled w/o alert during all my testing with it:

 

Test Results

The first test involved an attempt to inject eOPPFrame.exe. The test tool shut down immediately stating it could not perform any memory injection. Looking good so far.

The next test involved injecting IE11's parent process memory that displays Eset's OPP startup screen. This test was successful as shown in the below screen shot:

The next test involved injecting the Eset protected IE11 child process running in AppContainer where one would log on to their bank web site. This test was also successful as shown by the below screen shot:

The final test was to determine if perhaps non-detection of the memory injection and .dll execution was due to this new APC call method not being detectable by the HIPS process modification capability. It was not as evidenced by a created HIPS rule generating an Eset HIPS alert when the memory injection was attempted.

 

Summary

LiveGrid reputation scanning is worthless in my opinion if it is not used to condition process status e.g. monitor for suspicious activities from unknown/low reputation process. At the minimum, add an option whereby the user can receive an alert when an unknown/low reputation process is started.

Provide default HIPS rules to monitor against global hooking, debugging, event interception, and process modification when the browser is running under Eset On-line Payment protection mode.

-EDIT- 7/11/2017

I forgot that I had disabled Win 10 native SmartScreen. In any case, that would be appropriate since I am testing LiveGrid effectiveness. IE11 SmartScreen was enabled during my testing.

I enabled native SmartScreen to determine if it would detect the test tool startup. It did not as expected since Win 10 native SmartScreen is a blacklist and appears the test tool is not listed in it. 

-EDIT- 7/14/2017

Eset patched this OPP vulnerability. See my later posting in this thread for details.

Edited July 14, 2017 by itman

[itman 1,659]

I just became aware of something I need to supplement to the above posting. I was a bit puzzled by the IE11 AppContainer bypass.

In my initial conversations with the test tool developer, I mentioned I was having some difficulty with AppContainer processes. Although he never mentioned it to me, he built an AppContainer bypass into the updated test tool executable as evidenced the use of the highlighted SID in the below screen shot.

Again, Eset has an excellent HIPS. All they have to do is deploy it. I have!

[cyberhash 188]

8 hours ago, itman said:

Summary

LiveGrid reputation scanning is worthless in my opinion if it is not used to condition process status e.g. monitor for suspicious activities from unknown/low reputation process. At the minimum, add an option whereby the user can receive an alert when an unknown/low reputation process is started.

Provide default HIPS rules to monitor against global hooking, debugging, event interception, and process modification when the browser is running under Eset On-line Payment protection mode.  

LiveGrid has never tried to be anything more than informative. In September when the fall update for windows 10 arrives, you can bet there will be another batch of unknown (low reputation) processes showing in there that are legitimate but allowing users to block those items during a windows update could in a good scenario be dangerous and on a bad day leave a system unusable.

For example, if Microsoft update "svchost, dllhost , lsass" ....... just because its been updated does not mean it's trying to do anything suspicious. Leaving these choices to an average home user would most probably end in disaster.

We all love our security but there comes a point where home users can actually do more damage via a few clicks of a mouse when getting into areas of things they have very little knowledge of.
 

[itman 1,659]

13 hours ago, cyberhash said:

For example, if Microsoft update "svchost, dllhost , lsass" ....... just because its been updated does not mean it's trying to do anything suspicious. Leaving these choices to an average home user would most probably end in disaster.

We all love our security but there comes a point where home users can actually do more damage via a few clicks of a mouse when getting into areas of things they have very little knowledge of.

Exactly why I stated that the LiveGrid alert feature be an optional setting that would be disabled by default.

However, the main point is how Eset handles these processes at execution startup since "sleeper" malware is increasing being used to avoid sandboxed heuristic analysis. In fact, the test tool employs use of ordinal no. 1 which is used by malware for sandbox and AV detection and bypassing.

Also, I have never seen any low reputation settings given for system processes; even after a major system update. Reputation for these are established via Eset ongoing testing during the pre-release phase.

 

Edited July 9, 2017 by itman

[cyberhash 188]

4 hours ago, itman said:

Exactly why I stated that the LiveGrid alert feature be an optional setting that would be disabled by default.

However, the main point is how Eset handles these processes at execution startup since "sleeper" malware is increasing being used to avoid sandboxed heuristic analysis. In fact, the test tool employs use of ordinal no. 1 which is used by malware for sandbox and AV detection and bypassing.

Also, I have never seen any low reputation settings given for system processes; even after a major system update. Reputation for these are established via Eset ongoing testing during the pre-release phase.

 

LiveGrid can be disabled in the (F5)advanced setup > tools menu from the gui. But not recommended as this can block newer types of threat, as it actively sends data as well as receiving. Leaving your machine potentially vulnerable.

On your original post :

Tool Reputation

The below screen shot clearly shows the tool as an unknown process. However Eset let the tool run uncontrolled w/o alert during all my testing with it:

Your screenshot shows that the file you have run (has an alert) and does not have the GREEN for GOOD tick on the risk column.
It's leaving the decision to you as to run or close the app, by far the best choice i would think.

What you are suggesting appears to be more a case of mass blacklisting via LiveGrid. Block everything until its known what the particular file is/does, then once a team of(nuclear powered)staff verify the 260,000,000,000 samples per day then they whitelist it.

Or if you are meaning that HIPS failed your testing then im sure that once those methods are looked at and tested by ESET then the HIPS module itself will be updated to pick up that particular type of attack.

I don't doubt that you have never seen any low reputation system files on your machine via LiveGrid. After every large update since moving onto windows 10, i have seen instances of system files with low reputation and it takes time before they actually reflect the amount of users that are running the same(file/build).

Hence the reason why i said on my last post that its informative and not definitive. Just because something has a low user base does not mean that its a bad file or process. And by design ESET allows you to make an informed decision by yourself as to how to deal with them, and does not force an action for you.

 

[itman 1,659]

2 hours ago, cyberhash said:

Your screenshot shows that the file you have run (has an alert) and does not have the GREEN for GOOD tick on the risk column.
It's leaving the decision to you as to run or close the app, by far the best choice i would think.

I think you're missing my point. The point is LiveGrid should at the minimum inform the user at program startup that there is a reputation issue. For example, display a message like "Warning this program is unknown." Then show an option for additional information that state things like the program has a valid signature, any vendor identifying information, etc. along with an option to:

1. Run without restrictions

2. Run in monitored mode - Recommended

3. Block execution

In the LiveGrid section, an option would be provided to remove the process from monitored mode.

Obviously, monitored mode would be using the HIPS to monitor if the process is doing suspect activities such as global hooking or debugging, intercepting events, or modifying the state of another application.

I believe the above is a much better approach than recommending users create HIPS rules to monitor for process startup in the %AppData% and %TEMP% directories as Eset recently recommended. Since there are instances where legit processes use these directories, the likelihood of users "borking" the installation are much higher than what I am recommending.

-EDIT-

Ideally and preferred, the above monitoring activity would be automatic for unknown processes. A separate GUI screen could be added showing all processes currently monitored and what is being monitored in user friendly terms. Of course, each one of those monitored actions corresponds to a HIPS rule/s. Additional monitoring or unmonitored actions would be indicated via checkmark box. This would avoid average users from using the HIPS rules section altogether which would be desirable since creating such rules are confusing to say the least. A good prototype would be Emsisoft's behavior blocker GUI layout.

Edited July 9, 2017 by itman

[cyberhash 188]

I understand what you are saying, where something along the lines of sandboxing unknown apps would be beneficial to some users.

But to run something inside a sandbox you would have to be doubting the credibility of the application in the first place ?. Plus you already have UAC in windows.

If for example i go and get some new Nvidia drivers from their own website. These drivers that are updated regularly, some times weekly. But because they were only released 15 minutes ago, and my AV product deems this as new and a potential threat. A nag screen pops up when i go to install this and offers me choices of what route i want to go. People will eventually do what has been proven before with UAC in windows and turn the feature off, leaving themselves more exposed. People hate nag screens and especially ones that don't actually need a nag screen to begin with.

I cant speak for everyone but i think employing a similar thing in LiveGrid, without granular control of the options could possibly lead to people disabling LiveGrid completely as they have the other modules to fall back on. Just now it runs silent and informative for home users.
 

This is just my thoughts, but there will be plenty that also agree with you @itman

[itman 1,659]

And I @cyberhash also see your point of view.

However, the fact still remains that something is lacking in a mechanism that:

1. Only informs of a potential security risk after the process has begun execution. Granted Eset has initially scanned for malicious status and activities. But security scanning evasion tactics for heuristic scanning with sandboxing are becoming the norm with malware developers these days.

2. Does not continuously monitor suspect processes until adequate reputation can be determined.

3. The informational status of suspect processes is not proactively displayed but only given through a passive manually initiated action.  

[itman 1,659]

Added comment to test results posted.

-EDIT-

Also will add this comment.

When I added appropriate HIPS rules to monitor against browser memory modification, the HIPS alert clearly displayed the LiveGrid status of the process, unknown, in the alert.

So it appears to me that Eset has all the elements necessary to make the HIPS perform behavior detection. Create appropriate internal HIPS rules for known malware targeted processes and condition the HIPS to trigger on LiveGrid unknown status. Or alternatively, auto block, log, and display message of action which would remove the need for any decision on the user part.

Edited July 11, 2017 by itman

[cyberhash 188]

Today's update (Windows 10 KB4025342) which was pretty minor shows exactly the issue i was talking about where system files are updated and don't yet have any reputation. On the upcoming September update you can bet that there will even more system files are updated with LiveGrid showing no reputation.

 

[itman 1,659]

Same here. Win 10 updated today. As shown by the below screen shot, only one shows as unavailable, lsass.exe. However and important to note is that unavailable status is not the same as unknown status as indicated by the green checkmark. Additionally, lsass.exe has "origin" info associated with it.

I believe that LiveGrid works like most AV rep scanners in that a hash and signature check is made for the initial risk analysis rating. If those are OK, the file is given a green OK risk status. If no match on hash and the flle is unsigned, the user rep rating is used to determine risk status.

 

Edited July 12, 2017 by itman

[cyberhash 188]

I think the reason why i see a lot more low rep files is that you are using an old build of windows 10 and why in the past i have seen Microsoft signed files with the red warning flag against them.

The reason i mentioned the problem of using a live reputation based system with files is that someday LiveGrid may actually have an outage or not reachable for whatever reason, but at that same point in time you might have updates installing for windows.

I really wouldn't fancy the idea of having to click hundreds of pop up screens to do a update in windows, because my connection with the LiveGrid server is not reachable.

I like the way it works just now, where the loss of connection would make no difference in the short period of time where it was offline,
and having a downloadable database(stored locally,as a backup) of every legitimate or non legitimate file in the world is impossible.

Where as your test with a single executable via a live reputation test is plausible and workable.

ESET has always had a great record when it comes to false positives and a live reputation based blocker could destroy that if the service was ever unreachable. Although this wouldn't fall into a false positive category , leaving users to make hundreds of choices and one wrong click could prove troublesome.

 

[itman 1,659]

-EDIT- Also for clarification, I never proposed the LiveGrid enhancements I am recommending would be enabled by default. It would be an option that could be enabled by technical users that recognize the implications of employing the feature; primarily the risk of a false positive. Additionally, disabling the option prior to OS updating or upgrading could be done to mitigate the concerns @cyberhash stated. It should also satisfy Eset's wish to keep its false positive count low in the AV lab tests.

Eset has always been "a bit tight lipped" when it comes to giving detailed information about its protection mechanisms. I did find an Eset VAR that did provide one about LiveGrid.

Reputation system

ESET's reputation system allows for effective detection of malware samples even before their signatures are delivered to user’s computer in via updated virus database (which happens several times a day).

On top of the above mentioned ESET LiveGrid® implements a reputation system that helps to improve the overall efficiency of our anti-malware solutions. When an executable file or archive is being inspected on user’s system, its hash tag is first compared against a database of white- and blacklisted items.

If it is found on the whitelist, the inspected file is considered clean and also flagged to be excluded from future scans.

If it is on the blacklist, appropriate actions are taken – based on the nature of the threat.

Only if no match was found, the file is scanned thoroughly. Based on results of this scan the file becomes a candidate to extend the corresponding list.

Ref.: http://www.nod32adria.com/english/Support/ThreatCenter/ESETLiveGrid/tabid/3173/Default.aspx

The above validates my previous statement that when you see a green checkmark in the LiveGrid display, it means that Eset has validated the process via whitelist detection.

The point of note is the above last paragraph of when the file is "thoroughly scanned." Appears that if no malicious activities are found, the file is listed in LiveGrid based on available detection status from other Eset installed devices.

Again and in reference to my test results, there is obviously something very wrong with Eset's lack of detection of an "unknown" process injecting the browser's memory. At a minimum, Eset's real-time heuristic scanner should be scanning "unknown" processes at every startup in its sandboxed mode for suspicious activities such as memory injection of the browser. It is fairly obvious that if it is doing so, the heuristic scanning is failing to detect these activities.

Edited July 12, 2017 by itman

[itman 1,659]

Alerted by forum member @TomFace in a posting that changes were made to OPP, I retested it with the test tool. I can now gladly report that OPP, both IE11 site initiated or by stand-alone OPP start up, completely blocks the test tool. Kudos to Eset for a speedy resolution.

However, such is not the case for running IE11 outside of OPP mode. So my browser HIPS rules stay in place.

So Eset, do I get a free lifetime license for Smart Security in lieu of bug bounty payment?