Offline Scanning Issue

[itman 1,659]

Before I get into specifics, I will state that I have always used Eset's idle-state scanning option. I did so as an alternative to running periodic full connected disk drive scans. I assumed that idle-state scanning was equivalent to full scanning in terms of detection capability. Appears that is not the case.

I recently had to reinstall Eset IS 11.2.49 due to performing a Win 10 1803 reset installation. As expected, a full scan of all local drives was performed as a result of the installation. Below is a screen shot of what was found as a result of this scan:

Here's the problem. I do a lot of ad hoc testing with sample malware code. The global keylogger code Eset found has been sitting on my PC for months. I also performed an Eset reinstall about a month ago and its full scan did not detect this. I am assuming that somewhere between last month and currently, Eset developed a new signature for this test keylogger code? If so, why wasn't it detected via idle-state scanning?

Bottom line - is idle-state scanning the equal in detection capability as a manual/scheduled full local drive scan? Does idle-state scanning bypass files that were previously Eset scanned? Does manual/scheduled full local drive scanning bypass files that were previously Eset scanned? Is there any way to have Eset scan previously scanned local drive files using the latest signature database?

Edited September 11, 2018 by itman

[Marcos 5,069]

Quote

Bottom line - is idle-state scanning the equal in detection capability as a manual/scheduled full local drive scan? Does idle-state scanning bypass files that were previously Eset scanned?

Yes, the Idle-state scanner should be equal to a smart scan. Please provide the ps1 file so that I can check when exactly the detection was added.

[itman 1,659]

1 hour ago, Marcos said:

Yes, the Idle-state scanner should be equal to a smart scan. Please provide the ps1

Here's the .ps1 script renamed as a text file.

Also if idle-state is equal to Smart scan, I could see where that could be a problem since:

1. It only scans system areas commonly targeted by manual.
2. I assume it will not scan files previously marked as scanned?

So at this point, I am going under the assumption that a full Eset scan for the boot drive for example will scan all files regardless of their previous scan status?

logger.ps1.txt

Edited September 11, 2018 by itman

[TomFace 539]

Looking at my scan logs, the "Initial scan" after installation looks to be equivalent to a "smart scan" as far as the items scanned count. For my PC that is about 240,000 (or so) "items". I have full "in-depth" scans (no smart optimization enabled) scheduled which yield a scan count of about 2.2M "items". So it appears the safest way to go is with a regular "in-depth" full scan that is regularly scheduled.

Especially if you are doing "testing".  

[itman 1,659]

1 minute ago, TomFace said:

So it appears the safest way to go is with a regular "in-depth" full scan that is regularly scheduled.

Yeah, that appears to be the most comprehensive scan approach that will ensure all new signatures are applied to existing files.

[TomFace 539]

5 minutes ago, itman said:

Yeah, that appears to be the most comprehensive scan approach that will ensure all new signatures are applied to existing files.

It works for me. Even though I have noticed of late (the past 30 days or so), the scan times increasing. It went from about 2.25 hours to about 3 (or so) hours for an in-depth scan.

But I'll save that for another thread or trouble ticket.

Edited September 11, 2018 by TomFace

[Marcos 5,069]

The detection was added on Sept 4. Cached results are cleared after a module update so the file should have been re-scanned if the file was actually scanned by the Idle-state scanner.

[itman 1,659]

3 hours ago, Marcos said:

The detection was added on Sept 4. Cached results are cleared after a module update so the file should have been re-scanned if the file was actually scanned by the Idle-state scanner.

The whole issue might be "academic" at this point I now realize.

I disabled Eset's realtime protection and re-downloaded the above posted .ps1 file. However it appears any access attempt by I assume by any process; in this case Win explorer to rename the file, resulted in a realtime detection by Eset. It was my understanding that Eset realtime processing only scanned files at creation and execution time. Appears it also does so upon file access time? 

Also it is debatable if idle-time scanning would detect the file since the directory it is stored in is located under the root C:/ directory. Again I assume that only select directories are scanned via Smart scanning? If I remove the file from quarantine, will Eset redetect it again via realtime scanning? Yes, Eset detected it when I tried to access its properties via Win Explorer. So at this point, I assume Eset would detect the script if PowerShell attempted to run it. To run the script, Powershell would first have to open the file.

Edited September 11, 2018 by itman

[itman 1,659]

1 hour ago, Marcos said:

The detection was added on Sept 4.

Perhaps as a result of the initial scanning on my PC?

Do we finally have concrete proof of LiveGrid's responsiveness? I assume the keylogger detection was initially triggered by a HIPS behavior signature triggered by heuristic sandboxing  processing perhaps? And what really was "new" is the HIPS keylogger behavioral signature; i.e. SetWindowsHooKEx, etc.?  

Edited September 11, 2018 by itman