itman

No problem with my Eset installation with scheduled scan logging as the below screen shot shows. Also I was wrong about my prior statement about scan starting immediately after a time change. It did start running and worse, it does not now show the scan is running via Eset desktop toolbar icon animation!

Are you stating your log file issue has been resolved?

OK. I just modified my scheduled scan to run today at 11:25 AM. Will report back after scan runs if it created a log entry with details provided. A short time ago, I received a modules update. What I now observe when modifying an existing scan run time is it doesn't start running the scan immediately when saving my changes. So it appears Eset fixed that issue.

I am trying "to get a grip" on what you are describing. Are you stating that you are not receiving any detail log information in ver. 12.1.31 as my below screen shot shows for my EIS installation?

What your narrative describes is akin to something out of a malware sci-fi horror movie. Are you stating that every device you have connented to your network in the last 10 years has been affected by what you posted?

Again, not on my Eset installation. Perhaps Eset not in sync with U.S. DST? -EDIT- Just occurred to me the problem might only manifest with scans that existed prior to the 12.1.31 upgrade. You created a new scan to test. I will edit the Log maintenance scan and see it that eliminates the problem.

Well, daylight savings time is now in effect. Wanted to see if this resolved the default log maintenance scan running an hour ahead of schedule as noted in the above linked posting. It did not. That scan ran an hour ahead of schedule today. Definitely appears their is some type of time issue between Eset scheduler and system clock.

Below is a screen shot of what is shown from Eset desktop toolbar icon when my scheduled scan is running in ver. 12.1.31:

Appears to me is what you are observing is Eset's default scheduled scan after every module update:

Not possible as far as I am aware of. Lowest scan level in GUI select field is folder/directory level. However, see the below screen shot. There is an area where you can enter a specific path. You can "play" with that to determine if any wildcard capability exists; e.g. C:\SomeDirectory\*.exe.

I received a log entry for my scheduled weekly scan that ran a few hours after I upgraded to 12.1.31. I suspect the scan didn't run as scheduled. Hence no log entry. Did you see the scan running by visual confirmation of Eset desktop toolbar icon spinning? There have been issues with the scheduler in 12.1.31. You might try deleting your existing scan and recreating it. Then see if it runs as scheduled and a log entry is created.

Appears the issue has been resolved. I can download AdwCleaner from the Malwarebytes site w/o issue.

You will have to be patient and let @Marcos get back to you with whatever issue Eset is detecting with the web site. If you immediately have to download AdwCleaner for some reason, you can do so via the bleepingcomputer.com link I posted previously.

I just scanned toolslib.net using QUALS SSL Server check and they gave the site an A+ rating: https://www.ssllabs.com/ssltest/analyze.html?d=toolslib.net&s=51.15.229.92&latest . All certs. look OK except they are using a self-signed Let's Encrypt cert.. Only thing QUALS noted was: OCSP STAPLING ERROR: OCSP response expired on Tue Mar 05 18:00:00 UTC 2019

What malware was not being detected I guess is the major question.

My understanding is it is not compatible with x(64) kernel patch protection. The primary reason almost all the third party HIPS solutions shut down. Assume their profits from such software were not worth reengineering the software to be compatible.

Outpost was unique software and you're not going to find anything in an integrated AV solution with like features. One reason is you paid for all those features in the Outpost license.

I see one issue. Toolslib.net appears to use TLS 1.0. Also a bit strange that Malwarebytes.com would redirect to another web site for a download. You might want to download AdwCleaner from here: https://www.bleepingcomputer.com/download/adwcleaner/dl/125/ . Zip download issues.

To begin with, password protected files are almost always archives as your screen shot shows. I checked a few of my 12.0.31 scan logs and see the same "error - password-protected file" associated with know password protected archive files. So this status is not unique to the new 12.1.31 version. I started seeing these log entries when I changed Eset's default Smart Scan profile ThreatSense settings to scan archive files. In previous Eset versions, the Smart Scan profile did not scan archive files. Note that it is impossible for Eset to open a password protected file. Hence the message shown in the log although I personally believe the message should be a warning. One possible explanation as to why "error - password-protected file" message is now showing in ver. 12.1.31 scan log is Eset might have changed the default Smart Scan profile to now scan archive files? Also in my scan logs with these messages, I show zero detections. It appears Eset is flagging a password protected file, script.dat, within an archive as suspicious. Normally, the entire archive is password protected. I also would treat this as suspicious since its a great way to hide malware within an installer for example.

Since this thread has been twice hijacked, the second time by you, it is impossible to determine exactly what issue you are referring to. Proper forum etiquette is not to hijack existing threads but to post a new one about your specific issue.

@Marcos, in regards to this recent like posting https://forum.eset.com/topic/17991-as-soon-as-possible-option-of-scheduler/?do=findComment&comment=92026 , I can add some further information. Later yesterday, I edited my existing scheduled scan. It was originally coded to run the scan immediately if missed for 2 hours which as commented upon previously, didn't work in ver. 12.0.31. I changed it to run the scan to run as soon as possible. Upon saving the change, I observed that the prior scan run history had been deleted from the entry and the scan immediately started running. Of note is this was not the behavior on ver. 12.0.31 when the run options were changed. Appears to me that Eset devs. did this intentionally to set some type of internal trigger mechanism to ensure that scheduled scan run time options perform as designed. It also appears to me that anyone with existing scheduled scans will have to "reset" them by editing existing options or, by deleting the existing one and creating a new one.

Did you enter the new license key into the currently installed expired Eset version? I suspect any registration info. on Eset servers got wiped/hosed after the currently installed Eset version expired. Suggest you perform the following: 1. If you made any custom changes to NOD32, export your current settings. 2. Uninstall your current Eset version using Windows Control Panel -> Programs -> Uninstall a program. 3. Reboot your PC; Eset should instruct you to do so - if it doesn't, reboot anyway. 4. Download current version of NOD32 here: https://support.eset.com/kb2885/?locale=en_US&viewlocale=en_US . 5. Reinstall Eset and enter your new license key. Reboot your PC if Eset instructs you to do so to complete the installation. 6. Import your old Eset settings if you previously exported them.

Not based on my testing where I had the Eset GUI open and minimized on the desktop. I also screwed up on my above posted test and didn't run the test malware from an archive. However, it is still nice to see Eset detect .pdf malware upon file access. So I redownloaded the test malware from source as a password protected archive. This time Eset nailed it upon extraction. Again I checked this and equi.exe is immediately terminated upon close of Eset GUI on the desktop.

I restored one of my test malware from Eset quarantine. This one has Eicar imbedded in a zipped .pdf. As the below screen shot shows, only the Eset popup alert was shown and the Eset GUI did not open. So I don't know what is going on in regards to @0xDEADBEEF issue:

I couldn't duplicate the behavior also when the AMTSO desktop or wicar.org tests were run. However, those are all detected via the HTTP filter in Eset Web Access protection. I believe @0xDEADBEEF runs his malware samples from prior downloaded files? So this issue might lie with heuristic real-time scanning or perhaps possibly the new HIPS advanced behavioral modification detection.