"Warning - Threats Found" Window on multiple workstations

[chockomonkey 1]

Hi all, I've experienced some atypical behavior from ESET Endpoint Antivirus this morning and I'm looking for some insight. 

I have received multiple reports from users about an ESET window on their screen when they came into work this morning. One employee took a photo of this window, which I've attached. It reads:

Quote

 

Warning

Threats found

Multiple threats were found and could not be cleaned automatically. Please review the threats and select an action to take for each one.

 

Normally ESET Endpoint Antivirus just 'does its thing' in keeping malware, phishing attempts, trojans, and other malicious events under-wraps. I get notifications about its success in my ESET Remote Administrator where I make certain that the infections were properly handled, which, they always have been.

However there are certain things about this event that leaves me scratching my head: 

1. This is the first time in over a year of using ESET Endpoint Antivirus 6+ that users have ever seen this window or have had their input required.

2. These events do not show up in ESET Remote Administrator.

3. These events do not show up in the local logs on the workstations. 

Can someone please help me understand why this is? 

[itman 1,659]

See this thread for reference: https://forum.eset.com/topic/17439-scrinjectb/

[chockomonkey 1]

10 minutes ago, itman said:

See this thread for reference: https://forum.eset.com/topic/17439-scrinjectb/

Thanks for that. 

So basically ESET pushed out a definition update which added this new scrinject.b threat, and during routine scanning it located various instances of it in cache? 

That would make sense as to it's sudden appearance. However, why wouldn't this show up in ERA or local logs? 

[itman 1,659]

17 minutes ago, chockomonkey said:

However, why wouldn't this show up in ERA or local logs? 

Can't comment on ERA since I am not familiar with.

As far as not showing in the local logs, I suspect that depends on the action selected. Were all the detections shown manually blocked?

[chockomonkey 1]

Ah okay, well thanks for replying anyway. 

Out of necessity, all instances of this were manually deleted via the window that was on users' screens. 

Perhaps infections aren't reported to ERA or the logs when they are manually handled...

[Marcos 5,071]

I too assume that the files started to be detected after we blocked a link to the compromised counter.js. Since the files in the screen shot were not detected by real-time protection but by the on-demand scanner, Firefox didn't access them.  Do you have an on-demand scan scheduled to run on a daily basis?

As for the HTML/ScrInject detection, it requires user's interaction when cleaning. Therefore you might want to consider enabling strict cleaning in the real-time protection and web protection setup so that detected files are always cleaned automatically without user's interaction.

[chockomonkey 1]

2 hours ago, Marcos said:

I too assume that the files started to be detected after we blocked a link to the compromised counter.js. Since the files in the screen shot were not detected by real-time protection but by the on-demand scanner, Firefox didn't access them.  Do you have an on-demand scan scheduled to run on a daily basis?

As for the HTML/ScrInject detection, it requires user's interaction when cleaning. Therefore you might want to consider enabling strict cleaning in the real-time protection and web protection setup so that detected files are always cleaned automatically without user's interaction.

Thanks for sharing all that info. 

I am using the default ESET policy for Endpoint deployments, so it should be doing regular scans. Based on your suggestion I'll look at increasing the strictness of cleaning.

I am curious--how do you differentiate between the on-demand scanner and the real-time protection with regards to the warning screens? 

Lastly, where does Idle-state scanning come into the mix? I had assumed, incorrectly it seems, that the window which had popped up on these workstations was from the idle-state scan.