Pre-release updates have caused issues with my Win 10 build in the past. As a result, I never have the option enabled. I believe Eset's stance is to only use them after a quick problem fix has been pushed to the servers and you want an immediate solution to the issue you are having. Now that Eset has moved to PICO module updating which can be pushed at any time, I really think pre-releases will only be used for complete version upgrades.
A note of reminder for ESET users who may not have experienced this, or may not have even checked to see if it has happened... sometimes upgrades will change some of your personal settings. I know, it's not "supposed" to happen, but it does. Having experienced this more than a time or two over the years, I now update one machine, then carefully compare all configurations to the machine that has not been updated yet. Yes, this is a very time consuming way to go about it, but I have learned that this is what I must do if I want to be sure that none of my settings have "reverted" to a default.
A question_ I recently installed v11 to see how it ran on my machine and it automatically started a scan which was still running over two and a half hours later. Is this normal? Is this just an initial scan and any further scans are of a more normal time span? I have been using EAM for years and my license is almost up but I am hesitant to renew as it seems to be getting too dumned down for my liking.
Are these changes random or do they follow a pattern? Anything like this reported the other day? They mess up things sometmes. Import or export ESET configuration settings using an .xml file
Welcome. Sorry, I haven't kept track over time precisely what changed, but with certainty I can say that settings do seem to revert to default every now and then. Great suggestion, and will do next time. TY!
@Minimalist Hi Minimalist, May I ask you a question about a post you made in a CCleaner thread. My question is not about CCleaner but about Eset's HIPS. Your post: https://www.wilderssecurity.com/thr...rust-alternatives.396801/page-16#post-2789362 May I ask: Was that default HIPS setting, or an advanced setting (which "modus" of HIPS)? If not default, which exact rule(s) did you use to get those warning(s)? Many thanks in advance.
In other words, was a user HIPS rule created to monitor modification in this registry area? Or did Eset HIPS trigger this alert w/o one?
No I didn't create any specific HIPS rule. All I did was changed filtering mode from Automatic to Smart. Maybe in that mode HIPS is configured to ask user about changes to that registry key.
Eset "beefed up" a lot of internal stuff in ver. 10. Nice to see HIPS Auto mode detections were one of them. MalwareBytes has a good article on AutoURLConfig hijacking here: https://blog.malwarebytes.com/detections/hijack-autoconfigurl/ As to whether anyone should trust CCleaner anymore, I though that answer was rather obvious.
@FanJ You're welcome @itman - I've read about those hijackers in past. Personally I don't think that CCleaner ( and uTorrent also ) wants to hijack proxy settings in this case. Both of them try to delete that registry key and not modify it. Still it's disturbing to see software performing such actions without exactly knowing why would they try to do this.
Perhaps the question is why AutoConfigURL value exists in the HKEY_CURRENT_USER\S-1-5-21 ....\Software\Microsoft\Windows\ CurrentVersion\Internet Settings registry key? It does not on my Win10 x(64) 1803 build. There is however a subordinate reg. key there named Wpad. Perhaps this is something uTorrent does? https://securelink.be/blog/windows-proxy-settings-explained/
Hi @itman and @Minimalist, Am I now misreading or misunderstanding things? Minimalist wrote: "All I did was changed filtering mode from Automatic to Smart".
It doesn't exist on my system also. It looks like both programs try to delete that key just in case it did exist.
Let's backup a bit. The Eset alert you received indicated CCleaner was trying to "access" this registry key. How did you verify that CCleaner was actually trying to delete the registry key? Did you verify this using Process Monitor log? Eset HIPS in regards to registry access has the following options: Delete Rename Modify It additionally has a option for monitoring of reg. keys associated with startup areas such as run keys and the like. Finally and I believe applicable in this case, it has an option to monitor all registry access against a specific registry key. All registry access would include any attempted key read or creation access. What I believe occurred is CCleaner was attempting read access to the registry key in question to verify if it existed. Why, I have no idea. This is what the Eset default HIPS rule detected. It appears Eset will only allow access to this registry key by select system and app processes; most likely trusted apps that can establish a proxy. One other important point to note that I discovered through testing. The Eset HIPS cannot prevent a specific reg. key value from being created, modified, etc.; at least in prior versions it couldn't. I haven't tested same in ver. 12. This means the above stated monitoring actions apply to HKEY_CURRENT_USER\S-1-5-21 ....\Software\Microsoft\Windows\CurrentVersion\Internet Settings only; not to any specific activity in regards to AutoConfigURL value contained within. In other works, any reg. key access of HKEY_CURRENT_USER\S-1-5-21 ....\Software\Microsoft\Windows\CurrentVersion\Internet Settings would have triggered an alert.
But the question might be whether it is a wise decision to use it in all circumstances, maybe in particular after an upgrade (new version). Let's say a new version is released. Before installing it you export your ESET configuration settings (using an .xml file). You install the new version. Then you import your saved configuration from the previous version into the new version. But maybe ESET has made changes in the configuration that you don't want to miss. Little example: About LiveGrid in version 11.0.159 : see replies 80 - 85 in https://www.wilderssecurity.com/threads/eset-nod32-v11.397505/page-4 There was a small issue because the option "Turn off "ESET LiveGrid is not accessible"" was missing. Later it was corrected in version 11.1.42. See https://www.wilderssecurity.com/threads/eset-nod32-v11.397505/page-6#post-2745515 If you would have imported your config settings from 11.0.159 into 11.1.42 then you would have missed this correction, I guess .... Am I now right or wrong? PS: you could export your config settings before and after the upgrade into two different .xml files and compare those two files (for example with BeyondCompare or any other comparing tool).
Overall, there usually isn't an issue. What you have to watch out for is when Eset does a major redesign to the GUI as happened in ver. 10 with the "Metro" formatting. This caused all existing ver. 9 HIPS rules to become invalid to internal formatting changes. And what really sucked was Eset never did provide a converter for these old ver. 9 rules. If you had existing ver. 9 HIPS user rules, they all had to be entered again manually.
Hi, OK, so do I understand you right that even for that small example I gave about the LiveGrid issue I gave, there wouldn't have been an issue? Do I understand you right that even after importing the config settings from version 11.0.159 into 11.1.42 you would still have the missing option "Turn off "ESET LiveGrid is not accessible"" (missing in 11.0.159) in 11.1.42 (in which it was fixed). I can hardly believe it, but I haven't tested it, so I could be wrong. Is that what you're saying? Am I misunderstanding you (which, of course, could be possible!)? (yes, I know, it was only a little example).
It depends on how you look at the issue. I assume Eset purposely eliminated the option since it is a security feature. That is to warn if there is an issue with LiveGrid connectivity. On this issue, I never did fully understand what the problem was since I have never experienced it; at least on a persistent basis. I believe the "fix" was to now only notify when LiveGrid is not accessible for a long period; like an hour or so. And frankly, I don't believe that was the correct thing to implement.
Hi itman, Your thoughts are always appreciated. I guess so, yes. It was more of an example. I wanted to raise the question whether it is always, in all circumstances, a wise decision to put back a previous config .xml file, in particular after a version upgrade.
No I didn't use Process Monitor to log what was happening in background. You can check my screenshot in this post: https://www.wilderssecurity.com/thr...rust-alternatives.396801/page-16#post-2789362 When I tried to create a permanent rule and I used Advanced options, option Only for operation: Delete from registry was already set by ESET. So by this I concluded that program tried to delete that key. In Only for target section that key was the most specific one so I don't think that any other action triggered this. From that prompt I created rule that prevents deleting that specific key by those two apps. After that I got no more prompts from ESET's HIPS about accessing or deleting any registry key.
