Jump to content

Archived

This topic is now archived and is closed to further replies.

razorfancy

Eset Internet Security v11.0.159.9 update to v11.1.42

Recommended Posts

1 minute ago, Marcos said:

Is such small nfi file created even several times a day every time the system wakes up from hibernation?

No. As stated, traced the file creation to occurring only when something exits in Quarantine. Also as previously noted, Win hibernation and sleep modes are distinct and different power state modes. I believe hibernation is S3 power state which my motherboard doesn't support. My only supports S4 power mode state.

5 minutes ago, Marcos said:

Do you run scans with Windows Defender?

WD is totally disabled on my PC. That includes the optional periodic scanning feature.

Share this post


Link to post
Share on other sites

Actually, I didn't answer your first question.

No, only one FNDx file is created upon first instance of return from sleep mode with something in Quarantine. Any subsequent sleep mode instances do not create a new FNDx file.

Share this post


Link to post
Share on other sites

Also, this behavior doesn't occur on regular boot mode; only standby mode - go figure?

Share this post


Link to post
Share on other sites

Correction - S4 is hibernate which my PC only supports; states S1-S3 are lesser power saving modes: https://msdn.microsoft.com/en-us/library/windows/desktop/aa373229(v=vs.85).aspx

I also noticed that Win 10 installation is missing the hyberfil.sys. Wonder if that could be a factor in this Eset behavior?

Share this post


Link to post
Share on other sites

Upon further checking and reflection, I manually disabled hibernate mode in Win 10. Hence, no hyberfil.sys.

However, my BIOS only shows S2 and S4(hibernate) states supported. I wonder if Eset processing is getting "confused" upon resume from sleep and is looking for hyberfil.sys to determine Quarantine file submission to LiveGrid. Since that file doesn't exist, it somehow is interpreting that the file in Quarantine was never submitted to LiveGrid?

Share this post


Link to post
Share on other sites

@Marcos, here is what I believe is going on in ver. 11.1.

LiveGrid appears to set a flag in Quarantine files to indicate they have be previously scanned by LiveGrid. If one of those files gets inadvertently resubmitted to LiveGrid as is now occurring upon resume from standby,  LiveGrid servers reject it since the file indicates it has already been scanned. However, local LiveGrid processing is expecting a response from the LiveGrid servers. So local LiveGrid processing goes into a loop awaiting a response that will never come.

Share this post


Link to post
Share on other sites

@Marcos, I found the "culprit." And it is full hibernation mode in regards to ver. 11.1.

Procedure for diagnosis is as follows:

1. Enabled hibernation setting in Win 10 1709. This results in the following default settings being applied:

  • minimal size(approx. 3GB) hyberfil.sys created
  • hybrid-sleep mode enabled. That is, BIOS power mode setting in the S1-S3 range. Current OS RAM settings will be maintained in sleep mode. System will powered off down in S3 powered mode setting. Win OS performs "fast" boot procedure upon system power up from previous shutdown.
  • Verified my Gigabyte motherboard BIOS power mode setting is now set to S3.

Now there are no issues with LiveGrid constant polling activities upon resume from sleep mode when any files are present in Quarantine with or without malware submission enabled.

Appears that LiveGrid developer in ver. 11.1 is somehow doing a compare to previous system "state" to current state upon resume from standby in regards to items in LiveGrid's Quarantine. As long as there is no change in that state; i.e. settings maintained in memory, there are no issues.

I will state that many notebook users have full hibernation mode enabled. Also many users disable Win 10 hibernation option since it conflicts with their existing PC hardware. Finally as noted previously, many BIOS's will default to full hibernation S4 mode to support Windows standby processing when its hibernation mode is disabled.  

Share this post


Link to post
Share on other sites

@Marcos, where is Eset's quarantine directory supposed to be located in ver. 11.1?

The only ref. I have on my PC to an Eset "quarantine" file is here: C:\Users\xxx-xxxx\AppData\Local\Packages\windows_ie_ac_001\AC\ESET\ESET Security\Quarantine. It has a creation date of 2/18/2018 which proceeds any original ver. 11.1.42 release I believe. How the hell that directory ended up in IE11's package directory is totally beyond me. 

Share this post


Link to post
Share on other sites

Any updates on this problem?  Maybe add a new capability to revert to last installed version.  This has gone on a long time.

Share this post


Link to post
Share on other sites
6 hours ago, itman said:

The only ref. I have on my PC to an Eset "quarantine" file is here: C:\Users\xxx-xxxx\AppData\Local\Packages\windows_ie_ac_001\AC\ESET\ESET Security\Quarantine.

Never seen it in user's AppData\Local\Packages folder. It should be in C:\Users\%USER%\AppData\Local\ESET\ESET Security\Quarantine and C:\Windows\System32\config\systemprofile\AppData\Local\ESET\ESET Security\Quarantine. This hasn't changed since ESET v2 if I remember correctly.

Share this post


Link to post
Share on other sites
2 hours ago, 1222tmiller said:

Any updates on this problem?  Maybe add a new capability to revert to last installed version.  This has gone on a long time.

Please clarify as to what issue you are having with v11.1.42.

Share this post


Link to post
Share on other sites
6 hours ago, Marcos said:

Never seen it in user's AppData\Local\Packages folder. It should be in C:\Users\%USER%\AppData\Local\ESET\ESET Security\Quarantine and C:\Windows\System32\config\systemprofile\AppData\Local\ESET\ESET Security\Quarantine. This hasn't changed since ESET v2 if I remember correctly.

Just when you think "you've seen them all," this one "defies imagination."

What was actually stored in my C:\Users\xxx-xxxx\AppData\Local\Packages\windows_ie_ac_001\AC\ directory was a shortcut in the format of "ESET\ESET Security\Quarantine" as target directory and %LOCALAPPDATA% as target location. Then to "top it off," the Quarantine directory was missing from C:\Users\%USER%\AppData\Local\ESET\ESET Security\ directory.

How the heck this all happened is beyond me. It also a bit distressing that the Eset installer doesn't verify that this directory, Quarantine, does not exist under, C:\Users\%USER%\AppData\Local\ESET\ESET Security\.

So this finding might very well be the root of the LiveGrid looping issues I have been posting about. Suspect LiveGrid was expecting to find the malware in C:\Users\%USER%\AppData\Local\ESET\ESET Security\Quarantine. When it could not, it basically went into a loop expecting it to appear at some time.

Share this post


Link to post
Share on other sites
40 minutes ago, itman said:

So this finding might very well be the root of the LiveGrid looping issues I have been posting about. Suspect LiveGrid was expecting to find the malware in C:\Users\%USER%\AppData\Local\ESET\ESET Security\Quarantine. When it could not, it basically went into a loop expecting it to appear at some time.

Quarantine per se has nothing to do with LiveGrid whatsoever; there's no correlation between these two features. The quarantine folder should be created the first time a file has been quarantined.

Share this post


Link to post
Share on other sites
3 hours ago, Marcos said:

Quarantine per se has nothing to do with LiveGrid whatsoever; there's no correlation between these two features.

Not from what I have observed. I do believe I now have things straightened out though. 

For starters, there was a .NQI fil from yesterday testing in C:\Windows\System32\config\systemprofile\AppData\Local\ESET\ESET Security\Quarantine which I deleted to get a "clean slate." Again, previously the shortcut was deleted from the IE app folder and the Eset User app directory Quarantine folder restored.

Now what I am observing is proper Eset quarantine processing as follows. I went to the wicar.org file and tried to download a couple of samples. Guess what? Nothing stored in quarantine as should be since the samples were detected upon download and deleted per realtime "strict" policy. Next I went to the eicar.org web site and copied the test malware string. I then pasted that string into a .txt file using notepad.exe. I then attempted to save the file. Bingo! Eset realtime scanning detected it and placed it into the User\AppData\Local\ESET\ESET\Quarantine folder as expected.

It appears to me there is a processing relationship between the .NQI file in C:\Windows\System32\config\systemprofile\AppData\Local\ESET\ESET Security\Quarantine and the malware sample stored in the User\AppData\Local\ESET\ESET\Quarantine folder. This makes sense since further LiveGrid server analysis will confirm the sample as malicious or benign or simply to upload the sample if LiveGrid malware submission option is enabled. In any case, the fact that the malware sample was not stored where it was supposed to be I believe was the root cause of this polling behavior.

I will continuing monitoring for any further LiveGrid polling activity but am fairly confident the issue is resolved.

Share this post


Link to post
Share on other sites

@Marcos, I believe this is the source of the problem in regards to LiveGrid polling activities.

Its source is the AMTSO Cloudcar test, IE11, and Eset's interaction between the two. Of note is the following:

  1. In a security "sometimer's moment," I failed to realize that Eset changed malware submission in vers. 11.1. That is the suspicious malware category settings are independent of the detected malware setting. Disabling the detected malware setting still leaves the suspicious malware category settings enabled. To date, I had the suspicious malware category settings enabled.
  2. In vers. 11.0, I now remember I had all malware submission settings disabled. As such, this issue might have existed previously but never manifested.

In regards to Eset's detection of the AMTSO Cloudcar test download detection are the particulars:

  1. In IE11, it appears Eset detects the main cloudcar.exe download and generates an alert that the file has been detected and deleted.
  2. However, IE11 displays its download popup with the options to; Open, Save, or Cancel. Prior testing I performed in regards to selecting "Save" at this point will result in a "stub" clouldcar.exe file being created in the Download folder. By stub, it appears this file might just contain PE header data or the like. However If "Cancel" is selected, this stub file is not created.

It is at this point that LiveGrid's detected malware storage and submission processing gets "borked." The possible explanations are:

  1. LiveGrid stores in C:\Windows\System32\config\systemprofile\AppData\Local\ESET\ESET Security\Quarantine the actual cloudcar.exe file that was detected. Or, it may in fact be storing the stub file located in IE's download buffer area.
  2. Nothing at this point exists in C:\Users\%USER%\AppData\Local\ESET\ESET Security\Quarantine. This might be design; at LiveGrid file submission time the sample in systemprofile\AppData\ is copied to \%USER%\AppData\Local\. I did visually verify this transfer is not occurring at any time. 

It appears to me, LiveGrid Quarantine processing and subsequent sample submission maintains a reference to where the file was originally was supposed to be located for possible restoration purposes. It also appears that this relationship is "borked;" possibly due to the stub cloudcar file existing in IE's buffer area. In any case, when LiveGrid tries to submit the clouldcar.exe suspicious file sample stored, it can't find what it needs to either upload the sample, or "gets confused" to where it is located. The end result is a either a never ending LiveGrid submission or reply from LiveGrid server's processing loop.

The remaining mystery is why this behavior appears to only occurring upon resume from a system initiated standby. Possibly Eset's AMS scanner detects the cloudcar.exe stub file in memory or something on this order. 

Share this post


Link to post
Share on other sites

@Marcos, glad to report that it appears the problems have been resolved. Time will tell, but at this time things are looking good.

What I did was a clean install. And I mean clean. I used Revo Uninstaller Pro to uninstall the current 11.1.54 ver. and clean out all Eset traces prior to a reboot. I them manually inspected the disk for any traces and removed any residuals. Next, I used regedit to remove any Eset traces in the registry. Next rebooted. Then I downloaded Eset's online installer. Ran that which downloaded Eset Internet Security and updated it to ver. 11.1.54.

The stuff from previous Eset installations were a bit unbelievable. Like Eset registry....cfg entries under Smart Security folder in CurrentUser\AppData\Roaming directory versus those entries now stored in Eset's C:\ProgramData\ directory. In fact now, nothing Eset-wise exists in CurrentUser\AppData\Roaming directory. It appears ver. 11.1.54 now keeps a complete duplicate of its  C:\ProgramData\ directory in AllUsers\AppData\ directory. Most interesting is that nothing quarantine-wise exists in CurrentUser\AppData\Local\ directory. Only thing there is an empty Eset\Eset Security folder.

What I have learned is Eset's "on top of" existing installation upgrades do not properly remove residuals of prior Eset installations. 

Share this post


Link to post
Share on other sites

@Marcos, well it didn't take long for the LiveGrid "loop-d-loop" baloney to start up again. But this time, it appears to be at least partially justifiable.

The "loop-d-loop" baloney started up at approximately 4:40PM yesterday. At this time I had IE11 open for some time web surfing. I believe the following activity is what triggered LiveGrid.

I was browsing this malware repository site: https://t.co/4LAh4rmKri in search of a MD5 hash for the malware listed there. Had trouble copying the hash from that web site so I opened IE11's Inspect Element feature which I have used many times in the past to copy the MD5 hash from there. Why any of this would have triggered a LiveGrid suspicious submission is beyond me.

Anyway, I let the LiveGrid "loop-d-loop" baloney run for approx. 4 hours to see if it would resolve itself. It did not. So I killed off the FND0 file that I am attaching. Again, all the previous noted AMTSO desktop test detections were still present in Eset's Quarantine including the Cloudcar suspicious file detection. 

FND0.NFI.txt

Share this post


Link to post
Share on other sites

@Marcos, I will begin with this. How many times have I posted in this thread I think I resolved the LiveGrid "loop-d-loop" issue? I have lost count. Anyway, this time I think it is resolved.

To begin, my previous clean install was not that clean after all. I had forgotten to disable "hide operating system files" when I had scanned for Eset Quarantine file residuals. When I did that, "low and behold" there was a reference to a shortcut for %APPDATA%\Usesr\xxxx\Roaming\ESET\ESET Security\Quarantine. I could not establish what that ref. was, but deleted it since the shortcut no longer existed. Thought that would resolve the  LiveGrid "loop-d-loop." It did not.

So this time I "bit the bullet" and used Eset's Uninstaller utility. I was reluctant to do so since when used previously on Win 7, it did bork my network connections and restoring them per Eset save instructions did not restore them. This really isn't an issue on Win 10 since they have a built-in network stack restore feature. But "once burnt" is always burnt in my playbook.

Anyway, reinstalled ver. 11.1.54; btw your download servers are presently really ....... slow. This time, I let Eset do the full scan prior to importing my previously saved 11.1.54 settings. BTW - I verified those had no "wayward" Eset Quarantine file location refs. While the scan was going on, I could see a bunch of FNDx files beginning created in C:\ProgramData\ESET\ESET Security\Charon directory. So far so good, no LiveGrid "loop-d-loop."

When the initial Eset scan completed, I then imported my previous Eset settings. Those had both detected and suspicious malware submission disabled along with statistical submission. Whalla! Immediately there was this huge LiveGrid download that in turn wiped out two thirds of the FNDx files. I assume these were the previously submitted suspicious file detections. Still no LiveGrid "loop-d-loop." Looking good ..........

Later, I restarted and observed the remaining assumed statistic FNDx files were deleted upon boot completion. Looking great! Did some more test sample malware downloads and now could see actual LiveGrid connections to tsmxx servers with no FNDx file creation. So and "knock on wood," LiveGrid reputational scanning is working w/o issue.

BTW - the  %APPDATA%\Users\xxxx\Local\ESET\ESET Security folder still exists from the previous 11.1.54 install and was not deleted by Eset's Uninstaller nor, recreated in the subsequent installation. So I will probably delete it lest Eset "get's confused" in any subsequent ver. update activity. Appears the only Quarantine directory that exists in any fashion in ver. 11.1.xx is C:\Windows\System32\config\systemprofile\AppData\Local\ESET\ESET Security\Quarantine with interim encrypted storage done via FNDx file in C:\ProgramData\ESET\ESET Security\Charon directory. Also in ver. 11.1.xx, no Eset directories or files are created in %APPDATA%\Users\xxxx\* directories other that a copy of Eset's directory stored in C:\Program Data moved to %APPDATA%\Users\All Users\ESET\.

Finally, I cannot emphasis the importance of anyone installing ver. 11.1.xx to use the Eset Uninstaller utility first prior to its installation.

Share this post


Link to post
Share on other sites

@Marcos upon further reflection, I can tell you exactly where the bug is in regards to LiveGrid.

To begin with and applicable to all I have posted to date, it only will manifest in IE11 I believe, and only if F12 Tools functions are used such as Inspect Element that I described previously. Appears the LiveGrid developer inserted debug code into the old version of Smart Security that was superseded by Internet Security. If the Inspect Element function was used, a shortcut was created in C:\Users\xxxx\AppData\Local\Packages\windows_ie_ac_001\AC\ that pointed to %APPDATA%\Usesr\xxxx\Roaming\ESET\ESET Security\Quarantine. Also a link to that shortcut was stored in some unknown system file external to Eset installation directories or files. Also and most important, it appears this debug code is external Eset installation areas since the behavior persisted upon each reinstallation of Eset.

When Internet Security is installed on top of Smart Security, the above debug code still remains in place. All was fine until vers. 11.1.xx was introduced that no longer stores any LiveGrid file submission data in %APPDATA%\Usesr\xxxx\ files. If IE11 F12 functions are used in ver. 11.1.xx, it will cause LiveGrid to go into an endless loop since the data it is looking for in %APPDATA%\Usesr\xxxx\Roaming\ESET\ESET Security\Quarantine does not exist but rather now is stored in a FNDx file.

As best as I can determine the above referenced debug code not does exist in Internet Security versions in regards creation of the shortcut and references to it. I state this because no shortcut is created in C:\Users\xxxx\AppData\Local\Packages\windows_ie_ac_001\ACwhen F12 tools are used with Internet Security installed. However, my testing showed that the old Smart Security debug code can be triggered in ver. 11.1.xx when the Inspect Element function is used. It appears the only thing that fully resolves this mess is to use the Eset Uninstaller tool and then install ver. 11.1.xx.

Share this post


Link to post
Share on other sites

@Marcos, I encountered another instance that will cause LiveGrid to "run amock." This one will also shed some like on past behavior I have seen.

I inserted a CD-ROM that contained an old copy of Paragon Backup Pro disk imagining software I use. This disk is bootable and also contains an old Win PE installation on it. Obviously, this can't run from Windows but want to see how LiveGrid would respond to it.

The Eset popup appeared and asked if I want to scan the disk. I selected decline. LiveGrid sent to its servers a small FNDx file I am attaching. Believe we have seen this one before via my prior attachments. LiveGrid then went into a loop waiting for a reply on the transmission. After approx. a minute or so, I see an incoming transmission from LiveGrid of a single packet or 512 bytes. I assume this was LiveGrid's determination data that CD was OK. Shortly thereafter, LiveGrid loop connections one by one disappear. So far so good. Except for ………. the fact the FNDx file was not deleted. Upon reboot and as expected, LiveGrid went into endless "loop-d-loop" due to the existance of the FNDx file.

It appears to me that this small FNDx contains LiveGrid registration data. It is created usually at Eset installation time I believe and possibly reverified upon each LiveGrid startup after system restart . When done so, no LiveGrid looping issues occur if the installation itself is "a perfectly clean" one. However, the same activity can occur after Eset installation as I have illustrated. When that happens, LiveGrid "goes bonkers." What might have been causing this to occur on my prior noted Eset installations that had issues was I also run a Win 7 and 10 dual boot configuration with Win 10 the default boot OS. My best guess is LiveGrid was somehow picking up the Win 7 installation at boot time and sending registration data on it instead of the Win 10 installation which had been previously registered.

Let the LiveGrid developer ponder this one for a while.

FND0..txt

-EDIT- I forgot to mention that that subsequent reinsertion of the CD-ROM disk did not trigger any LiveGrid dial-out behavior. This indicates the LiveGrid server registration data is stored locally. So all the developer has to do is ensure the FNDx associated file is deleted.

Share this post


Link to post
Share on other sites

@Marcos, I found my major issue with LiveGrid. It was a corrupted CACHE.NDB file. I'll leave details on that for a latter posting. There is a more pressing matter that Eset needs to immediately address.

I found what is causing the Eset LiveGrid server connection looping. Each day at approx. 3:50 EST or so, It appears that Eset takes the LiveGrid servers off-line for maintenance, whatever. To ensure continued LiveGrid  protection, Eset creates the small FND0 file whose sole purpose is to force a loop connection to Eset alternate servers while the main LiveGrid servers remain off line. After a period of time, the LiveGrid servers go back online. This status can be verified by ekrn.exe starting its loop activity via its proxy 0.0.0.0 connection to LiveGrid DNS servers. The problem is that whatever mechanism Eset is using to terminate the alternate LiveGrid polling activity is not working. The polling activity will continue indefinitely eating up network bandwidth and system resources. The only way to stop this activity in ver. 11.1.54 is to delete the FND0 file and reboot.

This issue needs to be fixed immediately!

Share this post


Link to post
Share on other sites

@Marcos, I fixed my LiveGrid issues. They were due to the changes I made to Windows system default settings. Since I assume you know what those were, no need to elaborate.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...