j-gray

We're running a virtual 2012 R2 server with ESET Protect installed. We'd like to do an in-place upgrade from 2012R2 to 2016. Any feedback or experience as far as issues with ESET during the upgrade? Of course we'll stop ESET, SQL, and Apache services prior.

ESET has a paid service (Assessment and Optimization) that I would recommend, where they do just that; assess and optimize. We felt it was worth the price.

Yes, correct. The files that were being flagged were very old, static, not changing, not in use. I handled the malicious files some time ago. My point with the multiple detections per day of the same static files is that it indicates excessive scanning by idle-state. Which is also causing high memory utilization. I've disabled idle-state scanning and no longer get the multiple daily memory alerts.

This would make sense, though with Smart Optimization enabled it was detecting malware in the same static .iso and .mbx file 5-6 times every 24-hours, so clearly not the case. We can certainly add a bunch of exclusions, but that would seem to defeat the purpose of a scan. To me, the underlying issue is the frequency of the idle-state scan and the resources it consumes.

@Marcos Yes, that is understood. My point here is regardless of memory utilization, scanning a large volume 5-6 times every 24-hours seems excessive.

I don't believe that's the case, as the detection source always indicates 'idle-state scan'. I have a feeling that idle-state just runs continuously, hence the repeated detections and high memory utilization.

Yes, those settings were selected

The challenge is that it happens at random times whenever idle-state runs. From the detection logs, we can see that when malware is present, it gets detected 5-6 times daily, which indicates that idle-state is scanning the entire 2TB drive frequently. We use Microsoft System Center Operations Manager, which alerts to excessive memory consumption. We usually see the alerts after the issue has occurred and can't manually reproduce the issue. In addition, this alert/alarm state is generated in Vmare vCenter, where these virtual machines reside. I believe the easiest way for you to reproduce it would be with a vm of a Windows 2102 R2 file server with 4GBs of RAM, 2TB's worth of small files and idle-state scanning enabled.

Updated: I disabled idle-state scanning and I get no more high memory utilization errors. It's clear to me that the idle state does frequent and repeated scanning of file shares and causes high memory utilization. I'd open a support case, but I really don't have the patience to go through Level 1 support. If anyone at ESET cares to pursue this and can put me in touch with Level 2 support, I'd be happy to collect whatever information is needed to help resolve this.

@JamesR Thanks for the detailed response. The triggering process is actually tssdis.exe (ApcQueue), so I'll adjust accordingly. I'm sure that will do the trick, but will report back, regardless. Thanks again.

I'm assuming that due to the nature of terminal services, pretty much everything is getting flagged as 'Injection into system process' Is there a recommended method for handling these excessive alerts without actually defeating the purpose of EDR?

Interesting. I'm certainly not seeing that behavior after multiple detections over multiple days. In all cases we see, "Action error - Unable to clean". This particular mbx file appears to be a very old and disused Outlook Express file. And in fact, ESET support (#00393240) advised that the only way to clean it successfully was to enter the inbox and delete the suspect message.

In the detection instances they were all malware within an archive; one was an email within a very old .mbx file and the other within an .iso file. My understanding (and according to support), because it's an object within an archive, it's unable to be remediated by ESET. My bigger concern though is what seems to be frequent, repetitive idle-state scanning. And unfortunately I don't have a screenshot of memory usage. I get alerted by our monitoring application and typically miss the occurances. Because it's random in nature I can't predict when it will occur, either. It does coincide with times that idle-state is scanning. Additionally, it doesn't occur when idle-state scanning is disabled.

Is there any way to dial back the idle-state scanning? It frequently triggers excessive memory paging, specifically on our file servers. We also find that when an infected file is present, idle-state will report it up to 5 or 6 different times in a 24-hour period, which seems to indicate that it is scanning the entirety of a 1TB drive multiple times per day. We'd like to dial this back, as well if at all possible. TIA

@Marcos I found that 'Email files' was not selected in the Threatsense Parameters. Once I toggled this, it started to get detected by the other scans. A bit odd, because the info bubble says it only supports DBX and EML and doesn't list MBX, which is what this filetype is. Now, the question is, none of the detected files in archives (mbx, iso, etc.) are being cleaned even though the policy is set to 'Always remedy detection'. Is there any other way to force ESET to clean these files?

Logs have all been uploaded to support case #00393240. GUI scan was performed by; launch ESET GUI with admin rights, select Scan > Custom Scan. Choose Scan Profile = in-depth scan (which is the default). Select parent folder and click 'Scan'.

Sorry, I edited my last post. The first ecls.exe scan I forgot to add the switches. Once added, the Trojan was detected. However, nothing was cleaned.

@Marcos Yes, it does detect the Trojan with this method.

Support case has been open for a bit, but they're still unable to tell me why no other scans detect this Trojan. In the interim, I'm finding more malware detected by idle-state scans. It seems in all instances idle-state is unable to clean or remediate anything and I'm not sure why that would be the case.

That's part of the issue; on-demand scan is set to 'in-depth'. However neither manual on-demand scan, nor weekly scheduled scan detect the Trojan. I don't want to disable idle-state scanning, as it's the only component that detected this Trojan and it would have not been otherwise detected. Setting to 'user logoff' will be ineffective because it is a Windows file server and rarely is anybody actually logged into it. Thanks for your reply.

I want to create an exclusion for ssh protocol, but only coming from a specific host IP address but this is not one of the predefined options. Is it possible to specify source IP using the Advanced Editor? If so, what are the correct 'component' and 'property' values to use?

@Peter Randziak Actually, I believe part of the issue is due to a bug still with licensing on the OS X client. I had a support case (00291733) back in January where it was discovered that the install/upgrade task fails when a license is specified in the task. So running the install/upgrade succeeds more frequently in that case. I really wish we could get some traction with the myriad OS X issues. It's been consuming a lot of time and effort.

EP console now shows the detection, as expected. It's odd that logging is not enabled by default. Why would you not want to know about a detection? However, I'm still left with two questions; Why is only the idle-state scan catching this and not in-depth scheduled scan and in-depth manual scan? The idle-state scan is detecting this every 3-5 hours, which seems to imply it's scanning this 2TB file share that frequently. This seems excessive and I believe to be the reason our file servers show high memory utilization at random times. Can idle-state scanning be dialed back so it's not constantly scanning?

@Marcos Thanks for the reply. I've enabled idle-state scan logging. It's odd (and a bit disturbing) that neither in-depth manual scans, nor in-depth scheduled scans are detecting this malware. Is it possible to tell what in the idle-state scan is detecting this? I'd really like to determine why the other scans are not detecting it. It is a .mbx file from what appears to be a very old Outlook Express inbox.

Thanks for the reply. Unfortunately it seems pretty inconsistent. I just ran the EEI connector upgrade task on three OS X systems (same versions of everything, including OS) at the same time. One failed within 2 minutes, but the upgrade succeeded, as we can see the latest version installed and running. The second one is still running after 30 minutes, and the third one failed after 30 minutes and did not install successfully.