[Server 2012 upgrade with ESET Protect]

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 Inspect with ESET Protect]

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.

[Idle-stat scan causing high memory pages]

On 8/24/2022 at 12:32 PM, itman said:

By "static" I assume you mean this .iso file is one whose contents do not change?

It appears Eset for some reason can't remove the malware within the .iso file. How about copying the .iso file to external media. Then copy it to a stand alone device not connected to the corp. network. Mount the .iso file and use Eset to scan and remove any malware found. Dismount the .iso file, copy the cleaned .iso file to external media, and then reload it to its original location.

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.

[Idle-stat scan causing high memory pages]

1 hour ago, itman said:

I really believe the issue here is idle-time scan mode. By design, this mode performs continuous scanning. However, the Smart Optimization feature should exclude files previously scanned unless there was a change in the file; i.e. different file hash.

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.

[Idle-stat scan causing high memory pages]

10 hours ago, Marcos said:

Most likely detected threats remain uncleaned because they were found in an archive or mailbox. As I have already mentioned, if you could disable archives, sfx archives and email files in the Idle scan setup so that these are not scanned, or at least set a reasonable size limit for scanned objects, e.g. 10 MB.

@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. 

[Idle-stat scan causing high memory pages]

2 minutes ago, itman said:

It appears that when Eset detects the presence of malware, it is reverting to full scan mode.

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.

[Idle-stat scan causing high memory pages]

21 hours ago, itman said:

Verify that "Smart Optimization" is enabled in ThreatSense settings for Idle-Scan settings section. Also verify that "Run background scans with low priority" is also enabled in the same section.

Yes, those settings were selected

[Idle-stat scan causing high memory pages]

55 minutes ago, Marcos said:

You could provide some screenshots to illustrate the issue and we'll try to reproduce it ourselves.

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.

[Idle-stat scan causing high memory pages]

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.

[Issue with detections on Windows Terminal Server]

@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.

[Issue with detections on Windows Terminal Server]

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?

[Idle-stat scan causing high memory pages]

On 7/29/2022 at 10:51 PM, Marcos said:

Malicious attachments should be cleanable in MBX files. Is the MBX file the email storage that Thunderbird uses? You could also consider excluding MBX from being scanned by the idle-state scanner.

As for ISO, if it contains only a malicious file, the whole archive should be deleted/cleaned automatically.

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.

[Idle-stat scan causing high memory pages]

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.

[Idle-stat scan causing high memory pages]

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

[EEI server reports malware but EP Console does not.]

@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?

[EEI server reports malware but EP Console does not.]

18 minutes ago, Marcos said:

Please provide:
1, Logs collected with ESET Log Collector
2, Step by step instructions how you ran the scan via gui.

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'.

[EEI server reports malware but EP Console does not.]

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.

[EEI server reports malware but EP Console does not.]

24 minutes ago, Marcos said:

Is the threat detected if you run ecls with the /mailbox switch? In particular:
"C:\Program Files\ESET\ESET Security\ecls.exe" %mbox_file% /mailbox /mail

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

[EEI server reports malware but EP Console does not.]

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.

[EEI server reports malware but EP Console does not.]

1 hour ago, Marcos said:

1, Mailboxes are scanned only by the in-depth scan profile. I do not recommend enabling it since some email clients may keep message indexes in a separate file and removing an infected email message from a mailbox could corrupt it.

2, I'd disable idle-state scanning or try leaving only the "user logoff" event enabled to trigger a scan.

1. 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.
2. 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.

[Is it possible to create an exclusion using Source IP?]

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?

[OS X error - forking process does not exists]

@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.

[EEI server reports malware but EP Console does not.]

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;

1. Why is only the idle-state scan catching this and not in-depth scheduled scan and in-depth manual scan?
2. 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?

[EEI server reports malware but EP Console does not.]

@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.

 

[OS X error - forking process does not exists]

On 7/6/2022 at 5:45 AM, Peter Randziak said:

Does it fail in few minutes or after 24 hours? If after the 24 hours, it would mean that EP server hasn't received the result. so it considers the task as failed.

If it fails in few minutes we need to check what is in the logs.

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.