EEI server reports malware but EP Console does not.

[j-gray 35]

EEI Console indicates a critical alert/threat detection for malware detected by antivirus (idle scanner) on a specific host and also indicates that the threat was not handled. This detection occurs 4-8 times per day going back several weeks.

However, when I look at the specific host in the EP Console, it does not reflect this. EP console shows nothing under Alerts. EP Console also shows nothing under Detections and Quarantine. It also shows that the scheduled scan completed two days ago and found nothing.

So EP console shows critical antivirus issues, but EP console does not show them. All filters are cleared. I'm not sure why the conflict.

[j-gray 35]

An update to add to the confusion; when I log into the host and run a manual scan on the folder and file that is generating the alert in the EEI console, the antivirus scan does not detect anything.

So again, EEI shows an unhandled malware threat (Win32/BadJoke.KW), but AV shows nothing and detects nothing during scans. The file that is flagged is still in the location causing the detection in EEI.

[Marcos 5,071]

Please provide the undetected file for perusal.

In order to report detections found by the idle-state scanner to ESET PROTECT, try enabling logging first:

[j-gray 35]

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

 

Edited July 8, 2022 by j-gray
spelling/grammar

[itman 1,659]

Eset detects a variant as a screen locker: https://www.virusradar.com/en/Win32_BadJoke.CC/description .

[j-gray 35]

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?

[Marcos 5,071]

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.

[j-gray 35]

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.

[j-gray 35]

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.

[Marcos 5,071]

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

[j-gray 35]

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.

Edited July 13, 2022 by j-gray

[j-gray 35]

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.

Edited July 13, 2022 by j-gray

[Marcos 5,071]

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

[j-gray 35]

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

[j-gray 35]

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