ESET not cleaning malware from Installer directory

[j-gray 32]

Scheduled scans and on-demand (scan with cleaning) are not removing most malware lately.

MSIL/Adware.BrowserAssistant.B: these are just .msi files flagged as applications, not PUPs and are located in the C:\Windows\Installer directory. I can manually delete them without issues.

The others that aren't getting cleaned are HTML/ScrInject.B, JS/Adware.Chromex.Agent.E, JS/Mindspark.G, and a handful of others that are located in the user profile space.

Scan settings are set to 'Always remedy detection'. Systems are showing no reboot required.

I can't tell from the reports why none of these are being remediated. Any suggestions?

 

[itman 1,595]

1 hour ago, j-gray said:

Scan settings are set to 'Always remedy detection'. Systems are showing no reboot required.

If you review the text associated with this setting, system files are an exception. If automatic remediation cannot be performed and the device user is logged on, an alert will be displayed with options that can be performed. I assume these scheduled scans are being performed when no user is logged on?

[j-gray 32]

8 minutes ago, itman said:

If you review the text associated with this setting, system files are an exception. If automatic remediation cannot be performed and the device user is logged on, an alert will be displayed with options that can be performed. I assume these scheduled scans are being performed when no user is logged on?

Thanks for the reply. Scans are occurring after hours, so folks should be logged off, though we know that doesn't always happen.

I'm not sure how ESET defines system files. My assumption is an installer (msi) wouldn't necessarily be a system file, nor would those files in the user space, specifically in the user's Chrome profile. Just not sure if my assumption is correct. ESET in the past has indicated when a reboot is required for remediation, but it's not reflecting that, either.

I haven't been able to find in the reports or elsewhere any indication as to why ESET is unable to remediate. I'm sure this is logged somewhere, just not finding it.

[itman 1,595]

16 hours ago, j-gray said:

I'm not sure how ESET defines system files.

I am fairly confident that anything in C:\Windows\Installer directory would be classified as a system file. This directory is hidden and classified as an OS directory by Win Explorer for example.

16 hours ago, j-gray said:

I haven't been able to find in the reports or elsewhere any indication as to why ESET is unable to remediate. I'm sure this is logged somewhere, just not finding it.

The scan log should indicate what action was taken upon detection. Below is a screen shot of one of my scan logs clearly showing the file was cleaned via deletion:

 

Edited October 9, 2020 by itman

[j-gray 32]

11 minutes ago, itman said:

The scan log should indicate what action was taken upon detection. Below is a screen shot of one of my scan logs clearly showing the file was cleaned via deletion:

That looks helpful, though I'm not finding such a log. Where is that located?

It looks like you're working with Endpoint Security, whereas I'm using Endpoint AV, so there may be some differences?

[LesRMed 19]

Open the GUI. Click on Computer Scan--> Show Log

[j-gray 32]

This is what most look like with Action = retained and no apparent error or indication why it was retained:

[j-gray 32]

1 hour ago, LesRMed said:

Open the GUI. Click on Computer Scan--> Show Log

Thanks for the reply. That would be an option if I were sitting at these various computers. But we have 12 different campuses so my only viable option is pulling info from the ERA console.

[itman 1,595]

2 hours ago, j-gray said:

This is what most look like with Action = retained and no apparent error or indication why it was retained:

 

Quote

•Action - Select the action performed on the detection. ESET security products report the following actions to ESMC:

 

ocleaned - The detection was cleaned.

odeleted / cleaned by deleting - The detection was deleted.

owas a part of a deleted object - An archive that contained the detection was deleted.

oblocked / connection terminated - The access to the detected object was blocked.

oretained - No action was performed due to various reasons, for example:

➢ In the interactive alert, the user manually selected not to perform any action.

➢ In the ESET security product detection engine settings, the Protection level for the detection category is set lower than the Reporting level.

https://help.eset.com/esmc_admin/72/en-US/threats.html

Refer to this: https://help.eset.com/ees/7/en-US/idh_config_scanner.html . If Protection level not set lower than reporting level, then assume an alert would have been issued if a user was logged on. If not logged on, I assume Eset reports the detection activity but does nothing else.

 

Edited October 9, 2020 by itman

[itman 1,595]

Also note the below screen shot, Eset Reporting and Protection settings can be changed for On-demand scanning. By default, these settings use whatever is currently set up for Real-time scanning:

 

Edited October 9, 2020 by itman

[j-gray 32]

This is what how we have on-demand scanning configured. Cleaning is set to 'always remedy detection':

[itman 1,595]

2 hours ago, j-gray said:

This is what how we have on-demand scanning configured. Cleaning is set to 'always remedy detection':

I can only assume that these events are occurring when the user is logged off and Eset can't alert to the activity.

It appears that for some reason Eset might not be able to gain full access to select directories of the file share where the detection is occuring? For example, it appears Eset has read access to detect the malware but not write/delete access to eliminate it.

Referring to your above posted detection screen shots, you first have Potentially Unsafe Application set to Cautious. The W32\GameHack.CYY detection I believe, is a Potentially Unsafe Application detection. Next is the associated .exe was found in the device's Users Download directory. I assume that when this file was downloaded, Eset detected it then. Perhaps this device user created a real-time scanning exception for it and then either re-downloaded or removed it from Eset Quarrantine? What I am now wondering is if device Eset setting exclusions; e.g. real-time scanning exclusions, override remote EMSC scans? 

[itman 1,595]

Also of note is Sk8r: https://clubdark.net/d/Sk8rMonacoInstaller is a game exploiting tool. No one on a corp. network should be allowed to download crud like this.

[j-gray 32]

3 minutes ago, itman said:

Also of note is Sk8r: https://clubdark.net/d/Sk8rMonacoInstaller is a game exploiting tool. No one on a corp. network should be allowed to download crud like this.

Agreed. Hence my concerns. I believe something must have changed with the recent upgrades, as everything had been getting remediated properly.

No policies have been changed, but ESET is no longer remediating much of anything.

Sk8r is classified as a PUP, so potentially forgivable. It's the items flagged as trojans and malware applications that are being retained that are more concerning.

[itman 1,595]

I guess at this point, you need to open a support ticket with Eset on the issue.