itman
-
Posts
12,466 -
Joined
-
Last visited
-
Days Won
329
Posts posted by itman
-
-
Mystery solved as far as I am concerned. Also my previously posted suspicions were confirmed.
Today at first cold boot, I purposely waited approximately 30 secs. to logon to Win 10. When the desktop initialized, the Eset GUI icon was present on the lower toolbar and Eset had completed its update at logon task. I then opened the Eset GUI, the home page did indeed show last update was 12 hours ago. I then within the GUI went to the Eset logs section and opened the Event log. It indeed showed Eset was updated a minute ago. I then returned to the Eset GUI home page and it now showed the time of last update was a minute ago.
Appears the Eset home page last update time for some reason is dependent upon internal GUI access for updating at system startup time. Why, I really don't know. One possibility is the Eset update successful popup screen triggers an update to the last update time on home page. I really believe this is such a minor issue most will never notice it.
-
10 hours ago, novice said:
If you open "You are protected" screen, on the left lower corner says "last update 12 hours ago". However, if you go to "update" screen , the last update was "29 min ago"
When you return to the "You are protected" screen , now the time displays correctly. But on initial check, always the time is wrong.
What I am wondering is this is tied to how fast the Eset update is performed at boot time.
For example when I boot, the Eset update always completes after the desktop is fully initialized and the last update time is correct on the Eset GUI home page. However lets say you boot and then "dilly dally" at the Win logon screen for a while. You then eventually sign on. By that time, the Eset sig. update has been completed. When one then displays the Eset GUI home page is the last update time correct?
-
Well one issue with the Comodo firewall is it certainly isn't to specific in its source application identification. For me, Windows Operating System means possible two things. It's either what is referred to as "System;" i.e. ntoskrnl.exe or svchost.exe. Why you would be receiving that volume of blocked inbound connections from System is a mystery unless its NetBIOS related although the destination ports don't indicate that.
If you're satisfied with Comodo, by all means stay with it.
-
Ecmds.exe among other things is used to start the Eset GUI process. If that is not started or functioning properly, well a lot of things in Eset could be borked.
Another thing I strongly advise is you go to this web site: https://www.amtso.org/feature-settings-check-for-desktop-solutions/ and ensure Eset detects all the tests given there; especially the non-archive ones.
-
One more thing to check. Eset's firewall uses the Window Filtering Platform. Regardless of if the Network option to also use Windows firewall rules is enabled, elements of the Win Firewall are used.
In your Win Event log, check the Audit Failure log section for blocked network connections. My experience has been that anything blocked by the Eset firewall also shows in this log. Although I have also seen Win firewall blocks not related to Eset firewall blocks show there; especially at boot time. However, I also have the Eset option to use inbound Win firewall rules enabled.
-
One last thing to check. See if Eset Troubleshooting wizard shows a non-zero count per the below screen shot:
-
Eset's event logging has a few "quirks." Without getting into that, do this as a test. For one of your block rules that you feel you should be seeing Network log entries for, set the logging severity to "Warning." If you now start seeing Network log entries for that rule, set the logging severity likewise for your remaining block rules and your problem is solved.
-
14 hours ago, novice said:
Still update time doesn't display correctly on the main screen....
My best guess at this point is there is a bug in NOD32. This behavior does not manifest on Internet Security.
What we need is other NOD32 users to confirm it is happening to them. I suspect most users don't pay any attention to the update time displayed on the Eset GUI home screen. I didn't until you brought up the issue.
-
Off the top of my head, I would say it has to do with the fact the Eset firewall is stateful. It will only monitor inbound Internet activity for which a previous outbound connection was made. In the absence of explicit firewall rules to allow select inbound non-stateful Internet traffic, the inbound connections will be automatically dropped. The previous is evidenced by looking at the default Eset firewall rules. Of note is there is no default rule at the bottom of the rule set that explicitly blocks all inbound traffic.
In my case, I use a router that deploys a stateful firewall. So all unsolicited inbound traffic is dropped at the network perimeter.
-
Refer to the below screenshot. Check a device that was upgrade to ver. 12 and verify if the LiveGrid feedback setting is enabled. I can't recollect if the feedback system option existed in ver. 11. I believe it did not. If it didn't exist in ver. 11 whether it is enabled in ver. 12 might be dependent upon what feedback settings were enable in regards to the Submit options listed. Or the issue is at least one of the Submit options need to be enabled.
For a test, you could set the LiveGrid settings to default values; i.e. click on the circular arrow symbol across from "Cloud-Based Protection", on a device showing the popup screen you posted and see if that eliminates thereafter, the popup from appearing on the Eset GUI home screen.
-
2 hours ago, isam said:
the eset starts as it should start but the splash screen of eset made me realize that Firefox start is due to the eset start and not by it self or by any windows settings made to change how Firefox start ( I didn't modify Firefox)
So disable Eset's splash screen and see if that stops Firefox starting.
Again how the splash screen could be in anyway related to this really makes no sense at this point. The appearance of the splash screen has nothing to do with the base start up of Eset. That is done during the system boot phase. In other words by the time your desktop appears, Eset's kernel process is running already. I believe the slash screen is related to the starting of Eset's GUI processing as evidenced by the appearance of the Eset icon on the desktop lower toolbar.
I would suspect the "culprit" might be that graphical thing on your desktop containing the desktop icons? that is displayed right above the desktop lower toolbar whatever that is.
-
Based on what was originally posted, it appears there is an issue with the Eset splash screen and Firefox starting at the same time. Why really is beyond me. I suggest the following:
1. Disable the display of the Eset splash screen in the Eset GUI Interface settings.
or
2. Disable the startup of Firefox at boot time.
-
You need to clarify what this means "for computers I do not want to ever go online."
Assumed is you are using Win Updates to keep your OS patched and up to day. Also if you are running Win 10, it is connecting to the Internet for Store app updating and diagnostic data transmission.
Bottom line - Eset's web proxy filtering is monitoring all Internet connection activity; not just browser activity.
-
Eset has behavioral signatures that work very similar to YARA detection. You can read about YARA here: https://securityintelligence.com/signature-based-detection-with-yara/ . Basically select process behavior in the form of a rule is encoded in the signature.
Additionally, Eset's HIPS also has predefined rules to monitor process activity against sensitive system areas such as the Windows directory and registry.
Finally Eset has AMS, advanced memory scanning, that is monitoring a process's memory areas for malicious code that may be injected.
Eset did very well in this test beating out Kaspersky in overall malware detection.
-
I also have a Eset signature update issue. When I log off of Windows for an extended period of time and then log back in, Eset does indeed check for updates. However, I receive no update. Nor is one served up if I check manually. I has been 5 hours since my last sig. update. That doesn't seem right to me.
-
Well, a DSL connection, Ethernet or wireless is established as soon a Windows network connection is establish as part of the Windows boot process. Now there are a few routers that actual do have a type of DSL "dial up" network capability. A while back I had a Netopia commercial grade router that had that option along with some other neat stuff like honeypot capability.
-
On 11/12/2018 at 7:04 AM, Fiona said:
How can I put a wild card into the IP? I have tried blamnk, * and a range of 0.0.0.0 to 254.254.254.254 and nothing works.
You can't. The Eset firewall rules don't support wildcards.
The Eset default firewall rule only allows inbound traffic for RDP, port 3389, for IP address listed in the Trusted Zone. For the internal network device you wish to connect to, you can add the IP address for each external device to its Trusted Zone. I believe this is only feasible if those external devices have static IP addresses assigned.
Note: doing so will then activate all Eset default rules that allow inbound Trusted Zone traffic to be applicable to your external devices.
-
35 minutes ago, galaxy said:
@itman You do a great job that I just want to praise and ... thank you for all the help. Nice that you are so actively helping here. Thank you
You're welcome.
-
One final comment about this Search Service.exe sample that most might have not noticed.
Cloudstrike Falcon at VT detected it as 100% malicious. Assumed is the Falcon sandbox is not deployed at VT and only machine learning heuristics were deployed. However the analysis at Hybrid-Analysis does deploy the Falcon sandbox allowing for a more thorough process analysis. That analysis yielded a 89% malicious confidence rating.
Now lets factor the other known variables involved. This does not imply that there are other unknown ones involved:
1. An unknown and unsigned process created in a Windows directory.
2. A Windows autorun mechanism created to run the process at system startup time.
I really believe that at a minimum, Eset should have thrown a suspicious alert on this one.
-
1 hour ago, Marcos said:
1, Update at logon has always been disabled by default:
I still believe there is a bug in NOD32. Notice in the screen shot you posted, the like dial-up option is enabled instead. Virtually no one uses a dial-up connection these days.
-
There are at least 42 variants of Gen:Variant.Mikey.24795 going back to 2015: https://totalhash.cymru.com/search/?av:Gen*Variant.Mikey.24795 . Average VT AV vendor detection is around 50% for these.
Below are some of the variants that Eset detected in the past. I did not check all of the 42 variants for Eset detection:
https://totalhash.cymru.com/analysis/?5485d4ada205b0feddf559da044d41f048dbe177
https://totalhash.cymru.com/analysis/?6c63f84bb0363fa01a70d580b8c122e743eaa36d
https://totalhash.cymru.com/analysis/?3371cb7e337bf3da285e851026dbcd37f7382913
-
As far as this goes:
QuoteWhy "update at logon " is disabled by default???
It is enabled by default in Internet Security. It might not be for NOD32. So I would create a support request and report it as a bug to Eset.
Also for Internet Security when the update at logon occurs, the Eset GUI startup screen does show that the update occurred; i.e. Last Update xx minutes ago, if with the current hour.
-
7 hours ago, Johnny Wan said:
The issue happens because we block traffic to outlook.office35.com
I also don't understand the above statement. If you are blocking outlook.office365.com connections, why is Firefox showing that indeed a connection was made?
-
29 minutes ago, novice said:
1, Why "update at logon " is disabled by default???
It isn't. You must have somehow disabled it.
ESET Internet Security V12.0.27 possible bug
in ESET Internet Security & ESET Smart Security Premium
Posted · Edited by itman
Posting OS ver. used really is necessary to properly diagnosis this.
On Win 10 Home x(64), I never have had an issue with it opening the Win 10 system win update check screen.
My main complaint about the feature is it appears to be triggered by the Win 10 system update checking and is not sophisticated enough, or is not programmed, to wait to see if the update was actually done automatically. In other words, the Eset notification should only appear if the Win update was not installed.